Ethereum Layer 2 explained: how rollups batch transactions off the main chain

An Ethereum Layer 2 rollup runs transactions on its own chain. It bundles them into batches and posts the batch data to Ethereum, along with a new summary of its state. Ethereum stores that data and checks the state, either through a fraud-proof window (optimistic rollups) or a cryptographic validity proof (ZK-rollups). Because the data sits on Ethereum, anyone can rebuild the rollup's state. That is why ethereum.org says rollups get their security from Ethereum, and why sidechains, which keep their data elsewhere, do not. The newest change is about capacity. Since the BPO2 upgrade on January 7, 2026, Ethereum's blocks target 14 data blobs for rollups, up from 3 when blobs launched in March 2024.

What counts as a Layer 2

Ethereum.org defines Layer 2 as off-chain scaling solutions that derive their security from Ethereum Mainnet. It lists optimistic rollups, zero-knowledge rollups and state channels in this group.

Some systems that look similar are classed separately:

• Sidechains are independent EVM-compatible chains that run in parallel to Mainnet under their own consensus rules. Ethereum.org says they "derive their security separately from Mainnet."
• Validiums use validity proofs like ZK-rollups, but their transaction data is not stored on Ethereum. Without that data on Ethereum, users rely on whoever holds it.
• Plasma chains are separate chains anchored to Ethereum. They use fraud proofs but are not classed as Layer 2.

In practice, the test is where the transaction data lives. If it is posted to Ethereum, anyone can rebuild the chain's state from Ethereum alone.

How a batch moves from a rollup to Ethereum

1. Users send transactions to the rollup. Most rollups use an operator called a sequencer to order them. Ethereum.org notes that some rollups have a single sequencer, which is "the only entity authorized to submit transactions to the onchain contract."
2. The rollup executes the transactions off-chain and updates its state. That state is a Merkle tree, and its root is stored in a contract on Ethereum.
3. The operator compresses the batch and posts it to Ethereum, either as calldata or, since March 2024, in blobs. Ethereum.org says this lets rollups process "thousands of transactions in a batch and then only post some minimal summary data to Mainnet."
4. The new state root is checked. How it is checked is the main difference between the two rollup types.

If a sequencer ignores a user, optimistic rollups let the user send the transaction straight to the rollup's contract on Ethereum. Per ethereum.org, the sequencer must then include it within a time limit, or the state root it publishes can be proven wrong.

Optimistic rollups vs ZK-rollups

Optimistic rollups: assume valid, allow challenges

Optimistic rollups post batches without proving them. After each batch, a challenge window opens. During it, anyone can dispute the batch by computing a fraud proof. Current designs use multi-round interactive proving. The two sides narrow the dispute down to a single computation step, and Ethereum settles that step. If the fraud proof succeeds, the batch is re-executed and the sequencer responsible is penalised.

• Trust model: Ethereum.org says "the validity of the chain relies on the existence of one honest node" willing to challenge bad batches.
• Withdrawals: Moving funds back to Ethereum means waiting out the challenge period, which ethereum.org puts at "roughly seven days." Users can skip the wait by selling their pending withdrawal to a liquidity provider for a fee. The provider then carries the wait and the risk.
• Compatibility: They are generally easier to make compatible with the Ethereum Virtual Machine (EVM) than ZK-rollups.

ZK-rollups: prove every batch

ZK-rollups attach a validity proof to each batch. Ethereum.org defines it as "a succinct cryptographic commitment verifying the correctness of batched transactions." A new state root counts only after the verifier contract on Ethereum accepts the proof.

• Withdrawals: "There are no delays when moving funds from a ZK-rollup to Ethereum" once the proof is verified.
• Proof types: SNARKs have small proofs and constant-time verification, but they need a trusted setup. STARKs need no trusted setup and are described as resistant to quantum computers, but their proofs are larger and cost more to verify on Ethereum.
• Costs: Ethereum.org says generating proofs takes a lot of computing power and can raise user fees. Verifying a proof on Mainnet costs about 500,000 gas. Proof generation needs specialised hardware, which can concentrate control in a few hands.
• Compatibility: ZK-rollups "are not readily compatible with the Ethereum Virtual Machine." zkEVM projects are working to close that gap.
• Privacy: Publishing data to Ethereum "is not a privacy mechanism." Validity proofs alone do not make transactions confidential.

Blobs: the cheaper data lane, and how it has grown

Posting data is a large part of what a rollup pays Ethereum. EIP-4844 ("proto-danksharding") added blobs, a separate place in each block for that data. It went live in the Dencun upgrade on March 13, 2024. Ethereum.org says Dencun "significantly reduces the cost of rollups."

How blobs work, per the EIP-4844 specification and ethereum.org:

• Each blob holds 4,096 field elements of 32 bytes each, or 128 KiB.
• Blob data cannot be read by EVM execution. Only a commitment to it can.
• Blobs have their own fee market, "independent of normal gas," with an adjustment rule similar to EIP-1559.
• Nodes delete blobs after 4,096 epochs, about 18 days. Blobs are for checking data, not long-term storage. Older data depends on archival services.

Blob capacity per block has been raised three times since launch:

The Fusaka upgrade went live on December 3, 2025 and added PeerDAS. The Ethereum Foundation describes PeerDAS as a protocol that lets nodes "verify blob data availability through sampling" without downloading every blob. That made the later increases possible. Fusaka also introduced Blob Parameter Only (BPO) forks. These are small upgrades that change only the blob target, the blob maximum and the blob fee update fraction. At the BPO2 maximum of 21 blobs, a block can carry up to 2,688 KiB of blob data. The target is the level the fee mechanism aims for over time. The maximum is the hard limit per block.

What to check before trusting a Layer 2

The label "Layer 2" does not tell you how much of a chain's security actually comes from Ethereum. Check four things:

1. Where the data goes. Data posted to Ethereum (calldata or blobs) makes it a rollup. Data kept elsewhere makes it a validium or a sidechain, with weaker guarantees.
2. Whether the proof system is live and open. L2BEAT's Stages framework needs a working proof system even for Stage 0. For optimistic rollups, it also needs at least five outside actors who can submit fraud proofs. Stage 2 needs fraud proofs that anyone can submit.
3. Who can upgrade the contracts, and how fast. At Stage 1, L2BEAT needs a Security Council multisig with at least 8 members and a 75% threshold. Upgrades from anyone else must give users an exit window of at least 5 days. That minimum was 7 days before L2BEAT's April 2026 revision. At Stage 2, users must get at least 30 days to exit before an unwanted upgrade.
4. How withdrawals work. On an optimistic rollup, expect a wait of about a week unless you pay a liquidity provider. On a ZK-rollup, withdrawals depend on how often proofs are posted.

For background, see the explainers on how a blockchain works, how Bitcoin and Ethereum differ and how a smart contract call and its gas fee work.

Limitations: this explains the protocol design and does not compare current fees or throughput on individual rollups, which change constantly.