A zkEVM (Zero-Knowledge Ethereum Virtual Machine) is a virtual machine that executes smart contracts compatibly with the Ethereum Virtual Machine (EVM) and produces cryptographic proofs of these executions using zero-knowledge technology. It is designed as a scaling solution for Ethereum, aiming to increase transaction throughput and reduce costs while maintaining a high degree of security by leveraging the main Ethereum network. By bundling numerous transactions, executing them off-chain, and then posting a compact validity proof to the main blockchain, zkEVMs allow for the verification of computations without requiring every network node to re-execute them. ^{[1] [2]}​

Overview

The primary motivation behind zkEVM development is to address the scalability bottleneck of the Ethereum network. In Ethereum's standard model, every validator node must re-execute every transaction within a block to verify its validity, a process referred to as "N-of-N execution." This redundant computation limits the network's capacity and is a contributing factor to high gas fees during periods of high demand. ^[3]​

zkEVMs propose a "1-of-N" model, where a single specialized entity, known as a "prover," executes a block of transactions and generates a succinct cryptographic proof (a ZK-proof) confirming the correctness of the execution. Network validators then only need to verify this computationally inexpensive proof instead of re-running the entire block. This paradigm shift dramatically reduces the computational load on the network, enabling higher throughput and more affordable fees. ^[4]​

While earlier ZK-Rollups provided scalability benefits, they often did so at the cost of EVM compatibility, limiting their use to specific applications and requiring developers to learn new languages or tooling. zkEVMs are a significant evolution because they aim to be compatible or equivalent with the EVM, allowing developers to deploy existing Ethereum smart contracts and decentralized applications (dApps) onto a more scalable layer with minimal to no code modifications. This approach allows projects to tap into Ethereum's extensive ecosystem of developers, tools, and infrastructure. ^{[1] [5]}​

The technology is applied in two primary contexts: as Layer 2 rollups that operate on top of Ethereum, and in a more ambitious proposal to integrate a zkEVM directly into Ethereum's Layer 1 protocol to scale the mainnet itself. ^[6]​

How zkEVMs Work

A zkEVM architecture fundamentally consists of three core components that facilitate off-chain computation with on-chain verification. ^[2]​

Core Components

• Execution Environment: This component replicates the Ethereum Virtual Machine, providing a space where smart contracts written in languages like Solidity can be executed. It takes the current blockchain state, processes a batch of transactions provided by users, and computes a new, updated state. Its compatibility with the EVM is what allows for the seamless porting of existing dApps. ^[2]
• Proving Circuit: This is the cryptographic engine of the zkEVM. It observes the transaction executions and generates a zero-knowledge proof, typically a zk-SNARK or zk-STARK. This proof cryptographically attests that the state transition—from the initial state to the new state—was valid and that all computations were performed correctly according to the EVM's rules. The proof is generated without revealing the underlying transaction data itself. ^{[5] [2]}
• Verifier Contract: This is a smart contract deployed on the underlying Layer 1 blockchain (e.g., Ethereum). The zkEVM rollup submits the generated validity proof and the updated state data to this contract. The verifier contract's sole function is to check the cryptographic proof. If the proof is valid, the new state is accepted and finalized on the Layer 1 chain. This verification process is highly efficient and avoids the need for every Layer 1 node to re-execute the transactions. ^[2]

The Proving Process

In a zkEVM system, the prover executes the block "statelessly," meaning it does not need to maintain a full copy of the entire blockchain state. Instead, the necessary state data for the transactions being processed is supplied as an input, often called a "witness." This input is accompanied by Merkle proofs that verify its integrity against the known state root of the parent block. ^[4]​

It is important to note that the term "zk" (zero-knowledge) can be a partial misnomer in the context of scaling. While the technology can be used for privacy, zkEVMs primarily leverage the "succinctness" (the proof is small) and "integrity" (the proof is computationally sound) properties of ZK-proof systems like SNARKs. They prove that computations were executed correctly without necessarily hiding the transaction details, as privacy would require additional complexity and prover costs. ^[6]​

Types of zkEVMs

​Ethereum co-founder Vitalik Buterin proposed a classification system for zkEVMs, categorizing them into types based on their level of compatibility with Ethereum. This system highlights a fundamental trade-off: higher compatibility (lower-numbered types) makes it easier to use existing infrastructure but is slower and more expensive to prove, while lower compatibility (higher-numbered types) achieves faster proving times at the cost of breaking from Ethereum standards. ^[2]​

Type 1 (Fully Ethereum-equivalent)

Type 1 zkEVMs aim to be fully and uncompromisingly equivalent to Ethereum. They make no changes to the Ethereum system, including hash functions (like Keccak), state trees, or other consensus logic.

• Advantages: Perfect compatibility with all Ethereum dApps and infrastructure. Tools like block explorers and execution clients can be reused without modification.
• Disadvantages: Proof generation is extremely slow because certain parts of the Ethereum protocol are not ZK-friendly.
• Examples: This is the stated goal of the Ethereum Foundation's zkEVM project for Layer 1 integration. ^{[2] [3]}

