Optimistic vs ZK Rollups

The previous page fixed the core move of a rollup: execute thousands of transactions off-chain, then post the transaction data plus a state commitment — a single hash claiming “after these transactions, the L2 state root is 0xabc…” — down to L1. That gives you throughput. But it leaves the sharpest question of the whole part unanswered: the sequencer just told L1 a hash. Why should anyone believe it?

A dishonest sequencer could post a state root that credits itself a million ETH, or that quietly deletes your withdrawal. L1 does not re-execute the batch — that would defeat the point of moving execution off-chain. So the rollup needs a cheaper-than-re-executing way to convince L1 the posted state root really is what the transactions produce. There are exactly two known families of answer, and this page is about the fork between them. Everything downstream — how long your withdrawal takes, what it costs, which chains exist — falls out of this one design choice.

The question both families answer

Recall this part’s recurring test from the overview:

If the L2 lies — reorders your trade, steals your funds, or invents a balance — can you still appeal to a chain you don’t have to trust, and win?

For the answer to be yes, L1 must be able to reject a false state root without trusting the sequencer. Both families make the answer yes; they differ only in when the checking happens and who does it.

   The posted claim:  "these txs ⇒ new state root = 0xabc…"

   OPTIMISTIC                             ZK / VALIDITY
   ──────────                             ─────────────
   assume the claim is TRUE               PROVE the claim before accepting it
   accept it now, provisionally           attach a succinct validity proof
   open a CHALLENGE WINDOW (~7 days)       L1 verifies the proof in one cheap check
   anyone may submit a FRAUD PROOF         if it verifies, the root is final NOW
   → bad root reverted, liar slashed       → a false root can't be posted at all
   trust model: "innocent until           trust model: "guilty until
     proven guilty"                          proven innocent"

Optimistic rollups assume honesty and punish lies after the fact. ZK rollups refuse dishonesty up front by demanding a mathematical certificate with every batch. Hold that one-line contrast; the rest of the page is its consequences.

Optimistic rollups — innocent until proven guilty

An optimistic rollup posts the batch and its new state root and simply asserts the root is correct. L1 takes it on faith — optimistically — and marks it accepted, but not yet final. It then opens a challenge window, in practice around seven days, during which anyone running a full copy of the L2 can check the sequencer’s work by re-executing the batch themselves.

If a watcher finds the posted root is wrong, they submit a fraud proof to an L1 contract. The fraud proof is not “trust me, it’s wrong” — it is a mechanism that lets L1 itself adjudicate the disputed step and see the lie, without re-running the whole batch.

   day 0   sequencer posts batch + state root   (accepted, provisional)
     │
     │     ← challenge window open ~7 days →
     │
     ├─ nobody challenges ────────────► day 7: root becomes FINAL
     │
     └─ a watcher disputes ──► fraud proof ──► L1 checks the ONE bad step
                                              ├─ lie confirmed: root REVERTED,
                                              │                 sequencer's bond SLASHED
                                              └─ challenge bogus: challenger loses bond

Under the hood — how a fraud proof avoids re-executing the whole batch

The naive idea — “L1 re-runs the batch to check” — is exactly what rollups exist to avoid; re-executing on L1 costs L1 gas and caps you at L1’s throughput. Modern optimistic rollups instead use interactive fraud proofs (also called a bisection or dispute game). The idea is a binary search over the execution trace:

• The challenger claims the sequencer’s result diverged from the truth somewhere in a computation of, say, millions of steps.
• The two parties play a back-and-forth game, each round narrowing the disagreement to half the remaining steps: “we agree on the state after step N/2, so the error is in the second half,” and so on.
• After ~log₂(steps) rounds they have pinned the dispute to one single instruction — the first step where they disagree.
• Only that one instruction is executed on L1. L1 runs one opcode, sees which party told the truth about its result, and rules.

L1 thus never re-executes the batch; it executes a single step and lets the logarithmic game find which step matters. This is why the on-chain cost of adjudication is tiny even when the disputed computation was huge.

Under the hood — the challenge window rests on one assumption

