Case Study 1: The ZK-EVM Race — Four Approaches to the Same Problem

Case Study 1: The ZK-EVM Race — Four Approaches to the Same Problem

The Challenge: Making the EVM ZK-Provable

The Ethereum Virtual Machine was designed in 2014 with one goal: deterministic, sandboxed execution of smart contracts. Its designers — Gavin Wood, Vitalik Buterin, and others — were solving the problem of decentralized computation. They were not thinking about zero-knowledge proofs. They could not have been; practical ZK proof systems for general computation did not exist at the time.

A decade later, the Ethereum community converged on a consensus: ZK-rollups are the future of Ethereum scaling. But ZK-rollups that use custom virtual machines force developers to learn new tools, rewrite contracts, and abandon the vast ecosystem of EVM tooling — Solidity compilers, Hardhat, Foundry, OpenZeppelin libraries, block explorers, and debugging tools that thousands of developers use daily.

The solution was the ZK-EVM: a ZK-rollup that is fully compatible with the Ethereum Virtual Machine. Deploy any Ethereum contract on a ZK-EVM, and it works. Use any Ethereum development tool, and it works. The user experience is identical to Ethereum mainnet, but transactions are batched, proved, and verified at a fraction of the cost.

The problem is that building a ZK-EVM is one of the hardest engineering challenges in all of blockchain. The EVM has 140+ opcodes, many of which are deeply hostile to ZK circuit design. The KECCAK256 hash function (used pervasively in the EVM) is notoriously expensive to express as an arithmetic circuit. Memory operations are dynamic and unpredictable. The CALL opcode creates recursive execution contexts. Stack operations are sequential and difficult to parallelize.

By 2023, four major projects had emerged, each attacking the problem from a different angle. Their approaches illuminate the fundamental tradeoffs in ZK-EVM design.

The Four Contenders

zkSync Era (Matter Labs)

Approach: Type 4 ZK-EVM. zkSync does not emulate the EVM at the bytecode level. Instead, it compiles Solidity (and Vyper) source code to its own custom instruction set using a modified LLVM compiler. The resulting bytecode runs on a custom virtual machine called zkEVM, which is designed from the ground up for efficient ZK proving.

Key architectural decision: By abandoning EVM bytecode compatibility, zkSync can optimize its instruction set for ZK-friendliness. Operations that are expensive in ZK circuits (like Keccak256) can be replaced or restructured. The prover circuit is cleaner, smaller, and faster.

