Async cross chain messaging design. #1692
Conversation
WalkthroughThe recent changes introduce a new asynchronous messaging infrastructure for cross-chain communication. This infrastructure addresses the need for reliable message passing between chains, ensuring ordered delivery and gas cost refunds. It involves a merkle tree structure for efficient data verification, a new endpoint for message retrieval, and mechanisms for validators to monitor and challenge message bundles, enhancing the robustness and security of the system. Changes
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on X ? TipsChat with CodeRabbit Bot (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Review Status
Actionable comments generated: 1
Configuration used: CodeRabbit UI
Files selected for processing (1)
- design/bridge/async_messages_design.md (1 hunks)
Additional comments: 3
design/bridge/async_messages_design.md (3)
1-47: The design document is well-structured and provides a clear outline of the proposed asynchronous cross-chain messaging system. It addresses key aspects such as requirements, problems, a detailed proposal, potential challenges, and additional details to consider. This thorough approach is beneficial for understanding the scope and implications of the design.
33-35: The introduction of the new endpoint
ten_getMessageBundleis a notable change as it extends the system's interface. It's important to ensure that the implementation of this endpoint is consistent with the existing API design principles and that it is properly documented for developers to understand its usage.41-41: The challenge process for validators is a critical component of the system's security. It will be important to ensure that the implementation details are clearly defined and that the system is robust against potential attacks or disputes.
| # Ten Protocol - Async Cross Chain Messages | ||
|
|
||
| This document serves to capture some rationale behind preparing the messaging infrastructure for asynchronous out of order publishing of cross chain messages. This serves to allow relayers to fast publish messages before the batches in the DA layer for applications that can work with non finalized (pending) messages. | ||
|
|
||
|
|
||
| ## Requirements | ||
| 1 - The DA layer must be unblocked from reorgs (it currently is, as l1 proof is not checked) | ||
| 2 - There must be a path forward for fast outgoing xchain messages. This means being able to publish messages | ||
| before the relevant DA is posted on the L1 and have them in a `pending` state. | ||
| 3 - Relayers should be able to publish messages themselves by going through the sequencer and getting a signed bundle. | ||
|
|
||
| ## Problems | ||
|
|
||
| 1 - How do we determine the challenge period for bundles? | ||
| 2 - If bundles are published in reverse order, how do we enforce in order challenge period in order to prevent out of order submission to contracts? | ||
| 3 - What abstractions do we need to protect smart contracts from low level exploits? | ||
| 4 - How to differentiate between rollup signatures and cross chain bundle signatures and prevent "malleability"? | ||
| 5 - How to expose the ability to selectively get cross chain messages and have them signed. | ||
|
|
||
|
|
||
| ## Proposal | ||
|
|
||
| In order to enable relaying of messages and have them out of order, we can migrate to a merkle tree structure. | ||
| The management contract will now accept the `rootHash` of the xchain messages for a specific `L1 proof`. | ||
| When this `rootHash` is published early by a relayer, the management contract will refund the gas cost of this publishing for the concrete call into it. | ||
|
|
||
| The relayer will build transactions that contain `inclusion proofs` pointing to a `rootHash` and messages and feed them into target contracts. Those contracts will call into the message bus to verify the inclusion proofs and proceed with their logic. This way relayers will pay the entirety of the gas cost for external dapps. | ||
|
|
||
| Furthermore we can put rules in place for message ordering based on the `emitter` (whomever called the message bus to send the message) and enforce requirements to provide all messages in order. This will limit the potential for attacks where messages are relayed out of order and interfere with administrative functions of a contract while still allow for asynchronous relaying across different `emitters`. | ||
|
|
||
| Having a `rootHash` publishing scheme along with per contract ordering rule means that inclusion proofs will also become valid in order of message emission. One wouldn't be able to relay messages in reverse with different inclusion proofs pointing to different `rootHashes` as the verification will fail when trying to supply a message with a nonce in the future. | ||
|
|
||
| For this to work we will need a new endpoint `ten_getMessageBundle` that will take arguments in the form of block hashes which represents a range over which the enclave will collect and bundle messages in order to build the `rootHash` of the merkle tree. Furthermore, we can add the query filter that is used in normal querying for emitted events in order to make the process selective. | ||
|
|
||
| `ten_getMessageBundle` will return the messages, inclusion proofs for them and a signature over the `rootHash`. Furthermore there will be metadata (also signed) representing the l1 block for which the `rootHash` is valid to publish and the batch hashes representing the range from which the `rootHash` is built (and sequence numbers?). | ||
|
|
||
| The messages will be in a `pending` state until the management contract receives a DA rollup which ends with a higher `sequenceNo` than the batch from which the message was emitted. After this the challenge period begins. After the challenge the messages are considered `finalized`. | ||
|
|
||
| ## Challenges | ||
|
|
||
| Validators will monitor submissions of cross chain messages. When they acquire the relevant batch data for which a `rootHash` was generated, they will verify that iterating over it and building a merkle tree produces the same `rootHash`. If this is not true, they will begin a challenge. The challenge process might need to wait for the DA rollup encompassing all relevant messages to be published. As there are no fraud proofs currently it is unclear how the batch part of the challenge will be processed, but the message bundle challenge will require to prove that how the message where a difference is establish is generated and if it matches the sequencer or the validator's view. | ||
|
|
||
| ## Additional details | ||
|
|
||
| 1 - The management contract will only accept `rootHashes` that end in higher `sequenceNo` than what was last published. This will prevent relayers from republishing hashes encompassing the same messages with slight deviations out of order. | ||
| 2 - There is not much point of storing received messages once proven by their `inclusionProof`; Contracts asking for validity can store them as consumed and process directly as callbacks because the relayer is paying. | ||
| 3 - Rollups and message bundles will be signed going through some formatting that makes it impossible to present one as the other. For example we do not want to present a signature over a rollup hash as a signature over a merkle tree root. It shouldn't really be possible to exploit this anyway, but there might be some extreme edge cases which are hard to predict. |
There was a problem hiding this comment.
The PR description is incomplete, and it appears that the required PR checks have not been performed as indicated by the unticked checkbox. It is important to complete the PR description and perform all necessary checks to ensure that the proposed changes are well-understood and that they meet the project's standards for quality and completeness.
Why this change is needed
Please provide a description and a link to the underlying ticket
What changes were made as part of this PR
Please provide a high level list of the changes made
PR checks pre-merging
Please indicate below by ticking the checkbox that you have read and performed the required
PR checks