Research · Ethereum
Rollups
Last reviewed 2026-09-21Source: ethereum.org scaling documentation and the EIP-4844 specificationArchitecture descriptions only; no throughput, cost or adoption figures are claimed.
The rollup model
A rollup runs its own execution environment and its own state, and it periodically publishes a summary of what it has done to Ethereum. The summary takes two forms: a commitment to the new state, and the data needed to reconstruct it. The commitment is what the base layer enforces; the data is what makes the commitment checkable. A rollup that published a commitment without the data would be asking users to trust it, which is the arrangement rollups exist to avoid.
The reason the model works is that the base layer is used for the expensive part — agreeing on a single history — and not for the cheap part, which is executing transactions. Executing a transaction is cheap on any machine; getting a large number of independent machines to agree on the result is what costs. A rollup executes once and posts the result, so the base layer's cost is paid per batch rather than per transaction, and the saving scales with how many transactions the batch contains.
The model has a hard dependency that is easy to overlook: the data must be available. If a rollup posts a state commitment but withholds the data behind it, no one can reconstruct the state, and users cannot prove what they own or exit with their funds. Data availability is therefore not a performance concern but a safety one, and it is the reason the base layer's data capacity is the binding constraint on how much a rollup can scale. The blobs and data availability page in this cluster covers the mechanism that was added to address it.
Optimistic and zero-knowledge rollups
| Aspect | Optimistic rollup | Zero-knowledge rollup |
|---|---|---|
| Default assumption | The posted state is correct unless challenged | The posted state is correct only if a validity proof verifies |
| What is posted | State commitment plus the transaction data | State commitment plus a succinct validity proof |
| Dispute mechanism | A challenge window during which a fraud proof can be submitted | No challenge window; the proof is verified on the base layer |
| Withdrawal delay | Bounded by the challenge window | Bounded by proof generation and verification, not by a dispute period |
| Base-layer cost | Data posting, plus the cost of fraud proofs when they occur | Data posting, plus the cost of verifying a proof for every batch |
| Proving cost | Low; no proof is generated unless a dispute occurs | High; a proof must be generated for every batch |
Last reviewed 2026-09-21Source: ethereum.org, ScalingThe two families are described as architectures; individual implementations vary.
The optimistic design is the simpler of the two. A sequencer posts a batch and a commitment to the resulting state, and the base layer accepts it. Anyone who believes the batch is wrong can submit a fraud proof during a challenge window, and if the proof succeeds the batch is reverted and the sequencer is penalised. The design is efficient because nothing is proved unless something is disputed, and its cost is the challenge window: a user withdrawing to the base layer must wait for the window to close, because until it does the state they are withdrawing from could still be reverted.
The zero-knowledge design proves every batch. The sequencer produces a succinct proof that the state transition is correct, and the base layer verifies the proof before accepting the new state. Because the proof is verified rather than disputed, there is no challenge window and no fraud-proof game, and a withdrawal is limited by how long the proof takes to generate rather than by a dispute period. The cost is that a proof must be produced for every batch, which is computationally expensive and is the reason the design took longer to reach production.
The two designs are converging in practice. Optimistic rollups have added mechanisms to shorten effective withdrawal times, and zero-knowledge rollups have reduced proving costs. The distinction that remains is what a user is trusting: an optimistic rollup user trusts that someone will challenge a bad batch within the window, and a zero-knowledge rollup user trusts the proof system and its implementation. Neither is trustless in the sense that the base layer is trustless, and both are more trustworthy than a centralised service that holds the funds.
What a user is actually trusting
The trust assumptions of a rollup are not uniform, and they are usually described in stages rather than as a single property. The first question is whether the rollup's state commitment is enforced on the base layer at all, or whether the base layer merely records what the rollup says. The second is whether the data behind the commitment is available, because a commitment without data cannot be used to exit. The third is who can post batches, and whether a user has a way to force a transaction through if the sequencer refuses to include it.
The third question is the one that most often separates a rollup from a centralised service. If a single sequencer decides what goes into each batch and there is no mechanism for a user to bypass it, then the sequencer can censor a user indefinitely, and the rollup's guarantees are weaker than they appear. The mechanism that addresses this is forced inclusion: a path by which a user can submit a transaction directly to the base layer and have it included in the rollup's state regardless of the sequencer's wishes. The L2 sequencers page in this cluster covers how that works and how far each design has gone toward it.
The honest summary is that a rollup is a spectrum rather than a category. At one end is a system whose state is enforced by the base layer, whose data is always available, and whose sequencing is open to anyone; at the other is a system that posts commitments to the base layer while retaining full control over execution and ordering. Both are sometimes called rollups, and the difference between them is the difference between a user who can exit unilaterally and a user who cannot.
Sources and references
The rollup model and the two families described above are taken from Ethereum's scaling documentation and the blob specification.
- Scaling and rollups. ethereum.org, Scaling: the rollup model, and how it differs from other scaling approaches.
- Optimistic rollups. ethereum.org, Optimistic rollups: the challenge window, fraud proofs, and the withdrawal delay they impose.
- Zero-knowledge rollups. ethereum.org, Zero-knowledge rollups: validity proofs, and why they remove the challenge window.
- The data-availability change that reduced rollup costs. Ethereum Improvement Proposals, EIP-4844: Shard Blob Transactions: the blob space a rollup posts its data to.
Related reading
- Research HubEvery dataset on the site, with methodology and provenance.
- Altcoin ResearchAltcoins measured against Bitcoin: design intent, consensus, execution, scaling and market structure.
- The ETH-BTC Correlation RecordHow the correlation is measured, how it behaves across windows, and where it breaks down.
- The ETH/BTC RatioWhat the ratio measures, how to read its trend, and why it is not a forecast.
- ETH During Bitcoin Bull PhasesAssociation within a common market factor, and what co-movement cannot establish.
- ETH During Bitcoin Bear PhasesDrawdown depth and duration compared over identical windows, and the limits of the comparison.