This post outlines optimistic rollup: a construction which enables autonomous smart contracts on layer 2 (L2) using the OVM. The construction borrows heavily from both plasma and zkRollup designs, and builds on shadow chains as described by Vitalik. This construction resembles plasma but trades off some scalability to enable running fully general (eg. Solidity) smart contracts in layer 2, secured by layer 1. Scalability is proportional to the bandwidth of data availability oracles which include Eth1, Eth2, or even Bitcoin Cash or ETC — providing a near term scalable EVM-like chain in layer 2.

Quick Overview

Let’s start with some intuitions for how optimistic rollup works end to end on mainnet Ethereum, then dive in deep.

The following is a chronicle of the life of an optimistic rollup smart contract… named Fred:

Developer writes a Solidity contract named Fred. Hello Fred! Developer sends transaction off-chain to a bonded aggregator (a layer 2 block producer) which deploys the contract.

— Anyone with a bond may become an aggregator.

— There are multiple aggregators on the same chain.

— Fees are paid however the aggregator wants (account abstraction / meta transactions).

— Developer gets an instant guarantee that the transaction will be included or else the aggregator loses their bond. Aggregator locally applies the transaction & computes the new state root. Aggregator submits an Ethereum transaction (paying gas) which contains the transaction & state root (an optimistic rollup block). If anyone downloads the block & finds that it is invalid, they may prove the invalidity with verify_state_transition(prev_state, block, witness) which:

— Slashes the malicious aggregator & any aggregator who built on top of the invalid block.

— Rewards the prover with a portion of the aggregator’s bond. Fred the smart contract is safe, happy & secure knowing her deployment transaction is now a part of every valid future optimistic rollup state. Plus Fred can be sent mainnet ERC20’s deposited into L2! Yay!

That’s it! The behavior of users & smart contracts should be very similar to what we see today on Ethereum mainnet, except, it scales! Now let’s explore how this whole thing is possible.

Optimistic Rollup In Depth

To begin let’s define what it means to create a permissionless smart contract platform like Ethereum. There are three properties we must satisfy to build one of these lovely state machines:

Available head state — Any relevant party can download the current head state. Valid head state — The head state is valid (eg. no invalid state transitions). Live head state — Any interested party can submit transactions which transition the head state.

You’ll notice that Ethereum layer 1 satisfies these three properties because we believe 1) miners do not mine on unavailable blocks, 2) miners do not mine on invalid blocks*; and 3) not all miners will censor transactions. However, it doesn’t currently scale.

On the other hand, under some similar security assumptions, optimistic rollup can provide all three guarantees at scale. To understand the construction & security assumptions we’ll go over each property we’d like to ensure individually.

#1: Available head state

Optimistic rollup uses classic rollup techniques (outlined here) to ensure data availability of the current state. The technique is simple — block producers (called aggregators) pass all blocks which include transactions & state roots through calldata (ie. the input to an Ethereum function) on Ethereum mainnet. The calldata block is then merklized & a single 32 byte state root is stored. For reference, calldata is 2,000 gas per 32 bytes while storage is 20,000 gas. Additionally, the gas cost of calldata will be reduced by almost 5x in the Istanbul hard fork.

Notably, we can use data availability oracles other than the Ethereum mainnet including Bitcoin Cash and Eth2. With Eth2 phase 1 all shards can serve as data availability oracles, scaling TPS linearly in the number of shards. This is enough throughput that we will hit other scalability bottlenecks before we run out of available data, for example state computation.

Security Assumptions

Here we assume honest majority on Ethereum mainnet. In addition, if we use Eth2, ETC, or Bitcoin Cash, we similarly inherit their honest majority assumptions.

Under these assumptions, using a trusted availability oracle to publish all transactions we can ensure that anyone can compute the current head state, satisfying property #1.

#2: Valid head state

The next property we need to ensure is a valid head state. In zkRollup we use zero-knowledge proofs to ensure validity. While this is a great solution in the long term, for now it is not possible to create efficient zkProofs for arbitrary state transitions. However, there’s still hope for a general purpose EVM-style state machine! We can use a cryptoeconomic validity game similar to plasma / truebit.

Cryptoeconomic Validity Game

At a high level the block submission & validity game is as follows:

Aggregators post a security deposit to start producing blocks. Each block contains [access_list, transactions, post_state_root] . All blocks are committed to a ROLLUP_CHAIN contract by a bonded aggregator on a first come first serve basis (or round robin if desired). Anyone may prove a block invalid, winning a portion of the aggregator’s security deposit.

To prove a block invalid you must prove one of the three following properties:

1. INVALID_BLOCK: The committed block is *invalid*.

This is calculated with `is_valid_transition(prev_state, block, witness) => boolean`

2. SKIPPED_VALID_BLOCK: The committed block "skipped" a valid block.

3. INVALID_PARENT: The committed block's parent is invalid.

These three state transition validity conditions can be visualized as: