Patents Wiki
Back to briefings
GuideCryptography

The side chain that bet on honesty first

For most of 2018 and the first half of 2019, the loudest conversation in the Ethereum research community was not about consensus. It was about how to fit the world inside a chain that could only process fifteen transactions per second. Layer 2 was the agreed-upon destination, but the map kept getting redrawn. Plasma promised exits. Channels promised speed. Commit chains promised bandwidth. A long list of proposals each picked a different point in the trust-versus-throughput plane. Into that crowded field, in April 2019, an arXiv preprint from John Adler and Mikerah Quintyne-Collins quietly proposed something the rest of the field would spend the rest of the year trying to name. By the time the third revision of that preprint landed in July 2020, the construction had a label, a security model, and a small group of teams building production systems on top of it. The label was "optimistic rollup." The paper that introduced it is the most direct record we have of why this particular design won the argument.

The paper at a glance

  • arXiv ID: 1904.06441
  • Title: Building Scalable Decentralized Payment Systems
  • Authors: John Adler, Mikerah Quintyne-Collins
  • Institutions: Independent, HashCloak
  • Venue: arXiv preprint (cs.CR)
  • Submission date: April 12, 2019 (v1), revised May 24, 2019 (v2), July 24, 2020 (v3)
  • DataCite DOI: 10.48550/arXiv.1904.06441
  • Source: arXiv:1904.06441

Why fifteen transactions per second was never going to be enough

Adler and Quintyne-Collins open with a number that, in late 2020, has become hard to read in cold prose. Bitcoin processes an average of three transactions per second and is operating at maximum capacity. Ethereum is capped at fifteen transactions per second and is regularly at its ceiling. Global payment processors, by contrast, clear tens of thousands of transactions per second. The gap is large enough to define the difference between a settlement rail and a peer-to-peer experiment.

The paper is careful to point out that you can get more throughput trivially by removing decentralization or by removing security. The interesting question is how to keep both. The authors split the design space into Layer 1 and Layer 2. Layer 1 is the territory of sharding, where you split the chain into parallel sub-chains that share security. Layer 2 moves transactions off the base chain, settles to it periodically, and inherits its security through cryptography. State channels, Plasma, Arbitrum, and the proposal in this paper are all Layer 2 strategies. The question each one answers differently is: what exactly do you have to post back to the base chain, and what can a user be sure of without being online forever?

The construction that bet on a single honest watcher

The optimistic rollup construction is, at heart, a side chain that runs consensus on the parent chain. The paper proposes deploying a contract on the parent chain (assumed throughout to be Ethereum) that keeps track of side chain block headers, deposits, withdrawals, and the fraud proofs that arbitrate disputes. A leader-selection protocol runs entirely inside that contract, which the authors call "merged consensus," a name they distinguish from the older "merged mining" idea popularized by Namecoin. The distinction matters: in merged mining, a parent chain's hash power secures a child chain. In merged consensus, the parent chain's consensus itself schedules the side chain's block production.

The contract accepts a side chain block from a leader who has posted a bond. The block must extend the current tip known to the contract, and the full block is posted in the transaction's data field. On Ethereum, that means calldata. The contract Merklelizes the side chain transactions and either compares the resulting root to a posted transactions root or computes the block header hash itself, running a light client of the side chain on-chain. After a parametrizable finalization delay, an unchallenged block becomes irreversible. If anyone believes a non-finalized block contains an invalid state transition, they can submit a non-interactive fraud proof on-chain. A valid fraud proof rolls the tip back to the previous block, slashes the leader's bond, and rewards half of it to the prover. The other half is burned.

This is the bet. The construction assumes that at least one honest full validator is watching the chain and will submit a fraud proof inside the finalization window. If that assumption holds, invalid state transitions are punished. If it fails, an invalid block can finalize. The system is "optimistic" in the same sense that optimistic concurrency control is optimistic: it proceeds without explicit checks and relies on the threat of retroactive punishment to keep everyone honest.

The construction is also clean in its handling of users. Deposits are simple transfers to the contract, spendable on the side chain immediately. Withdrawals are non-interactive: burn the funds on the side chain, then post a withdrawal request with an inclusion proof against a finalized side chain block. Users do not need to be online indefinitely, which is the property that distinguished this design from earlier Plasma-style constructions. Leader selection is "first come, first served" and runs entirely on the parent chain, so anyone can become a block producer (even if every other producer is censoring transactions), and Sybil resistance is inherited from the parent chain rather than re-derived from scratch.

Core architecture and flow

From posts to finality, in three pages

The mechanics section of the paper is short and self-contained. Section 3.1 sets up the side-chain-with-merged-consensus construction in plain language. Section 3.2 walks through the deposit, block production, fraud proof, and withdrawal flow. Section 3.3 sharpens the merged-consensus terminology, distinguishes it from merged mining, and shows, in three figures, the normal path, the case where two producers mine on different parent-chain heads, and the resolution when the parent chain reorgs to follow a new longest head.

