zkEVM: How Zero-Knowledge Proofs Scale Ethereum

Without zkEVM:
  L1 Ethereum: ──▶ Execute tx ──▶ Update state ──▶ Everyone verifies
               Each L1 node re-executes every tx.
               Cost: ~$50/tx at high gas prices.

With zkEVM (ZK rollup):
  L2 Sequencer: ──▶ Execute tx ──▶ Generate proof ──▶ Submit to L1
                     │                                       │
                     │ (single execution)                     │
                     │                                       │
  L1 Ethereum:      ────────────────────────────────────────▶ Verify proof
                     Cost: ~$0.01-0.10/tx (proof verification is cheap)
                     Security: Inherits Ethereum security (proof is on-chain)

Key property of ZK proofs:
  Proof size: ~200-500 KB (constant, independent of computation)
  Verification time: ~5ms (on-chain → cheap L1 gas cost)
  Proving time: 2-8 minutes per block (off-chain → doesn't limit L2)

Without ZK: Verify = re-execute (10M gas = 100ms on L1)
With ZK:    Verify = check proof (5ms on L1, constant cost)

Block execution (10M gas, ~50-100 txs):
  CPU time: ~1 second (native execution)
  GPU time: ~100ms (with optimized executors)

Proof generation (for the same block):
  Type 1 zkEVM (full EVM): 5-15 minutes (prover cluster)
  Type 2 zkEVM (compatible): 2-5 minutes
  Type 4 zkEVM (different VM): 30 seconds - 2 minutes

The bottleneck: Proving is 300-900x slower than execution!

Cost per 10M gas block:
  2023: $50-100/proof
  2024: $20-50/proof
  2025: $10-25/proof
  2026: $3-15/proof
  Target: <$1/proof (2027-2028)

Improvements driving cost down:
  - Better prover algorithms (optimized MSM, FFT)
  - Custom hardware (FPGAs, specialized ASICs in development)
  - Proof aggregation (many txs → one proof)
  - Recursive proofs (roll up multiple blocks)

Definition: Proves EVM execution identically to L1 (same opcodes, same gas costs)

Example: Scroll

Characteristics:
  - Can run ANY existing Ethereum smart contract without changes
  - Same gas costs as L1
  - Proving is the HARDEST (complex ≈ many constraints)
  - Proving time: 5-15 min per block

Best for:
  - Maximum compatibility — just deploy current contracts
  - Teams that want "ETH at scale" without migration
  - Long-term goal of making ZK proving fast enough for L1 itself

Definition: Proves EVM execution with slightly modified gas costs or precompile handling

Example: Polygon zkEVM, Linea

Characteristics:
  - Most contracts work without changes (99%+)
  - Minor gas cost differences
  - Proving is HARD but slightly easier than Type 1
  - Proving time: 2-5 min per block

Best for:
  - Teams that want compatibility with slight perf improvements
  - Most current Ethereum developers

Definition: Executes a different VM that's designed for ZK friendliness

Example: zkSync Era (zkVM → compiles to ZK-friendly circuit)

Characteristics:
  - Most contracts work (some require modification)
  - Different opcodes, different gas costs
  - Proving is much FASTER (ZK-friendly VM design)
  - Proving time: 1-3 min per block

Best for:
  - Teams willing to make small contract changes
  - Applications that benefit from lower gas costs
  - Use of native account abstraction

Definition: Uses a non-EVM ZK VM that compiles from high-level language

Example: StarkNet (Cairo VM)

Characteristics:
  - Contracts must be rewritten in Cairo or compiled from Solidity
  - Most efficient proving (designed for ZK from ground up)
  - Proving time: 30 sec - 2 min per block
  - Limited ecosystem compatibility

Best for:
  - Greenfield projects
  - Teams that want maximum ZK efficiency
  - Projects that can rewrite contracts

EVM Compatibility:    100%  ◄──────────────────────►  0%
Proving Efficiency:   1x    ◄──────────────────────►  10x+

Type 1: 100% compat, 1x proving speed
Type 2: 99% compat, 2-3x proving speed
Type 3: 95% compat, 5-10x proving speed
Type 4: Solidity→Cairo, 10-15x proving speed

Most popular zkEVM proving system (zkSync, Scroll, Polygon):

Key features:
  - Universal trusted setup (one-time ceremony, applies to all circuits)
  - Constant-size proofs (~200-400 bytes)
  - Efficient on-chain verification (~300K gas)
  - Supports recursion (proof of a proof)

Proving pipeline (simplified):
  1. Execution trace → constraints → polynomial representation
  2. Commit to polynomials (KZG commitments)
  3. Open commitments at random challenge points
  4. Aggregate into single proof

Performance:
  - Prover: O(n log n) where n = constraint count
  - Verifier: O(1)
  - Memory: O(n) for proving (can be 100+ GB)

Used by StarkNet, emerging as alternative for zkEVM:

Key features:
  - No trusted setup (transparent — just public randomness)
  - Larger proofs (~100-200 KB)
  - Post-quantum secure (hashes, not pairings)
  - Best for parallel proving (GPU-friendly)

Proving pipeline:
  1. Execution trace → algebraic intermediate representation (AIR)
  2. Low-degree extension (Reed-Solomon)
  3. Merkle tree commitments
  4. FRI protocol (proximity testing)

Performance:
  - Prover: O(n log² n)
  - Verifier: O(log² n)
  - Better parallelism than PLONK
  - Most suited for large circuits (Type 1 zkEVM)

2026 consensus:

For Type 1/2 (full EVM):
  Starks (or Stark-like): Better for large circuits
  → More parallelizable
  → Better GPU utilization
  → No trusted setup

For Type 3/4 (designer VM):
  PLONK (or Halo2): Better for smaller circuits
  → Faster verification on-chain
  → Lower L1 fixed cost

Emerging: Hybrid systems
  SNARK inside STARK: Good of both
  Scroll's GKR-based proving: Custom zkEVM prover

Phase 1: Execution (L2 Sequencer)
  1. User submits transaction to L2 sequencer
  2. Sequencer executes it in go-ethereum (standard EVM)
  3. Produces execution trace: every opcode, stack state, memory, storage
  4. Updates L2 state root
  5. Sends block to prove

Phase 2: Witness Generation
  1. Trace → witnesses (program inputs/outputs)
  2. Generate circuit constraints:
     - Each opcode → polynomial constraint
     - Stack operations → permutation constraints
     - Memory operations → lookup constraints
     - Storage writes → write-once constraints
  3. Witness size: ~10-100 GB (depends on block complexity)

Phase 3: Proof Generation (Prover)
  1. Commit to polynomials (KZG commitments)
  2. FFTs to evaluate polynomial at roots of unity
  3. Multi-scalar multiplication (MSM) for each commitment
  4. Opening proofs for each evaluated point
  5. Aggregate all proofs

  Parallel:
    - Many opcodes can be proved independently
    - Scroll uses 4-8 GPUs in parallel
    - Proof time: 7-10 min for 10M gas block

Phase 4: On-Chain Verification
  1. Proof (~300 KB) submitted to L1
  2. L1 verifier contract checks the proof (~300K gas)
  3. If valid: L1 updates state root
  4. User's transaction is final (no 7-day wait!)

Total time from tx submission to L1 finality:
  Execution:      ~1 second
  Proving:        ~7-10 minutes
  L1 submission:  ~1 minute (wait for L1 block)
  L1 finality:    ~12 seconds
  ─────────────────────────────────
  Total:          ~8-12 minutes

Scroll: Prover credits — $0.0001/gas of proving
zkSync: Shared prover (sequencer covers proving cost)
Linea:  ConsenSys-managed prover
StarkNet: SHARP prover (shared across multiple dApps)

For most developers: Proving cost is included in L2 gas fees.
You don't need to run a prover unless you're operating a sequencer.

Current bottlenecks ranked:
1. MSM (Multi-Scalar Multiplication) — 60% of proving time
   → Optimized: Use H100 tensor cores, MSM ASICs emerging

2. FFT (Fast Fourier Transform) — 20% of proving time
   → Optimized: Cooley-Tukey, parallel FFT libs

3. Memory bandwidth — 15% of proving time
   → Optimized: HBM3e on H200/B200

4. Network (for multi-GPU) — 5% of proving time
   → Optimized: NVLink + InfiniBand

Expected improvements:
  2027: 2-3x faster proving (FPGA + software)
  2028: 5-10x faster proving (custom ASICs)

2026 trend: Optimistic rollups adopting ZK
- Arbitrum: Researching "zk-arbitrum" for fast finality
- Optimism: Exploring OP-Succinct (ZK for fault proofs)
- Base: Coinbase supporting ZK-prover research

Vision: Hybrid model
  - Use optimistic for normal operations (no prover cost)
  - Generate ZK proof in background to enable fast exits
  - After ZK proof: no more 7-day wait
  - Called "ZK fault proof" or "validity proof bridge"

Expected timeline:
  2026: Research + early implementation
  2027: Production ZK for optimistic rollups
  2028: All major L2s have ZK finality

Level 0: Block N proof (200 KB)
Level 1: Proof of Block N-1 + Block N (200 KB)
Level 2: Proof of Level 1 + Level 1 (200 KB)
...

Result: One proof can verify a thousand blocks!
Final proof size: still ~200 KB
Verification cost: still ~300K gas

Aggregation: Combine many proofs into one

Instead of submitting a proof for every L2 block:
  1. Prove block 1
  2. Prove block 2
  2. Aggregate: proof(proof(block1) + proof(block2))
  ...
  n. Submit ONE aggregated proof for 1000 blocks

L1 cost savings:
  Without aggregation: 300K gas per block × 1000 = 300M gas
  With aggregation:    300K gas for all 1000 blocks = 300K gas
  Savings: 99.9% reduction in L1 settlement costs!

2026: Most zkEVMs have basic recursion
  - Scroll: Recursive proof for 2-4 blocks
  - zkSync: Using recursion for proof compression
  - StarkNet: SHARP already aggregates

2027-2028: Full aggregation
  - One proof per day (for all L2 blocks)
  - L1 settlement cost: ~$5/day regardless of L2 volume
  - Effectively zero-cost L1 security