zkEVM

The zkEVM proves the correct execution of every single EVM opcode within a validity proof. Unlike transpiler-based approaches that compile Solidity to a custom instruction set, a true zkEVM implements the Ethereum Yellow Paper specification directly in its arithmetic circuit. This means the prover must handle the EVM's stack-based architecture, memory model, and gas accounting precisely. The benefit is full compatibility with existing tooling (Hardhat, Foundry) and bytecode, but the cost is a massive circuit with millions of gates for a single block. Implementations like the Type 1 zkEVM prioritize this equivalence above all else, accepting longer proving times for the guarantee that any Ethereum transaction can be proven without modification.

The cryptographic engine underlying a zkEVM's proof system. This primitive allows the prover to commit to the execution trace (a massive polynomial) and later open it at random points chosen by the verifier. The choice of scheme dictates the proof size, verification cost, and security assumptions:

• KZG Commitments: Used in Plonk-based zkEVMs. They produce the smallest proof sizes but require a trusted setup ceremony and rely on pairing-based cryptography.
• FRI (Fast Reed-Solomon IOP): Used in STARK-based zkEVMs. They are transparent (no trusted setup) and post-quantum secure but produce larger proofs.
• IPA (Inner Product Arguments): Used in Halo2-based systems. They eliminate the trusted setup without the proof size blowup of FRI, but have linear verification time unless aggregated.

A zkEVM must cryptographically prove that the state accessed during execution (account balances, contract storage) is correct according to the pre-state root. This involves generating Merkle Patricia Trie inclusion proofs within the circuit. This is one of the most expensive parts of the zkEVM because the EVM's Keccak-256 hash function is circuit-unfriendly, requiring tens of thousands of constraints per invocation. To mitigate this, many zkEVMs adopt Poseidon hashes for a secondary state tree or use lookup arguments to batch Keccak operations. The circuit must also handle state read/write collisions and prove that the final state root correctly transitions from the initial state root.

Instead of generating a single monolithic proof for an entire block, a zkEVM can generate many smaller proofs in parallel (e.g., one per transaction or per opcode segment) and then recursively aggregate them into a single constant-size block proof. This is achieved through Proof Carrying Data (PCD) or Incrementally Verifiable Computation (IVC). The advantage is massive parallelization: thousands of provers can work simultaneously, drastically reducing latency. Systems like Nova use folding schemes to make this recursion extremely cheap, as the expensive cryptographic operations are deferred. The final proof attests that the verifier of each sub-proof accepted, creating a chain of computational integrity.

The zkEVM circuit is not built from generic addition and multiplication gates alone. To optimize prover time, engineers design custom gates that handle common EVM operations in a single constraint. For example, a single 'Keccak chip' might handle an entire round of the hash function, or a 'modular arithmetic chip' might handle the EVM's 256-bit integer math. These specialized sub-circuits are connected via a bus argument or lookup argument, which proves that the output of one chip is correctly used as the input to another. This modular architecture allows different parts of the zkEVM to be upgraded or optimized independently, and is a hallmark of Type 2 and Type 3 zkEVMs that trade some equivalence for performance.