Rollup Protocol Overview

Table of Contents

This section of the specs describes the rollup protocol and bridge design, which facilitates communications and settles state between Ethereum Mainnet (L1) and the rollup. It does not discuss the particulars of keystore application logic, which are specified in Keystore.

Design Objectives

The rollup protocol design optimizes for the following objectives:

  1. Finality via ZK verification: To achieve objective finality, the rollup verifies the state transition function using ZK validity proofs.
  2. Censorship resistance via force inclusion: Users who are censored by a sequencer can pay more to force include their transactions on L1, with the guarantee that they will be included on L2 within a fixed timeframe.
  3. Minimize dependence on L1 implementation details: The protocol minimizes reliance on L1 implementation details such as the Merkle-Patricia-Trie (MPT) structure of the transaction and receipt tries.
  4. Minimize latency in the typical case: The protocol minimizes time-to-finality in the typical case of honest / live protocol participants, while maintaining soundness in the adversarial case. In particular, the L2 node and sequencer are designed to be resilient to L1 reorgs without waiting for L1 finality for L1-related operations.
  5. No single sequencer or prover assumption for soundness: The protocol is initially designed with a single sequencer and prover. However, in preparation for decentralizing these roles, no part of protocol soundness can rely on the assumption of a single sequencer or prover.

Architecture Overview

The rollup protocol specifies the following components, detailed in the sections below:

  • State, transactions, and blocks: These define the rollup state and its modification via blocks comprised of transactions. We also specify preblocks and batches, which are intermediate data structures used to construct inputs to the state transition function.
  • Rollup bridge, node, sequencer, and prover: The rollup node, sequencer, and prover interact with L1 via the rollup bridge, where the sequencer posts transaction batches, the node reads rollup data and applies the state transition function, and the prover verifies rollup execution in ZK.
  • State transition function: This derives the state of the rollup from L1 data alone. As new L1 data is available, the state transition function maps a rollup state and new L1 blocks to a new rollup state.
  • ZK verifier: This verifies ZK proofs that the state transition function is correctly applied to create new rollup states from previous states.