zkEVM (Zero-Knowledge Ethereum Virtual Machine)

What Is a zkEVM?

A zkEVM (Zero-Knowledge Ethereum Virtual Machine) is a virtual machine that executes smart contracts in a manner compatible with Ethereum while generating validity proofs that cryptographically attest to the correctness of every computation. Instead of requiring every node to re-execute every transaction (as Ethereum L1 does), a zkEVM lets a single prover execute transactions off-chain and produce a succinct proof that any verifier can check cheaply on-chain.

The core challenge is that the Ethereum Virtual Machine was never designed with zero-knowledge proof systems in mind. EVM opcodes like KECCAK256, SLOAD, and CALL involve operations that are computationally expensive to represent inside an arithmetic circuit: the algebraic framework that ZK proof systems require. A zkEVM must bridge this gap, translating EVM semantics into a provable format without breaking compatibility with existing Solidity contracts and developer tools.

This technology sits at the intersection of two major blockchain trends: ZK-rollups for scaling and EVM compatibility for ecosystem adoption. Before zkEVMs, ZK-rollups required developers to write contracts in custom languages (like Cairo for StarkNet). A zkEVM removes that barrier, letting developers deploy existing Solidity code on a ZK-rollup with minimal or no changes.

How It Works

A zkEVM operates as the execution layer of a ZK-rollup. The process follows a cycle of off-chain execution, proof generation, and on-chain verification:

1. Users submit transactions to the ZK-rollup's sequencer, which orders and batches them
2. The zkEVM executes each transaction, updating account balances, contract storage, and other state: exactly as the standard EVM would
3. A prover takes the execution trace (the record of every opcode executed and every state change made) and converts it into an arithmetic circuit
4. The prover generates a ZK-SNARK or ZK-STARK proof that the execution was performed correctly
5. This proof, along with the new state root, is submitted to a verifier contract on Ethereum L1
6. The L1 verifier contract checks the proof (a constant-time operation regardless of how many transactions the batch contained) and accepts the state transition

The Proving Pipeline

The most technically demanding part of a zkEVM is converting EVM execution into a provable format. This involves several stages:

First, the execution trace is generated. Every opcode the EVM processes produces a row in a trace table recording the program counter, stack state, memory contents, and storage reads/writes. A single Ethereum block can produce millions of trace rows.

Next, custom circuits enforce constraints on the trace. Each EVM opcode maps to a set of polynomial constraints that must hold true if the opcode was executed correctly. For example, an ADD opcode constraint verifies that the output equals the sum of the two inputs.

Finally, the prover runs a cryptographic protocol (typically based on polynomial commitment schemes like KZG or FRI) to compress the entire constrained trace into a compact proof. This proof is typically a few hundred bytes to a few kilobytes, regardless of the original computation size.

// Simplified proving pipeline
ExecutionTrace = zkEVM.execute(transactions)
// trace: [opcode, stack, memory, storage] per step

Constraints = Circuit.compile(ExecutionTrace)
// constraints: polynomial equations that must hold

Proof = Prover.prove(Constraints, Witness)
// proof: ~300 bytes (SNARK) or ~50-200 KB (STARK)

L1Verifier.verify(Proof, oldStateRoot, newStateRoot)
// constant-time on-chain verification (~200k-300k gas)

Proof System Choices

Different zkEVM implementations use different proof systems, each with distinct tradeoffs:

Many zkEVM projects use a two-layer approach: generate an intermediate proof using a ZK-friendly proof system, then wrap it in a final SNARK (like Groth16) that is cheaper to verify on Ethereum L1. This technique, known as proof recursion or proof composition, reduces on-chain verification costs.

Vitalik's Type Classification

In August 2022, Vitalik Buterin proposed a classification system for zkEVMs that has become the standard framework for comparing implementations. The system ranges from Type 1 (fully Ethereum-equivalent) to Type 4 (high-level language compatible), with each type representing a different point on the compatibility-performance tradeoff curve.

Type 1: Fully Ethereum-Equivalent

Type 1 zkEVMs aim for complete equivalence with Ethereum, including the same state tree structure (Merkle Patricia Trie), the same hash function (Keccak-256), and the same gas schedule. A Type 1 zkEVM can verify actual Ethereum blocks without any modification.

The advantage is total compatibility: existing Ethereum clients, tools, and infrastructure work unchanged. The disadvantage is that Ethereum's design choices (like using Keccak-256 and the Merkle Patricia Trie) are extremely expensive to prove in ZK circuits. Proof generation times for Type 1 systems can take hours per block.

