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.

翻译：暂无翻译