In-depth analysis of zkEVM: how it works, how difficult it is to build, why it matters, and how it is developing.

Original title: "zkEVM Knowledge Q&A --Alchemy"
Original source: Alchemy
 
The zero-knowledge Ethereum Virtual Machine (zkEVM) is a virtual machine that generates zero-knowledge proofs to verify the correctness of programs. ZkEVM is designed to execute smart contracts in a way that supports zero-knowledge technology.
ZkEVM is part of zero-knowledge (ZK) rollups, an Ethereum layer 2 scaling solution that increases throughput by moving computation and state storage off-chain. ZK-rollups submit transaction data to Ethereum along with zero-knowledge proofs verifying the validity of transaction batches off-chain.
Early ZK-rollups lacked the ability to execute smart contracts and were limited to simple token swaps and payments. However, with the introduction of EVM-compatible zero-knowledge virtual machines, ZK-rollups began to support Ethereum dApps.
In this article, we’ll explore how zkEVM works, why it’s important, and what types of zkEVMs exist.
 
What is zkEVM?
 
zkEVM is an EVM-compatible virtual machine that supports zero-knowledge proof computations. Unlike regular virtual machines, zkEVM proves the correctness of program execution, including the validity of inputs and outputs used in operations.
We'll break this definition down further to make it easier to understand:
EVM compatibility
EVM (Ethereum Virtual Machine) is the runtime environment for executing smart contracts deployed on the Ethereum network. EVM acts as the “world computer” that powers decentralized applications (dApps) running on the Ethereum blockchain.
A virtual machine is "EVM-compatible" if it can run programs created to run in the EVM environment. Such a virtual machine can execute smart contracts written in Solidity or other high-level languages ​​used in Ethereum development. ZkEVMs are compatible with the EVM because they can execute Ethereum smart contracts without requiring significant modifications to the underlying logic.
Support zero-knowledge technology
The EVM was never designed to support zero-knowledge proofs, which made it difficult to build EVM-compatible, zero-knowledge-friendly virtual machines. However, research advances have made it possible to wrap EVM computations in zero-knowledge proofs to some extent.
Different zkEVM projects take different approaches to combining EVM execution with zero-knowledge proof computations. Each approach has unique trade-offs, which we will explore later in this guide.
 
How does zkEVM work?
 
Like the EVM, the zkEVM is a virtual machine that transitions between states via program actions. But the zkEVM goes a step further by generating proofs to prove the correctness of each part of the computation. Essentially, the zkEVM uses a mechanism to prove that executing the steps (as described previously) follows the rules.
To understand how the zkEVM works (and why it’s different), let’s review how the EVM currently works.
How EVM works
The Ethereum Virtual Machine is a state machine that moves from an old state to a new state in response to some input. Each smart contract execution triggers a change in the EVM state (called a "state transition"). Here is a high-level overview of what happens during a smart contract transaction:
1. The contract bytecode (compiled from source code) is loaded from the EVM’s storage and executed by peer-to-peer nodes on the EVM. The nodes use the same transaction inputs, which guarantees that each node reaches the same result (otherwise they cannot reach consensus).
2. EVM opcodes (contained in the bytecode) interact with different parts of the EVM state (memory, storage, and stack). Opcodes perform read and write operations—reading (get) values ​​from state storage and writing (send) new values ​​to the EVM’s storage.
3. The EVM opcode performs a computation on the value obtained from the state store before returning a new value. This update causes the EVM to transition to a new state (hence, the transaction is called a "state transition"). This new state is replicated by other nodes and maintained until another transaction is executed.
Diagram showing how programs are executed in the Ethereum Virtual Machine (EVM). [Source]
 
How zkEVM works
 
The zkEVM generates zero-knowledge proofs to verify various elements of each computation:
1. Bytecode access: Is the appropriate program code correctly loaded from the correct address?
2. Read and Write Operations: Does the program get the correct values ​​from the stack/memory/storage before calculation? b. Does the program write the correct output values ​​to the stack/memory/storage after it completes execution?
3. Computation: Are the opcodes executed correctly (i.e. one after another, without skipping steps)?
zkEVM Architecture
The zkEVM is divided into three parts: the execution environment, the proof circuit, and the verifier contract. Each component contributes to program execution, proof generation, and proof verification in the zkEVM.
1. Execution Environment
As the name implies, the execution environment is where programs (smart contracts) are run in the zkEVM. The zkEVM’s execution environment functions very similarly to the EVM: it takes an initial state and the current transaction to output a new (final) state.
2. Verify the circuit
The proving circuit generates a zero-knowledge proof to verify the validity of the transaction computed in the execution environment. The proof generation process is done using the previous state, transaction input, and post-state information as input. Afterwards, the prover obtains a succinct proof of the validity of that particular state transition.
Diagram showing how the zkEVM generates validity proofs for programs. [Source]
3. Validator Contract
ZK-rollups submit validity proofs to a smart contract deployed on the L1 chain (Ethereum) for verification. The inputs (pre-state and transaction information) and outputs (final state) are also submitted to the verifier contract. The verifier then runs the computation on the provided proofs and confirms that the submitted outputs are correctly calculated based on the inputs.
 
