ZK Rollups: zkSync, StarkNet

Optimistic Rollups make you wait 7 days, hoping no one cheats. What if correctness could be proven mathematically in minutes? ZK Rollups generate a cryptographic proof that L1 verifies in one cheap transaction. The prover spends millions of dollars on GPU clusters so the L1 verifier spends $1 on the check. This asymmetry is the foundation of scaling: creating the proof is hard, verifying it is instant. How does math replace trust - and why does the race for the fastest proof define the future of blockchain?

• **zkSync Era** processes transactions for $0.02–0.07 with finalization in minutes instead of 7 days. More than 200 dApps deployed, including SyncSwap, Mute, and SpaceFi
• **StarkNet** with Cairo delivers the fastest proving and was already used by dYdX v3 (StarkEx) to process $1T+ in trading volume - every trade cryptographically proven
• **Proof markets** (Gevulot, =nil; Foundation) are creating a new compute market: provers compete for the right to generate ZK proofs, much like miners competed for blocks in Bitcoin

Предварительные знания

• Rollups: the Scaling Idea

Validity Proofs: Math Instead of Waiting

In the Optimistic Rollups lesson, we saw their main problem: the **7-day challenge period**. The user initiates a withdrawal and waits a week while the system ensures no one disputes the result. ZK Rollups solve this problem decisively: instead of waiting for disputes, they **prove correctness mathematically**. Every transaction batch is accompanied by a **validity proof** - a cryptographic proof that all state transitions were executed correctly.

The difference in approaches is fundamental. Optimistic Rollups use a **reactive** model: publish the result and wait for someone to find an error. ZK Rollups use a **proactive** model: they prove correctness **before** L1 accepts the result. It's like the difference between a teacher grading every paper (ZK - each one is checked) versus a system that gives everyone an A and revisits only if someone complains (Optimistic).

A validity proof guarantees: "for every transaction in the batch, there exists a correct state transition, and the final state root mathematically follows from the initial state root and the list of transactions". The L1 contract receives the proof, verifies it for ~250K gas (one cheap transaction), and instantly accepts the new state root. No waiting, no trust - pure math.

**Trusted setup - what it is and why it matters.** SNARK systems (Groth16, PLONK) require a one-time parameter generation ceremony. If at least one participant destroyed their secret - the system is secure. But if ALL participants colluded - fake proofs can be created. Zcash ran a famous ceremony with 6 participants, including Edward Snowden. STARK systems require no trusted setup - parameters are derived from public randomness. This makes STARKs "transparent", which is considered an advantage for long-term security.

A hybrid approach is gaining popularity. Polygon zkEVM and other systems use STARK proofs for the main computation (no trusted setup, better scalability), then wrap the result in a compact SNARK proof for cheap L1 verification. This gets the best of both worlds: STARK security and the cost efficiency of SNARK verification.

Prover and Verifier: the Asymmetry of Computation

At the heart of ZK Rollups lies a remarkable mathematical asymmetry: **creating a proof** (proving) requires enormous computation, while **verifying a proof** (verification) requires almost none. It's like the difference between writing a novel and checking that it has 300 pages. The prover is a powerful server or GPU cluster working off-chain for minutes or hours. The verifier is an L1 smart contract that checks the proof in a single transaction.

This asymmetry is the key to scaling. On Ethereum L1, 500,000 validators **each** execute **every** transaction. In a ZK Rollup, one powerful prover executes all transactions off-chain, generates a compact proof, and L1 verifies **one proof instead of thousands of transactions**. The larger the batch, the cheaper each transaction - the verification cost of the proof is fixed (~250K gas), and it is divided among all transactions.

**Centralized proving - today's reality.** In 2025, zkSync Era, StarkNet, and Scroll all use centralized provers run by project teams. If the prover stops generating proofs, the rollup stalls (L2 transactions execute but are not finalized on L1). Decentralizing proving via proof markets is an active area of research, but no production-ready protocol has been deployed on mainnet yet.