The seven-day window is only as safe as its liveness assumption: at least one honest party must be watching, able to re-execute the L2, and able to get a transaction onto L1 within the window to raise a fraud proof. If every honest watcher were censored off L1 for the full seven days, a bad root could finalize. This is why the window is measured in days, not minutes — it must be long enough to survive L1 congestion, a short reorg, or an attempted censorship attack, and still leave an honest challenger time to act. The length is a security parameter, not an arbitrary delay.

ZK rollups — guilty until proven innocent

A ZK rollup (more precisely a validity rollup) refuses to rely on anyone watching. Instead of asserting the new state root and inviting challenges, it proves the root is correct, mathematically, before L1 accepts it. Attached to every batch is a validity proof — a zero-knowledge succinct proof (a SNARK or STARK) that says, in effect:

“I know a set of transactions that, applied to the old state root, produce this new state root, and every one of them followed the rules.”

The two words that make this practical are succinct and fast to verify. The proof is small — on the order of a few hundred bytes to a few kilobytes — regardless of whether the batch had ten transactions or ten thousand. And an L1 contract can verify it in a single, cheap, constant-ish operation, far cheaper than re-executing the batch. The proof reveals nothing about the individual transactions beyond the fact that they were valid — that is the “zero-knowledge” part, though for rollups the load-bearing property is really the succinctness, not the privacy.

   off-chain                                  on-chain (L1)
   ─────────                                  ─────────────
   run N txs  ───►  new state root
       │
       └─ PROVER builds a validity proof π  ─────►  VERIFIER contract checks π
          (expensive: minutes of CPU/GPU,           (cheap: one succinct check)
           the "proving cost")                        │
                                                       ├─ π verifies:  root FINAL immediately
                                                       └─ π fails:     batch REJECTED, never accepted

The consequence is the mirror image of optimistic: there is no dispute window, because there is nothing to dispute. A false state root cannot even be posted — you cannot produce a valid proof for an invalid execution, any more than you can produce a valid signature without the key. L1 either accepts a proven-correct root now, or rejects an unproven one now. Finality is a single L1 confirmation away, not a week.

The cost moved, it did not vanish. Generating that proof is expensive — the prover does a large amount of specialized computation (often minutes on beefy hardware, increasingly GPU-accelerated) to compress “I ran the batch correctly” into a few kilobytes. Optimistic rollups pay nothing in the happy path (no proof, just an assertion); ZK rollups pay proving cost on every batch, whether or not anyone would ever have challenged it. You are buying certainty up front instead of insurance against fraud.

The consequence that users feel: withdrawal speed

Both families let you transact cheaply on L2. The difference bites when you want to move funds from L2 back to L1 — a withdrawal, which requires L1 to be convinced the L2 balance you’re claiming is real.

   OPTIMISTIC withdrawal              ZK / VALIDITY withdrawal
   ─────────────────────              ────────────────────────
   request exit on L2                 request exit on L2
   wait out the CHALLENGE WINDOW      batch's validity proof is verified on L1
     (~7 days) so a fraud proof         (once the proof lands & verifies)
     could still revert a bad root    root is FINAL, no window to wait
   window closes ⇒ root final         funds claimable in minutes–hours
   claim on L1

An optimistic withdrawal must wait out the challenge window — you cannot safely release funds on L1 until the L2 root that credits your balance is final, and it isn’t final until the ~7-day window has passed with no successful fraud proof. A ZK withdrawal has no such wait: once the batch’s validity proof is verified on L1 (typically minutes to a couple of hours, gated by how often the rollup submits proofs, not by any mandatory delay), the root is final and you can exit.

By the numbers — why the fast-bridge fee exists

The ~7-day optimistic wait is a real product problem, so a market grew around it: liquidity-provider “fast bridges.” A watcher who is confident the withdrawal is honest fronts you the funds on L1 now, then reclaims from the bridge after the window closes — for a fee.

   your L2 balance to withdraw:  1.000 ETH
   native optimistic exit:       arrives in ~7 days, fee ≈ just L1 gas
   fast-bridge exit:             arrives in minutes
                                 LP fee ≈ 0.05%–0.30% of amount + gas
                                 → on 1 ETH: ~0.0005–0.003 ETH to skip the week

The fee is the price of the LP’s time-value-of-money and their fraud risk for the seven days they’re exposed. A ZK rollup needs no such market for its native exit, because there is no window to skip. (Figures are illustrative and move with gas and competition; the mechanism — paying an LP to absorb the wait — is the durable point.)

