Optimistic Rollup Architecture
This section develops a model of the architecture of an optimistic rollup by abstracting away most of the internal complexity, and focusing mainly on the interactions between the sequencer and other components. Thus, this model should be sufficient to guide the integration of a wide variety of optimistic rollups with Espresso.
Background
In this model, an Optimistic rollup (OR) is a distributed state machine in which one or more proposers propose new state roots - the result of applying transactions to the current state - and optional challengers verify the state root and challenge it in case it is incorrect. The state transitions are determined by applying the deterministic function which defines the rollup to a sequence of transactions, or state transition requests, starting from a known initial state. This sequence is usually represented as a sequence of blocks, where each block consists of an ordered list of many transactions.
The architecture model will aim to isolate the sequencer, the component of the system which determines this sequence. Modelling the sequencer's interactions with the rest of the system can shed light on how to integrate with Espresso.
Components
We model the rollup as a collection of four abstract components:
The sequencer is responsible for batching transactions from various users into ordered blocks, and then committing to an order of those blocks. The order can be arbitrary or subject to rollup-specific . The important thing is that the order is public and immutable: all rollup users at all times should agree on the relative ordering of blocks.
The proposer's job is to evolve the VM state by applying the sequenced transactions and commit to the new state by posting the new state root to the rollup contract. The result of evolving the state machine is expected to be deterministic: any party evolving the same state through applying the same ordered list of transactions with the transition function of the rollup must arrive at the same evolved state.
The challenger's job is similar to the proposer but instead of posting new state roots to the rollup contract it will challenge the state root in the rollup contract if it computes a different VM state than the proposer. The details of how the challenge process is implemented will differ from rollup to rollup.
The rollup contract's primary functions are to store the state roots, provide an interface for storing sequenced transactions, and provide a challenge mechanism. In reality this functionality is usually split up over multiple contracts.
This model is designed to make it easy to understand what needs to change when an optimistic rollup integrates with Espresso. For a fully functional product other services such APIs for clients to connect to (e. g. a JsonRPC server for EVM rollups) are required.
Transaction Flow
The figure below shows the interactions between these components as a transaction flows through the system. The dashed arrows indicate places where more than one design is possible, and different optimistic rollups may make different choices.
The user submits a transaction. This will often be submitted to a rollup-specific service of the user's choice (such as a JSON-RPC server) before being forwarded to the sequencer. However, many rollups also allow the user to submit directly to the sequencer. In some rollups, the sequencer may even be combined with the rollup service, so that it can execute transactions before sequencing them and filter out invalid transactions.
The sequencer eventually includes the transaction in a block.
The block is sent to the rollup contract, where it is stored. This serves two purposes:
The contract can act as a source of truth for the order of blocks, so that if the sequencer later tries to equivocate, and report a different order to different participants, all parties can take the order saved in the contract as authoritative.
The layer 1 blockchain hosting the contract provides data availability for the rollup. Even if the sequencer goes down, users, proposers and challengers can read the data for each sequenced block from storage in the layer 1 blockchain, which is presumed to be highly available. This means that the sequencer cannot stop any participant from reconstructing the state of the layer 2 blockchain.
The proposer is notified of the new block. They may get it from the rollup contract, or directly from the sequencer. In the latter case, they will authenticate the block provided by the sequencer against the ordering (or a succinct commitment to the ordering) stored in the contract.
The proposer executes the block and updates its local copy of the VM state.
The proposer posts a commitment to the new state to the rollup contract.
The challengers notice a new state being posted to the rollup contract.
The challengers fetch the block and new state root from the rollup contract and use it to re-compute the new state root themselves.
If a challenger finds the state root in the rollup contract to be incorrect it initiates a challenge process. If successful it will obtain a reward and the proposer at fault will be punished.
The user observes the result of their transaction by querying the server provided by the rollup API. If the user does not trust this API they can choose to recompute the state locally (akin to what the proposer does), or wait until the challenge period has expired.
Last updated