**Proof markets** are a market mechanism for decentralizing proving. The idea: any participant with sufficient hardware can become a prover. The sequencer publishes a proof generation task; provers compete on price and speed; the winner receives a reward. This creates a compute market analogous to mining - but instead of pointless hash grinding, provers do useful work: proving transaction correctness.

**Economics of proving.** Generating a proof for a batch of 1,000 transactions on a GPU cluster costs $5–50 (electricity + hardware depreciation). Verifying it on L1: ~250K gas (~$0.50–2.00). Total: ~$0.005–0.05 per transaction for proving + verification. For comparison: a direct L1 Ethereum transaction costs $1–10+. A ZK Rollup makes transactions 20–200x cheaper while inheriting L1 security.

zkEVM: Four Types of Compatibility

The main engineering challenge of ZK Rollups: **the EVM was not designed for ZK proofs**. The Ethereum Virtual Machine was built to execute transactions, not to make every opcode provable in a ZK circuit. Opcodes like `KECCAK256` (hashing) are extremely inefficient for ZK proving, and `SELFDESTRUCT`, `DIFFICULTY`, and `BLOCKHASH` don't even make sense in an L2 context. Building a "ZK-compatible EVM" is therefore an engineering challenge with many tradeoffs.

In 2022, Vitalik Buterin proposed a classification of zkEVMs into **four types**, from full Ethereum equivalence (Type 1) to language compatibility (Type 4). Each subsequent type sacrifices compatibility for proving efficiency. This is not a better/worse scale - it's a spectrum of tradeoffs.

**zkSync Era** (Type 4) is a clear example of the tradeoff. Matter Labs built their own compiler **zksolc**, which compiles Solidity not to standard EVM bytecode but to an intermediate representation (IR) optimized for ZK proving. This means Solidity code compiles and runs, but the bytecode differs from EVM. Contracts using inline assembly or EVM-specific tricks may not work. But proving is fast and cheap.

**StarkNet** went furthest in the Type 4 direction by creating its own programming language - **Cairo**. Cairo is designed from scratch for ZK proving: every operation is efficiently provable, and there are no "heavy" opcodes. This delivers maximum proving performance, but requires developers to learn a new language. Cairo 2.0 became similar to Rust (with an ownership model), making it easier for Rust developers to migrate - but Solidity developers must start from scratch.

**Why KECCAK256 is the enemy of zkEVM.** Ethereum uses KECCAK256 everywhere: hashing storage slots, contract addresses, the Merkle Patricia Trie. But KECCAK256 is extremely inefficient for ZK circuits: a single KECCAK operation in a ZK proof requires ~150,000 constraints, while the ZK-friendly Poseidon hash needs only ~250 constraints. That's a 600x difference! Type 1 zkEVM must prove KECCAK as-is (slowly). Types 2+ can replace internal hashes with Poseidon while keeping KECCAK only for EVM opcode compatibility.

Proof Generation: from Circuit to On-Chain Verification

Generating a ZK proof means turning a computational task into a mathematical equation and finding its "witness". The process begins with **arithmetization** - transforming a program (transactions) into a system of polynomial constraints (**circuit**). Every opcode, every storage read, every arithmetic operation becomes a set of constraints. The more transactions in a batch, the more constraints, and the longer proving takes.

**Proof time** depends on batch size and transaction complexity. A simple ETH transfer - ~500 constraints. A complex DeFi swap with storage reads - ~50,000+ constraints. A batch of 1,000 mixed transactions can contain 10–100 million constraints. GPU acceleration is critical: the main proving operations (Fast Fourier Transform, Multi-Scalar Multiplication) parallelize on GPU 10–50x more efficiently than on CPU.

**Proof aggregation** (recursive proofs) is a key optimization. Instead of one proof per batch, the prover generates small proofs for parts of the batch, then creates a **meta-proof** that proves: "all the small proofs are valid". This meta-proof is verified on L1 as a single proof. Recursion enables: 1. parallelizing proving across multiple machines 2. aggregating proofs from multiple batches into one, reducing L1 gas cost.

