“Collaborative Validity Ranking” New Direction: Achieving Atomic Interoperability between Rollups

"Collaborative Validity Ranking": Achieving Interoperability between Rollups

Original Source: umbraresearch

Original Author: @pumatheuma (CEO, SuccinctLabs), @0xShitTrader (Cofounder, EllipsisLabs), @jtguibas (CTO, SuccinctLabs)

Original Title: SharedValiditySequencing

Translation: Yvonne, MarsBit

Introduction

The future of Ethereum scaling is a world with thousands of rollups. Currently, the dominant rollup is optimistic rollup, and most rollup-as-a-service companies are building optimistic rollup.

However, there are two main problems with optimistic rollup in its current design:

Rollups rely on centralized sequencers, which is a form of soft censorship and MEV centralization.

There is no good solution to achieve atomic interoperability between optimistic rollups. Due to the 7-day challenge period in the security model of optimistic rollup, optimistic rollup cannot verify the state of another party without waiting for the anti-fraud window to pass. Therefore, existing cross-rollup bridging and interoperability (arbitrary message passing) designs are inherently centralized and asynchronous.

Shared, decentralized sequencer sets have been proposed as a way to decentralize the sequencer role for rollups. However, existing designs only perform transaction ordering, so they only solve the first problem and do not solve atomic cross-rollup interoperability.

In this paper, we propose a shared sequencer structure that supports atomic cross-rollup interoperability. Shared validity sequencing unlocks a unified native asset layer that can serve the entire rollup ecosystem.

Background

Consider two optimistic rollups A and B. This design can be generalized to N rollups, but for clarity, we describe the system with two rollups.

In the current environment, the two sequencers for A and B independently order transactions for their respective rollups. The goal is to achieve atomic cross-chain operations between A and B. Specifically, transaction ai on A can only be included and succeed if and only if transaction bj on B is included and succeeds (not rolled back).

A typical example of this primitive is the destruction and minting of shared tokens between two rollups. When a user bridges a shared token from rollup A to rollup B, it is required that the destruction transaction on side chain A can only succeed when the minting transaction on rollup B succeeds. Otherwise, funds may be lost (e.g., if destruction succeeds but minting fails) or erroneously minted (e.g., if destruction is rolled back due to insufficient user funds, but minting is still included).

Note that without executing transaction a i, it is not possible to know whether the transaction can be successfully executed or whether its success depends on cross-domain conditions. Without some degree of sorter-level execution, it may not be possible to enable cross-rollup atomicity.

Existing designs of shared sorters do not require sorter execution of transactions, so they can only achieve a weak form of interoperability through condition inclusion. Atomic transactions contained in non-executing shared sorters cannot achieve atomic bridging of tokens, since the invariant of token minting/burning cannot have the same security as underlying fraud proof mechanisms. Overall, atomic conditional transaction execution is more expressive than atomic transaction inclusion.

Shared Validity Sorter

Here we describe the Shared Validity Sorter, a shared sorter design that enables atomic cross-chain interoperability between optimistic rollups. The design has three key components:

The method by which the shared sorter accepts cross-chain operations

The block-building algorithm of the shared sorter to process these cross-chain operations while respecting atomicity and conditional execution guarantees

Enforcement of the guarantees involved in these cross-chain operations through shared fraud proofs.

For simplicity, we outline a system that enables atomic minting and burning operations between two rollups: the burn operation on rollup A succeeds only if the corresponding mint operation on rollup B succeeds. Later, we will extend this system to arbitrary cross-rollup message passing.

Cross-chain operation of the system contract

Current rollups already include system contracts that implement specific rollup functionality, such as bidirectional message passing between L1 and L2, and other special precompilations. We propose adding a system contract that allows other smart contracts to trigger cross-chain operations.

The copy of this contract is stored on two rollups and is used for atomic bridging of native tokens. On rollup A, burnTree contains all included burn actions. On rollup B, mintretree contains all included mint actions. The expected invariant is that the burnTree on A is the same as the mintretree on B, or their Merkle roots are equal.

Block Building with Shared Validity Sorting

In this design, rollup A and rollup B share a sorter. This shared sorter is responsible for sending transaction batches and declared state roots to L1. The shared sorter can be a centralized sorter, like today’s production rollup sorter, or a leader in a decentralized sorter network.

The only requirement we make is that the shared sequencer must publish transaction batches and the declaration state roots of the two rollups to L1 in the same transaction. While different rollups can choose different methods for transaction ordering and block construction, our modifications to the block builder should be compatible with most sorting mechanisms.

The shared sorter receives transactions and constructs blocks for A and B. For each transaction on A, the sorter executes the transaction and checks if it interacts with the MintBurnSystemContract. If the transaction is successfully executed and interacts with the burn function, the shared sorter attempts to execute the corresponding mint transaction on B. If the mint transaction succeeds, the shared sorter includes the burn on A and mint on B; then, if the mint transaction fails, the shared sorter excludes these two transactions.

The above block construction modification is a simple extension to the existing block construction algorithm. It only requires the shared sorter to construct blocks for two rollups, and the sorter executes transactions and inserts conditionally triggered transactions from one rollup to another rollup.

