[Flow EVM] Add support for ABI encoding/decoding of Solidity byte types

[m-Peter]

Closes: #5365

Support ABI encoding/decoding the following Solidity byte types:

• bytes & bytes[]
• bytes4 & bytes4[]
• bytes32 & bytes32[]

Note: A contract upgrade for EVM system contract is needed.

The test payloads have been generated with the help of: https://abi.hashex.org/

[turbolent]

Great work adding support for more types!

I had a look at the documentation at https://docs.soliditylang.org/en/latest/types.html#fixed-size-byte-arrays, and from what I understood, the Solidity bytes type (dynamic-sized byte array) is equivalent to the Cadence type [UInt8] (variable-sized array), the bytesN type (fixed-size byte-array) is equivalent to the Cadence type [UInt8; N] (constant-sized array).

Why do we need the "wrapper types", like EVM.EVMBytes4?

[m-Peter]

Great work adding support for more types!

I had a look at the documentation at https://docs.soliditylang.org/en/latest/types.html#fixed-size-byte-arrays, and from what I understood, the Solidity bytes type (dynamic-sized byte array) is equivalent to the Cadence type [UInt8] (variable-sized array), the bytesN type (fixed-size byte-array) is equivalent to the Cadence type [UInt8; N] (constant-sized array).

Why do we need the "wrapper types", like EVM.EVMBytes4?

@turbolent Let me explain this with a working example, to illustrate the differences:

let bytes4 = '0x050a0f14' // these are the values 5, 10, 15, 20 in hex
let abiEncoded = web3.eth.abi.encodeParameter('bytes4', bytes4)
assert.equal(
    abiEncoded,
    '0x050a0f1400000000000000000000000000000000000000000000000000000000'
)
    
let uint8four = [5, 10, 15, 20] // this is the same value as `bytes4` variable above
abiEncoded = web3.eth.abi.encodeParameter('uint8[4]', uint8four)
assert.equal(
    abiEncoded,
    '0x0000000000000000000000000000000000000000000000000000000000000005000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000f0000000000000000000000000000000000000000000000000000000000000014'
)

let bytes = '0x050a0f14'
abiEncoded = web3.eth.abi.encodeParameter('bytes', bytes)
assert.equal(
    abiEncoded,
    '0x00000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000004050a0f1400000000000000000000000000000000000000000000000000000000'
)

The Solidity bytes-related types, are probably used for compact encoding, compared to Solidity arrays.

Right now, we have mapped the Cadence dynamic-sized & fixed-sized arrays, to Solidity arrays:

• [UInt8] -> uint8
• [UInt8; 4] -> uint8[4]

Which means that we need to somehow control the ABI encoding/decoding of Solidity bytes-related types. That's why I've introduced the wrapper types.

• EVM.EVMBytes -> bytes
• EVM.EVMBytes4 -> bytes4
• EVM.EVMBytes32 -> bytes32

These are the most commonly used Solidity bytes-related types. I have also added support for arrays of those types. Let me know if this makes sense 🙏

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 88.15789% with 27 lines in your changes missing coverage. Please review.

Project coverage is 41.33%. Comparing base (3ba181e) to head (f067110).

Files with missing lines	Patch %	Lines
fvm/evm/impl/abi.go	82.01%	17 Missing and 8 partials ⚠️
utils/unittest/execution_state.go	0.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #6553      +/-   ##
==========================================
+ Coverage   41.28%   41.33%   +0.05%     
==========================================
  Files        2031     2031              
  Lines      145883   146072     +189     
==========================================
+ Hits        60222    60385     +163     
- Misses      79442    79461      +19     
- Partials     6219     6226       +7     

Flag	Coverage Δ
unittests	41.33% <88.15%> (+0.05%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[turbolent]

Thank you for the explanation, it makes sense now! Initially I assumed that the byte types were just aliases, but I understand now that they are independent types, to allow for more compact encoding.

Ideally we would probably like to have a type like EVM.EVMBytes<N>, which contains a [UInt8; N], and where N is a compile-time constant. However, Cadence does not support generic types in Cadence code yet.

The code looks good, and adding support for the common types makes sense. Maybe we can consider generating the code for all N 1...32 with go:generate, but we can do that later, if needed

[turbolent]

Nice!

[turbolent]

As the EVM contract change, the state commitments need to be updated as well. You can just use the new reported values as the expected values.

[m-Peter]

As the EVM contract change, the state commitments need to be updated as well. You can just use the new reported values as the expected values.

Updated in f067110

[bluesign]

Ideally we would probably like to have a type like EVM.EVMBytes, which contains a [UInt8; N], and where N is a compile-time constant. However, Cadence does not support generic types in Cadence code yet.

Out of curiosity, can we do something like EVM.createBytes<N>([UInt8;N]): EVM.EVMBytes<N> and EVM.createBytes([UInt8]): EVM.EVMBytes ?

[turbolent]

@bluesign

Out of curiosity, can we do something like EVM.createBytes<N>([UInt8;N]): EVM.EVMBytes<N> and EVM.createBytes([UInt8]): EVM.EVMBytes ?

That would be nice, and the ideal solution. However, Cadence does not support generic types defined in Cadence programs yet, and further, it only supports generic parameters which are types at the moment, there is no support for generic parameters like numeric constants yet (see e.g. "const generics" in Rust)

[turbolent]

Great work! 👏

[janezpodhostnik]

Nice!