Taiko is the most prominent project pursuing a Type 1 approach, and the Privacy and Scaling Explorations (PSE) team at the Ethereum Foundation has been developing a Type 1 prover.

Type 2: Fully EVM-Equivalent

Type 2 zkEVMs are equivalent at the EVM level but differ in internal data structures. They execute every EVM opcode identically to Ethereum but may use a different state tree (such as a Poseidon-based binary Merkle tree instead of a Keccak-based Merkle Patricia Trie).

This means Solidity contracts run without changes, but tools that depend on Ethereum's specific storage layout or state proof format need adaptation. Proof generation is faster than Type 1 because the prover uses ZK-friendly hash functions and data structures.

Scroll and Polygon zkEVM target Type 2 equivalence, meaning nearly all existing smart contracts and developer tooling work as-is.

Type 2.5: EVM-Equivalent Except Gas Costs

A practical middle ground where the zkEVM implements all EVM opcodes correctly but charges different gas costs for certain operations. Operations that are expensive to prove in ZK (like Keccak-256 hashing) cost more gas, while ZK-friendly operations cost less.

This is significant because some contracts contain gas-sensitive logic (hardcoded gas limits for internal calls, gas estimation assumptions) that breaks when gas costs change. Most contracts are unaffected, but edge cases exist.

Type 3: Almost EVM-Equivalent

Type 3 zkEVMs implement most but not all EVM features. They may omit certain precompiled contracts (like the MODEXP precompile) or handle edge cases differently for opcodes that are prohibitively expensive to prove. Scroll initially operated at Type 3 before progressing toward Type 2.

Contracts using unsupported features need modification, but the majority of Solidity code works without changes. The benefit is significantly faster proof generation compared to Type 2.

Type 4: High-Level Language Compatible

Type 4 systems compile Solidity (or other high-level languages) into a custom VM instruction set optimized for ZK proving, rather than executing actual EVM bytecode. This yields the fastest proof generation but the lowest compatibility.

zkSync Era is the primary example: it compiles Solidity and Vyper through its own LLVM-based compiler into a custom instruction set (EraVM). Contracts must be recompiled, and subtle differences in behavior (such as the CREATE2 address derivation) can cause issues when porting contracts directly.

The advantage is dramatic: proof generation is orders of magnitude faster because the instruction set was designed from the ground up for provability.

Classification Summary

Major zkEVM Implementations

Polygon zkEVM

Polygon zkEVM launched its mainnet beta in March 2023 and targets Type 2 equivalence. It uses a custom prover architecture that breaks EVM execution into multiple sub-circuits (arithmetic, memory, storage, Keccak, etc.), proves each independently, and aggregates them into a single Groth16 proof for L1 verification.

Polygon has since expanded its zkEVM technology into the broader AggLayer vision, where the zkEVM prover serves as a shared proving layer that multiple chains can use to settle to Ethereum. The prover is open-source and written primarily in Rust.

zkSync Era

zkSync Era (by Matter Labs) launched on mainnet in March 2023 and operates as a Type 4 zkEVM. Rather than emulating EVM bytecode directly, it compiles Solidity and Vyper through an LLVM-based toolchain into its custom EraVM instruction set.

This approach enables fast proof generation and supports features not found on Ethereum L1, including native account abstraction where every account is a smart contract by default. However, contracts must be compiled with zkSync's custom compiler, and some low-level EVM behaviors differ.

Scroll

Scroll launched its mainnet in October 2023 and targets Type 2 equivalence. Built in collaboration with the Ethereum Foundation's PSE group, Scroll uses a Halo2-based proving system that does not require a trusted setup. Its circuit design closely mirrors the EVM specification, prioritizing bytecode-level compatibility over proving speed.

Scroll's architecture uses a decentralized prover network where anyone can generate proofs for batches, moving away from the centralized sequencer and prover model common in early rollup designs.

Taiko

Taiko pursues Type 1 equivalence: the most ambitious compatibility target. Its goal is to prove actual Ethereum blocks without any modifications, using Ethereum's exact state tree, hash functions, and gas schedule. This approach is called a "based rollup" because Taiko also relies on Ethereum L1 validators for transaction sequencing rather than running its own centralized sequencer.

