EIP-5164: Cross-Chain Execution

EIPs
61

The MessageDispatcher method description specifies: " MessageDispatcher s MUST revert if toChainId is not supported."

This requires the smart contract to store the supported receiving chain-ids. However, please consider the following case:

  • MessageDispatcher and MessageExecutor functionalities are coded in the same smart contract
  • Dispatcher/Executor contract deployed on EVM such that the contract address is identical on each chain

In this case the executor does not need to verify that the chain-id is supported, but instead compares the sender address to the receiverā€™s own address. This is because if the address is identical, the code is identical and so the dispatcher must be supported. Without the revert ā€œtoChainId not supportedā€, we could deploy an immutable contract (without owner-keys) that can later handle messages from and to new EVM chains on which the identical contract was deployed with the same address without the need of a permissioned addition of chain-ids.

From a user perspective, the cross-chain message would be ā€œlostā€ if they enter a chain id that either does not exist or does not have the dispatcher/executor contract deployed yet. Entering a wrong chain id, arguably, is a similar irreversible mistake as if one had entered a wrong receiver address for token transfers and, hence, we might deem it acceptable.

Looking forward to get your views on this.

62

In your example, if Iā€™m understanding it correctly, there is no way for the Dispatcher to verify whether a receiving chain is supported. In that case the Dispatcher would never revert on bad chain ids, since itā€™s impossible to verify on-chain whether a message can be successfully relayed. It doesnā€™t know whether a chain is supported or unsupported.

IMO, the ideal UX is one where the Dispatcher can validate that the target chain is legal

63

Last Call

ERC-5164 has entered Last Call status! In two weeks the ERC will be finalized.