What are zkEVM opcodes?
 
ZkEVM opcodes are low-level machine instructions used to execute programs in a ZK-rollup that is compatible with the EVM. As with the EVM, contracts written in a high-level language must be compiled into a low-level language (bytecode) that the VM can interpret. This bytecode specifies the opcodes used to execute the program when it is deployed in the VM.
We need zkEVM opcodes because regular EVM opcodes are inefficient to use in zero-knowledge proof circuits. There are generally two ways to create opcodes for zkEVM:
Building ZK circuits for native EVM opcodes
Creating a new language for ZK proof computation
Building zero-knowledge circuits for native EVM opcodes
This approach requires implementing the entire EVM instruction set in arithmetic circuits - a complex and time-consuming task. The benefit is that developers can use existing blockchain development tools to create smart contracts, or port existing Ethereum contracts to ZK-rollups without extensive modifications.
 
Creating a new language for ZK proof computation
 
This approach requires building a new language — designed to support validity proofs — and developing custom opcodes. Developers will need to either write contracts directly in the new language or compile Solidity source code into custom zkEVM opcodes.
While this approach is generally easier to implement than the first, it also has disadvantages. For example, developers may not have access to existing Ethereum infrastructure and resources.
Zero-knowledge virtual machines classified by EVM compatibility. [Source]
 
What makes building a zkEVM difficult?
 
Because the EVM was not built with zk-proof computations in mind, it has properties that are not friendly to proof circuits. Here is a quick overview of four things that make building a zkEVM difficult:
Special opcodes
Stack-based architecture
Storage overhead
Proof of cost
1. Special opcodes
Unlike a regular VM, the EVM uses special opcodes for program execution (CALL, DELEGATECALL) and error handling (REVERT, INVALID), among other operations. This increases the complexity of the process of designing verification circuits for EVM operations.
2. Stack-based architecture
The EVM uses a stack-based architecture, which, while simpler than a register-based structure, increases the difficulty of computational proofs. This is why famous zero-knowledge VMs such as ZkSync’s zkEVM and StarkWare’s StarkNet use a register-based model.
3. Storage overhead
The EVM’s storage layout relies on the Keccak hash function and the Merkle Patricia Trie, both of which have high proof overhead. Some zkVMs, such as ZkSync, attempt to sidestep this problem by replacing the KECCAK256 function — but this could break compatibility with existing Ethereum tooling and infrastructure.
4. Prove the cost
Even if the above issues are solved, there is still the proof generation process to deal with. Generating zero-knowledge proofs requires specialized hardware and a significant investment of time, money, and effort.
While not exhaustive, this list presents some of the issues that have hindered building a zkEVM that is compatible with the EVM. Nonetheless, several breakthroughs in zero-knowledge technology have made it possible to mitigate these issues — leading to a renewed interest in zkEVM solutions.
 
Why is zkEVM important?
 
Building a fully functional zkEVM will encourage the development of EVM-compatible ZK-rollup projects. This has several advantages:
Secure scalability
Lower costs
Faster finality and capital efficiency
Network Effects
1. Secure scalability
According to the protocol rules, all validating nodes must re-execute all computations performed in the Ethereum Virtual Machine. This approach ensures security, as Ethereum nodes can independently verify the correctness of the program, but it limits the scalability of the Ethereum network to only manage about 15-20 transactions).
EVM-compatible ZK-rollups could solve Ethereum’s throughput problem without undermining network security. Like other scaling protocols, ZK-rollups are not burdened by the rules of the Ethereum consensus protocol and can be optimized for execution speed. Some estimates suggest that ZK-rollups could process around 2,000 transactions per second without incurring Ethereum’s high fees.
However, ZK-rollups have higher security guarantees than other scaling projects; they use validity proofs to verify the correctness of off-chain computations. This means that transactions executed by smart contracts on L2 can be reliably verified on L1 (Ethereum) without the need for nodes to re-execute operations. This can significantly increase Ethereum's processing speed without reducing security.
2. Lower costs
Rollups derive their security from Ethereum mainnet by writing transaction data to Ethereum as CALLDATA. However, optimistic rollups and zero-knowledge rollups differ in how much data they must publish on Ethereum.
Because optimistic rollups do not provide proof of validity of transactions off-chain, they require publishing all transaction-related data on-chain (including signatures and transaction parameters). Without putting all data on-chain, challengers cannot construct fraud proofs to dispute invalid rollup transactions.
In contrast, ZK-rollups can publish minimal data to Ethereum because the credibility of state transitions is already guaranteed by validity proofs. The zkEVM can even omit transaction inputs and publish only final state changes, further reducing CALLDATA requirements.
3. Faster certainty and capital efficiency
In addition to better security, ZK-rollups have another advantage over optimistic rollups: faster finality. Finality in a blockchain is the time it takes for a transaction to become irreversible; a transaction is finalized only when network participants have objective evidence of its validity.
With ZK-rollups, transactions executed in the zkEVM are typically finalized almost immediately after being posted to Ethereum. Since each transaction batch comes with an instantly verifiable proof of validity, state updates can be quickly applied by the Ethereum mainchain.
Since optimistic rollups only publish VM transactions without proofs, a challenge period must pass before transactions reach finality. The challenge period is 1-2 weeks, during which anyone can challenge a transaction after it has been submitted to Ethereum.
Slower finality has many implications for user experience. For example, users cannot withdraw assets from the rollup until the delay period expires. Liquidity providers may be able to resolve the issue, but this may not be effective if the withdrawal involves high-value assets or even NFTs.
zkEVM does not have the above issues. Faster finality is ideal for advanced users such as NFT traders, DeFi investors, or arbitrage traders who need to move assets seamlessly (especially between L1 and L2).
4. Network Effects
The most important reason to build an EVM-compatible zkVM is to leverage Ethereum’s network effect. As the world’s largest smart contract platform, Ethereum has a huge ecosystem that provides value to developers and projects.
For example, developers have access to a battle-tested and audited codebase, extensive tooling, documentation, and more. Creating a new zkVM that is incompatible with Ethereum infrastructure would prevent projects and development teams from leveraging Ethereum’s network effects.
 
