Strict encoding order for ABI

[axic]

This is in reference to the ABI specification in the Solidity documentation: https://solidity.readthedocs.io/en/develop/abi-spec.html - AFAR this is the most comprehensive spec we have.

Dynamic types (such as string, bytes and arrays) are quite liberal in terms of encoding.

In short: types are encoded as 256bit slots, except dynamic types which only contain a byte offset where their encoded versions follow.

There are no restrictions about offsets or the order of these offsets, therefore it is possible to encode for example string("a"),string("b") as:

• 0...20 0...40 0...1 0...41 0...1 0...42 or
• 0...40 0...20 0...1 0...42 0...1 0...41

While this worked so far it does seem to be a risk (together with the fact that Solidity contracts accept truncated ABI inputs where the truncated parts are padded with zeroes), it definitely raises concerns when using ABI encoded input in precompiles such as in #152 and #603.

Proposal is to:

1. Introduce a specification for strict encoding (https://github.com/ethereum/solidity/pull/3047/files)
2. Enforce the strict encoding in precompiles which use the ABI encoding
3. Enforce the strict encoding for contracts

Part 3) is only a recommendation for the community as its up to the language designers to enforce this. Solidity definitely can be changed to ensure it sends only strict ABI in CALLs and could be also changed to reject non-strict inputs.

[chriseth]

Note that the specification is already strict in the way as explained above. The decoders are only a bit more flexible and allow deviations from this strict specification.

[axic]

As long as all major decoders allow deviations (actually I haven't seen restrictions on offset order in most decoders) that renders the strictness of spec of less use.

One way I see it could be enforced if a standard test suite is defined for the ABI, which has out-of-order encoding as failure cases.

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.