Type 2 (Fully EVM-equivalent)

Type 2 zkEVMs are fully equivalent from a developer's perspective but make minor modifications to the underlying Ethereum architecture, such as using a different state tree structure, to accelerate proof generation.

• Advantages: Compatible with most existing applications, offering faster proving times than Type 1.
• Disadvantages: Proving time can still be a bottleneck for some use cases.
• Examples: Polygon zkEVM and Scroll are projects that aim for this level of equivalence. ^{[5] [2]}

Type 2.5 (EVM-Equivalent Except for Gas Costs)

This is a variation of Type 2 that increases the gas costs for specific operations that are particularly hard to prove within a ZK circuit. This modification improves worst-case proving times but can break developer tooling and smart contracts that depend on precise gas cost calculations. ^[2]​

Type 3 (Almost EVM-equivalent)

Type 3 zkEVMs sacrifice perfect EVM compatibility to further simplify development and improve prover performance. They may omit features that are particularly difficult to implement in ZK circuits, such as certain precompiled contracts.

• Advantages: Easier to build and offers faster proof generation than Type 2.
• Disadvantages: Some applications may require code modifications to be deployed. The current implementations of Polygon zkEVM and Scroll are often considered closer to this type. ^[2]

Type 4 (High-Level-Language Equivalent)

Type 4 systems do not aim for direct compatibility at the EVM bytecode level. Instead, they compile smart contract source code written in a high-level language like Solidity or Vyper directly into a ZK-friendly language or instruction set.

• Advantages: Can lead to significantly faster proof generation times.
• Disadvantages: Incompatibility at the bytecode level can cause issues with debugging tools, contract addresses, and applications that use handwritten EVM bytecode.
• Examples: zkSync Era is a prominent example of a Type 4 zkEVM. ^{[5] [2]}

Advantages and Challenges

Advantages

• Secure Scalability: zkEVMs execute transactions off-chain for speed but settle them on a Layer 1 by submitting validity proofs. This allows them to inherit the security and decentralization of the parent chain while operating with higher throughput, potentially increasing transaction capacity from around 30 transactions per second (TPS) on Ethereum to over 2,000 TPS. ^{[2] [1]}
• Low Cost: By batching thousands of transactions and amortizing the cost of a single on-chain proof across them, zkEVMs can substantially lower gas fees. Costs can be reduced from nearly a dollar to less than a cent per transaction. ^{[7] [1]}
• Fast Finality: Transactions on a zkEVM are considered final as soon as the validity proof is accepted by the verifier contract on Layer 1. This avoids the one-to-two-week challenge period required by Optimistic Rollups, improving capital efficiency and user experience, especially for withdrawals. ^[2]
• Developer Experience: EVM compatibility or equivalence is a major benefit, allowing developers to migrate existing dApps and leverage the established Ethereum developer ecosystem and tools with few changes. This taps into large network effects and reduces the learning curve for builders. ^[7]

Development Challenges

• Proving Cost and Complexity: The generation of zero-knowledge proofs is a computationally intensive process that often requires specialized, powerful hardware, which can be a bottleneck and a cost center. ^[5]
• Architectural Mismatch: The EVM was not designed with ZK-proofs in mind. Its stack-based architecture, complex opcodes (e.g., CALL), and use of ZK-unfriendly hashing functions like Keccak present significant technical challenges and expense when creating proofs for their execution. ^[2]
• Compatibility vs. Performance Trade-off: As detailed in the zkEVM types, there is an inherent tension between achieving full Ethereum compatibility and designing a system that can generate proofs efficiently. ^[5]
• Decentralization Concerns: The reliance on expensive, specialized hardware for proof generation raises concerns about potential centralization, as only a few well-resourced entities might be able to participate as provers or sequencers. ^[5]

Security Considerations

Integrating zkEVMs into the Ethereum ecosystem, whether at Layer 2 or Layer 1, introduces new security considerations and potential attack vectors. Research from the Ethereum Foundation has identified numerous areas of concern. ^[6]​

System Diversity

A primary concern is the risk of a single point of failure. If the ecosystem becomes reliant on only one or two Execution Layer (EL) clients for proving, or on a single underlying zkVM implementation, a bug in that dominant software could halt or compromise the entire network. A proposed mitigation is a "multiproofs strategy," where a block is only considered valid after receiving proofs from multiple, diverse zkEVM systems. ^[6]​

Guest Program and Compilation

Significant risk lies in the process of making an EL client "provable." EL clients are designed for complex CPUs with features like caches and system calls, which are absent in the constrained environment of a zkVM. The mismatch between these environments is a high-level concern. Furthermore, bugs can be introduced when modifying clients, and the compilers for niche Instruction Set Architectures (ISAs) like RV32IM used by zkVMs are less battle-tested than mainstream compilers. Custom "zkVM precompiles," which are used to speed up ZK-unfriendly operations like Keccak hashing, also add complexity and introduce their own attack surface. ^[6]​