Shared Fraud Proof

The most important part of optimistic rollup is the effective, permissionless fraud proof; this is how the rollup inherits security from the underlying L1 (currently, Optimism does not have fraud proofs, while Arbitrum has included fraud proofs in the whitelist). We have described how the shared sorter conditionally includes transactions on two chains that it sorts at the same time. Now we describe how to enforce conditional inclusion through fraud proofs.

Fraud proofs are a mechanism on L1 that ensures that the rollup sequencer honestly processes transactions and updates states. There is a simple and elegant way to extend the existing anti-fraud mechanism to ensure that the sorter honestly handles cross-chain operations and includes these conditional transactions correctly.

The MintBurnSystemContract described above maintains a Merkle tree of all burn transactions on one rollup and maintains the corresponding mint transactions on another rollup. Entries are only added to the Merkle tree if the transaction is successfully executed. Therefore, to ensure that all burn transactions on rollup A have corresponding mint transactions on rollup B, it is sufficient to check that the Merkle root of the burnTree on A matches the Merkle root of the mintretree on B.

Only slight modifications need to be made to the existing fraud proof mechanisms of rollups A and B. If the root of burnTree on A does not match the root of mintretree on B, it is considered an incorrect sort, and the person responsible for sorting may be punished.

An alternative mechanism for implementing cross-chain atomicity guarantees is for the L1 smart contract that accepts rollup transaction batches to also require a Merkle proof that proves that the root of burnTree on A matches the root of mintretree on B, rather than the state root claimed at the time of batch submission.

Universality beyond minting and burning

We have outlined the shared validity sequencing with only mint and burn functions. But it can easily be generalized to arbitrary message passing and conditional transaction execution across multiple rollups. A cross-rollup action can be called where the invariant is that either all triggered contract calls succeed and are included or none succeed.

Properties of shared validity sequencing

Compared to a single chain

A set of rollups that support atomic cross-rollup transactions via shared validity sequencing can be thought of as a big chain with multiple shards. The advantages compared to a single rollup are:

Native fee markets for each individual rollup.

Lockset pricing mechanism: cross-rollup action effectively acquires lock on both chains.

Out-of-the-box sharding: it is possible to choose to trust certain shards and verify others.

Support for different execution environments, such as application chains with runtimes optimized for specific use cases.

These are differentiating factors compared to a single rollup. The biggest difference compared to high-performance base layers like Solana (which supports parallel execution and weak-form native fee market) is the native support for different execution environments and compatibility with the Ethereum roadmap. However, with shared validity sequencing, multiple rollups combine into a shard state machine, which is a coarse and inefficient implementation relative to a base layer designed from day one to support parallelism. Throughput, fees, and finality will always be limited by Ethereum.

Sequencer and node requirements

Compared to the shared sequencer design that does not execute transactions, shared validity sequencing puts more load on the shared sequencer. The shared sequencer needs to execute all transactions to access the current state and determine whether they should trigger the execution of other transactions. Note that by default, cross-rollup execution can still be sharded.

A full node operator of rollup A also needs to run a full node of rollup B because A’s validity depends not only on A’s valid state transitions, but also on the validity of the cross-rollup state (A+B). To verify A’s validity, the node operator also needs to verify the validity of the cross-rollup state (A+B), which requires verifying B’s validity.

Sovereignty

The model ties the effectiveness of rollups A and B together, as the effectiveness of their respective states now depends on each other. This is a subjective decision made by rollups for composability. Their application is more sovereign than deploying on a single chain, but less than an application-specific chain. We will explore the trade-offs between these models in future articles.

ZK Rollup Application

ZK rollups have out-of-the-box asynchronous interoperability, as they can directly verify each other’s ZK proofs. However, atomic interoperability still has benefits, including better user experience and synchronous composability.

While this design of shared validity sequencing was built for optimistic rollups, it can be slightly modified to be applicable to ZK rollups. The MintBurnSystemContract and sequencer block building algorithm remain unchanged. The shared fraud proof is replaced by a proposed alternative mechanism, where the L1 smart contract accepts batch transactions and verifies the ZK proof for rollup state transitions, and now also verifies that the root of burnTree on rollup A matches the root of mintTree on rollup B.

With ZK rollups designed under this approach, a full node operator of A does not need to run a full node for B. To verify cross-rollup invariants, it simply verifies B’s state transition proof and uses Merkle proofs to obtain B’s MintBurnSystemContract state.

Conclusion

In this article, we describe Shared Validity Sequencing, a shared sequencer design that supports atomic interoperability between rollups. In this design, the sequencer not only sorts transactions, but also executes them, allowing for enforcement of cross-chain invariants while increasing the load on the sequencer and node operators. By choosing to share validity with other rollups, rollups gain atomic interoperability and its associated benefits (such as a unified native asset layer). The system can be generalized to multiple rollups, including ZK rollups.

Shared Validity Sequencing and its trade-offs may be relevant to some rollup ecosystems. To collaborate with us, please email [email protected].