What is a ZK rollup? A complete guide to zero-knowledge and rollups-as-a-service (RaaS)

For most of the last decade, the honest answer to "should you build on a ZK rollup?" was "not yet." Generating a validity proof took minutes and cost real money, and running ordinary EVM bytecode through a proof system was closer to a research project than a deployment target.

That changed fast. Over roughly a year, proving latency for Ethereum blocks fell from 16 minutes to 16 seconds and proving costs collapsed 45 times over, according to the Ethereum Foundation's zkEVM security roadmap. ZK rollups replace trust with proof. What is left to decide is not whether the technology works, but whether running a chain of your own is worth the operational surface it brings.

What is a ZK rollup?

A zero-knowledge rollup is a scaling design that executes transactions off the main chain, then posts a cryptographic validity proof back to the base layer showing the resulting state is correct. The base layer never re-executes those transactions. It checks the proof.

Think of it like turning in a math test where the grader checks a short certificate instead of re-doing every problem. The certificate is small, checking it is fast, and a wrong answer cannot produce a valid certificate. That asymmetry is the whole mechanism. Verifying a proof costs far less than executing the transactions behind it, so a rollup can push much more throughput through the same base layer capacity.

"Zero-knowledge" is a misleading name. It describes the proof system, not the chain's privacy properties. Transactions on a ZK rollup are public by default, the same way they are on Ethereum. The proofs establish that the state transition is valid without the verifier re-running it, which is a succinctness property rather than a confidentiality one. Real privacy needs deliberate extra work, usually encryption or a dedicated privacy layer built on top.

So treat a ZK rollup as a scaling and finality decision. If you need confidentiality, that is a separate design problem you still have to solve.

How do ZK rollups work?

Four components do the work, and they hand off in sequence.

• The sequencer accepts transactions from users, orders them, and groups them into a batch. This is what gives users their fast confirmation, well before anything reaches the base layer.
• The prover takes the batch and generates a validity proof, usually a SNARK or a STARK, attesting that executing those transactions against the previous state produces the new state.
• The verifier contract lives on the base layer. It checks the proof and, if it holds, accepts the new state root as canonical.
• The data availability layer stores enough transaction data for anyone to independently reconstruct the rollup's state and verify the operator is not hiding anything.

State itself is tracked in a Merkle tree, where a single root hash commits to every account balance and contract slot. Each accepted batch advances that root, so the base layer holds one small commitment rather than the full rollup state.

That last component, data availability, is where the economics changed most. Rollups used to pay for base layer calldata to publish batch data, which was expensive and which stayed onchain permanently. Ethereum's Dencun upgrade introduced blobs in March 2024, a separate data lane priced independently and sized for exactly this job. Blob data is pruned after roughly 18 days rather than kept forever, which is deliberate. Rollup data does not need to persist indefinitely; it only needs to be available long enough for anyone to download it and rebuild the chain's state. PeerDAS, the data availability sampling upgrade that shipped with Fusaka in December 2025, made larger blob counts safe to run. The capacity increases themselves came from small follow-up forks that changed blob parameters only.

Data availability is no longer the dominant line item it once was. For a team pricing out a rollup today, proof generation and sequencer operations are the costs that matter, and any cost model built on the old calldata assumptions will be wrong by an order of magnitude.

Why do ZK rollups matter for builders?

Fees drop because the cost of posting and verifying one batch is amortized across every transaction inside it. Throughput rises for the same reason, since the base layer's capacity constrains proof verification rather than transaction execution.

Withdrawals settle without a challenge window. An optimistic rollup assumes batches are valid unless someone disputes them, so it holds withdrawals for a dispute period, conventionally seven days. A validity proof already establishes correctness at the moment it is verified, so there is nothing to wait out. For anything involving moving value between layers, that difference is the one users actually feel.

Verifiability comes from the data availability requirement. Because batch data is published, anyone can reconstruct the rollup's state independently, so an operator can neither commit a false state nor withhold the data needed to check it. What that does not give you is censorship resistance. A sequencer can still quietly decline to include your transaction, and no amount of published data reveals a transaction that was never sequenced. That protection comes from a forced-inclusion path, where a user submits a transaction to the base layer contract directly and the rollup is obliged to pick it up. When you evaluate a chain, confirm that escape hatch exists and that it works without the operator's cooperation.

Together these make ZK rollups a reasonable default for applications where settlement speed and per-transaction cost are product features rather than implementation details. Payments, exchanges, and games feel the difference immediately. A low-frequency application probably will not.

How do ZK rollups support smart contract integration?

Proving arbitrary smart contract execution is much harder than proving simple transfers, which is why the earliest ZK rollups only supported payments and swaps. Proving EVM bytecode means expressing every opcode as constraints inside a proof system, and the EVM was not designed with that in mind.

A zkEVM is the answer, and implementations differ in how closely they match Ethereum. Some prove Ethereum's execution layer directly, which maximizes compatibility at the cost of proving performance. Others adjust the bytecode or the state tree to make proving cheaper, which means some contracts and tooling need adjustment before they work. Check any zkEVM against your actual dependencies rather than its compatibility label.

The performance gap that made this a research problem has largely closed. Provers now handle 99% of Ethereum blocks in under 10 seconds on target hardware, per the Ethereum Foundation, which is a per-block proving measure rather than the end-to-end latency figure quoted above. Its current focus has shifted from speed to security. The published roadmap sets 128-bit provable security and proof sizes under 300 KiB as the target for the end of 2026, with formal verification of the recursion architecture alongside it.

Proving speed is no longer what stands between you and a production zkEVM. Ask a team how far along their security proofs are instead.