The trade-off, stated plainly

Neither family is strictly better; they sit at different points on the same curve.

	Optimistic rollup	ZK / validity rollup
How the root is trusted	assumed valid, fraud-provable	proven valid before acceptance
Extra data per batch	none (just the assertion)	a succinct validity proof
L1 work per batch	cheap in happy path	verify one proof (cheap, but nonzero)
Off-chain work per batch	just execution	execution + expensive proving
Withdrawal to L1	wait out ~7-day window	fast: once proof verifies
Trust/liveness assumption	≥1 honest watcher within the window	none for validity (only prover liveness)
EVM compatibility	easy — run a near-stock EVM	hard — the EVM must be made provable
Build complexity	lower	higher (prover, circuits, ZK-EVM)

The two lines to remember:

• Optimistic is cheaper and simpler to build — you run something very close to a stock EVM off-chain, and in the common case you post no proof at all. This made EVM-equivalence (contracts and tooling that behave exactly like L1) reachable early. The price is the slow exit: security relies on a challenge window, so native withdrawals wait it out.
• ZK finalizes fast and needs no honest watcher — validity is enforced by math on every batch, so exits are quick and there is no liveness assumption to defend. The price is heavy proving cost and, historically, harder EVM support: proving general EVM execution efficiently (a “ZK-EVM”) is a deep engineering problem, though it has advanced fast.

Why EVM support is the hard part for ZK

An optimistic rollup only needs to run the EVM; it can use an almost-unmodified execution client, because the EVM’s correctness is only checked when a dispute forces a single opcode onto L1. A ZK rollup must prove every step of EVM execution inside an arithmetic circuit — it has to express each opcode, each storage access, each hash, as constraints a SNARK/STARK can attest to. Some EVM operations (notably certain hash functions and precompiles) are expensive to arithmetize, which is why early ZK rollups shipped custom VMs first and EVM-compatibility later, along a spectrum from “language-level equivalent” to “bytecode-level equivalent.”

Who’s who — real examples (with a hedge)

As of 2024–2025, the ecosystem sorts roughly into the two families. Treat specifics as a snapshot: teams add proving to optimistic chains, roll out new ZK-EVM versions, and change parameters continually, so verify current details before relying on them.

• Optimistic rollups: Arbitrum (One/Nova), Optimism and the OP Stack chains it powers — including Base (Coinbase’s L2) — and others. These favor EVM-equivalence and simplicity, and carry the ~7-day exit.
• ZK / validity rollups: zkSync Era, Starknet, Scroll, Linea, Polygon zkEVM, and more. These attach validity proofs and finalize fast, and have been steadily closing the EVM-compatibility gap.

The families are converging in ambition — optimistic chains are exploring validity proofs, and ZK-EVMs keep improving — so the label matters less over time than the underlying question it answers: when, and how, is the state root proven honest?

It actually happened — the exit-window is a security property, not a nuisance

In February 2022, a whitehat, Jay Freeman / “saurik”, disclosed a critical bug in Optimism’s OVM (a SELFDESTRUCT-related flaw) that could have allowed unbacked ETH minting; it was fixed and the researcher was paid a large bounty (reported at roughly $2 million). The lesson for this page isn’t the specific bug — it’s why optimistic rollups can afford a bug-tolerant posture at all: the challenge window and the on-chain dispute game are a defense-in-depth layer. A window that feels like a mere waiting inconvenience to users is, mechanically, the time and place where a false or buggy state transition can be caught and reverted before it becomes final. Shorten it recklessly and you trade a UX win for a weaker guarantee. A ZK rollup pays for equivalent safety differently — its guarantee is that a false transition was never accepted in the first place, so there is no window to shorten, but also no built-in grace period in which to catch a flawed proof system, which is why audited, battle-tested proving stacks matter so much there. Both families move risk around; neither deletes it.

The architect’s lens