The tradeoff is proving cost. Type 1 proving requires circuits for Keccak-256 and the Merkle Patricia Trie, which are among the most expensive operations to represent in ZK. Taiko uses a multi-prover architecture where different proof systems can compete to generate the cheapest valid proof for each block.

Use Cases

zkEVMs enable several categories of applications that benefit from both Ethereum compatibility and ZK-rollup scaling:

• Scalable DeFi: decentralized exchanges, lending protocols, and other DeFi applications can deploy on a zkEVM with higher throughput and lower fees while inheriting Ethereum's security through validity proofs
• Enterprise adoption: organizations already building on the EVM can move to a zkEVM without retraining developers or rewriting code, lowering the barrier to blockchain scaling
• Cross-rollup composability: as zkEVM rollups mature, shared proving layers (like Polygon's AggLayer) enable atomic transactions across multiple ZK-rollup chains
• Privacy applications: while current zkEVMs focus on scaling (using ZK proofs for computation integrity, not privacy), future implementations could add transaction-level privacy by proving execution without revealing inputs
• Reduced verification costs: with EIP-4844 reducing data availability costs and proof compression reducing verification costs, zkEVM rollups become increasingly economical for users

zkEVM vs. Optimistic Rollups

zkEVMs and optimistic rollups represent two fundamentally different approaches to Ethereum scaling. The core distinction lies in how they guarantee correctness:

The 7-day withdrawal delay in optimistic rollups is a major UX disadvantage that zkEVMs eliminate. Once a validity proof is verified on-chain, the state transition is final: no challenge period needed. This difference matters especially for bridging assets between L1 and L2, where faster settlement improves capital efficiency. For a deeper comparison, see the rollup scaling tradeoffs research article.

Why It Matters

zkEVMs represent one of the most significant advances in blockchain scaling because they solve two problems simultaneously: they inherit Ethereum's security model (every state transition is cryptographically proven) while preserving the developer ecosystem that makes Ethereum the most widely used smart contract platform.

For the broader Layer 2 landscape, zkEVM development has pushed forward the state of the art in ZK proof systems, producing faster provers, smaller proofs, and more efficient verification. These advances benefit not just Ethereum but all blockchain ecosystems exploring ZK-based scaling, including Bitcoin Layer 2 solutions. Research into zero-knowledge proofs for Bitcoin draws heavily on breakthroughs made in the zkEVM space.

The lessons from Ethereum L2 scaling are instructive for anyone evaluating rollup architectures across chains. As proving costs decrease and data availability solutions like blob transactions reduce on-chain data costs, zkEVM rollups are becoming increasingly viable as the default execution layer for high-throughput applications.

Risks and Considerations

Proving Costs and Centralization

Generating ZK proofs for EVM execution is computationally intensive. Most zkEVM provers require high-end hardware (multi-core CPUs with hundreds of gigabytes of RAM, or GPU accelerators) to generate proofs within reasonable timeframes. This creates centralization pressure: only a small number of well-resourced operators can act as provers.

Projects like Scroll are working toward decentralized prover networks, but the economic viability of distributed proving at scale remains an open question.

Circuit Bugs and Security

A zkEVM circuit is a complex piece of cryptographic engineering. A bug in the circuit could allow a malicious prover to generate a valid-looking proof for an invalid state transition: the worst-case scenario for a ZK-rollup, because the L1 verifier would accept a fraudulent proof.

Formal verification of zkEVM circuits is an active research area, and most projects run extensive audit programs, bug bounties, and testnet deployments. Several zkEVMs initially launched with training wheels: security councils that could override the proof system in case of a critical bug.

Compatibility Gaps

No zkEVM below Type 1 is a perfect drop-in replacement for Ethereum. Developers should test contracts thoroughly before deploying, paying attention to:

• Differences in gas costs that may cause out-of-gas reverts in gas-sensitive code
• Missing or differently implemented precompiled contracts
• Subtle behavioral differences in opcodes like SELFDESTRUCT, BLOCKHASH, or DIFFICULTY
• Type 4 systems requiring recompilation and potentially different ABI behavior

Maturity and Track Record

zkEVM technology is still relatively new. All major implementations launched their mainnets in 2023, and the proving systems they rely on are under active development. While the mathematical foundations of ZK proofs are well-established, the specific circuit implementations for EVM equivalence are large, complex codebases where undiscovered bugs may exist.

Users should evaluate the security posture of each zkEVM: whether it has undergone multiple audits, whether it retains upgrade keys or security councils, and what the escape hatch mechanism is if the proving system fails.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.