Superchain Shared Sequencer V2

TLDR; Below is a short proposal for a simple shared-sequencer design that enables synchronous cross-chain transactions with a minimal diff to the current Optimism architecture.

Design Goals

• Enable seamless atomic mint/burn of assets within the superchain to enable a unified native asset layer for the Superchain
• Minimal diff to the current Optimism architecture to reduce technical complexity

Context

Let

$O_i$ and

$B_i$ denote Optimism and Base transactions respectively. Currently, the Optimism and Base sequencer commit to an ordering of transactions:

$$S_O=[O_1,O_2,...,O_N]S_B=[B_1,B_2,...,B_M]$$

We want to enable synchronous cross-chain transactions between Optimism and Base. In other words, an arbitrary transaction

$O_j\in S_O$ should have the power to conditionally include a transaction

$B_j$ in

$S_B$ if and only if

$O_j$ succeeded. Specifically, it should satisfy the following properties:

• If
  $O_j$ executes succesfully,
  $B_j$ gets included in
  $S_B$
• If
  $O_j$ reverts,
  $B_j$ does not get included in
  $S_B$
• $O_j$ and
  $B_j$ should happen at the same "time"

Note that given an arbitrary transaction

$O_j$, it is not possible to know whether the transaction will execute successfully or that it will attempt to emit a cross-chain transaction without execution. Thus, we believe that it is not possible to enable synchronous cross-chain communication without some form of execution at the sequencer level (Espresso and Astria do not execute transactions, so they only enable atomic inclusion of transactions).

A simple shared sequencer design

Here is a simple proposal for a shared sequencer that would enable synchronous cross-chain transactions between Optimism and Base, under a shared trust model.

Instead of routing their transactions to the rollup-specific sequencer, users will send their transactions to the shared sequencer.

Upon receiving a transaction

$T_j$, the shared sequencer will:

• Observe the chain id and sequence
  $T_j$ to be included in
  $S_O$ or
  $S_B$ respectively

Upon receiving a shared transaction

$SS(T_j)$, the shared sequencer will:

• Observe the chain id and request an execution trace for
  $T_j$ on the respective chain
• If the execution trace denotes that the transaction sucessfully executed and requested a cross-chain transaction
  $T_{j+1}$ to be included, the sequencer will include
  $T_{j+1}$ into the requested chain.

How do we make sure the sequencer was not malicious?

To ensure that the sequencer was not malicious, assume a few smart contracts have been implemented on-chain for sending these cross-chain transactions.

On the sending chain:

contract Burn {
    uint256 nonce = 0;
    MerkleTree burns;
    function burn() payable {
        uint256 user = msg.sender
        uint256 value = msg.value;
        bytes32 msgHash = keccak256(user, value, nonce++);
        burns.insert(msgHash);
    }
}

On the receiving chain:

contract Mint {
    uint256 nonce = 0;
    MerkleTree mints;
    function receive(address user, uint256 value) {
        bytes32 msgHash = keccak256(user, value, nonce++);
        mints.insert(msgHash)
        ...
        opETH.mint(user, value)
        ...
    }
}

Note that we implement mint-and-burn for simplicity, but it could be generalized to arbitrary messaging.

Then, for every batch posted on L1, it suffices to prove that the mint and burn Merkle trees have the same root. This can be done using a fraud proof which would require more latency, a ZK proof, or a simple Merkle proof. The design space here is open.

• If the roots do not match, either the sequencer is posting fradulent state roots OR the sequencer failed to include a cross-chain transaction.
• If the roots do match, but it's not supposed to, then the execution fraud proof system will catch the incorrectly executed transactions.
• Note that a Base full node must now run a Optimism full node as well and vice-versa. Certain transactions on Base should only be included if a transaction successfully executed on Optimism. This is the price you pay for atomic composability.

This design is very similar to the existing Optimism sequencer/fraud proof design, but adds 1 extra condition to validate when posting state roots. The fundamental difference between this architecture and other proposals for shared/decentralized sequencers is the following:

Our model:

• enables atomic composability across all chains that are being sequenced (i.e. mint/burn for native assets across all members of the superchain)
• sequencer has to run execution as well as sequencing, but the execution is sharded across the different chains
• superchain specific architecture

Other shared sequencing models (e.g., Espresso or Astria)

• Only allows for atomic transaction inclusion, but not conditional inclusion based on whether a tx executes succesfully
• sequencer doesn't have to run execution (execution is done lazily after sequencing is posted to L1)

Open questions

• How to handle L1 exit
  • Mostly seems to work out of the box, but some edge cases need to be handled.
• How to ensure they get included at the same "time"
  • If we're okay with "time" being at the batch level, the current design works
  • If we want more granularity, we may need to add a global tx index