Merge pull request ethereum#1 from frangio/new-erc/crosschain-gateway-interface

Updates based on feedback

Author: Amxx

ERCS/erc-7786.md

@@ -12,15 +12,17 @@ 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 systems. 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".
+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 systems (or bridges) allow communication between smart contracts deployed on different blockchains. There is a large diversity of such systems with multiple degrees of decentralization, with various components, that implement different interfaces, and provide different guarantees to the users.
+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 implementing a different workflow, using a specific interface, portability between bridges is basically impossible. This also forbid the development of generic contracts that rely on cross chain communication.
+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 nativelly implement this interface, should be able to adopt it using adapter gateway contracts.
+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
 
@@ -60,14 +62,13 @@ The following standard attributes MAY be supported by a gateway.
 
 - `postProcessingOwner(address)`: The address of the account that shall be in charge of message post-processing.
 
-### Source Gateway
+### 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`.
+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 MessageCreated(bytes32 indexed outboxId, string sender, string receiver, bytes payload, uint256 value, bytes[] attributes);
-    event MessageSent(bytes32 indexed outboxId);
+    event MessagePosted(bytes32 indexed outboxId, string sender, string receiver, bytes payload, uint256 value, bytes[] attributes);
 
     error UnsupportedAttribute(bytes4 signature);
 
@@ -100,35 +101,23 @@ MAY accept call value (native token) to be sent with the message. MUST revert if
 
 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 `MessageCreated` event, including the optional outbox identifier that is returned by the function.
-
-If an outbox identifier was generated, MUST emit a `MessageSent` event if no post-processing is required.
+MUST emit a `MessagePosted` event, including the optional outbox identifier that is returned by the function.
 
-#### `MessageCreated`
+#### `MessagePosted`
 
-This event signals that a would-be sender has initiated the sending of a message.
+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.
 
-#### `MessageSent`
-
-This event signals that no more post-processing in the source chain is required, and that the message has been sent 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.
 
-The gateway MUST emit a `MessageSent` event with the appropriate identifier once no more post-processing is required by the source gateway. Further post-processing MAY be required in the source or destination gateways.
+### Reception Procedure
 
-### Destination Gateway
-
-A Destination Gateway is a contract that implements a protocol to validate messages sent on other chains and have them received at their destination.
-
-The gateway can operate in Active or Passive Mode.
-
-In both modes, the destination account of a message, aka the receiver, MUST implement a `receiveMessage` function. The use of this function depends on the mode of the gateway as described in the following sections.
+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.
 
 ```solidity
 interface IERC7786Receiver {
@@ -143,6 +132,8 @@ interface IERC7786Receiver {
 }
 ```
 
+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 `receiveMessage`, and only does so with valid messages. The receiver MUST assume that a message is valid if the caller is a known gateway.
@@ -185,7 +176,7 @@ A receiver SHOULD support both active and passive modes for any gateway. This is
 
 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](https://github.com/0xFableOrg/xchain/blob/7789933bba24e2dd893cf515157af70474e7180b/README.md).
 
-- The protocol MUST guarantee Safety: A message is delivered at the destination if and only if it was sent at the source, and the sending transaction was finalized.
+- 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.