Prover and Circuit Correctness

The most critical components of a zkEVM are the arithmetic circuits that define the VM's rules and the underlying cryptographic protocol. A bug in either could be catastrophic, potentially allowing a malicious prover to create a valid-looking proof for an invalid state transition, which could lead to theft of funds. Such flaws could originate from the source research paper, ambiguities in specifications, or errors during implementation. Other implementation risks include incorrect "witness" generation, transpilation bugs between program formats, or unsafe "optimizations" that deviate from a protocol's proven security guarantees. ^[6]​

Mitigation Strategies

To address these risks, the ecosystem relies on several strategies, including formal verification (using mathematics to prove the correctness of code), extensive testing against standardized test suites (like the Ethereum Execution Spec Tests), independent security audits, bug bounties to incentivize white-hat hacking, and architectural designs like the multiproofs strategy. ^[6]​

Formal Verification Initiatives

To bolster security, the Ethereum Foundation has initiated the zkEVM Formal Verification Project, an ecosystem-wide effort to apply formal verification methods to the entire zkEVM stack with the goal of creating "bug-free zkEVMs." The project, which is expected to run through the end of 2026, aims to develop tools, standards, and processes to ensure the correctness and security of zkEVMs. ^[8]​

The initiative is structured into three main focus areas, or "Tracks": ^[8]​

• RISC-V zkVM Track: Focuses on verifying that the polynomial constraints of RISC-V based zkVMs correctly implement the official RISC-V instruction semantics.
• EVM Track: Aims to prove that an EVM implementation running on a RISC-V architecture is a correct implementation of the official EVM specification.
• Cryptography Track: Verifies the specifications, security proofs, and implementations of the underlying cryptographic proof systems and primitives.

The project operates through a grants program that funds various teams to tackle these challenges. Supported work includes the development of ArkLib, a library of formalized cryptographic proofs in the Lean proof assistant; cLean, a Domain-Specific Language (DSL) for writing circuits in Lean; and LLZK, a unified intermediate representation for zero-knowledge languages. These efforts highlight a community-driven, open, and methodologically diverse approach to securing the next generation of Ethereum scaling solutions. ^[8]​

History and Notable Projects

While early zk-Rollups like dYdX and Loopring demonstrated the power of ZK technology for scaling, they lacked general EVM compatibility. The development of zkEVMs represented a major push to combine ZK proofs with the EVM's programmability. ^[1]​

Early Development and Mainnet Launches

The first public zkEVM mainnets went live in March 2023, marking a significant milestone for Ethereum scaling.

• zkSync Era: Developed by Matter Labs, zkSync Era launched its public mainnet on March 24, 2023. As a Type 4 zkEVM, it compiles Solidity and Vyper code into a ZK-friendly format for faster proving times. ^{[1] [5]}
• Polygon zkEVM: Polygon launched its zkEVM Mainnet Beta on March 27, 2023. Noted for being open-source, its first transaction was sent by Ethereum co-founder Vitalik Buterin. It is generally classified as a Type 2 or Type 3 zkEVM. Both the zkSync and Polygon teams acknowledged the early-stage nature of the technology at launch. ^[1]

Evolution of Polygon zkEVM

Throughout 2024, the Polygon zkEVM Mainnet Beta received several upgrades, including the "Etrog," "Elderberry," and "Eggfruit" updates, which introduced features such as the cdk-erigon sequencer. However, in a strategic shift, Polygon Labs announced in January 2026 the plan to deprecate the Polygon zkEVM Mainnet Beta. The technology and learnings from the project are being integrated into other ecosystem products, such as the Polygon Chain Development Kit (CDK), which allows developers to launch their own ZK-powered chains. ^[7]​

Other Projects

• Scroll: A zkEVM project, categorized as Type 2, developed in collaboration with the Ethereum Foundation's Privacy and Scaling Explorations (PSE) group. ^[5]
• Linea: A zkEVM developed by Consensys, one of the leading software companies in the Ethereum ecosystem. ^[1]
• Taiko: Another project developing a zkEVM solution to scale Ethereum. ^[1]

The Ethereum Foundation's L1 Initiative

The Ethereum Foundation is pursuing research into integrating a Type 1 zkEVM directly into Ethereum's base layer. The goal is to achieve "Real-Time Proving" (RTP), which means generating a ZK-proof for a full Ethereum block within the 12-second slot time. This would allow the entire network to benefit from ZK scaling without users needing to migrate to a separate Layer 2. The project's guiding principle is "full, uncompromising EVM-equivalence." ^[3]​

"Our goal is full, uncompromising EVM-equivalence." ^[3]

As of early 2026, this initiative involves ongoing benchmarking of zkVM implementations like OpenVM and RISC0, as well as work to prepare Ethereum clients like Reth and Geth for potential integration with proof-based validation. ^[3]​