Add ERC: Cross-Chain Messaging Gateway

ERCS/erc-7786.md

@@ -0,0 +1,215 @@
+---
+eip: 7786
+title: Cross-Chain Messaging Gateway
+description: An interface for contracts to send and receive cross-chain messages.
+author: Francisco Giordano (@frangio), Hadrien Croubois (@Amxx), Ernesto Garcia (@ernestognw), CJ Cobb (@cjcobb23)
+discussions-to: https://ethereum-magicians.org/t/erc-7786-cross-chain-messaging-gateway/21374
+status: Draft
+type: Standards Track
+category: ERC
+created: 2024-10-14
+---
+
+## Abstract
+
+This proposal describes an interface, and the corresponding workflow, for smart contracts to send arbitrary data through cross-chain messaging protocols. The end goal of this proposal is to have all such messaging protocols accessible via this interface (natively or using "adapters") to improve their composability and interoperability. That would allow a new class of cross-chain native smart contracts to emerge while reducing vendor lock-in. This proposal is modular by design, allowing users to leverage bridge-specific features through attributes while providing simple "universal" access to the simple feature of "just getting a simple message through".
+
+## Motivation
+
+Cross-chain messaging protocols (or bridges) allow communication between smart contracts deployed on different blockchains. There is a large diversity of such protocols with multiple degrees of decentralization, different architectures, implementing different interfaces, and providing different guarantees to users.
+
+Because almost every protocol implements a different workflow using a specific interface, portability between bridges is currently basically impossible. This also prevents the development of generic contracts that rely on cross chain communication.
+
+The objective of the ERC is to provide a standard interface, and a corresponding workflow, for performing cross-chain communication between contracts. Existing cross-chain communication protocols that do not natively implement this interface should be able to adopt it using adapter gateway contracts.
+
+Compared to previous ERCs in this area, this ERC offers compatibility with chains outside of the Ethereum/EVM ecosystem, and it is extensible to support the different feature sets of various protocols while offering a shared core of standard functionality.
+
+## Specification
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
+
+### Message Field Encoding
+
+A cross-chain message consists of a sender, receiver, payload, and list of attributes.
+
+#### Sender & Receiver
+
+The sender account (in the source chain) and receiver account (in the destination chain) MUST be represented using CAIP-10 account identifiers. Note that these are ASCII-encoded strings.
+
+A CAIP-10 account identifier embeds a CAIP-2 chain identifier along with an address. In some parts of the interface, the address and the chain parts will be provided separately rather than as a single string, or the chain part will be implicit.
+
+#### Payload
+
+The payload is an opaque `bytes` value.
+
+#### Attributes
+
+Attributes are structured pieces of message data and/or metadata. Each attribute is a key-value pair, where the key determines the type and encoding of the value, as well as its meaning and behavior.
+
+Some attributes are message data that must be sent to the receiver, although they can be transformed as long as their meaning is preserved. Other attributes are metadata that will be used by the intervening gateways and potentially removed before the message reaches the receiver.
+
+The set of attributes is extensible. It is RECOMMENDED to standardize attributes and their characteristics by publishing them as ERCs.
+
+A gateway MAY support any set of attributes. An empty attribute list MUST always be accepted by a gateway.
+
+Each attribute key MUST have the format of a Solidity function signature, i.e., a name followed by a list of types in parentheses. For example, `minGasLimit(uint256)`.
+
+In this specification attributes are encoded as an array of `bytes` (i.e., `bytes[]`). Each element of the array MUST encode an attribute in the form of a Solidity function call, i.e., the first 4 bytes of the hash of the key followed by the ABI-encoded value.
+
+### Sending Procedure
+
+An **Source Gateway** is a contract that offers a protocol to send a message to a receiver on another chain. It MUST implement `IERC7786GatewaySource`.
+
+```solidity
+interface IERC7786GatewaySource {
+    event MessagePosted(bytes32 indexed outboxId, string sender, string receiver, bytes payload, uint256 value, bytes[] attributes);
+
+    error UnsupportedAttribute(bytes4 signature);
+
+    function supportsAttribute(bytes4 signature) external view returns (bool);
+
+    function sendMessage(
+        string calldata destinationChain, // CAIP-2 chain identifier
+        string calldata receiver, // CAIP-10 account address
+        bytes calldata payload,
+        bytes[] calldata attributes
+    ) external payable returns (bytes32 outboxId);
+}
+```
+
+#### `supportsAttribute`
+
+Returns a boolean indicating whether an attribute is supported by the gateway, identified by the selector computed from the attribute signature.
+
+A gateway MAY be upgraded with support for additional attributes. Once present support for an attribute SHOULD NOT be removed to preserve backwards compatibility with users of the gateway.
+
+#### `sendMessage`
+
+Initiates the sending of a message.
+
+Further action MAY be required by the gateway to make the sending of the message effective, such as providing payment for gas. See Post-processing.
+
+MUST revert with `UnsupportedAttribute` if an unsupported attribute key is included. MAY revert if the value of an attribute is not a valid encoding for its expected type.
+
+MAY accept call value (native token) to be sent with the message. MUST revert if call value is included but it is not a feature supported by the gateway. It is unspecified how this value is represented on the destination.
+
+MAY generate and return a unique non-zero *outbox identifier*, otherwise returning zero. This identifier can be used to track the lifecycle of the message in the outbox in events and for post-processing.
+
+MUST emit a `MessagePosted` event, including the optional outbox identifier that is returned by the function.
+
+#### `MessagePosted`
+
+This event signals that a would-be sender has requested a message to be sent.
+
+If `outboxId` is present, post-processing MAY be required to send the message through the cross-chain channel.
+
+#### Post-processing
+
+After a sender has invoked `sendMessage`, further action MAY be required by the gateways to make the message effective. This is called *post-processing*. For example, some payment is typically required to cover the gas of executing the message at the destination.
+
+The exact interface for any such action is out of scope of this ERC. If the `postProcessingOwner` attribute is supported and present, such actions MUST be restricted to the specified account, otherwise they MUST be able to be performed by any party in a way that MUST NOT be able to compromise the eventual receipt of the message.
+
+### Reception Procedure
+
+The underlying protocol MUST ensure delivery of the message to the **receiver**, which MUST implement `IERC7786Receiver`. The requirements for `executeMessage` will be detailed further below. Upon successful processing of the message, the receiver MUST return `IERC7786Receiver.executeMessage.selector` (`0xc887c5da`).
+
+```solidity
+interface IERC7786Receiver {
+    function executeMessage(
+        address gateway,
+        bytes calldata gatewayMessageKey,
+        string calldata sourceChain, // CAIP-2 chain identifier
+        string calldata sender, // CAIP-10 account address
+        bytes calldata payload,
+        bytes[] calldata attributes
+    ) external payable returns (bytes4);
+}
+```
+
+A **Destination Gateway** is a contract that implements a protocol to validate messages sent on other chains. The gateway can operate in Active or Passive Mode, depending on whether `executeMessage` is invoked by the gateway itself or some other acocunt.
+
+#### Active Mode
+
+The gateway directly invokes `executeMessage`, and only does so with valid messages. The receiver MUST assume that a message is valid if the caller is a known gateway.
+
+The arguments `gateway` and `gatewayMessageKey` are unused in active mode and SHOULD be zero and empty respectively.
+
+The gateway MUST verify that `executeMessage` returns the correct value, and MUST revert if that is not the case.
+
+##### Interaction Diagram
+
+![](../assets/erc-7786/active-mode.svg)
+
+#### Passive Mode
+
+The gateway does not directly invoke `executeMessage`, but provides a means to validate messages. The receiver allows any party to invoke `executeMessage`, but if the caller is not a known gateway it MUST check that the gateway provided as an argument is a known gateway, and it MUST validate the message against it before accepting it, forwarding the message key.
+
+A gateway acting in passive mode MUST implement `IERC7786GatewayDestinationPassive`. If a gateway operates exclusively in active mode, the implementation of this interface is OPTIONAL.
+
+```solidity
+interface IERC7786GatewayDestinationPassive {
+    function setMessageExecuted(
+        bytes calldata messageKey,
+        string calldata sourceChain, // CAIP-2 chain identifier
+        string calldata sender, // CAIP-10 account address
+        bytes calldata payload,
+        bytes[] calldata attributes
+    ) external;
+}
+```
+
+##### `setMessageExecuted`
+
+Checks that there is a valid and as yet unexecuted message whose contents are exactly those passed as arguments and whose receiver is the caller of the function. The message key MAY be an identifier, or another piece of data necessary for validation.
+
+MUST revert if the message is invalid or has already been executed.
+
+##### Interaction Diagram
+
+![](../assets/erc-7786/passive-mode.svg)
+
+#### Dual Active-Passive Mode
+
+A gateway MAY operate in both active and passive modes, or it MAY switch from operating exclusively in active mode to passive mode or vice versa.
+
+A receiver SHOULD support both active and passive modes for any gateway. This is accomplished by first checking whether the caller of `executeMessage` is a known gateway, and only validating the message if it is not; the first case supports an active mode gateway, while the second case supports a passive mode gateway.
+
+### Properties
+
+The protocol underlying a pair of gateways is expected to guarantee a series of properties. For detailed definition and discussion we refer to XChain Research’s *Cross-chain Interoperability Report*.
+
+- The protocol MUST guarantee Safety: A message is delivered at the destination if and only if it was sent at the source. The delivery process must ensure a message is only delivered once the sending transaction is finalized, and not delivered more than once. Note that there can be multiple messages with identical parameters that must be delivered separately.
+- The protocol MUST guarantee Liveness: A sent message is delivered at the destination eventually, assuming Liveness and censorship-resistance of the source and destination chains.
+- The protocol SHOULD guarantee Timeliness: A sent message is delivered at the destination within a bounded delivery time, which should be documented.
+- The above properties SHOULD NOT rely on trust in some centralized actor. For example, safety should be guaranteed by some trustless mechanism such as a light client proof, or attestations by an open, decentralized validator set. Relaying should be decentralized or permissionless to ensure liveness; a centralized relayer can fail and thus halt the protocol.
+
+### Pending discussion
+
+- Should the destination and receiver inputs of `sendMessage` be kept as two separate strings, or merged as a single CAIP-10 string with a `:` separator? This has implication of the calldata length, which in some cases may be stored.
+- Do we want the gateway to have the ability to inform users of the address of the new version, similar to how `AccessManager` can update then authority trusted by an `AccessManaged`? This could be useful if a gateway is ever deprecated in favor of a new version.
+- Should data and metadata attributes be split in two? What are data attributes used for? Do we need them?
+- Passing full payload or payload hash (as done by Axelar) ? Same question for attributes, possibly different answer depending on attribute malleability.
+
+## Rationale
+
+Attributes are designed so that gateways can expose any specific features the bridge offers without having to use a specific endpoint. Having a unique endpoint, with modularity through attributes, SHOULD allow contracts to change the gateway they use while continuing to express messages the same way. This portability offers many advantages:
+- A contract that relies on a specific gateway for sending messages is vulnerable to the gateway being paused, deprecated, or simply breaking. If the communication between the contract and the gateway is standard, an admin of the contract COULD update the address (in storage) of the gateway to use. In particular, senders to update to the new gateway when a new version is available.
+- Bridge layering SHOULD be possible. In particular, this interface should allow for a new class of bridges that routes the message through multiple independent bridges. Delivery of the message could require one or multiple of these independent bridges depending on whether improved liveness or safety is desired.
+
+As some cross-chain communication protocols require additional parameters beyond the destination and the payload, and because we want to send messages through those bridges without any knowledge of these additional parameters, a post-processing of the message MAY be required (after `sendMessage` is called, and before the message is delivered). The additional parameters MAY be supported through attributes, which would remove the need for a post-processing step. If these additional parameters are not provided through an attribute, an additional call to the gateway is REQUIRED for the message to be sent. If possible, the gateway SHOULD be designed so that anyone with an incentive for the message to be delivered can jump in. A malicious actor providing invalid parameters SHOULD NOT prevent the message from being successfully relayed by someone else.
+
+Some protocols gateway support doing arbitrary direct calls on the receiver. In that case, the receiver must detect that they are being called by the gateway to properly identify cross-chain messages. Getters are available on the gateway to figure out where the cross-chain message comes from (source chain and sender address). This approach has the downside that it allows anyone to trigger any call from the gateway to any contract. This is dangerous if the gateway ever holds any assets ([ERC-20](./erc-20.md) or similar). The use of a dedicated `executeMessage` function on the receiver protects any assets or permissions held by the gateway against such attacks. If the ability to perform direct calls is desired, this can be implemented as a wrapper on top of any gateway that implements this ERC.
+
+## Backwards Compatibility
+
+Existing cross-chain messaging protocols implement proprietary interfaces. We recommend that protocols natively implement the standard interface defined here, and propose the development of standard adapters for those that don't.
+
+## Security Considerations
+
+Unfortunately, CAIP-2 and CAIP-10 names are not unique. Using non-canonical strings may lead to undefined behavior, including message delivery failure and locked assets. While source gateways have a role to play in checking that user input are valid, we also believe that more effort should be put into standardizing and documenting what the canonical format is for each CAIP-2 namespace. This effort is beyond the scope of this ERC.
+
+Needs discussion.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).

assets/erc-7786/active-mode.mermaid

@@ -0,0 +1,13 @@
+sequenceDiagram
+    box Source chain
+    participant Sender
+    participant SourceGateway
+    end
+    box Destination chain
+    participant DestinationGateway
+    participant Receiver
+    end
+    Sender->>SourceGateway: sendMessage(...)
+    SourceGateway-->>DestinationGateway: [underlying protocol]
+    DestinationGateway->>+Receiver: executeMessage(...)
+    Receiver->>-Receiver: _processMessage(...)