What Are ZK Rollups?

In brief

• ZK rollups are more precisely called validity rollups: an L1 verifier accepts a state transition only with a valid proof.
• The proof establishes execution correctness under a particular program and proof system; it does not by itself guarantee privacy or data availability.
• Canonical withdrawals avoid the optimistic fault-proof delay, but still wait for transaction inclusion, proof generation, L1 submission, verification and any bridge-specific delay.
• A sequencer can still censor, reorder or delay transactions before proof submission.
• A centralized prover can affect liveness, even though it cannot make an invalid transition pass a sound verifier.
• Validiums also use validity proofs but keep required state data outside Ethereum, creating a different availability assumption.
• Upgrade administrators may be able to replace the verifier, bridge or system program, so deployed governance matters as much as the proof label.

The live Layer 2 article surveys scaling designs. This page explains what validity proofs change—and what they do not.

From transactions to a validity proof

A typical validity rollup has several moving parts:

1. Users submit signed transactions, usually to a sequencer.
2. The sequencer orders and executes them under the rollup’s state-transition rules.
3. Data representing the new state, often compressed transaction data or state differences, is published to Ethereum.
4. A prover turns the execution trace into a cryptographic proof.
5. An L1 verifier contract checks the proof against public inputs such as the previously accepted state commitment and the proposed new commitment.
6. If verification succeeds and the contract’s other checks pass, the new state commitment becomes accepted on L1.

The exact pipeline varies. ZKsync documentation separates L2 blocks from larger batches and describes commit, prove and execute stages. Starknet publishes compressed state differences alongside proofs so observers can reconstruct its state. These examples illustrate the design space; they are not requirements that every ZK rollup implements identically.

The important property is soundness: except with negligible cryptographic probability, a prover should not be able to convince the verifier of a false statement. L1 verifies a small proof instead of repeating the full offchain workload.

Validity does not mean privacy

“Zero knowledge” describes a property a proof system can provide: a prover can demonstrate that a statement is true without revealing a private witness. A rollup can use the same cryptographic machinery mainly for verifiable computation while making transaction or state data public.

Whether users receive privacy depends on what the circuit treats as private, what appears in the proof’s public inputs and what data the protocol publishes. A validity proof for “these public transactions produced this state root” does not hide senders, recipients or amounts merely because the product is called a ZK rollup.

This distinction prevents two common errors:

• Validity proof: establishes that execution followed specified rules.
• Privacy proof: reveals only selected facts while hiding chosen inputs.

A system can offer either property, both, or neither in a particular part of its design.

Data availability still matters

A proof can establish that a transition is valid while leaving users without the data needed to inspect balances, build future state, generate account witnesses or submit an independent exit. A rollup therefore publishes enough state-reconstruction data to its data-availability layer.

For an Ethereum rollup, that data is commonly posted through calldata or EIP-4844 blobs. Blobs lower publication costs and are available under Ethereum’s protocol for a limited retention window, rather than being permanent file storage. Nodes and archives may retain them longer.

A validium changes this arrangement: it verifies state transitions on L1 but stores the required data elsewhere, such as with a committee or separate data-availability network. Correctness remains protected by the validity proof, while data withholding and recovery depend on the external availability system. Calling a validium a “ZK rollup” conceals a material trust difference.

Proof systems and trusted setup

SNARKs and STARKs are broad families, not two fixed products with universal cost profiles. Proof size, proving time, verifier cost, recursion, cryptographic assumptions and hardware requirements depend on the actual construction.

Some proof systems require a structured reference string produced through a trusted setup. A well-designed multiparty ceremony can remain secure if at least one participant destroys its secret contribution, but that is still an assumption to document. Other systems use transparent setup. It is safer to inspect a rollup’s named proving stack than to infer its properties from “SNARK” or “STARK” alone.

Proof generation can be computationally demanding. Specialized hardware and complex software may concentrate proving among a small number of operators. This is principally a liveness and censorship concern when the verifier is sound: a centralized prover can stop producing proofs, but should not be able to prove an invalid state transition.

Proof systems also introduce implementation risk. Bugs can exist in the circuit, compiler, virtual machine, prover, verifier contract or the mapping between them. A mathematically sound proof system does not guarantee that the deployed circuit expresses the intended rules.

Sequencers, confirmations and finality

Many ZK rollups provide a quick sequencer confirmation before a proof reaches Ethereum. That confirmation says the sequencer included and executed the transaction according to its current view. Until data and a proof are accepted on L1, users may still rely on the sequencer and prover for ordering and progress.

Validity proofs constrain incorrect execution, but they do not force a sequencer to include a user promptly. A rollup can add an L1 priority queue, forced-inclusion route or escape mechanism. Whether that route is live, permissionless and practical is an implementation-specific question. ZKsync’s transaction-lifecycle documentation, for example, describes an L1 submission route, while its current L1-contract documentation says its broader censorship-resistance mechanism remains under research. Those statements describe different scopes and should not be flattened into “censorship is solved.”

Once the verifier accepts a batch, there is no need to wait a week for anyone to dispute its correctness. A withdrawal can then proceed under the bridge’s rules. “Instant withdrawals” is still misleading: the user may wait for the sequencer to include the exit, the prover to cover that batch, Ethereum to include and finalize the proof transaction, and the bridge to process the message.

Upgrades can outrank the verifier

The L1 verifier checks exactly the rules encoded in the deployed contracts and proof program. If a privileged actor can quickly replace those components, users also trust that actor.

As a concrete example, ZKsync’s official L1-contract documentation describes upgradeable facets, privileged roles, freezing powers and multisig/security-council paths for protocol changes. That does not characterize every validity rollup, but it demonstrates the questions users should ask:

• Who can change the verifier or accepted program hash?
• Is there an upgrade delay?
• Can a security council freeze execution or withdrawals?
• Can users exit before a scheduled upgrade?
• Are bridge contracts and state commitments under the same controls?
• Is there more than one independent prover or node implementation?

Cryptographic validity protects against claims outside the verifier’s rules. Governance determines who can change those rules.

Fees and EVM compatibility

Rollup fees combine L2 execution, proof generation, L1 verification, data publication and operator overhead. Batching amortizes fixed proof and settlement costs across many transactions. Recursion—proving multiple proofs inside another proof—can reduce how often L1 verifies.

There is no timeless gas number for “a ZK proof.” Verification cost changes with the proof system, verifier implementation, Ethereum upgrades and aggregation strategy, so fixed figures quickly become misleading.

A zkEVM proves execution that is compatible with some definition of the Ethereum Virtual Machine. Compatibility can refer to bytecode, opcodes, developer tooling or higher-level language behavior. Differences in gas accounting, unsupported opcodes, system contracts and precompiles can remain. “EVM compatible” is therefore a spectrum, not a security grade.

ZK versus optimistic rollups

Both designs need available data, settlement contracts, bridges and operational infrastructure. Their central disagreement is how an invalid transition is excluded:

• a ZK rollup requires a validity proof before acceptance;
• an optimistic rollup accepts a claim after a challenge period unless a fault proof defeats it.

Validity proofs remove the challenge wait and the need for an always-alert honest challenger. They add a complex proving stack and do not remove sequencer, liveness, upgrade, data-availability or bridge risks.