Constraint-Level Design of zkEVMs: Architectures, Trade-offs, and Evolution
This survey offers a systematic, constraint-level taxonomy of zkEVM design for researchers and engineers building or evaluating zero-knowledge proof systems for Ethereum compatibility.
This survey provides the first constraint-level analysis of five production zkEVMs and three universal zkVMs, revealing that EVM compatibility (Type 1-4) is the defining architectural decision. It shows that all surveyed zkEVMs use PLONKish arithmetization, while zkVMs use AIR, and that higher EVM compatibility leads to higher constraint counts.
Zero-Knowledge Ethereum Virtual Machines (zkEVMs) must reconcile an inherent tension. The Ethereum Virtual Machine (EVM) was designed for transparent step-by-step execution with dynamic control flow. Proving such execution in zero-knowledge, however, requires transforming it into algebraic circuit representations that encode computation as mathematical constraints. Existing surveys address zkEVMs at the level of implementations, cryptographic primitives, or Layer 2 deployment, leaving the constraint-system design that governs their cost largely unexamined. This survey provides the first constraint-level analysis of how five production zkEVM systems and three universal Zero-Knowledge Virtual Machines (zkVMs) resolve this tension through constraint engineering. We show that the degree of EVM compatibility, captured by the Type 1-4 spectrum, is the defining architectural decision that shapes all subsequent technical choices. We classify the design space along four architectural dimensions, namely arithmetization frameworks, dispatch strategies, semantic rewrites, and recursion approaches. Examining the mechanisms within each dimension, we identify the technical factors and trade-offs that drive each choice. The analysis reveals that all five surveyed production zkEVMs adopt PLONKish arithmetization. The zkVMs instead rely on the Algebraic Intermediate Representation (AIR), which suits uniform state machines. A single trade-off between EVM compatibility and constraint cost underlies these choices. The most Ethereum-equivalent systems accept higher constraint counts to preserve full bytecode fidelity, while systems that relax that fidelity attain substantially lower constraint counts. We close with the critical open problems and future research directions that this constraint-level view brings into focus.