ZK-Rollups: Zero-Knowledge Scaling

ZK-rollups (Zero-Knowledge rollups) are a Layer 2 scaling solution that uses cryptographic validity proofs to verify the correctness of off-chain computations on the Layer 1. Unlike optimistic rollups, which assume transactions are valid and retroactively check for fraud, ZK-rollups mathematically prove that every state transition is correct before it is accepted on the L1.

This fundamental architectural difference eliminates the need for a challenge period, enables faster L1 finality, and provides stronger security guarantees. However, ZK-rollups come with their own tradeoffs, particularly in computational overhead and EVM compatibility.

Zero-Knowledge Proofs: A Primer

A zero-knowledge proof is a cryptographic method by which one party (the prover) can demonstrate to another party (the verifier) that a statement is true without revealing any information beyond the truth of the statement itself.

In the context of rollups, the relevant property is not actually the "zero-knowledge" aspect (hiding information) but rather the succinctness: a small proof can attest to the correctness of a large computation. The verifier (the L1 smart contract) can check the proof in constant or near-constant time, regardless of how many transactions were executed.

Key Properties

• Completeness: If the statement is true, an honest prover can convince the verifier.
• Soundness: If the statement is false, no dishonest prover can convince the verifier (except with negligible probability).
• Succinctness: The proof is much smaller than the computation it attests to, and verification is fast.
• Zero-knowledge (optional): The proof reveals nothing beyond the truth of the statement. This property is used for privacy applications but is not strictly required for scaling.

Proof Systems: SNARKs vs. STARKs

Two major families of proof systems are used in ZK-rollups:

Validity Proofs vs. Fraud Proofs

The distinction between validity proofs (ZK-rollups) and fraud proofs (optimistic rollups) is the most important architectural difference in L2 design:

• Validity proofs (ZK-rollups): Every batch of transactions must be accompanied by a cryptographic proof of correctness. The L1 verifies the proof before accepting the state update. Invalid states are impossible to finalize.
• Fraud proofs (optimistic rollups): State updates are accepted provisionally. During a challenge period (7 days), anyone can prove that a state update is incorrect. Invalid states are detected and reverted after the fact.

The practical implications:

• Finality: ZK-rollup state updates are final on L1 as soon as the proof is verified (minutes). Optimistic rollup state updates are final only after the challenge period expires (7 days).
• Withdrawals: ZK-rollup withdrawals to L1 are fast (minutes to hours). Optimistic rollup native withdrawals take 7 days.
• Security assumption: ZK-rollups rely on mathematical soundness (no honest verifier needed). Optimistic rollups require at least one honest watcher (1-of-N assumption).
• Computational cost: ZK-rollups require significant off-chain computation to generate proofs. Optimistic rollups have lower off-chain overhead.

How ZK-Rollups Work

1. Transaction collection: The sequencer collects and orders user transactions.
2. Off-chain execution: Transactions are executed off-chain, producing a new state root.
3. Proof generation: A prover generates a validity proof (SNARK or STARK) that mathematically demonstrates the state transition is correct. This is the most computationally intensive step.
4. L1 submission: The sequencer posts the new state root, compressed transaction data (or state diffs), and the validity proof to the L1 rollup contract.
5. On-chain verification: The L1 smart contract verifies the proof. If valid, the new state root is accepted immediately. If invalid, the submission is rejected.

The key insight: verifying a ZK proof on-chain is orders of magnitude cheaper than re-executing the transactions. A proof attesting to thousands of transactions can be verified in a single L1 transaction consuming approximately 300,000–500,000 gas.

zkEVM Types (Type 1 through Type 4)

Achieving EVM compatibility within a ZK-rollup is one of the hardest problems in blockchain engineering. The EVM was not designed with ZK-provability in mind—many of its opcodes and data structures are "ZK-unfriendly" (expensive to prove in a ZK circuit).

Vitalik Buterin proposed a classification of zkEVMs by their level of Ethereum equivalence:

Type 1: Fully Ethereum-Equivalent

Proves the exact Ethereum execution environment, including the same state tree (Merkle Patricia Trie), hash functions, and all opcodes. A Type 1 zkEVM can prove existing Ethereum blocks. No existing zkEVM has achieved Type 1 in production, though projects like Taiko are working toward it.