What types of zkEVM are there?
 
Current zkEVM projects fall into two broad categories: zkVMs that support native EVM opcodes and zkVMs that use custom EVM opcodes. Below we compare different zkEVM protocols and explain how they work:
Polygon zkEVM
Polygon Hermez is a Polygon ZK-rollup with a zero-knowledge virtual machine designed to support EVM compatibility. To do this, EVM bytecode is compiled into “micro-ops” and executed in uVM - a virtual machine that uses SNARK and STARK proofs to verify the correctness of program execution.
The decision to combine the two proof types makes strategic sense. STARK (Scalable Transparent Argument of Knowledge) proofs are faster to generate, but SNARK (Succinct Non-Interactive Argument of Knowledge) proofs are smaller and cheaper to verify on Ethereum.
Polygon Hermez zkEVM uses STARK proof circuits to generate validity proofs of state transitions. STARK proofs verify the correctness of STARK proofs (think of it as generating a “proof of proof”) and are submitted to Ethereum for verification.
zkSync zkEVM
zkSync is an EVM-compatible ZK-rollup developed by Matter Labs and powered by its own zkEVM. ZkSync achieves compatibility with Ethereum using the following strategy:
1. Compile the contract code written in Solidity into Yul, an intermediate language, which can be compiled into bytecode for different virtual machines.
2. Recompile the Yul bytecode (using the LLVM framework) into a custom, circuit-compatible bytecode set designed specifically for zkSync’s zkEVM.
Like Polygon Hermez, zkSync zkEVM implements EVM compatibility at the language level rather than the bytecode level. For example, zkSync’s zkEVM does not support traditional multiplication and addition opcodes (ADDMOD, SMOD, MULMOD).
Scroll zkEVM
Scroll is a new zero-knowledge EVM implementation under development. The Scroll team plans to design zero-knowledge circuits for every EVM opcode. This will allow developers to deploy Ethereum native smart contracts on Scroll without modifying the underlying EVM bytecode.
In addition to this, Scroll zkEVM will use a “cryptographic accumulator” to verify the correctness of the storage. This is used to prove that the contract bytecode was correctly loaded from a given address.
It also provides a circuit to link the bytecode with an execution trace. An execution trace is a sequence that specifies which VM instructions were executed and in what order. The prover will submit the execution trace during proof generation to verify that the computation is consistent with the original bytecode.
Applied ZKP zkEVM
Applied ZKP is a project funded by the Ethereum Foundation to develop EVM-compatible ZK-rollups and a mechanism to generate validity proofs for Ethereum blocks. This last part is crucial because pairing a block with a validity proof will eliminate the need for nodes to re-execute the block.
The innovation of Applied ZKP lies in the separation of computation and storage. It uses two types of validity proofs - state proofs and EVM proofs:
Status Proof
Checks that operations involving storage, memory, and the stack occur correctly. State proofs essentially verify the accuracy of read and write operations.
EVM Proof
Checks that the computation called the exact opcodes at the right time. EVM proofs verify the computation itself and confirm that the state proofs performed the correct operations for each opcode.
AppliedZKP zkEVM uses bus mapping to link state proofs and EVM proofs. Furthermore, both proofs must be verified before an Ethereum block is considered valid.
 
Where are we in the development progress of zkEVM?
 
With the exception of zkSync, most of the zero-knowledge EVM is still a work in progress. However, the continued development of zero-knowledge technology means that the prospect of a fully functional zkEVM is better than ever.