Ethereum Improvement ProposalsAbstract
This EIP standardizes an interface for cross-chain messengers, providing basic functionality to send and receive a cross-chain message (state).
Motivation
Cross-chain messaging protocols lack standardization, resulting in unnecessarily complex competing implementations: Layerzero, Hyperlane & Wormhole each use a different interface. This makes integration difficult at the aggregator or plugin layer for protocols that must conform to any standards and forces each protocol to implement its adapter, which might be error-prone.
Even chain-native arbitrary messaging protocols like the MATIC State Tunnel have an application-specific interface.
Specification
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
Every compliant messaging tunnel must implement the following interface.
pragma solidity >=0.8.0;
/// @title Cross-Chain Messaging interface
/// @dev Allows seamless interchain messaging.
/// @author Sujith Somraaj
/// Note: Bytes are used throughout the implementation to support non-evm chains.
interface EIP6170 {
/// @dev This emits when a cross-chain message is sent.
/// Note: MessageSent MUST trigger when a message is sent, including zero bytes transfers.
event MessageSent(bytes _from, bytes _to, bytes _toChainId, bytes _message, bytes _extraData);
/// @dev This emits when a cross-chain message is received.
/// MessageReceived MUST trigger on any successful call to receiveMessage(bytes chainId, bytes sender, bytes message) function.
event MessageReceived(bytes _from, bytes _fromChainId, bytes message);
/// @dev Sends a message to a receiving address on a different blockchain.
/// @param chainId is the unique identifier of receiving blockchain.
/// @param receiver is the address of the receiver.
/// @param message is the arbitrary message to be delivered.
/// @param data is a bridge-specific encoded data for off-chain relayer infrastructure.
/// @return the status of the process on the sending chain.
/// Note: this function is designed to support both evm and non-evm chains
/// Note: proposing chain-ids be the bytes encoding their native token name string. For eg., abi.encode("ETH"), abi.encode("SOL") imagining they cannot override.
function sendMessage(
bytes memory chainId,
bytes memory receiver,
bytes memory message,
bytes memory data
) external returns (bool);
/// @dev Receives a message from a sender on a different blockchain.
/// @param chainId is the unique identifier of the sending blockchain.
/// @param sender is the address of the sender.
/// @param message is the arbitrary message sent by the sender.
/// @return the status of message processing/storage.
/// Note: sender validation (or) message validation should happen before processing the message.
function receiveMessage(
bytes memory chainId,
bytes memory sender,
bytes memory message
) external returns (bool);
}
Rationale
The Cross-Chain interface is designed to be optimized for interoperability layer integrators with a feature-complete, yet minimal interface. Validations such as sender authentication, receiver whitelisting, relayer mechanisms and cross-chain execution overrides are intentionally not specified, as Messaging protocols are expected to be treated as black boxes on-chain and inspected off-chain before use.
Security Considerations
Fully permissionless messaging could be a security threat to the protocol. It is recommended that all the integrators review the implementation of messaging tunnels before integrating.
For eg., without sender authentication, anyone could write arbitrary messages into the receiving smart contract.
This EIP focuses only on the way the messages should be sent and received with a specific standard. But any authentication (or) message tunnel-specific operations can be implemented inside the receive function by integrators.
Copyright
Copyright and related rights waived via CC0