• Advantage: Perfect compatibility. Any Ethereum contract works without modification.
• Challenge: Extremely slow proof generation due to ZK-unfriendly components (Keccak hashing, MPT).

Type 2: Fully EVM-Equivalent

Equivalent at the EVM level but may use different internal data structures (e.g., a different state tree). Smart contracts behave identically, but block structure and state proofs differ from Ethereum.

• Advantage: Near-perfect compatibility. Existing contracts and tooling work.
• Challenge: Some EVM opcodes remain expensive to prove.
• Example: Scroll, Polygon zkEVM (targeting Type 2).

Type 3: Almost EVM-Equivalent

Removes a few EVM features that are particularly hard to prove (e.g., precompiles). Most contracts work, but some may need minor modifications.

• Advantage: Faster proof generation.
• Challenge: Some contracts require adaptation.
• Example: Polygon zkEVM in early versions.

Type 4: High-Level Language Equivalent

Compiles Solidity (or other high-level languages) to a ZK-friendly instruction set rather than proving EVM bytecode. The developer experience is similar, but the execution environment is fundamentally different.

• Advantage: Fastest proof generation. Can optimize the instruction set for ZK efficiency.
• Challenge: Bytecode-level tools (debuggers, verifiers) may not work. Subtle behavioral differences possible.
• Example: zkSync Era (uses LLVM-based compiler to custom bytecode).

Major ZK-Rollup Implementations

zkSync Era

Developed by Matter Labs, zkSync Era is a Type 4 zkEVM that compiles Solidity and Vyper to its own bytecode using an LLVM-based compiler.

• Proof system: SNARK (PLONK-based)
• Native account abstraction: All accounts are smart contracts by default, enabling gasless transactions and social recovery
• Hyperchains: Framework for deploying custom ZK-rollup chains that settle on zkSync
• Data availability: Posts state diffs to L1 (not full transaction data), reducing costs

StarkNet

Developed by StarkWare, StarkNet uses STARK proofs (no trusted setup, quantum-resistant) and a custom smart contract language called Cairo.

• Proof system: STARK (transparent, no trusted setup)
• Language: Cairo (purpose-built for ZK-provable computation)
• Architecture: Recursive proofs—multiple proofs can be combined into a single proof for L1 submission
• Existing deployment: StarkEx (application-specific ZK engine) powers dYdX v3, Immutable X, and Sorare

Polygon zkEVM

Developed by Polygon Labs, Polygon zkEVM targets Type 2 EVM equivalence—proving actual EVM bytecode execution.

• Proof system: SNARK (custom recursive proof system)
• EVM equivalence: Aims for full bytecode-level compatibility
• Integration: Part of the broader Polygon 2.0 ecosystem with the AggLayer for cross-chain interoperability
• Approach: Type 2/3 equivalence, progressing toward Type 1

Advantages Over Optimistic Rollups

• No challenge period: State updates are verified immediately via validity proofs. No 7-day waiting period for withdrawals.
• Stronger security: Security relies on mathematical soundness, not on the assumption that at least one honest verifier is watching.
• Lower L1 data costs (potentially): Some ZK-rollups can post only state diffs rather than full transaction data, since the proof itself guarantees correctness.
• Privacy potential: The zero-knowledge property can be leveraged for private transactions and selective disclosure.

Current Limitations

• Proof generation cost: Generating ZK proofs requires significant computational resources (specialized hardware, high-memory servers). This cost is amortized across many transactions but remains a significant infrastructure expense.
• Proof generation latency: Generating a proof for a batch of transactions takes minutes to hours, depending on batch size and proof system. This introduces a delay between transaction execution and L1 finality.
• EVM compatibility gaps: No production zkEVM has achieved full Type 1 equivalence. Developers may encounter edge cases where contracts behave differently from Ethereum.
• Complexity: ZK proof systems are among the most complex cryptographic constructions in use. Bugs in the proof system or circuit implementation could have catastrophic security consequences.
• Ecosystem maturity: ZK-rollup ecosystems are younger than optimistic rollup ecosystems, with smaller TVL, fewer deployed applications, and less battle-tested infrastructure.