The authors are explicit about what they mean by "trustless." A blockchain system is trustless, in their definition, if and only if its state is both live and safe. It is decentralized if and only if it is distributed, trustless, and permissionless. With that yardstick, the construction's liveness follows from the fact that anyone can become a side chain block producer, so all state elements are live subject only to finite delay. Its safety follows from the fact that anyone can fully validate the side chain client-side (all data is on-chain) and submit a fraud proof, so as long as the parent chain is not being censored for the entire finalization delay, every state element is safe. The authors are direct that the scheme is "optimally trustless modulo an assumption on the small amount of block space needed to post a fraud proof." That is, in their reading, a stronger guarantee than Plasma chains or state channels, both of which are vulnerable to chain congestion.

There is one last design point worth pulling out. Because the parent chain acts as a timestamping server and the side chain is fork-free by construction, the leader-selection rule can be the simplest possible one: first come, first served. The paper credits the commit-chain paradigm (and NOCUST, by Khalil, Gervais, and Felley) for that insight, and it is the point at which the design stops looking exotic and starts looking inevitable.

The five engineering bets that became research programs

The deepest signal in the paper is not the construction itself. It is the list of follow-on engineering directions the authors put at the end of the design section, because every one of those directions had, by the end of 2020, become its own active research program.

The first is parallelizable data authentication and availability: separate consensus on execution from data availability on the parent chain, and let transactions flag invariants so that Merkleization can be pre-processed as a pure function outside the EVM. The second is UTXO-specific fraud proofs that avoid intermediate state serialization entirely, by having the block producer attach metadata to each input that commits to the exact output being spent. A non-interactive fraud proof can then disprove the claim without serializing state after every transaction. The third is the state-lookupless client paradigm, extending stateless-client and Utreexo ideas to a UTXO model where validating a stateless transaction and confirming it is not double-spent in later blocks is "an entirely stateless process." The fourth is on-chain data availability proofs via a precompile, with the Al-Bassam, Sonnino, and Buterin data-availability scheme cited as the canonical example and LazyLedger named as the system that takes the separation of execution, data, and ordering furthest. The fifth is halting for weaker synchrony requirements: stop producing side chain blocks after a fixed, predetermined time window, then run a long fraud-proof-only window so that users know exactly when they have to be online, rather than having to be online forever.

Every sentence in that list maps to a real, named research effort underway by the end of 2020, whether the question is data-availability sampling, fraud-proof formats, stateless clients, or the synchrony assumptions L2 systems are willing to make. The paper is a design document, and it is also a forecast.

What this means for the L2 conversation

The optimistic rollup framing did three things to the L2 conversation in 2020, and the paper is the artifact that lets you see all of them at once. It gave the field a shared vocabulary: "rollup" as a verb for the act of posting batched transaction data to the parent chain, "optimistic" as the assumption that at least one honest validator is watching, and "fraud proof" as the cryptographic instrument that enforces the assumption. It gave the field a security template: trust-minimized exits, full data availability on the parent chain, no requirement for users to be online indefinitely, and permissionless leader selection. Those are the four properties Section 4 explicitly argues no prior construction delivers in combination. And it gave the field a research agenda: the five engineering directions in Section 3.5 are the agenda the rest of 2020 and 2021 are now executing against.

The fact that the paper is a preprint does not change its centrality. It has been cited as the canonical source for the construction by every subsequent write-up that uses the term "optimistic rollup" in the structural sense, and the L2 ecosystem's documentation traces the term back to it. For a reader trying to understand why the Ethereum community converged on this particular scaling strategy, this is the document to read first.

Where the construction is still soft

It is worth being honest about the edges. The adversarial model is "weaker than a majority block producer censorship attack on the parent chain," which the paper calls an "optimal" model, but the word "optimal" is doing a lot of work. The scheme's safety depends on a small amount of parent-chain block space being available to post a fraud proof, and the parent chain is, by assumption, the same congested chain the side chain is trying to relieve. The authors are aware of this and argue it is a stronger guarantee than Plasma or channels, which are vulnerable to the same congestion in worse ways. The argument is right, but the underlying constraint is real and has not gone away.

The "merged consensus" terminology is also a known source of confusion. The paper is explicit on this point, but the names are close enough that a casual reader can be forgiven for mixing them up, and the field has not yet settled on a uniform alternative. The state-lookupless client work depends on accumulator and witness technology that is still moving in late 2020, and the on-chain data-availability proof work is gated on precompile work and on the broader data-availability-sampling research agenda, both of which are still in motion.

Then there is the question the paper does not ask, because it is the question the field is only now starting to ask. If the optimistic assumption is "at least one honest validator is watching," what happens when the economics of validation change? When fees on the side chain are too low to pay for full validation, when the bond size is miscalibrated relative to the value at stake, when the finalization window is shortened in the name of UX and the proof window becomes the new bottleneck. These are incentive-compatibility questions that the paper gestures at in its security analysis but does not answer in detail. The incentive-compatibility literature that has built on top of it in 2020 is where to look for that work.

Sources