Constraint-Level Design of zkEVMs: Architectures, Trade-offs, and Evolution

TL;DR

This work addresses the challenge of reconciling Ethereum’s transparent, sequential EVM execution with zero-knowledge proof constraints by developing a systematic architectural framework. It analyzes arithmetization choices (R1CS, PLONKish, AIR), constraint-dispatch mechanisms (static inlining, selectors, ROM-based fetch), and EVM semantic rewrites across production zkEVMs, including Type 1–4 compatibility spectra. The paper also surveys recursion strategies for proof composition, contrasts zkVMs with zkEVMs, and identifies open problems—proving equivalence, benchmarking, hardware acceleration, privacy, and cross-chain interoperability. By synthesizing findings from five major implementations, it provides a practical roadmap for deploying scalable, secure zkEVMs and guiding future research toward sub-second proving, formal verification, and interoperable, hybrid architectures.

Abstract

Zero-knowledge Ethereum Virtual Machines (zkEVMs) must reconcile a fundamental contradiction: the Ethereum Virtual Machine was designed for transparent sequential execution, while zero-knowledge proofs require algebraic circuit representations. This survey provides the first systematic analysis of how existing major production zkEVM implementations resolve this tension through distinct constraint engineering strategies. We develop a comparative framework that maps the design space across three architectural dimensions. First, arithmetization schemes reveal stark trade-offs: R1CS requires compositional gadget libraries, PLONKish achieves elegance through custom gates that capture complex EVM opcodes in single constraints, while the homogeneous structure of AIR fundamentally mismatches the irregular instruction set of EVM. Second, dispatch mechanisms determine constraint activation patterns: selector-based systems waste trace width on inactive constraints, while ROM-based approaches trade memory lookups for execution flexibility. Third, the Type 1-4 spectrum quantifies an inescapable trade-off: the bit-level EVM compatibility of Type 1 demands significantly higher constraint complexity than the custom instruction sets of Type 4. Beyond cataloging implementations, we identify critical open problems across multiple domains: performance barriers preventing sub-second proving, absence of formal verification for constraint-to-EVM semantic equivalence, lack of standardized benchmarking frameworks, and architectural gaps in hybrid zkEVM/zkVM designs, decentralized prover coordination, privacy preservation, and interoperability.

Figures (2)

• Figure 1: Architectural variants for encoding the SHA3 opcode in zkEVMs. (a) The monolithic design encodes the entire SHA3 operation as a single high-degree constraint in the main trace. (b) The decomposed design models each SHA3 sub-operation with a separate low-degree constraint. (c) The decomposed with auxiliary table design moves the SHA3 logic to a dedicated auxiliary table. The main trace references the auxiliary computation through compact boundary constraints. For brevity, the low-degree decomposition constraints are omitted in (c), but their structure is identical to (b) within the auxiliary table.
• Figure 2: Three-layer trust model of zkVMs emulating EVM. Layer 3 (compiler) and Layer 2 (runtime) are trusted to correctly implement EVM semantics but lack cryptographic verification—bugs produce valid proofs of incorrect computations. Only Layer 1 (constraints) provides cryptographic guarantees, verifying zkVM instruction correctness without checking EVM semantic fidelity.