• Why does it exist? Because a rollup posts only a hash claiming its off-chain execution was correct, and L1 refuses to re-run the batch. Some mechanism must let a chain you don’t trust reject a false state root. Fraud proofs and validity proofs are the only two known families of that mechanism.
• What problem does it solve? It closes the recurring test of this part: if the L2 lies, can I appeal to a chain I don’t trust and win? Optimistic proofs answer “yes, by catching the lie within a window”; validity proofs answer “yes, by never accepting the lie at all.”
• What are the trade-offs? Optimistic buys simplicity and easy EVM-equivalence but pays with a ~7-day exit and a one-honest-watcher liveness assumption. ZK buys fast finality and no watcher assumption but pays heavy proving cost and harder EVM support. Same security goal, opposite cost structures.
• When should I avoid it? Avoid optimistic when fast, trust-minimized L1 withdrawal or cross-chain settlement is essential and you can’t tolerate the window (or the fast-bridge fee). Avoid ZK when you need day-one, bug-for-bug EVM-equivalence with minimal engineering, or when per-batch proving cost would dominate a low-value, high-volume workload.
• What breaks if I remove it? Remove the proving mechanism entirely and the rollup collapses back into “just trust our sequencer” — a fast database, not a scaling of Ethereum’s guarantees. The recurring test’s answer flips from yes to no, and the L2 stops inheriting L1’s security.

Check your understanding

1. A rollup posts only a state root — a hash — claiming its off-chain execution was correct, and L1 does not re-execute the batch. State the one-line contrast between how optimistic and ZK rollups make L1 trust that hash anyway.
2. Walk through what happens over the ~7 days after an optimistic rollup posts a batch. What is a fraud proof, and how does an interactive (bisection) fraud proof let L1 rule on a huge computation while running only one instruction on-chain?
3. A ZK rollup has no challenge window. Why not — and which two properties of the attached validity proof (name them) make verifying it on L1 cheaper than re-executing the batch?
4. Explain, from the mechanism, why an optimistic L1 withdrawal must wait ~7 days while a ZK withdrawal can finalize in minutes to hours. What is a “fast bridge” charging you for, and why does a ZK rollup not need one for its native exit?
5. State the core trade-off in one sentence, then name one real optimistic rollup and one real ZK rollup. Why does the task’s phrasing insist you hedge those examples?

Show answers

1. Optimistic assumes the posted root is valid and accepts it provisionally, then opens a challenge window in which anyone can submit a fraud proof to revert a bad root (“innocent until proven guilty”). ZK/validity attaches a succinct validity proof to every batch that L1 verifies before accepting the root, so a false root can never be posted (“guilty until proven innocent”). The split is when the checking happens: after the fact vs up front.
2. On posting, the root is accepted but provisional, and a ~7-day window opens. Watchers re-execute the batch off-chain; if the posted root is wrong, one submits a fraud proof. An interactive/bisection fraud proof binary-searches the execution trace: each round the parties narrow the disagreement to half the remaining steps until it’s pinned to a single instruction — the first step they disagree on. L1 executes only that one instruction, sees who told the truth, and rules; if a lie is confirmed the root is reverted and the sequencer’s bond slashed. If nobody challenges within the window, the root becomes final.
3. Because the batch’s correctness is proven before acceptance — there is nothing to dispute, so no window is needed. The proof is succinct (small — hundreds of bytes to a few KB — regardless of batch size) and fast/cheap to verify (a single constant-ish L1 check). Both together make verifying the proof far cheaper than re-executing every transaction, which is exactly what rollups exist to avoid on L1.
4. An optimistic root isn’t final until the challenge window closes, because until then a fraud proof could still revert it; releasing L1 funds against a not-yet-final root would be unsafe, so the withdrawal waits out the ~7 days. A ZK root is final as soon as its validity proof verifies on L1 (minutes to hours, gated by proof cadence, not a mandatory delay), so the withdrawal can settle quickly. A fast bridge is a liquidity provider fronting you L1 funds now and reclaiming after the window closes — you pay a fee for their locked capital and fraud risk. A ZK rollup needs no such market because there is no window to skip.
5. Optimistic is cheaper and simpler to build (especially EVM-equivalent) but has a slow ~7-day exit; ZK finalizes fast and needs no honest watcher but pays heavy proving cost and has historically harder EVM support. Example optimistic: Arbitrum / Optimism / Base. Example ZK: zkSync Era / Starknet / Scroll / Linea / Polygon zkEVM. You hedge because the specifics evolve fast — teams add proving to optimistic chains, ship new ZK-EVM versions, and change parameters — so any snapshot of who-is-which can go stale.