Are ZK rollups actually private?

Usually not. The 'zero-knowledge' label refers to the proof technology, but most ZK rollups publish transaction data on the base chain so the state can be reconstructed and verified. The proofs demonstrate that a batch was computed correctly; they are not generally used to hide who sent what. Privacy is a separate design choice that few production rollups currently prioritize.

What's the practical difference between a SNARK and a STARK?

Both prove that a computation was performed correctly. SNARKs produce very small proofs that are cheap to verify but often depend on a trusted setup ceremony. STARKs need no trusted setup and rely on more conservative cryptographic assumptions, but their proofs are larger. The choice trades proof size and verification cost against setup assumptions and post-quantum resilience.

Why can ZK rollups finalize faster than optimistic rollups?

An optimistic rollup assumes batches are valid and waits out a challenge window — often about a week — during which fraud can be reported. A ZK rollup instead proves each batch correct up front, so once the base chain verifies the proof there is nothing left to dispute and withdrawals can settle much sooner.

ZK rollups explained | Blockchain Research

From “trust but check later” to “prove it now”

Rollups scale a base chain by executing transactions off-chain and posting data back on-chain, so that the base layer can still be the source of truth. The open question for any rollup is how the base chain becomes convinced that the off-chain execution was honest. Optimistic rollups answer with a delay and a dispute process. ZK rollups answer with mathematics.

A ZK rollup processes a batch of transactions off-chain and submits, along with the data, a validity proof: a compact cryptographic object that demonstrates the batch was executed according to the rules. The base chain verifies the proof and accepts the new state. As Ethereum’s documentation describes it, ZK rollups “increase throughput on Ethereum Mainnet by moving computation and state-storage offchain” while still letting the base layer confirm correctness. There is no need to re-run the transactions and no need to wait for someone to challenge them.

What a validity proof actually proves

The label “zero-knowledge” can mislead. The cryptography behind these systems lets one party convince another that a statement is true without revealing all the underlying information. In the rollup context, the statement being proved is roughly: “Starting from this known state, applying this batch of transactions yields that new state, and every transaction followed the rules.”

A correct validity proof gives the verifier near-certainty of this claim. It does not need to trust the entity that produced the batch, because a false claim cannot produce a passing proof. This is a stronger guarantee than the optimistic model, where a batch is presumed valid unless someone actively proves otherwise within a window. With validity proofs, an invalid batch simply cannot be finalized in the first place.

Prover and verifier

Two roles structure every ZK rollup.

The prover does the expensive work. It takes the batch of transactions, executes them, and runs a proving system that encodes the entire computation into a single validity proof. Generating that proof is computationally intensive and requires specialized hardware and software — it is the main cost and complexity of the ZK approach.

The verifier lives on the base chain, typically as a smart contract. Its job is the opposite: cheap and fast. It checks the submitted proof against the state commitment the rollup posted. If the proof verifies, the new state is accepted; if not, it is rejected. The asymmetry is the whole point — proving is hard and happens once, off-chain; verifying is easy and happens on-chain for everyone to see.

SNARKs and STARKs

Two families of proving systems dominate, and they make different engineering trade-offs. The Ethereum documentation summarizes the contrast well.

zk-SNARKs (Succinct Non-interactive Arguments of Knowledge) produce very small proofs with fast, near-constant-time verification, which keeps on-chain verification cheap. Their historical drawback is that many SNARK constructions require a trusted setup — a one-time ceremony that generates public parameters. If the secret values from that ceremony were not properly destroyed, they could in principle be used to forge proofs, so the integrity of the setup matters.

zk-STARKs (Scalable Transparent Arguments of Knowledge) were designed to remove that dependency. They need no trusted setup — that is the “transparent” in the name — and rely on hash-based cryptography that is generally considered resistant to quantum attacks. The trade-off is larger proof sizes, which can make verification more expensive on-chain. As Vitalik Buterin notes in An Incomplete Guide to Rollups, ZK rollups in general carry more technological complexity than their optimistic counterparts, and the SNARK-versus-STARK decision is part of that complexity budget.

Finality versus the optimistic model

The most visible user-facing difference between ZK and optimistic rollups is finality.

An optimistic rollup posts a batch and then waits out a challenge window — frequently around seven days — during which watchers can submit fraud proofs. Only after that window closes is a withdrawal to the base chain fully safe. A ZK rollup carries its proof of correctness with the batch, so once the base-chain verifier accepts the proof, the state transition is settled. There is nothing left to dispute, and withdrawals back to L1 can complete in a far shorter time.

This faster, dispute-free settlement is the headline advantage of the ZK approach. The cost is paid earlier and elsewhere: in the engineering effort to build correct proving circuits and in the computational expense of running the prover.

Examples in production

Several general-purpose ZK rollups are live and illustrate different points in the design space.

zkSync is an EVM-compatible ZK rollup; its official documentation describes a network of interoperable chains “secured by ZK,” aimed at letting existing Ethereum applications deploy with minimal changes.
Starknet is a general-purpose STARK-based rollup. Its documentation centers on a custom virtual machine and the Cairo language, with an associated prover, betting on STARKs’ transparency and scalability.
Scroll pursues bytecode-level EVM equivalence, prioritizing compatibility with existing Ethereum tooling.

These projects differ in their virtual machines, languages, and proving systems, but all share the core mechanic: execute off-chain, prove correctness, verify on the base layer.

Trade-offs to weigh

ZK rollups offer strong correctness guarantees and fast finality, but they are not free of compromise. Proof generation demands significant computation and specialized expertise, raising operational complexity and cost. Building a proving system that faithfully captures a full virtual machine is genuinely hard, and bugs in those circuits are a serious risk surface. Some systems still rely on trusted setups depending on their proving scheme. And, as with every rollup, the security story holds only if transaction data remains available so that state can be reconstructed.

For builders and analysts, the practical lesson is to look past the “ZK” label and ask concrete questions: which proving system is used, whether a trusted setup is involved, how mature the prover is, and where the data lives. The cryptography is powerful, but its guarantees are only as good as the system built around it. For the broader context of how rollups fit among scaling approaches, see what are layer 2 solutions.

ZK rollups explained