Cross-Domain Composability

Allowing atomic composability with any rollup

A diagram showing the Compose Shared Publisher.
A diagram showing the Compose Shared Publisher.
A diagram showing the Compose Shared Publisher.
The Compose network allows integrated rollups to atomically compose with each other. Still, it's desirable that composability has no bounds. This paper introduces such a missing bridge, providing a new feature that broadens this horizon by enabling native rollups (rollups integrated with Compose) to atomically compose with any other rollup in the ecosystem (outside Compose). The proposed protocol further improves Compose's effort to unify Ethereum by extending the already established Two-Phase commit protocol to achieve atomicity for cross-domain user intents; the guarantee that instructions through many spaces all succeed or don’t.
For more context, read the Shared-Publisher minipaper.
  1. Introduction

Native rollups in Compose can enjoy synchronous atomic composability with each other due to two different mechanisms:

  • A two-phase commit protocol for agreeing on the inclusion of a bundle of transactions (that spans multiple chains).

  • A unified settlement pipeline for synchronous finalization of L2 blocks.

These two general interoperability challenges, i.e., coordination and settlement alignment, arise again when we face composability with external rollups. Fortunately, the architecture of Compose allows these hurdles to be minimized.

The proposed protocol introduces a new actor, the Wrapped-Sequencer (WS),

which represents the external rollup and fulfills the necessary coordination gap. In parallel, secure state updates from the external rollup help with guiding the settlement path.

  1. Compose’s Cross-Domain Composability Protocol

At a high level, CDCP mirrors the structure of the Synchronous Composability Protocol (SCP) but extends it to involve the external rollup (ER), through the wrapped-sequencer (WS), which constantly fetches the latest state from it.

The following explains the protocol steps, denoting the shared publisher by SP and native sequencers (that belong to each rollup integrated with Compose) by NSs, for succinctness.

  1. The SP starts the protocol by broadcasting a start message to everyone.

  2. The NSs and WS then start the simulation phase, in which they exchange mailbox messages, originated by a transaction simulation with a mailbox-aware tracer.

  3. Once the NSs know their execution result, each sends a vote to the SP.

  4. The SP collects the votes and:

  • If any NS votes “No” or there's a timeout, it aborts immediately.

  • If all NSs vote “Yes”, it delegates the final decision to the WS, by sending it a message with the decision from the native rollups.

  1. If the WS also had a local success, it submits its transactions, along with all exchanged mailbox messages, to the ER.

  2. Once the ER replies, signaling the inclusion or exclusion of the transaction, the WS notifies the final decision to the SP, who propagates it to the NSs.

Figure 1: CDCP Sequence Diagram

Atomicity Guarantee

The protocol guarantees that the user's intent succeeds and will be included on all chains or on none of them, respecting both the native and external rollups acknowledgements. 

Settlement alignment is described in section 4.

  1. Safe Execution on the External Rollup

From the protocol analysis, a critical question may arise:

Once the ER executes the transactions on its local state, isn't it possible that the write messages produced by it are different from the ones produced by the WS? Even if it succeeds, wouldn't the native rollups have acted upon different messages, hurting the composability property?

This issue is solved with a new mailbox system specifically developed for the ER, the Pre-Approved Mailbox contract.

The usual Mailbox for native rollups works as follows:

  • The write(m) contract operation stores m in the outbox. The NS detects it and sends m to the sequencer of the destination chain.

  • When a sequencer receives a mailbox message m from another sequencer, it stores it in the inbox by creating a putInbox(m) transaction.

  • The read(m) contract operation reads the message from the inbox if it exists.

The Pre-Approved Mailbox, dedicated to the External Rollup, works the same for read and inbox, but differently for write:

  • Once the WS detects a write(m) operation, it both sends m to the sequencer of the destination chain and also creates a putOutbox(m) transaction to store it in the outbox.

  • The write(m) contract operation does not store m in the outbox, but rather confirms that m exists in it, with the exact same content.

How does this solve the problem? On the WS side, during simulation, it creates putOutbox auxiliary transactions, sending the messages it created to other native sequencers. Once it's time to call the ER, providing both the main transactions and these created auxiliary ones, that mailbox is populated. On the ER side, it executes such auxiliary transactions and then the main transactions, producing its own content for the written messages.  According to the Pre-Approved Mailbox contract:

  • If the new messages produced are exactly the same, the write operation succeeds and so the transaction.

  • Else, it fails, causing the whole transaction to revert.

Because the ER result is tailored to what the WS produced, the consistency between what the ER produces and what NSs received is guaranteed.

It's desirable that the ER executes all of these transactions (the auxiliary and the user’s one) atomically. To guarantee this, the ER only executes a special transaction, called Safe Execution, that encompasses all of them.

function safe_execute(inboxMsgs, outboxMsgs, mainTxs) external {
    for (msg in inboxMsgs) preApprovedMailbox.putInbox(msg...);
    for (msg in outboxMsgs) preApprovedMailbox.putOutbox(msg...);
    for (tx in mainTxs) call tx();
}

It receives as input the list of messages to be inserted via putInbox and putOutbox, followed by the main user transactions. Because the function is atomic, either the mailboxes are populated, and the main transactions succeed, or the mailbox is left untouched, and the transactions fail.

Figure 2. SafeExecute call with putInbox and putOutbox arguments

  1. Settlement Alignment

Alongside coordination, the settlement of cross-chain transactions must also be aligned. This is already present in the current Compose network. Sequencers periodically and synchronously produce proofs that attest to the correctness of their blocks and mailbox states. These proofs are collected by the SP, which verifies mailbox consistency between chains and produces a unique proof to be submitted to L1.

To include optimistic external rollups in the settlement process, the WS will also produce a ZK proof about the ER's state. For rollups that already utilize ZK proofs, the WS can simply extend the ZK proof with the mailbox state. Similarly to native rollups, the SP will verify it and validate for mailbox consistency, generating a final ZK proof that is submitted to L1, ensuring atomicity and correct composability between native and external rollups.

Figure 3: Settlement pipeline schema

  1. Security Considerations

The current design supports a crash-fault-tolerant WS. Its byzantine-tolerant extension will be explored in future work. Still, we can already introduce one of the paths for such robustness: decentralization through a staked committee.

This approach involves opening up the WS role and designing it through an MPC perspective. This automatically achieves the desirable security and decentralization properties that are necessary for such an important role. Firstly, a threshold signature scheme can be used to guarantee that simulation results, mailbox exchanges, and the safe_execute requests are correct.

Moreover, the committee may help manage transitive dependencies. That is, the initial protocol version supports only one ER per session. More precisely, there can't be non-finalized CDCP instances related to different ERs at the same time. This is required because the settlement of the network is tightly coupled with the settlement and inclusion decision of the ER. Thus, if the network's settlement suddenly depends on more than one external source, deadlocks may arise. To improve the protocol's flexibility and allow parallel (but non-conflicting) ERs instances, the WS committee may help with the appropriate scheduling of new CDCP instances.

  1. Conclusion and Future Work

Compose's Cross-Domain Composability Protocol establishes the path for atomic composability between the Compose network and any external rollup in the ecosystem. This represents a significant step towards the goal of making Ethereum unified again.

For the future, we aim at broadening the protocol from supporting a single external rollup per session to multiple parallel ER composability instances, made possible through careful session and parallelism management to avoid transitive dependencies or settlement deadlocks.

Furthermore, we aim at improving the protocol's robustness by making it byzantine fault-tolerant, a key property for our permissionless path. This follows with making the important WS role decentralized, via a staked committee, for example. This automatically enables threshold signatures for mailbox messages on the ER communication level.