ZK Rollup Lab

Agent Mode
Display
backend offline

Chain activity

click a proof batch to open the concept tour

pendingCollecting
acceptedVerifier accepted
rejectedVerifier rejected

ZK batches group L2 blocks under one proof submission. Click a batch card to inspect public inputs and verifier results.

① Claim

Header + state root on L1

② Prove

Off-chain witness & constraints

③ Verify

Instant accept / reject

Validity, not privacy or DA

This is a validity-proof demo, not a privacy demo. The proof shows the state transition is valid. It does not model data availability, calldata/blobs, or private transaction designs.

What the proof does not solve here: users still need transaction data to reconstruct L2 state. This lab focuses on validity checking, not how batch data is published or stored.

L1 Mainnet#0
0
ZK L2#0
0…

Scoreboard

ZK: Validity

Prove first, accept after

Submitted

0

Verified

0

Rejected

0

Challenge window

0

Invalid claims ~1 in 16. They fail at proof verification, not through a fraud-proof game.

ZK in three beats

Same batch window as OP, opposite trust model, validity is proved, not assumed.

①

Claim

Header + state root on L1

②

Prove

Off-chain witness & constraints

③

Verify

Instant accept / reject

OptimisticZK
Default assumptionSequencer is honest until someone challengesEvery batch must carry a validity proof
When fraud is caughtAfter a challenge window (bisection → opcode replay)At submit time, verifier rejects invalid proofs
Cost shapeCheap to post, expensive to disputeExpensive to prove off-chain, cheap to verify on L1

Start the demo, a live ZK batch tour appears here.

Event log

ZK lane · click any event for details

0 events

Recent

No events yet - start a demo.

Proof lab

Open a ZK proof when you want to inspect witness inputs, proof cost, and L1 verifier output.

Start a demo and wait for a ZK batch submission. Validity proof tours appear here.

What happens when a ZK proof reaches L1?

  1. The prover builds a witness from the L2 execution trace and public inputs.
  2. The operator pays proving cost off-chain and submits proof data to L1.
  3. The verifier contract checks the proof against the claimed state transition.
  4. If the proof verifies, L1 accepts the new state root and bridge finality advances.
  5. If the proof fails, L1 rejects that update at the validity gate.
  6. A failed ZK proof does not become an optimistic fraud-proof game.