In a zk-rollup vs optimistic rollup comparison, both run transactions off the main chain and post the data back to it. An optimistic rollup assumes each batch is valid and gives anyone a window to prove fraud. A zk-rollup sends a validity proof with each batch, so the main chain checks the batch as soon as the proof is verified. The trade is withdrawal time against proving cost.
Both are layer 2 networks on Ethereum. They exist because running every transaction on the main chain is slow and costly, and both move the heavy work off-chain while keeping Ethereum as the place where the final state is settled. This post compares them row by row, explains each mechanism, and lists which well-known networks use which design.
zk-rollups vs optimistic rollups at a glance
| Optimistic rollup | zk-rollup |
|---|
| How a batch is checked | Assumed valid; anyone can submit a fraud proof during the challenge period | A validity proof is verified by a contract on Ethereum |
| Withdrawal to Ethereum | About one week, after the challenge period ends | No challenge delay; exits run once the proof is verified |
| Main cost driver | Posting data to Ethereum | Posting data plus generating proofs, which is resource-intensive |
| EVM compatibility | Compatible with the EVM (the Ethereum Virtual Machine that runs smart contracts), so existing apps port easily | Needs a zkEVM to run Ethereum smart contracts |
| Data posted on-chain | Transactions as calldata (transaction input data stored on-chain) or blobs | Transactions or state data as calldata or blobs |
| Examples | Arbitrum One, OP Stack chains | Starknet, ZKsync, Linea |
Sources: the ethereum.org developer docs on optimistic rollups, zk-rollups, validium and danksharding (read 2026-11-12); project docs named in the section on which rollup is which.
How an optimistic rollup works
An optimistic rollup does not prove that its batches are correct. It assumes the off-chain transactions are valid and posts them to Ethereum without a validity proof, as ethereum.org describes. Correctness comes from a fraud-proving scheme that catches batches that were calculated wrongly.
After a batch is posted, a challenge period starts. ethereum.org gives it as roughly seven days. During that window, any watcher can recompute a batch and submit a fraud proof if the result is wrong. If the proof holds, the rollup's state is corrected and the party that posted the batch loses its bond, a deposit it locked up as a promise to act honestly. One honest watcher is enough to keep the chain correct.
The challenge period is also why withdrawals are slow. Users must wait for it to end before their funds can leave the rollup for Ethereum. The upside is simplicity: there are no proofs to generate, and optimistic rollups are compatible with the EVM, so existing applications move over with few changes.
How a zk-rollup works
A zk-rollup proves each batch instead of assuming it. The rollup operator runs the batch and produces a validity proof: a short piece of math that shows the new balances follow correctly from the old ones and the transactions. Per ethereum.org, these succinct proofs show that off-chain state changes were computed correctly. A contract on Ethereum checks the proof, and an invalid batch is rejected because its proof fails.
There is no challenge window, so there is no withdrawal delay of that kind. Exit transactions run once the rollup contract verifies the validity proof. The cost moves elsewhere: operators must generate a proof for every batch, which takes real computing power, and checking the proof on Ethereum costs gas, which ethereum.org puts at about 500,000 gas.
A common belief is that zk-rollups cannot run smart contracts. Proving general-purpose EVM computation inside circuits is harder and costs more, as ethereum.org notes, but it is done today. A
zkEVM recreates Ethereum's basic instructions inside the proof system, so a zk-rollup can execute smart contracts. Some zk-rollups use SNARK proofs and others use STARKs; Starknet, for example, uses STARK-based proofs. Our comparison of zk-SNARKs vs zk-STARKs explains the difference.
Which rollup is which
These answers come from each project's own documentation, read on 2026-11-12. Designs change over time, so check the project docs before you rely on them.
- Arbitrum One: optimistic rollup. The Arbitrum docs state that Arbitrum is an optimistic rollup.
- OP Stack chains: optimistic rollups. The Optimism docs state that an OP Stack chain is an optimistic rollup.
- Starknet: zk-rollup. The Starknet docs describe it as a validity rollup that uses STARK-based proofs.
- ZKsync: zk-rollup. The ZKsync docs describe a network of chains secured by zero-knowledge proofs, where zk-rollup is the recommended mode and validium is an option.
- Linea: zk-rollup. The Linea docs describe its stack as a zero-knowledge rollup stack.
How decentralized each network is today is a separate question from its proof type. Our post on the
security classification of rollups covers that side.
Do zk-rollups give privacy?
No, not by default. ethereum.org is direct about this: whichever mechanism a rollup uses, the published data is public, and using validity proofs for scaling does not by itself make transactions confidential. The proof shows the batch was computed correctly; it does not hide what was in it.
Where the data lives: rollup vs validium
A rollup posts its transaction data to Ethereum, as calldata or as blobs. Blobs arrived with EIP-4844 in the Dencun upgrade of March 2024 and give rollups a cheaper place to post data, which is pruned after about 18 days, according to ethereum.org's page on danksharding. A validium is a close cousin of a zk-rollup rather than a third type: it also uses validity proofs, but it keeps the transaction data off Ethereum. ethereum.org notes the trade: lower cost, but if the operators withhold the data, users can have their funds frozen.
Rollups prove execution, not the data behind it
A rollup proves its own state changes: that each transaction in a batch was applied correctly to the rollup's state. It does not prove anything about data that lives outside the chain, such as a fund's holdings, a reserve report or a customer database. That data needs its own proof before a smart contract or an auditor can rely on it.
This is the gap zkDatabase is built for. zkDatabase is a verifiable database powered by
Zero-Knowledge Proofs. It stores data as documents in collections, generates a proof for every update, and lets smart contracts on EVM chains check those proofs without seeing the data. For example, a stablecoin issuer can prove that its reserve report adds up without publishing its bank accounts. The same thinking shapes our research on
ZK-Data-Rollups. Orochi's data availability layer, zkDA, is on the roadmap and not live yet.
FAQ
Which is cheaper, a zk-rollup or an optimistic rollup?
It depends on activity. Optimistic rollups skip proof generation, so they avoid that cost. zk-rollups pay for proofs, but each proof covers a whole batch. Both pay to post data to Ethereum, and since EIP-4844 they can post it as blobs, which costs less than calldata.
Which is safer?
They rest on different assumptions. An optimistic rollup is safe if at least one honest party watches and submits fraud proofs in time. A zk-rollup is safe if its proof system and circuits are correct. In both, the operator setup and upgrade rights also matter.
Why do optimistic rollup withdrawals take days?
Because the rollup must leave time for anyone to challenge a batch. Funds can leave only after the challenge period, about one week, has passed with no successful fraud proof.
View Docs: see how zkDatabase proves off-chain data for smart contracts on EVM chains.