Add ERC: Cross-chain Message Format and Mailbox #766
Conversation
Make the Mailbox contract "Abstract".
Update URL.
Add ats to github names.
Co-authored-by: Andrew B Coathup <[email protected]>
|
The commit 59928c2 (as a parent of 3514096) contains errors. |
|
|
||
| ## Abstract | ||
|
|
||
| This ERC proposes a **mailbox API** and **message format** for sending and receiving data between L2s. This standard makes it easier for developers to build cross-chain applications that work over a variety of VMs, chain settlement mechanisms (e.g., ZK or optimistic settlement), and messaging protocols (e.g., synchronous or asynchronous protocols). Example applications include an intent-based bridge, a liquidity-unifying DEX operating across multiple chains, or a cross-chain lending application. |
There was a problem hiding this comment.
You abstract should sketch out a high level technical overview so readers get a sense of how your proposal accomplishes its goals.
| } | ||
| ``` | ||
|
|
||
| It is RECOMMENDED that there exists a global rollup registry service that supports registration, deregistration, and efficient lookup of a rollup's chain ID. This work is outside the scope of this ERC, however. To display the sender and receiver of a `Message`, wallets and frontends MAY use [ERC-3770](./eip-3770.md) for chain-specific addresses. |
There was a problem hiding this comment.
It is RECOMMENDED that there exists a global rollup registry service that supports registration, deregistration, and efficient lookup of a rollup's chain ID.
This is a weird way to word this. You're creating a recommendation not for implementers of your standard, but for the entire ecosystem.
I'd recommend something more like:
| It is RECOMMENDED that there exists a global rollup registry service that supports registration, deregistration, and efficient lookup of a rollup's chain ID. This work is outside the scope of this ERC, however. To display the sender and receiver of a `Message`, wallets and frontends MAY use [ERC-3770](./eip-3770.md) for chain-specific addresses. | |
| Implementations SHOULD use a global rollup registry service that supports registration, deregistration, and efficient lookup of a rollup's chain ID. This work is outside the scope of this ERC, however. | |
| To display the sender and receiver of a `Message`, wallets and frontends MAY use [ERC-3770](./eip-3770.md) for chain-specific addresses. |
| type: Standards Track | ||
| category: ERC | ||
| created: 2024-12-12 | ||
| --- |
There was a problem hiding this comment.
| --- | |
| requires: 3770 | |
| --- |
| /// @notice Mailbox for sending (resp. receiving) messages to (resp. from) | ||
| /// other chains, standardized for messaging protocols that support | ||
| /// synchronous or asynchronous, or both types of message passing. | ||
| abstract contract Mailbox { |
There was a problem hiding this comment.
abstract contracts include too much implementation detail, and as such we don't generally allow them. I don't really see anything in here that couldn't be included in an interface, unless the storage requirements of inbox are meaningful?
|
|
||
| ### Related Proposals | ||
|
|
||
| In comparison to IBC-like standards, this ERC is designed to work in a *stateless* manner. Messages do not need to pass a proof from the source chain at the time they are consumed on the destination chain. This allows use cases such as synchronous composability and intra-block messaging since messages don’t need to include finalized state from the source chain. Additionally, this ERC does not require multiple steps to establish a link between two chains. Messages can be directly sent from one chain to another in a single step. |
There was a problem hiding this comment.
IBC-like
Please expand uncommon abbreviations the first time they are used.
|
|
||
| In comparison to IBC-like standards, this ERC is designed to work in a *stateless* manner. Messages do not need to pass a proof from the source chain at the time they are consumed on the destination chain. This allows use cases such as synchronous composability and intra-block messaging since messages don’t need to include finalized state from the source chain. Additionally, this ERC does not require multiple steps to establish a link between two chains. Messages can be directly sent from one chain to another in a single step. | ||
|
|
||
| [ERC-7683](./eip-7683.md) standardizes intent-based systems by defining structs for orders and interfaces for settlement smart contracts. This standard is application-specific and aimed at designers of cross-chain intent systems, while our proposal is more general and targets developers implementing arbitrary cross-chain applications. However, an intent system based on ERC-7683 **can be built on top** of our standard due to its modularity. An application implementing ERC-7683 could use the `Mailbox` API defined in this proposal to send `originData` from event messages between the source chain (where user funds are deposited) and the destination chain(s) (where intents are solved). We provide more details in the *Example Usage* section. |
There was a problem hiding this comment.
If you mention ERC-7683, your standard will not be able to progress past its status. See markdown-link-status for more detail.
There's absolutely nothing wrong with that. I just wanted to let you know.
|
|
||
| ### Example Usage - Sync and Async Cross-chain Transfers | ||
|
|
||
| We show a *possible* implementation of the mailbox contract for synchronous messaging protocol, and explain how it can be easily modified to support asynchronous protocols as well. |
There was a problem hiding this comment.
This sounds like it belongs in the reference implementation section?
|
|
||
| ## Copyright | ||
|
|
||
| Copyright and related rights waived via CC0. |
There was a problem hiding this comment.
Please use the exact copyright waiver from the template.
When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md
We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met: