Rollups Explained: How Ethereum Layer 2s Work

Ethereum's base layer historically processed roughly 15 transactions per second, and even after recent gas limit increases it averages under 30. At peak demand, that ceiling creates congestion, and congestion creates fees. Transactions that cost a few dollars under normal conditions ran tens of dollars during the network activity spikes of 2021 and 2022.

Rollups fix this without changing Ethereum itself.

How Do Rollups Work as Ethereum Layer 2s?

A rollup executes transactions outside Ethereum, orders them through a sequencer, compresses their data into batches, and posts the data or commitments needed for settlement to Ethereum. Ethereum anchors the rollup's state and enforces its bridge and proof rules. The rollup provides the throughput.

The two main designs differ in how Ethereum determines that a state transition is valid:

• Optimistic rollups assume a submitted state is valid unless it is successfully challenged during a dispute window.
• ZK rollups submit a validity proof that Ethereum verifies before accepting the proven state transition.
• Data availability determines whether the information needed to verify or reconstruct the rollup remains accessible.
• Withdrawal finality depends on the proof design, the rollup's bridge, and when the state is accepted on Ethereum. Optimistic rollup withdrawals through the canonical bridge commonly wait about 7 days. ZK rollups avoid that challenge period, but proof generation, batch submission, Ethereum finality, and bridge processing can still create a delay.

What Does a Rollup Do?

A rollup is a separate blockchain that processes transactions off Ethereum, compresses them into batches, and posts those batches to Ethereum for settlement. Ethereum provides the settlement layer, while the rollup provides the throughput. Transaction fees can drop sharply while transactions still benefit from Ethereum, subject to the rollup's proof system, data availability, bridge contracts, sequencer design, and upgrade controls.

Ethereum stores commitments to the rollup state and the data required by rollups that use Ethereum for data availability. It validates the rollup through a fault-proof or validity-proof system without re-executing each transaction individually as a normal Ethereum transaction. Transactions are processed on the rollup, making them faster and cheaper while anchoring settlement to Ethereum.

How Does a Rollup Work Step by Step?

A rollup processes transactions on its own execution layer, orders them via a sequencer, compresses transactions into batches, and publishes data to Ethereum. Since EIP-4844 activated with Ethereum's Dencun upgrade in March 2024, rollups can use blobs instead of relying only on calldata for data publication.

A cryptographic state commitment is published to Ethereum. In an optimistic rollup, that commitment can become the anchor for a fault challenge. In a ZK rollup, Ethereum verifies a validity proof associated with the state transition.

1. Transaction ordering

Users submit transactions to the rollup's sequencer, the node responsible for ordering incoming transactions and building blocks. The sequencer collects transactions, orders them, and processes them on the rollup's execution layer.

The OP Stack defines how execution, sequencing, data publication, and settlement work together for OP Stack chains.

2. Batch submission

The sequencer or another batch-publishing component compresses transactions and posts the required data to Ethereum. EIP-4844 introduced blobs, a dedicated data format that made Ethereum data publication substantially cheaper for rollups than earlier calldata-only posting.

Blob capacity and fee conditions can change as Ethereum upgrades. The core function remains the same: blobs give rollups a dedicated place to publish data that Ethereum makes available for protocol verification.

3. State commitment

The rollup publishes a state commitment to Ethereum at regular intervals. A state root is a cryptographic fingerprint of the rollup's current state.

For an optimistic rollup, the commitment can be disputed through the deployed fault-proof system. Whether challenges are permissionless and how they work depends on the rollup's implementation and stage of development. OP Mainnet's fault proofs, for example, have been permissionless since June 2024.

For a ZK rollup, the state transition is accompanied by a validity proof. Ethereum verifies the proof before accepting the proven transition.

4. Ethereum settlement

The rollup's bridge contracts use the accepted state on Ethereum to settle deposits and withdrawals. Once Ethereum finalizes the relevant transaction, reversing the accepted rollup state would generally require reversing Ethereum or exploiting an additional rollup-specific control, such as an upgrade mechanism or bridge contract.

What Are the Two Types of Rollups?

Optimistic rollups use a post-submission challenge mechanism. ZK rollups use cryptographic validity proofs. The difference affects how state is accepted, how canonical withdrawals work, and which proof-system risks users inherit.

Neither label alone establishes the complete security level of a deployed chain. Users also need to check data availability, proof-system maturity, bridge controls, sequencer failure paths, upgrade keys, and whether users can force transactions or withdrawals through Ethereum.

Leading Optimistic Rollups: OP Mainnet, Base, Unichain, and Ink

Optimistic rollups assume submitted state transitions are valid by default. They do not require a validity proof with each batch. Instead, they publish state commitments and provide a challenge period during which an incorrect state can be disputed through a fault-proof system.

If a challenger identifies an invalid claim and proves it through the rollup's contracts on Ethereum, the invalid claim is rejected. If no valid challenge succeeds within the configured period, the state can be finalized under the rollup protocol.

Optimistic rollups can provide strong compatibility with Ethereum's execution environment. Smart contracts written for Ethereum can often run without modification, though exact compatibility depends on the rollup implementation.

OP Mainnet, Base, Unichain, and Ink (built by Kraken) are examples of optimistic rollups built with the OP Stack.

ZK Rollups: ZKsync, Starknet, Scroll, and More

ZK rollups generate a cryptographic validity proof for batches of state transitions. This proof mathematically establishes that the proven transition follows the rollup's rules. Ethereum verifies the proof rather than re-executing every rollup transaction.

The validity proof removes the fraud-challenge period. That can make canonical withdrawals faster than optimistic rollup withdrawals. It does not make every withdrawal literally instant: users may still wait for the rollup to close a batch, generate a proof, submit it, receive Ethereum confirmation, and process the bridge message.

The tradeoff historically has been compatibility with Ethereum's execution environment and the cost and complexity of proof generation. ZK teams including ZKsync, Starknet, and Scroll use different approaches to execution and proof generation. Their compatibility, proving systems, and withdrawal behavior should be evaluated individually.

What Is Data Availability, and Why Does It Matter?

Data availability determines whether the information needed to verify or reconstruct a rollup's state is accessible. Standard rollups publish transaction data to Ethereum. That lets independent parties derive the rollup state and support proof or withdrawal mechanisms without relying on the sequencer to keep the data available.

Some systems use external data availability networks to reduce costs. That changes the security model and, under some classification systems, changes whether the network is considered a rollup, validium, or optimium.

Onchain data availability through Ethereum

Transaction data is posted to Ethereum through calldata or blobs. Even if the rollup's sequencer disappears, other parties can use the available data and the rollup's derivation rules to reconstruct the state needed to operate the chain or exercise protocol recovery paths.

EIP-4844 introduced blobs as a dedicated format for rollup data. Ethereum consensus nodes are required to serve blob sidecars for a limited retention window of roughly 18 days under the original EIP-4844 parameters. The blob commitments remain part of Ethereum's consensus history, but long-term access to the complete historical blob contents can depend on archival services and other data-preservation infrastructure.

The retention window is designed to cover the period in which live rollup protocols need the data for verification and disputes. Each rollup still needs a recovery and archival design appropriate to its proof system.

Alternative data availability

Some systems reduce Ethereum posting costs by storing data through networks like Celestia, EigenDA, or Avail rather than Ethereum itself.

This lowers costs but changes the security model. State validity may still be proven or challenged through Ethereum, but users also depend on the external network to keep the transaction data available. If the data is withheld, users may be unable to reconstruct the state even when an invalid transition cannot be finalized.

The terminology varies:

• A validity-proof system with external data availability is commonly called a validium.
• An optimistic system with external data availability is sometimes called an optimium.
• A rollup using Ethereum for data availability inherits Ethereum's availability guarantees for the data published there.

What Security Guarantees Does a Rollup Provide?

A rollup can inherit Ethereum settlement security when it publishes the required data to Ethereum and maintains a working proof, bridge, and recovery mechanism. That inheritance is not automatic. It depends on the deployed contracts and operational controls.

Two core properties are:

