How a rollup works
A rollup runs its own execution environment, usually EVM-compatible, and a sequencer orders user transactions. Instead of each transaction going to Ethereum separately, the rollup compresses a batch and posts it to Ethereum along with a new state root.[1]
A smart contract on Ethereum stores the rollup's state commitment and holds deposited funds. Because the batch data is on Ethereum, anyone can reconstruct the rollup state from it, which is what lets users withdraw even if the operator stops.[2]
The difference between rollup types is how Ethereum becomes convinced that the new state root is correct.
The sequencer gives users fast soft confirmations. Arbitrum's sequencer publishes a feed that gives instant information about transaction order to anyone who trusts it to keep its promise. Final settlement on Ethereum comes later, when the batch is posted and, for optimistic rollups, when the challenge period ends.[5]
In an optimistic rollup, ethereum.org describes a centralized operator that processes transactions. It can delay or reorder them, but it cannot make an invalid state stick: an incorrect batch can be challenged with a fraud proof, and users can exit using the data already posted to Ethereum.[1]
See also: Layer 2 in the glossary
Optimistic rollups
Optimistic rollups post state roots without proving them. Any watcher can submit a fraud proof during a challenge period, and if it succeeds the bad state root is rolled back. Withdrawals from L2 to L1 wait until that period ends, roughly seven days.[1]
Arbitrum documents its challenge period as about 6.4 days. Its protocol assumes at least one honest party watches the chain and can win a dispute within that window.[5]
The OP Stack added fault proofs on OP Mainnet on June 10, 2024. They allow anyone to propose the state of the L2 and anyone to challenge proposals made by others.[6]
The seven-day wait applies only to withdrawals to Ethereum. Transfers and trades inside the rollup settle in seconds, and moving between two apps on the same rollup never touches the challenge period.
The dispute itself works by narrowing a disagreement to a single step. The two parties bisect the disputed execution until one instruction remains, and the L1 contract evaluates only that step to decide who is right. This keeps the onchain cost of a dispute small.[5]
ZK rollups
ZK rollups submit a validity proof with each batch. The Ethereum contract verifies the proof and accepts the new state only if it checks out, so there is no challenge window and funds can exit once the proof is verified.[2]
Because the proof finalizes the state transition, ZK rollups do not need to post every transaction detail the way optimistic rollups do. They still publish enough data to reconstruct the state.[2]
The cost is computation. ethereum.org notes that producing validity proofs requires specialized hardware, which may encourage centralized control of the chain by a few parties.[2]
ethereum.org also notes that building EVM-compatible ZK rollups is difficult because of the complexity of zero-knowledge technology.[2]
Blobs: the cheaper data lane for rollups
EIP-4844, part of the Dencun upgrade, gave rollups a cheaper place to post data: blobs. Each blob holds 4,096 field elements of 32 bytes, or 128 KiB, and consumes 2^17 (131,072) units of blob gas priced in a separate fee market.[3]
Blobs are not kept forever. EIP-4844 sets MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS to 4,096 epochs; at 32 slots of 12 seconds per epoch, that works out to about 18 days, long enough for anyone to download and check the data.[3]
EIP-4844 set blob gas limits equal to a target of 3 blobs per block and a maximum of 6. EIP-7691, part of the Pectra upgrade, raised them to a target of 6 and a maximum of 9.[4]
Danksharding is the longer-term plan: data availability sampling across blobs so validators can confirm blob data is available without each downloading all of it.[7]
Blob gas has its own base fee that rises and falls with blob demand, separate from execution gas, with a floor of 1 wei per unit set by MIN_BASE_FEE_PER_BLOB_GAS. That is why rollup data costs can fall sharply in quiet periods.[3]
| Property | Optimistic rollup | ZK rollup |
|---|---|---|
| How state is checked | Fraud proof if challenged | Validity proof every batch |
| L2 to L1 withdrawal | About 7 days (6.4 on Arbitrum) | After proof is verified |
| Data posted to L1 | Full transaction data | Enough data to rebuild state |
| Main cost driver | L1 data | L1 data plus proof verification |
Worked example: one blob's capacity
A blob holds 131,072 bytes. For this example we assume a simple compressed transfer takes 100 bytes of rollup data; that figure is our assumption, not a published number, and the real size depends on each rollup's compression. Under that assumption, one blob carries about 1,300 transfers.[3]
At the EIP-7691 target of 6 blobs per block, Ethereum carries 786,432 bytes of blob data per block. Divided by the assumed 100 bytes, that is on the order of 7,800 simple transfers per block across all rollups, in a lane priced separately from mainnet execution gas.[4]
Blob space is only one part of a rollup's cost. ethereum.org lists a fixed cost for writing to Ethereum's state, data publication, and, for ZK rollups, proof verification, which it calls the larger cost of operating one. Blob capacity sets the ceiling on throughput, while the fee you see is the sum of these parts.[2]
See also: Across Protocol · Arbiscan
Trust assumptions to check
A rollup is only as safe as its contracts on Ethereum. If a small group can upgrade those contracts instantly, they could in principle change the rules, so check whether upgrades go through a delay that gives users time to exit.
Data availability is what separates a rollup from designs such as validiums. ethereum.org notes that validiums also verify transactions with validity proofs but store transaction data elsewhere, while ZK rollups rely on Ethereum for data availability.[2]
For optimistic rollups, the security model needs at least one party that is watching and able to submit a challenge within the window. Permissionless fault proofs, as on OP Mainnet, mean anyone can play that role.[6]
Sequencer control matters for liveness rather than theft. ethereum.org notes that users can submit transactions on L1 instead of to the sequencer, and the sequencer then has to include them within a time limit to keep producing valid blocks.[1]
Before depositing a large amount, look up three points for the rollup you plan to use: whether its proof system is live, its upgrade delay, and its forced-inclusion path.
See also: Arbitrum on Arbiscan
The bottom line
Pick a rollup by its exit path, not its fee. On an optimistic rollup, a native withdrawal to Ethereum takes about a week; on a ZK rollup it takes as long as proving the batch. Both are cheap today because EIP-4844 and EIP-7691 created 6 target blobs per block, and both depend on posting data to Ethereum, which is what makes them rollups rather than separate chains.[4]
Educational content, not financial advice. Crypto assets are volatile; do your own research.