Ethereum Smart Contracts in L2: Optimistic Rollup

Karl Floersch
Aug 28, 2019 · 9 min read

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.

Image for post
Image for post

Quick Overview

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

  1. Developer writes a Solidity contract named Fred. Hello Fred!
  2. 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.
  3. Aggregator locally applies the transaction & computes the new state root.
  4. Aggregator submits an Ethereum transaction (paying gas) which contains the transaction & state root (an optimistic rollup block).
  5. 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.
  6. 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

  1. Available head state — Any relevant party can download the current head state.
  2. Valid head state — The head state is valid (eg. no invalid state transitions).
  3. 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

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

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

Cryptoeconomic Validity Game

  1. Aggregators post a security deposit to start producing blocks.
  2. Each block contains [access_list, transactions, post_state_root].
  3. 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).
  4. 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:

Image for post
Image for post

There are a few interesting properties that fall out of this state validity game:

  1. Pluggable validity checkers: We can define different validity checkers for is_valid_transition(…) allowing us to use different VMs to run smart contracts including EVM and WASM.
  2. Only one valid chain: Blocks are submitted to Ethereum which gives us a total ordering of transactions & blocks. This enables us to deterministically decide the “head” block, and thereby require aggregators to prune invalid blocks before submitting a new block.
  3. Sharded validation: This validity game can be played out at an individual UTXO basis. Instead of invalidating full blocks, we partially invalidate them — similar to Plasma Cash. Note that this does not require proving all invalid transitions up front for a single block. Partial block invalidation means we can validate only UTXOs for contracts we care about to secure our state. To learn more about how UTXOs enable parallelism check out this video!

A Note on Watchtowers

A Note on Plasma

Security Assumptions

  1. Additionally we assume the mainnet is live, meaning it is not censoring all incoming transactions attempting to prove invalidity. Note that the aggregator unbonding period is in some sense the liveness assumption on the mainnet (eg. if we require a 1 month unbonding period, then invalidity must be proven within that month to forfeit that bond).

Under these assumptions, all invalid blocks / state transitions will be discarded leaving us with a *single* valid head state, satisfying property #2.

#3: Live Head State

  1. Anyone with a bond size above MINIMUM_BOND_SIZE may become an aggregator for the same rollup chain.
  2. Because honest aggregators may prune invalid blocks, the chain does not halt in the event of an invalid block.

With these two properties we’ve already got liveness! Honest aggregators may always submit blocks which fork around invalid blocks & so even if there’s just one non-censoring aggregator your transaction will eventually get through — similar to mainnet.

A Note on Liveness vs Instant Confirmations

Security Assumptions

  1. There exists a non-censoring aggregator.
  2. Mainnet Ethereum is not censoring.

Under these assumptions, the optimistic rollup chain will be able to progress & mutate the head state based on any valid user transactions, satisfying property #3.

Now all three properties are satisfied & we’ve got a permissionless smart contract platform in Ethereum L2!

Scalability Metrics

ERC20 Transfers with ETH1 Data availability

Note that these ERC20 transfers are calldata optimized. Additionally note that the nice thing about Optimistic Rollup is we aren’t limited to ERC20 transfers!

ECDSA Signature
~100 TPS without EIP 2028
~450 TPS with EIP 2028 (coming in October 2019)

BLS Signature / SNARK-ed Signatures
~400 TPS without EIP 2028
~2000 TPS with EIP 2028 (coming in October 2019)

With external availability oracles (eg. ETH2, Bitcoin Cash)

That’s a lot more than 2000 TPS!

Optimistic Rollup vs Plasma

Image for post
Image for post

The similarities between the two solutions allows for lots of shared infrastructure & code between the two constructions. In a mature layer 2 ecosystem it’s likely that we will see rollup, plasma, and state channels all working together in the same client (a smart wallet). Oh, have I mentioned the OVM? 😁

Yay Optimistic Rollup 🎉

Call it “the layer 1 of layer 2s.”

Anyway, enough research — time to implement a robust, comprehensive, and user friendly Ethereum layer 2! 😍

Special thanks to Vitalik Buterin for working through these ideas with me and for coming up with much of this.

Additionally, thank you Ben Jones for much of this and Jinglan Wang, Kevin Ho & Jesse Walden for edits.

Update: Shout out to the great and related work by John Adler in his article on Merged Consensus which can be compared to optimistic rollups — Check it out here! Plus this proposal to improve Eth1’s ability to act as a data availability oracle — more tps!

Plasma Group Blog

Plasma research and development

Thanks to Vitalik Buterin and Jesse Walden

Karl Floersch

Written by

An open source creator who loves spreading the love. Interests include: Cryptoeconomics, Ethereum, P2P, Networking, and of course Meditation.

Plasma Group Blog

Plasma research and development

Karl Floersch

Written by

An open source creator who loves spreading the love. Interests include: Cryptoeconomics, Ethereum, P2P, Networking, and of course Meditation.

Plasma Group Blog

Plasma research and development

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store