• Liveness: Users have a protocol path to submit transactions or withdraw even if the sequencer stops cooperating.
• Finality: Once a rollup state is accepted and finalized through Ethereum, it cannot normally be reversed without reversing Ethereum or using a separate rollup-specific control.

Liveness depends on the rollup's forced-inclusion and escape mechanisms. If the sequencer stops working, the chain may stop producing blocks. Users are protected only if the deployed contracts let them bypass the sequencer or withdraw through Ethereum using available state data and valid proofs.

Finality depends on the rollup type. For optimistic rollups, it follows the dispute period and Ethereum settlement. For ZK rollups, it follows proof acceptance and Ethereum settlement.

L2BEAT's stages framework tracks whether deployed systems have permissionless proofs, working exit mechanisms, restricted upgrade controls, and other properties needed to reduce dependence on operators.

What Is Sequencer Risk?

Most rollups today run a sequencer controlled by the chain's team or a limited operator set. This sequencer determines transaction ordering and inclusion. If the sequencer goes offline, the chain can stop producing blocks. Whether users can continue transacting or withdraw depends on the rollup's forced-inclusion and bridge mechanisms.

Sequencer centralization affects:

• Which transactions get included and in what order
• Whether certain transactions are censored or delayed
• MEV extraction from transaction ordering
• Whether the chain continues producing blocks during an outage

A centralized sequencer cannot create a valid ZK proof for an invalid state transition or win a correctly implemented optimistic fault dispute merely by controlling transaction order. It can still delay, censor, or reorder transactions until users invoke a protocol bypass.

How Do Rollup Withdrawals Reach Finality?

A rollup transaction can appear confirmed by the sequencer before its state is final on Ethereum. Withdrawal finality describes when the canonical bridge can safely release assets on Ethereum.

For an optimistic rollup:

1. The transaction executes on the rollup.
2. The resulting state commitment is submitted to Ethereum.
3. The configured challenge period runs.
4. The state becomes eligible for finalization if no successful challenge invalidates it.
5. The canonical bridge completes the withdrawal.

For a ZK rollup:

1. The transaction executes on the rollup.
2. The operator includes it in a batch.
3. A validity proof is generated.
4. Ethereum verifies the proof and accepts the state transition.
5. The bridge processes the withdrawal.

How Are Rollups Being Used in Production Today?

Rollups process a substantial share of Ethereum ecosystem activity. Current transaction throughput, value secured, fees, and maturity levels change continuously and can be compared through L2BEAT's live activity data.

OP Stack chains support payments, trading, lending, identity, gaming, and general-purpose applications. One production example is ether.fi, which migrated its live consumer payments product, with $220 million in TVL, 300,000 accounts, and 70,000 active cards, to OP Mainnet.

Glossary

Rollup: A blockchain that processes transactions outside Ethereum and publishes the data and state commitments required for settlement and verification.

Sequencer: The component responsible for collecting, ordering, and processing transactions on a rollup's execution layer.

State root: A cryptographic fingerprint of the rollup's current state. It is published to Ethereum as part of the rollup's state commitment.

Fault proof: A challenge mechanism used to show that an optimistic rollup's disputed state claim does not follow the rollup's rules.

Validity proof: A cryptographic proof that establishes that a batch or state transition follows a ZK rollup's rules. Ethereum verifies the proof.

Blob: A dedicated format for rollup data introduced by EIP-4844 in March 2024. Blob contents are retained by Ethereum consensus nodes for a limited period rather than permanently stored as ordinary execution calldata.

Data availability (DA): Whether the transaction data needed to verify or reconstruct a rollup's state is accessible.

Transaction confirmation: The point when a sequencer includes a transaction in a rollup block. This can occur before Ethereum settlement.

Finality: The point at which an accepted state is no longer reversible under the protocol's normal rules.

Withdrawal finality: The point when a canonical bridge can release withdrawn assets on Ethereum.

EVM equivalence: The property of an execution environment matching Ethereum closely enough for Ethereum smart contracts and tooling to run without modification.

Validium: A validity-proof system that stores transaction data outside Ethereum.

Optimium: A term commonly used for an optimistic system that relies on external data availability.