Add ERC: Verification-independent Cross-Chain Messaging #817
Conversation
ERCS/erc-xxxx.md
Outdated
| @@ -0,0 +1,392 @@ | |||
| --- | |||
| eip: XXXX | |||
| title: Verification-independent Cross-Chain Messaging Standard | |||
There was a problem hiding this comment.
There are already multiple cross-chain messaging ERCs. Please consider collaborating.
- ERC-6170: Cross-Chain Messaging Interface
- ERC-7786: Cross-Chain Messaging Gateway
- ERC-7841: Cross-chain Message Format and Mailbox
- RIP-7755: Cross-L2-Call
There was a problem hiding this comment.
Yup have been in conversations with all these authors about collaboration and potential merging
Co-authored-by: Andrew B Coathup <28278242+abcoathup@users.noreply.github.com>
Co-authored-by: Andrew B Coathup <28278242+abcoathup@users.noreply.github.com>
Co-authored-by: Andrew B Coathup <28278242+abcoathup@users.noreply.github.com>
eip-review-bot
changed the title
Co-authored-by: Philippe Camacho <philippe@espressosys.com>
|
The commit 0f0cf2c (as a parent of e2ce462) contains errors. |
| } | ||
| ``` | ||
|
|
||
| **ISM Types** |
There was a problem hiding this comment.
Might want to use a subheading?
| **ISM Types** | |
| #### ISM Types |
| * messages based on the provided metadata. | ||
| * @param _metadata Off-chain metadata provided by a relayer, specific to | ||
| * the security model encoded by the module (e.g. validator signatures) | ||
| * @param _message Hyperlane encoded interchain message |
| ROUTING, | ||
| AGGREGATION, | ||
| LEGACY_MULTISIG | ||
| ... // more but excluded for brevity |
There was a problem hiding this comment.
Is there a full list somewhere? Seems odd to exclude variants from a standard.
|
|
||
| ### Default values and allow override vs. Adapter Entrypoints | ||
|
|
||
| To accomplish similar developer experience to vendored alternatives, having a configuration-light starting experience is critical. Other ERCs ([ERC-7786](https://github.com/ethereum/ERCs/pull/673), [EIP-5164](https://eips.ethereum.org/EIPS/eip-5164)) and other protocols (often because they start without modular considerations) end up with an adapter pattern where message senders/recipients manage different verification methods by calling/permissioning calls on different contracts. While both patterns are fundamentally the same level of expressiveness, singular entrypoint contracts are an easier integration point especially for newer developers. |
There was a problem hiding this comment.
You'll either want to link to the file within the repository (eg. ./eip-7786.md) or remove these links entirely. While providing extra context is nice, by linking to another proposal you create an implicit dependency on it. Your proposal will not be able to advance past its dependencies' statuses. For example, if 7786 is Review, 7854 won't be able to go to Last Call.
|
|
||
| Singular entrypoints also make auxiliary tooling like test harnesses or explorers easier to develop and maintain. Mailboxes can be easily expressed as adapters by simply deploying multiple instances on a given chain, which take away the main concern with singleton entrypoints. | ||
|
|
||
| ## (Backwards) Compatibility |
There was a problem hiding this comment.
| ## (Backwards) Compatibility | |
| ## Backwards Compatibility |
|
|
||
| A developer who wants to send a message via this API with the native OpStack rollup bridge trust assumptions can simply specify the [`OpStackHook`](https://github.com/hyperlane-xyz/hyperlane-monorepo/blob/f26453ee55a444b4ee1a1ac948ebebc92be26ac5/solidity/contracts/hooks/OPStackHook.sol#L2) on Ethereum and the [`OpStackIsm`](https://github.com/hyperlane-xyz/hyperlane-monorepo/blob/f26453ee55a444b4ee1a1ac948ebebc92be26ac5/solidity/contracts/isms/hook/OPStackIsm.sol#L31) on the OpStack chain | ||
|
|
||
| ```mermaid |
There was a problem hiding this comment.
Mermaid is not supported by our renderer. You'll want to generate an image file (preferably SVG) and include it in your assets directory.
This ERC specifies an API for sending messages across chains to enable interoperability in the greater Ethereum ecosystem (but is flexible enough to encompass alternate VMs). It specifically is capable of sending messages via arbitrary transport and verifying them via diverse mechanisms. At the same time, it aims to provide enough standardization with a modular relaying mechanism to provide a consistent developer experience. As such, it allows for a clean separation of high level abstractions to be built by “application developers” like cross-chain tokens and account abstraction, while allowing for innovation at the verification and transport layer.