Skip to content
Financial Context Wiki

ZK rollups

A verification-first guide to ZK-rollup batches, validity proofs, data availability, settlement states, fees, withdrawals and deployment-specific risks.

Updated

For educational purposes only; not investment, bridge or security advice. A ZK rollup is only as reliable as its proved program, public inputs, data-availability path, contracts, operators, governance and settlement chain.

Direct answer

A ZK rollup, more precisely a validity rollup, executes transactions outside a settlement chain, groups them into batches and submits data commitments, state claims and validity proofs to contracts on that chain. The verifier checks that a batch follows the encoded transition rules without re-executing every transaction. This can amortize data publication and proof-verification costs across many transactions.

The guarantee is specific, not absolute. A verified proof supports only the statement encoded by the deployed program and bound public inputs. It does not by itself prove data is retrievable, the sequencer is live or fair, the settlement block is final, the bridge is correct or an upgrade is safe. “ZK” also does not make a rollup private: many validity rollups publish transaction or state-difference data and expose user activity.

1
Execute

The prover executes a batch or computation and records the resulting state transition.

How it works

  1. Pin the deployment: L1 and L2 chain IDs, rollup and bridge contracts, verifier and verification-key version, proved program or circuits, batch format, data-availability mode, sequencer, prover, administrators, pause powers and observation block. A stack name is not evidence that every deployment has the same guarantees.
  2. Separate ordering from proof. A sequencer can give a fast receipt and build L2 blocks before their data commitment or proof reaches L1. Record the exact batch containing the transaction and distinguish sequenced, committed, proved, accepted, settlement-safe, settlement-finalized and withdrawal-complete states.
  3. Reconstruct the batch. Obtain the protocol-required transactions, state differences, blob sidecars or other availability payload; verify the ordering and commitments; then derive the prior state root, post-state root, withdrawal or message root and other public inputs. A proof bound to the wrong chain, batch or root proves the wrong claim.
  4. Verify the proof path. Confirm that the settlement transaction called the intended verifier with the expected proof, verification key and public inputs, succeeded, emitted the expected event and updated the correct state slot. Where practical, reproduce verification and execution with independent software.
  5. Audit data availability separately. Ethereum blobs provide protocol-window availability and commitments, not permanent archival retrieval. An external committee or alternative DA layer adds its own assumptions. If users cannot recover the data needed to reconstruct state or make exits, proof validity alone does not restore it.
  6. Trace deposits and withdrawals end to end. Match the canonical token and messenger, amount, destination, message nonce, inclusion root, proof, finality rule and executed balance change. A third-party fast bridge advances liquidity under separate pricing, routing and counterparty risk; it does not shorten the canonical proof or settlement clock.
  7. Monitor liveness and control. Measure batch and proof backlog, forced-inclusion and escape paths, prover diversity, upgrades, timelocks, guardians and emergency modes. Repeat the analysis after a contract, circuit, key, DA mode or protocol upgrade.

Worked examples

  • Compression. A teaching batch contains 10,000 transactions, with 1,200 KB of raw protocol input compressed to 300 KB. The compression ratio is 1,200 / 300 = 4.0x, the size reduction is 1 - 300 / 1,200 = 75%, and the decimal average is 300,000 / 10,000 = 30 bytes/transaction. These figures do not measure proof soundness, state growth or archival availability.
  • Cost allocation. Users pay 3.0 ETH for the batch; measured L1 data publication costs 1.4 ETH, proof verification 0.4 ETH and L2 execution 0.2 ETH. The unexplained residual is 3.0 - 1.4 - 0.4 - 0.2 = 1.0 ETH, while the user average is 3.0 / 10,000 = 0.0003 ETH/transaction. The residual is not net profit because proving, hardware, failed submissions, bridging, capital and taxes are omitted.
  • Lifecycle. A wallet receives a sequencer receipt at minute 0; the batch commitment lands on L1 at minute 12; its proof is accepted at minute 50; a chosen settlement-finality policy is satisfied at minute 64; and the canonical withdrawal executes at minute 70. The sequential elapsed time is 12 + 38 + 14 + 6 = 70 minutes. None of the earlier timestamps is equivalent to withdrawal completion.

Risks

  • Wrong chain, deployment, contract, batch, root, verifier, key or circuit version.
  • An incomplete or incorrect proved program that a sound proof system faithfully proves.
  • Missing or misencoded public inputs, domain separators, messages or protocol parameters.
  • Verifier, precompile, bridge, messenger or state-update contract vulnerabilities.
  • Compromised setup material or broken cryptographic assumptions.
  • Sequencer censorship, reordering, equivocation, outage or delayed batch publication.
  • Prover outage, centralization, censorship, capacity shortage or growing proof backlog.
  • Unavailable, malformed or unarchived transaction data, state differences or blob sidecars.
  • Treating a data commitment or committee signature as evidence of current retrievability.
  • L1 reorganization or premature reliance on an unsafe settlement transaction.
  • Privileged upgrades, short timelocks, verifier replacement, pauses or emergency bypasses.
  • Forced-inclusion, state-recovery or escape paths that are absent, disabled or unusable.
  • Canonical bridge bugs, wrong token mappings, replay, message or withdrawal-proof failures.
  • Fast-bridge liquidity, pricing, routing, insolvency and counterparty risk.
  • Fee estimates that omit L1 data, proving, bridge, congestion or failed-transaction costs.
  • Assuming one rollup’s EVM compatibility, finality, privacy or security model applies to another.

Common misconceptions

  • Every ZK rollup hides transaction amounts, addresses and application activity.
  • A valid proof guarantees data availability and lets anyone reconstruct the current state.
  • A sequencer receipt is the same as an L1-accepted proof or finalized withdrawal.
  • Validity proofs remove sequencer, prover, governance, upgrade and bridge risk.
  • The cheapest or fastest proof system automatically produces the safest user outcome.

Sources

Navigation

Search the wiki...