Hashing is inconsistent with respect to ethers js about ethers-rs HOT 6 OPEN

What is super bizarre is my tests with Address work fine. It is uint that specifically is giving strange results

even if there is an explanation for this , the documentation is highly insufficient and this is very confusing

from ethers-rs.

Okay i found another clue. It looks like in rust, Uint only matches JS if doing 'encode' and Address only matches if doing 'encodePacked' . The reference on JS is doing ' ethers.utils.solidityKeccak256 '. To my limited knowledge, that JS reference is doing encodePacked so i thought rust would also always be doing that. uh oh.

unfortunately, this means it is impossible for me to match hashes on a struct that has both an address and a uint. This seems like a bug... ?

from ethers-rs.

Okay i forked the code and changed it to this

'''
Uint(n) => {
/*

let mut buf = [0; 32];
n.to_big_endian(&mut buf);
let start = if in_array { 0 } else { 32 - ((n.bits() + 7) / 8) };
out.extend_from_slice(&buf[start..32]);

*/

        let mut buf = [0; 32];
        n.to_big_endian(&mut buf);
        let start = 0;
        out.extend_from_slice(&buf[start..32]);
    
    }

'''

and now it works like a charm for me. Needs some investigation for sure !

from ethers-rs.

Btw im talking abt etherscore/src/abi/encode_packed having an issue here

from ethers-rs.

This is an unfortunate limitation of ethabi tokens.
https://docs.rs/ethers/latest/ethers/abi/fn.encode_packed.html

Uint and Int tokens will be encoded using the least number of bits, so no padding will be added by default.

from ethers-rs.

Uhh so

1. encodePacked isnt encodePacked? It means something different in rust versus javascript???

And 2 ) so there is absolutely no way to do solidityKeccak256(tokens[]) in rust yet ?

🤔 i feel like these are some serious problems as they relate to applications that want to use ECRecover with rust backend

from ethers-rs.