ABI encodePacked with < 256 bit integers

[rellfy]

It doesn't seem like it is currently possible to encodePacked an integer with less than 256 bits?

Additional abi::Token types could be added to handle these values, which would be redundant for abi.encode but not the packed variant.

From packed.rs:

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

If I am reading this right, it means that the caller has no control over the number of bits the integer will be encoded as, which doesn't seem ideal as the EVM could be expecting a certain number of bits regardless of the value passed, such as for signature validation.

[ratankaliani]

Agreed, this implementation is incorrect. When encoding Uint's that are not U256 (ex. U64, U32), into_token within encode_packed does not encode the parameters correctly.

Ex.
For abi.encodePacked(uint64, uint32), this is the expected output:

uint64 authoritySetId = 4;
uint32 trustedBlock = 10;
bytes memory encodedBytes = abi.encodePacked(authoritySetId,trustedBlock);
console.logBytes(encodedBytes);

Output:
0x00000000000000040000000a

However, when invoking the same with ethers-rs, this is the output:

let authority_set_id: u64 = 4;
let trusted_block_number: u32 = 10;

let input = encode_packed(&[
    authority_set_id.into_token(),
    trusted_block_number.into_token(),
]).expect("Failed to encode packed data.");
println!("input {:?}", hex::encode(input));

Output:
0x040a

The reason this is the case is that ethabi is the library that ethers-rs uses for encodePacked, and its implementation is deprecated.

Can we move ethers-rs ABI encoding to alloy-rs, which does abi.encodePacked here?

[ratankaliani]

Honestly, would be good to use alloy-rs either way, as ethabi is not actively maintained.