**Real-time proving - the holy grail of ZK.** Today, proving takes minutes. The goal is to bring proving down to block time (~1–2 seconds) so every L2 block immediately comes with a proof. This would eliminate finalization delays entirely. Several teams are working on it: Succinct SP1, RISC Zero, Polygon Miden. A combination of ASIC acceleration, optimized proof systems, and parallelization may achieve real-time proving by 2026–2027.

Proving costs decline following a law that resembles Moore's Law: costs roughly halve each year through algorithmic optimizations (new proof systems), hardware acceleration (GPU → FPGA → ASIC), and better parallelization. StarkNet in 2024 cut proving costs by 90% relative to 2023 by switching to SHARP (Shared Prover) with recursive proofs. The trend is unambiguous: ZK proving is becoming a commodity resource.

Key Takeaways

• **Validity proofs** replace Optimistic Rollups' 7-day wait with a mathematical guarantee: the prover generates the proof, the L1 verifier checks it for ~250K gas, and the state root finalizes instantly. SNARK - compact proofs (300 bytes) but require a trusted setup. STARK - larger (40–200 KB) and more expensive to verify, but transparent and quantum-resistant
• **Prover/Verifier asymmetry** is the core of scaling: prove = O(n log n) off-chain on a GPU cluster for minutes; verify = O(1) on-chain for ~$1. Proving cost is divided across the entire batch: 10,000 transactions → ~$0.001 per verification. Proof markets decentralize proving through prover competition
• **zkEVM Types 1–4** balance compatibility and proving speed: Type 2 (Scroll, Polygon zkEVM) - full EVM equivalence, slow proving. Type 4 (zkSync Era/Solidity→IR, StarkNet/Cairo) - maximum ZK efficiency, limited compatibility. KECCAK256 in ZK = 600x overhead vs Poseidon
• **Proof generation** involves arithmetization (code → circuits), witness generation, and polynomial commitments. GPU accelerates proving by 25–30x vs CPU. Recursive proofs aggregate many batches into one proof, fixing the L1 verification cost regardless of volume
• The math in the hook is not just a metaphor - ZK Rollups literally replace trust ('wait 7 days in case of fraud') with mathematical certainty ('proof verified, state root is correct'). The prove/verify asymmetry makes this economically feasible: expensive to prove, cheap to verify - and transactions scale without sacrificing L1 security

Related Topics

ZK Rollups sit at the intersection of cryptography, L2 scaling, and EVM compatibility engineering:

• Rollups: Introduction — The foundation of ZK Rollups: data availability, off-chain execution, on-chain settlement. ZK Rollups follow the same principles but replace fraud proofs with validity proofs
• Optimistic Rollups: Arbitrum, Optimism — An alternative scaling approach: fraud proofs instead of validity proofs, 7-day challenge period instead of instant finalization, full EVM equivalence without zkEVM constraints
• ZK Proof Fundamentals — Mathematical foundations: zero-knowledge proofs, commitment schemes, interactive vs non-interactive proofs - the theory behind SNARK and STARK systems
• zk-SNARK: Deep Dive — Detailed breakdown of the SNARK system: pairing-based cryptography, Groth16, PLONK, trusted setup ceremonies - how compact proofs are generated and verified

Вопросы для размышления

• Type 4 zkEVM (zkSync, StarkNet) sacrifices compatibility for proving speed, while Type 2 (Scroll, Polygon zkEVM) does the opposite. Which approach will win? Or is the L2 market large enough for both, the way Windows and macOS have coexisted for decades?
• Proving today is centralized - one team controls the GPU cluster. Proof markets promise decentralization, but create a new kind of 'mining' (whoever has more GPUs earns more). Won't this lead to the same concentration seen in Bitcoin mining?
• If real-time proving becomes a reality (proof in <1 second), will Optimistic Rollups still be needed? Or will their ecosystem advantage (Arbitrum TVL, Base adoption) make ZK's technical superiority irrelevant?

Связанные уроки

• crypto-34-zkp-basics