Tradeoffs: - Advantage: Fastest proving times among the four. The custom VM is inherently more efficient to prove than an EVM emulator. - Advantage: The LLVM-based compiler can apply aggressive optimizations that are impossible at the bytecode level. - Disadvantage: Not all EVM bytecode works on zkSync. Contracts that rely on specific EVM opcode behavior, inline assembly, or low-level bytecode manipulation may need modification. - Disadvantage: Debuggers and analysis tools that operate at the EVM bytecode level (like Tenderly or Etherscan's bytecode decompiler) do not work directly.

Status (2025): zkSync Era launched its mainnet in March 2023. By 2025, it had processed hundreds of millions of transactions and held billions in TVL. Its "Boojum" proving system (a custom STARK-based prover) generates proofs for batches of thousands of transactions. zkSync has been the most aggressive in pursuing account abstraction and native features that go beyond EVM compatibility.

StarkNet (StarkWare)

Approach: Type 4 ZK-EVM (with some Type 3 characteristics). StarkNet uses the Cairo programming language and virtual machine — a Turing-complete language specifically designed for STARK-provable computation. Solidity support is provided through Warp, a Solidity-to-Cairo transpiler, and through Kakarot, an EVM interpreter written in Cairo.

Key architectural decision: StarkNet is built entirely around STARKs (not SNARKs). This means no trusted setup, quantum resistance, and the ability to leverage StarkWare's decade of research on STARK optimization. The STARK proof is then "wrapped" in a SNARK for cheaper L1 verification — getting the transparency of STARKs and the compression of SNARKs.

Tradeoffs: - Advantage: STARK-based proving is transparent — no trusted setup ceremony. This is a significant selling point for institutions and governments that require fully auditable cryptographic infrastructure. - Advantage: Cairo is designed for provable computation, so writing ZK-native applications is more natural than shoehorning EVM semantics into ZK circuits. - Advantage: StarkNet can prove very large computations efficiently (STARKs scale quasi-linearly with computation size). - Disadvantage: Cairo is a new language. Developers must learn it or rely on transpilation tools. The Solidity-to-Cairo toolchain is improving but does not cover all edge cases. - Disadvantage: Native STARK proofs are large (hundreds of kilobytes). The SNARK-wrapping step adds complexity and introduces a SNARK trust assumption at the final verification stage.

Status (2025): StarkNet launched its mainnet in late 2022. By 2025, it had a growing ecosystem of native Cairo applications, particularly in gaming and DeFi. The Kakarot project (an EVM implementation in Cairo) was enabling increasing EVM compatibility. StarkWare's SHARP (Shared Prover) system generates proofs that are shared across multiple StarkEx applications, amortizing proving costs.

Polygon zkEVM (Polygon Labs)

Approach: Type 2 ZK-EVM. Polygon zkEVM aims for full EVM bytecode equivalence. Any contract that works on Ethereum mainnet should work on Polygon zkEVM without modification — including contracts that use inline assembly, precompiled contracts, and specific opcode behavior.

Key architectural decision: Polygon built a ZK circuit that directly emulates every EVM opcode. This is the brute-force approach: rather than redesigning the VM, they proved the existing VM. Every opcode has a corresponding sub-circuit in the prover. The result is a proving system that is much more complex than zkSync's or StarkNet's, but achieves significantly higher compatibility.

Tradeoffs: - Advantage: Highest EVM compatibility among the four. Developers can deploy existing contracts without any modifications. Existing tooling works out of the box. - Advantage: Gas costs closely match Ethereum mainnet (with some deviations for operations that are particularly expensive to prove). - Disadvantage: The proving circuit is enormous and complex. Proof generation is slower and more resource-intensive than zkSync or StarkNet. - Disadvantage: Some EVM operations (particularly Keccak256 and the CALL opcode) require very large circuits, making proving more expensive for contracts that use these operations heavily.

Status (2025): Polygon zkEVM launched its mainnet beta in March 2023. By 2025, it had steadily improved its prover performance and expanded compatibility coverage. Polygon's strategy of integrating zkEVM with its broader ecosystem (Polygon PoS, Polygon CDK, and the "AggLayer" proof aggregation system) gave it a unique position as an infrastructure provider rather than just a single rollup.

Scroll

Approach: Type 2 ZK-EVM (with aspirations toward Type 1). Like Polygon, Scroll aims for full bytecode-level EVM equivalence. Scroll has been particularly focused on open-source development and community-driven research.

Key architectural decision: Scroll uses a combination of Halo 2 (a recursive SNARK without a trusted setup, developed by the Zcash team) and custom proving infrastructure. Their approach emphasizes correctness and auditability — every part of the proving system is open-source and has been the subject of multiple security audits.

Tradeoffs: - Advantage: Open-source, community-driven development. The entire codebase — including the prover — is publicly available. - Advantage: Halo 2 eliminates the trusted setup while maintaining SNARK-like proof sizes, avoiding the STARK proof size overhead. - Advantage: Close collaboration with the Ethereum Foundation's research team, ensuring alignment with Ethereum's long-term roadmap. - Disadvantage: Development has been slower and more methodical than competitors, prioritizing correctness over speed-to-market. - Disadvantage: Proving times, while improving, are generally longer than zkSync (which benefits from its custom VM).

Status (2025): Scroll launched its mainnet in October 2023. By 2025, it had built a reputation for technical rigor and developer-friendliness. Scroll's emphasis on EVM equivalence and open-source development made it a natural partner for Ethereum-aligned projects.

The Tradeoff Landscape

The four projects can be mapped along two axes:

Axis 1: EVM Compatibility (low to high) - Low: zkSync (Type 4 — Solidity compatible, not bytecode compatible) - Low-Medium: StarkNet (Type 4 — Cairo-native, EVM via transpilation/interpretation) - High: Polygon zkEVM (Type 2 — bytecode equivalent) - High: Scroll (Type 2 — bytecode equivalent, aspiring to Type 1)

Axis 2: ZK-Proving Efficiency (low to high) - Low: Polygon zkEVM, Scroll (brute-force EVM emulation is computationally expensive) - Medium: StarkNet (Cairo is ZK-native, but STARKs have overhead) - High: zkSync (custom VM optimized for ZK proving)

The fundamental tradeoff is clear: the more compatible you are with the EVM, the less efficient your ZK prover is, and vice versa. This is not a temporary engineering limitation — it reflects the fact that the EVM was not designed for ZK provability, and optimizing for ZK provability requires deviating from the EVM.

Analysis Questions

The EVM compatibility spectrum: Why might a project targeting Type 2 (bytecode equivalence) ultimately attract more developers than a Type 4 project, even if the Type 4 project has better performance? Under what circumstances might the reverse be true?
The convergence question: Are these four approaches converging toward a common solution, or are they likely to remain differentiated? What evidence supports each view?
The STARK wrapping strategy: StarkNet generates STARK proofs and then wraps them in SNARK proofs for L1 verification. What are the security implications of this hybrid approach? Does the SNARK wrapper negate the "no trusted setup" advantage of STARKs?
The long-term winner: In 10 years, will we have one dominant ZK-EVM architecture or multiple coexisting ones? What factors will determine the outcome — technical performance, developer experience, network effects, or something else?
Beyond the EVM: Is the assumption that ZK-rollups must be EVM-compatible fundamentally correct? What would a blockchain ecosystem look like if the most popular smart contract execution environment were designed from the ground up for ZK provability?