Add EIP-5164: Cross-Chain Execution

EIPS/eip-5164.md

@@ -0,0 +1,211 @@
+---
+eip: 5164
+title: Cross-Chain Execution
+description: This specification defines an interface that supports execution across EVM networks.
+author: Brendan Asselstine (@asselstine), Anna Carroll (@anna-carroll), Hadrien Croubois (@Amxx), Nam Chu Hoai (@nambrot), Georgios (@geogons), Theo Gonella (@mintcloud), Rafael Solari (@rsolari), Auryn Macmillan (@auryn-macmillan), Nathan Ginnever (@nginnever)
+discussions-to: https://ethereum-magicians.org/t/eip-5164-cross-chain-execution/9658
+status: Draft
+type: Standards Track
+category: ERC
+created: 2022-06-14
+---
+
+## Abstract
+
+This specification defines a cross-chain execution interface for EVM-based blockchains. Developers will be able to have contracts call contracts on other chains. There are two parts to this spec: the "sending" interface and the "receiving" interface. The "sending" interface specifies the interface to send a call to another chain; this interface must be implemented by bridges. The "receiving" interface must be implemented by the developer; it is an interface for receiving cross-chain calls. This specification is agnostic of the bridge implementation; it simply standardizes the call interfaces.
+
+## Motivation
+
+Many Ethereum protocols need to coordinate state changes across multiple EVM-based blockchains. These chains often have native or third-party bridges that allow Ethereum contracts to execute code. However, bridges have different APIs so bridge integrations are bespoke.
+
+Bridge technology is improving rapidly, and there are multiple bridges to choose from. Each one affords different properties; with varying degrees of security, speed, and control.
+
+By standardizing a cross-chain execution interface, we can cleanly separate the transport layer from the application layer. Cross-chain execution becomes another composable piece with which the Ethereum ecosystem can build shared infrastructure.
+
+## Specification
+
+This specification allows contracts on one chain to send messages to contracts on another chain. There are two key contracts:
+
+- CrossChainRelayer
+- CrossChainReceiver
+
+The `CrossChainRelayer` lives on the origin chain. Users can share a single `CrossChainRelayer` or deploy their own.
+
+The `CrossChainReceiver` lives on the destination chain and receives relayed calls.
+
+The key words “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.
+
+### CrossChainRelayer
+
+The `CrossChainRelayer` lives on the chain from which messages are sent. The Relayer's job is to broadcast the messages through a transport layer.
+
+#### Methods
+
+**relayCalls**
+
+MUST emit the `Relayed` event when successfully called.
+
+MUST increment a `nonce` so that each batch of calls can be uniquely identified.
+
+MAY require payment. Some bridges may require payment in the native currency, so the function is payable.
+
+Implementations MUST relay the Calls by calling the `receiveCalls` function on the `CrossChainReceiver` on the receiving chain with the call data.
+
+```solidity
+struct Call {
+  address target;
+  bytes data;
+  uint value;
+}
+
+interface CrossChainRelayer {
+    function relayCalls(CrossChainReceiver receiver, Call[] calldata calls, uint256 gas) external payable;
+}
+```
+
+```yaml
+- name: relayCalls
+  type: function
+  stateMutability: payable
+  inputs: 
+    - name: receiver
+      type: CrossChainReceiver
+    - name: calls
+      type: Call[]
+    - name: gas
+      type: uint256
+```
+
+#### Events
+
+**RelayedCalls**
+
+MUST be emitted by the `CrossChainRelayer` when `relayCalls` is called.
+
+```solidity
+interface CrossChainRelayer {
+  event RelayedCalls(
+      uint256 indexed nonce,
+      address indexed sender,
+      CrossChainReceiver indexed receiver,
+      Call[] calls,
+      uint256 gas
+  );
+}
+```
+
+```yaml
+- name: RelayedCalls
+  type: event
+  inputs:
+    - name: nonce
+      indexed: true
+      type: uint256
+    - name: sender
+      indexed: true
+      type: address
+    - name: receiver
+      indexed: true
+      type: address
+    - name: calls
+      type: Call[]
+    - name: gas
+      type: uint256
+```
+
+### CrossChainReceiver
+
+The `CrossChainReceiver` contract executes call batches. Developers must implement a `CrossChainReceiver` in order to receive messages.
+
+#### Methods
+
+**receiveCalls**
+
+Receives a batch of calls.
+
+SHOULD authenticate the caller as being the bridge transport layer.
+
+MUST emit the ReceivedCalls event when calls are received.
+
+```solidity
+interface CrossChainReceiver {
+  function receiveCalls(
+    CrossChainRelayer relayer,
+    uint256 nonce,
+    address caller,
+    Call[] calldata calls
+  ) external;
+}
+```
+
+```yaml
+- name: receiveCalls
+  type: function
+  stateMutability: nonpayable
+  inputs:
+    - name: relayer
+      type: CrossChainRelayer
+    - name: nonce
+      type: uint
+    - name: caller
+      type: address
+    - name: calls
+      type: Call[]
+```
+
+#### Events
+
+**ReceivedCalls**
+
+MUST be emitted when calls are received.
+
+```solidity
+interface CrossChainReceiver {
+  event ReceivedCalls(
+      CrossChainRelayer indexed relayer,
+      uint256 indexed nonce,
+      address indexed caller,
+      Call[] calls
+  );
+}
+```
+
+```yaml
+- name: ReceivedCalls
+  type: event
+  inputs:
+    - name: relayer
+      indexed: true
+      type: CrossChainRelayer
+    - name: nonce
+      indexed: true
+      type: uint256
+    - name: caller
+      indexed: true
+      type: address
+    - name: calls
+      type: Call[]
+```
+
+## Rationale
+
+There are some notable design decisions worth talking about:
+
+- Relayer and nonce are passed to the Receiver
+- Calls are relayed in batches
+
+The Relayer address is passed to the receiver so that the execution can easily be traced by a client using the relayer address and nonce. A third party just needs to be aware of a list of Relayers and a list of Receivers and can trace execution across all of them.
+
+Calls are relayed in batches because it is such a common action. Rather than have implementors take different approaches to encoding multiple calls into the `data` portion, this spec includes call batching to take away any guess work.
+
+## Backwards Compatibility
+
+This specification is compatible with existing governance systems as it offers simple cross-chain execution.
+
+## Security Considerations
+
+Different bridges have wildly different trust profiles, so it's important that the user understands that bridge security will depend on the implementation being used.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).