How do ZK rollups compare to optimistic rollups?

Both post transaction data to a base layer and both inherit its security. They differ in what they ask the base layer to believe.

Optimistic rollups are cheaper to run and had a long head start on EVM compatibility, which is why the largest general-purpose L2s by activity are still optimistic. ZK rollups pay for proving and get faster settlement and a cryptographic rather than economic trust model in exchange.

Neither side wins cleanly on general-purpose workloads anymore. Pick ZK when fast, trust-minimized settlement is worth paying the proving cost for, and pick optimistic when raw operating cost and maximal EVM compatibility matter more.

What is rollups-as-a-service (RaaS)?

Launching a rollup used to mean standing up a sequencer, a prover, a bridge contract, and a data availability path yourself, then keeping all four running indefinitely. That is a chain team, not a feature.

Rollups-as-a-service turns that stack into something a provider runs for you. You choose a framework, set your parameters, and the provider operates the sequencer, prover, bridge, and node infrastructure underneath. What you keep is the chain itself, including its fee token, gas policy, transaction ordering rules, and any compliance logic a shared chain would never enforce on your behalf.

The part of the early RaaS pitch that aged badly is the suggestion that this is a five-minute, walk-away operation. It is dramatically faster than building from scratch, and it removes the on-call burden. It does not remove the architecture decisions. You still choose which base layer to settle to, what your data availability tradeoff is, how sequencer decentralization evolves, and how upgrades to the underlying stack reach your chain without breaking it.

Treat RaaS as outsourcing the operations, not the design. For a closer look at the model itself, we cover it in rollups-as-a-service and RaaS and appchains.

When does launching your own ZK rollup make sense?

A dedicated rollup earns its complexity in a few specific situations.

• Predictable, high transaction volume. Once you are consistently paying for a lot of blockspace, dedicated capacity starts to price better than competing for shared capacity.
• A compliance requirement a shared chain cannot meet. Allowlisted participants, transaction-level policy, or jurisdictional constraints are enforceable on a chain you control and nowhere else.
• A product experience that depends on dedicated blockspace. If your confirmation times cannot degrade because an unrelated mint is congesting the network, sharing blockspace is a liability.

It is the wrong call when volume is speculative. A managed provider absorbs the operational load, but you still inherit bridge security, sequencer liveness, and an upgrade cadence you have to track. That surface area is worth taking on against real demand, not projected demand. The business model of rollups is worth reading before you commit, since a chain has to earn its operating cost.

Most teams are better served shipping on an established chain through standard RPC access first, then revisiting once usage patterns make the case. Deferring the decision costs you very little. Unwinding a chain you should not have launched costs a lot.

FAQs about zero-knowledge rollups

What is a ZK rollup?

A ZK rollup is a Layer 2 scaling solution that executes transactions offchain in batches and posts a cryptographic validity proof to the base layer proving the resulting state is correct. The base layer verifies the proof instead of re-executing the transactions, which lowers cost and raises throughput while inheriting the base layer's security.

How do ZK rollups work?

A sequencer batches transactions, a prover generates a validity proof such as a SNARK or STARK, and a verifier contract on the base layer checks that proof before accepting the new state root. Transaction data is published so anyone can reconstruct the rollup's state independently. Ethereum rollups now publish that data in blobs rather than calldata.

Are ZK rollups private?

No, not by default. "Zero-knowledge" describes the proof system, which lets a verifier confirm a state transition is valid without re-executing it. Transactions on a ZK rollup are publicly visible, the same as on Ethereum. Confidentiality requires an additional privacy layer built deliberately on top.

How do ZK rollups differ from optimistic rollups?

ZK rollups prove every batch is valid, so withdrawals settle as soon as the proof is verified. Optimistic rollups assume batches are valid unless challenged, which is why withdrawals wait out a dispute window, conventionally seven days. ZK rollups rely on cryptographic guarantees; optimistic rollups rely on economic incentives and at least one honest challenger.

What are some leading ZK rollup projects?

ZKsync Era, Starknet, Scroll, and Linea are the general-purpose ZK rollups most teams evaluate, with Scroll and Linea both targeting close EVM equivalence. Starknet currently holds L2Beat's Stage 1 rating, though a downgrade to Stage 0 is expected as stricter rules take effect; Scroll, ZKsync Era, and Linea are all Stage 0. Polygon zkEVM's Mainnet Beta sequencer was sunset on July 1, 2026, with Polygon redirecting effort to Polygon PoS and Agglayer.

Can smart contracts run on ZK rollups?

Yes, through zkEVM implementations that prove EVM execution. Compatibility varies. Some zkEVMs prove Ethereum's execution layer directly for maximum compatibility, while others modify bytecode or state structure to make proving cheaper, which can require adjusting contracts or tooling. Check compatibility against your actual dependencies rather than a general claim.

What does rollups-as-a-service (RaaS) mean?

Rollups-as-a-service means a provider operates the sequencer, prover, bridge, and node infrastructure for a rollup you configure and own. It removes the operational burden of running a chain. It does not remove the architecture decisions, including base layer choice, data availability tradeoffs, sequencer decentralization, and how stack upgrades reach your chain.

What makes ZK rollups secure?

ZK rollups inherit security from the base layer. Funds are held in base layer contracts, and a new state root is only accepted when a valid proof is verified onchain, so an operator cannot commit an invalid state. Publishing batch data separately ensures anyone can reconstruct that state independently and detect an operator withholding the data. Resisting censorship of individual transactions is a separate guarantee that depends on a forced-inclusion path to the base layer.