RLP decoding for EVM ABI compatibility

[ascjones]

Contracts written in Solidity and deployed to pallet-revive should be able to seamlessly call ink! contracts. Additionally, EVM wallets/tooling should be able to interact with ink contracts. This requires RLP decoding of ink message parameters.

The question is, when handling an invocation, how do we determine whether the data is RLP or SCALE encoded?

Proposal 1: A "magic" selector prefix for RLP encoded messages

⚠️ Showstopper. This means that a solidity contract/tooling calling an ink! contract will need to know that it is calling an ink contract and prepend the magic selector.

For determining whether input is SCALE or RLP, I have the following proposal:

1. Define a known 4 byte constant e.g 0xAAAAAAAA or similar, this denotes that the encoding will be RLP.
2. In the dispatch logic which matches by selector, check if the first 4 bytes match this constant. If so we read the next 4 bytes as the actual selector and then decode using RLP.
   This scheme allows a 99.9% backwards compatible ink! ABI, with the exception of any contracts which may already use the chosen selector constant. In the new version we can prevent users from using that.

The alternative would be to have the encoding specified as a prefix to the encoded data itself. However this would mean we lose ABI compatibility with older ink contracts and compatible external tooling. Also a possible lack of safety where the encoding prefix is incorrectly decoded as input data, or vice versa.

Proposal 2: Each entry point has 2 selectors, one per encoding

Each message/constructor has one selector for SCALE encoding (determination remains as is), and a new one for RLP encoding, which can be derived from the first.

This would ensure full backwards compatibility and also transparent calls.