ERC-7786: Cross-Chain Messaging Gateway

ERCs
1

Official discussion thread for Add ERC: Cross-Chain Messaging Gateway by Amxx · Pull Request #673 · ethereum/ERCs · GitHub

9 Likes
2

What is the purpose of the return argument (bytes4) in executeMessage?

1 Like
3

This is to mitigate selector clashes, to make sure the receiver acknowledges the protocol it’s engaging in.

2 Likes
4

What would be an example of an attack / things going wrong if the Gateway does not check the return value of executeMessage?

1 Like
5

I think I get it now, this is for ensuring that the Destination Gateway only can call the executeMessage function of the receiving application and not something else.

1 Like
6

I love this ERC!

This ERC uses a ‘push’ mechanism rather than a ‘pull’ mechanism for messaging. In my mind, a ‘push’ mechanism like the one described essentially uses a ‘pull’ mechanism under the hood - Whoever is calling the executeMessage function is pulling the message from the Destination Gateway. I don’t think there’s anything wrong with either approach; I just find it to be a useful mental model.

1 Like
7

Links to reference implementation with Axelar Network and audits:

1 Like
8

ERC contains this text: “The sender account (in the source chain) and receiver account (in the destination chain) MUST be represented using CAIP-10 account identifiers”. Unfortunately CAIP-10 for Ethereum addresses ( EIP155 Namespace, aka EVM Chains - Addresses | Chain Agnostic Namespaces ) contains this: “Anywhere “Postel’s Law” can apply, implementers SHOULD produce checksum-case secure addresses (whether in CAIP-10 or native format), and SHOULD accept both checksum case and legacy lowercase addresses, except where the security concerns of the particular usecase outweigh interoperability”.

In other words, CAIP-10 for Ethereum doesn’t contain definitive answer whether address should be lowercase or EIP-55 encoded. I think this is bad, so I reported this to CAIP: CAIP-10 and CAIP-19: mandate case-normalization · Issue #351 · ChainAgnostic/CAIPs · GitHub . But, as well as I understand, CAIP editors don’t plan to change anything here.

So, ERC-7786 should make its own decision here.

Also, another option may be to use CAIP-50 instead (it is binary) or CAIP-350 a. k. a. ERC-7930 (it is binary, too) ( New CAIP profile: interoperable address binary specification by 0xteddybear · Pull Request #350 · ChainAgnostic/CAIPs · GitHub , ERC 7930: Interoperable Addresses )

1 Like