EIP-6170: Cross-Chain Messaging Interface

As the ecosystem is moving towards a cross-chain solution to piece all those fragmented liquidities, this proposal will speed up the development lifecycle of cross-chain applications.

Why Cross-Chain?
Imagine a bank sitting with $$ Trillion of deposits that are untransferable to any other bank and have to be used within its ecosystem.

What does it serve them? Similarly, liquidity/state in one-chain unaccessible with ease to the other chain is problematic for scaling.

I’m aware there are multiple topics in discussions surrounding this.

Nearly 18 months ago, @auryn suggested the same A standard interface for arbitrary message bridges between chains/layers but focussed on the interface for chain native bridges on Sidechains and L2s and never outlined non-EVM chains.

There is also an interesting EIP-5164 for cross-chain execution to standardize it at the relayer level.

But this proposal is to streamline cross-chain bridging protocols like Layerzero, Hyperlane and Wormhole. These aren’t sidechains (or) native bridges and are interoperable with non-EVM chains.

Not just limited to these bridges, even native bridges using this standard will more streamline the cross-chain messaging eco-system

Hence, this proposal aims to support message/state transfer between any chain whether its EVM (or) non-EVM

Abstract

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.

Even chain-native arbitrary messaging protocols like the MATIC State Tunnel has 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 tunnels 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 along the entire implementation to support non-evm chains.

interface EIP6170 {
    /// @dev This emits when a message is sent from a sender on source chain to a receiver on a different blockchain.
    /// @param _sender is the address of the sender.
    /// @param _fromChainId is the identifier of the sending blockchain.
    /// @param _receiver is the address of the receiver.
    /// @param _toChainId is the identifier of the receiving blockchain.
    /// @param _data is the encoded custom data type required by off-chain infrastucture required information.
    /// NOTE: _data can encode any protocol specific data types.
    /// NOTE: this emits when the message is sent, it does not gurantee successful delivery.
    event MessageSent(
        bytes _sender,
        bytes _receiver,
        bytes _toChainId,
        bytes _data
    );
    /// @dev This emits when a cross-chain message is delivered succesfully at the receiver.
    /// @param _sender is the address of the sender.
    /// @param _receiver is the address of the receiver.
    /// @param _fromChainId is the identifier of the sending blockchain.
    /// @param _toChainId is the identifier of the receiving blockchain.
    /// @param _data is the encoded custom data type required by off-chain infrastucture required information.
    /// NOTE: _data can encode any protocol specific data types.
    /// NOTE: this emits when the message is delivered successfully.
    event MessageReceived(
        bytes _sender,
        bytes _receiver,
        bytes _fromChainId,
        bytes _data
    );

    /// @dev Sends message to a receiving address on 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.
    /// @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 of their native token name string. For eg., abi.encode("ETH"), abi.encode("SOL") imagining they cannot override.
    /// Note: MUST emit a {MessageSent} event.
    function sendMessage(
        bytes memory chainId,
        bytes memory receiver,
        bytes memory message
    ) external returns (bool);

    /// @dev Receives message from a sender on 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: MUST emit a {MessageReceived} event.
    /// 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 messaging 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.

Copyright

Copyright and related rights waived via CC0

2 Likes