Ethereum Rollups Explained: How Optimistic and ZK Rollups Actually Differ

This article covers the two main approaches to scaling Ethereum — optimistic rollups and ZK rollups — what each one actually does, how they differ mechanically, and what those differences mean when you use them. If you've bounced off this topic before, the sticking point was probably that nobody explained why these two designs exist. That's where we start.

Ethereum's base layer (called Layer 1 or L1) can process roughly 15–30 transactions per second. That's not enough. When demand spikes, fees spike with it — sometimes to tens of dollars per transaction. Rollups are a scaling strategy: they execute transactions on a separate chain (a Layer 2 or L2), then post a compressed summary of those transactions back to Ethereum. Ethereum still acts as the final authority on what happened, but the expensive computation happens somewhere cheaper.

• Rollups inherit Ethereum's security because their transaction data gets permanently recorded on L1
• They batch hundreds or thousands of transactions into a single L1 submission, spreading the cost across all users
• Users interact with rollups through a bridge — a smart contract that locks your assets on L1 and makes them available on L2
• The core design question for any rollup: how does Ethereum verify that the L2 didn't process fraudulent transactions?

What this means practically: You pay lower fees on a rollup than on Ethereum directly, but your transactions are still ultimately secured by Ethereum's validator set.

Optimistic rollups assume every batch of transactions posted to Ethereum is valid — unless someone proves otherwise. That's the "optimistic" part. A sequencer (the entity that orders and batches L2 transactions) submits transaction data to L1 without any proof attached. Then a challenge period opens — typically seven days — during which anyone can submit a fraud proof showing that a specific transaction was processed incorrectly. If a valid fraud proof appears, the incorrect batch gets rolled back and the dishonest sequencer is penalized.

• The challenge period is why withdrawals from optimistic rollups to L1 take about seven days by default
• Third-party liquidity providers offer faster withdrawals by fronting the funds and assuming the seven-day wait themselves, charging a small fee
• Fraud proofs only need to be submitted when something is actually wrong — in normal operation, none are ever used
• Major optimistic rollups include Arbitrum and Optimism (OP Mainnet), both live since 2021 with billions in deposited value
• The security model requires at least one honest participant watching for fraud — this is called a 1-of-N trust assumption

What this means practically: Optimistic rollups are simpler to build and already widely deployed, but the seven-day withdrawal delay is a real friction point unless you use a third-party bridge.

This is where most explanations go wrong — they describe ZK rollups as "using math" and leave it there. Here's what actually happens. A ZK rollup (short for zero-knowledge rollup) posts each batch of transactions to Ethereum along with a cryptographic validity proof — a compact mathematical certificate that every transaction in the batch was executed correctly. Ethereum verifies this proof on-chain. If the proof checks out, the batch is final. No waiting period needed.

• The proof is generated using advanced cryptographic techniques (commonly ZK-SNARKs or ZK-STARKs) that let you prove a computation was done correctly without re-running every step
• Generating these proofs is computationally expensive and requires specialized hardware, which is why ZK rollups are harder and slower to develop
• Once the proof is verified on L1, finality is immediate — no seven-day wait for withdrawals
• Major ZK rollups include zkSync Era, StarkNet, Scroll, and Polygon zkEVM
• Achieving full EVM compatibility (meaning developers can deploy existing Ethereum smart contracts without rewriting them) has been the central engineering challenge for ZK rollups

What this means practically: ZK rollups offer faster finality and don't rely on anyone watching for fraud, but the technology is newer, the prover infrastructure is more complex, and full EVM equivalence is still maturing.

The entire optimistic-vs-ZK distinction comes down to one design choice: when and how the rollup proves its work to Ethereum.

• Optimistic: proof is only generated reactively (after a dispute). Cheap in the normal case; slow in the worst case.
• ZK: proof is generated proactively (with every batch). Expensive to produce; fast to settle on L1.
• Optimistic rollups post full transaction data to L1 so that anyone can reconstruct the state and verify it. ZK rollups can post less data in some designs because the validity proof already guarantees correctness.
• For the end user, the biggest visible difference is withdrawal time: ~7 days (optimistic) vs minutes (ZK).
• For developers, the biggest difference is tooling maturity: optimistic rollups currently have deeper ecosystem support and easier contract deployment.

What this means practically: Neither approach is strictly better. They make different tradeoffs between proof cost, withdrawal speed, and engineering complexity.

Abstract comparisons only go so far. Here are the concrete differences you'll encounter.

• Transaction fees: Both types are dramatically cheaper than L1. As of mid-2025, typical L2 transaction fees range from fractions of a cent to a few cents, varying by rollup and network load. ZK rollups can theoretically achieve lower per-transaction data costs at scale because validity proofs compress more efficiently.
• Withdrawal to L1: Optimistic rollups enforce ~7 days natively. ZK rollups finalize in minutes to hours depending on proof generation speed.
• Smart contract compatibility: Optimistic rollups (Arbitrum, OP Mainnet) achieved near-full EVM equivalence first. ZK rollups have been closing the gap — zkSync Era and Scroll both support Solidity — but edge-case incompatibilities still surface.
• Decentralization of sequencers: Both rollup types currently rely on centralized sequencers in most deployments, with plans for decentralization on published roadmaps. This is a shared limitation, not unique to either type.

What this means practically: If you're choosing an L2 today, compare the specific rollup's fees, ecosystem, and bridge options — not just its proof system category.

Understanding the step-by-step sequence makes the architectural difference tangible.

1. You submit a transaction on the L2. Your wallet sends it to the rollup's sequencer. This is the same for both types.

2. The sequencer orders and executes transactions. It groups them into a batch. Execution happens off Ethereum, which is where the cost savings come from.

3. The batch is posted to Ethereum L1. For optimistic rollups, this is the transaction data plus a state commitment. For ZK rollups, this is the transaction data (or a compressed version) plus a validity proof.

4. Ethereum verifies the batch. On an optimistic rollup, "verification" means the challenge window opens and anyone can dispute. On a ZK rollup, a smart contract on L1 checks the validity proof cryptographically — if it passes, the batch is final.

5. Settlement. Once verified (immediately for ZK, after the challenge window for optimistic), the rollup's state is considered settled on Ethereum.

What this means practically: Both types follow the same general pipeline. They diverge at step 3 — what gets posted — and step 4 — how Ethereum confirms correctness.

• Rollups scale Ethereum by executing transactions off-chain and posting compressed results back to L1, inheriting Ethereum's security.
• Optimistic rollups assume batches are correct and allow a ~7-day window to prove fraud; they're mature, widely used, and EVM-compatible today.
• ZK rollups attach a cryptographic validity proof to each batch, enabling fast finality and shorter withdrawals, at the cost of higher proof-generation complexity.
• Neither type is universally superior — the right choice depends on whether you prioritize ecosystem maturity, withdrawal speed, or long-term scalability potential.