Network
Launch Date
Consensus
Note
Sepolia
Oct 2021
PoW
Like-for-like representation of Ethereum
Görli
Jan 2019
PoA
Proof-of-Authority
Kiln
Mar 2022
PoS
Post-Merge (for ETH2), shadow fork of the mainnet
Kintsugi
Dec 2021
PoS
DEPRECATED, use Kiln; post-Merge (for ETH2)
Ropsten
Nov 2016
PoW
DEPRECATED, use Sepolia; the Merge to happen on Jun 8, 2022
Rinkeby
Apr 2017
PoA
DEPRECATED, use Görli and Görli Faucet
Kovan
Mar 2017
PoA
DEPRECATED, use Sepolia or Görli
List of active and deprecated Ethereum testnets, including Kintsugi.
Features
Optimistic rollup 
ZK-rollup 
Proof
Uses fraud proofs to prove transaction validity. 
Uses validity (zero-knowledge) proofs to prove transaction validity. 
Capital efficiency
Requires waiting through a 1-week delay (dispute period) before withdrawing funds. 
Users can withdraw funds immediately because validity proofs provide incontrovertible evidence of the authenticity of off-chain transactions. 
Data compression
Publishes full transaction data as calldata to Ethereum Mainnet, which increases rollup costs. 
Doesn't need to publish transaction data on Ethereum because ZK-SNARKs and ZK-STARKs already guarantee the accuracy of the rollup state. 
EVM compatibility
Uses a simulation of the Ethereum Virtual Machine (EVM), which allows it to run arbitrary logic and support smart contracts. 
Doesn't widely support EVM computation, although a few EVM-compatible ZK-rollups have appeared. 
Rollup costs
Reduces costs since it publishes minimal data on Ethereum and doesn't have to post proofs for transactions, except in special circumstances. 
Faces higher overhead from costs involved in generating and verifying proofs for every transaction block. ZK proofs require specialized, expensive hardware to create and have high on-chain verification costs. 
Trust assumptions
Doesn't require a trusted setup. 
Requires a trusted setup to work. 
Liveness requirements
Verifiers are needed to keep tabs on the actual rollup state and the one referenced in the state root to detect fraud. 
Users don't need someone to watch the L2 chain to detect fraud. 
Security properties 
Relies on cryptoeconomic incentives to assure users of rollup security. 
Relies on cryptographic guarantees for security. 
Start building
on Alchemy.
Sign up for free
Start building on Optimism.
Sign up for free
Start building on Arbitrum.
Sign up for free
Start building on Ethereum.
Sign up for free
Start building on Polygon.
Sign up for free
Start building on Starknet.
Sign up for free
Start building on Flow.
Sign up for free
kiln faucet
Get free Kiln ETH.
Start building today
Goerli faucet
Get free Goerli ETH.
Start building today
mumbai faucet
Get free Mumbai Matic.
Start building today
rinkeby faucet
Get free Rinkeby
ETH.
Start building today
Start building on Ethereum.
Get started for free
Start building on Ethereum.
Get started for free
Start building on Flow.
Get started for free
Start building on Polygon.
Get started for free
Start building on Starknet.
Get started for free
Start building on Optimism.
Get started for free
Start building on Solana.
Get started for free
Start building on Solana.
Sign up for beta access
Start building on Solana.
Join the waitlist
Arbitrum logo
Start building on Arbitrum.
Get started for free
Learn
Solidity at
Alchemy
University
Get started today
curl 
https://release.solana.com/v1.10.32/solana-install-init-x86_64-pc-windows-msvc.exe 
--output 
C:\solana-install-tmp\solana-install-init.exe 
--create-dirs
Layer 2
ZKEVM OVERVIEW

Zero Knowledge EVMs: What is a zkEVM?

Types of zkEVMs, How They Work, and Why They Matter
Last Updated:
June 21, 2022

A zero-knowledge Ethereum Virtual Machine (zkEVM) is a virtual machine that generates zero-knowledge proofs to verify the correctness of programs. ZkEVMs are designed to execute smart contracts in a manner that supports zero-knowledge technology. 

ZkEVMs are part of zero-knowledge (ZK) rollups, Ethereum layer 2 scaling solutions that improve throughput by transferring computation and state storage off-chain. A ZK-rollup submits transaction data to Ethereum along with zero-knowledge proofs verifying the validity of off-chain transaction batches. 

Early ZK-rollups lacked the ability to execute smart contracts and were constrained to simple token swaps and payments. But, with the introduction of EVM-compatible zero-knowledge virtual machines, ZK-rollups are starting to support Ethereum dApps.

In this article, we explore how a zkEVM works, why it matters, and what types of zkEVM exist. 

What is a zkEVM?

A zkEVM is an EVM-compatible virtual machine that supports zero-knowledge proof computation. Unlike regular virtual machines, a zkEVM proves the correctness of program execution, including the validity of inputs and outputs used in the operation. 

We’ll break down this definition further to make it easier to understand:

EVM compatibility 

The EVM (Ethereum Virtual Machine) is the runtime environment in which smart contracts deployed on the Ethereum network are executed. The EVM functions as a “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 VMs can execute smart contracts written in Solidity or other high-level languages used in Ethereum development. ZkEVMs are EVM-compatible because they can execute Ethereum smart contracts without extensive modifications of the underlying logic

Support for zero-knowledge technology 

The EVM was never designed to support zero-knowledge proofs, which makes building EVM-compatible, zero-knowledge-friendly virtual machines difficult. However, advances in research have made it possible—to some extent—to wrap EVM computation in zero-knowledge proofs.

Different zkEVM projects adopt different approaches to combining EVM execution with zero-knowledge proof computation. Each method has unique tradeoffs, which we explore in a later section of this guide. 

How does a zkEVM work?

Like the EVM, a zkEVM is a virtual machine that transitions between states as a result of program operations. But the zkEVM goes further by producing a proof to attest to the correctness of every part of the computation. Essentially, a zkEVM uses a mechanism to prove that the execution steps (described earlier) followed rules. 

To understand how a zkEVM works (and why it’s different), let's review how the EVM works currently. 

How the EVM works

The Ethereum Virtual Machine is a state machine that moves from an old state to a new state in response to some inputs. Every smart contract execution triggers a change in the EVM’s state (called a “state transition”). Here’s a high-level overview of what happens during a smart contract transaction:

1. Contract bytecode (compiled from the source code) is loaded from the EVM’s storage and executed by peer-to-peer nodes on the EVM. Nodes use the same transaction inputs, which guarantees that each node arrives at the same result (or else they cannot reach consensus). 

2. EVM Opcodes (contained in the bytecode) interact with different parts of the EVM’s state (memory, storage, and stack). Opcodes perform read-write operations—reading (getting) values from state storage and writing (sending) new values to the EVM’s storage. 

3. EVM opcodes perform computation on the values obtained from state storage before returning the new values. This update results in the EVM transitioning to a new state (transactions are called “state transitions” for this reason). This new state is replicated by other nodes and remains until another transaction is executed. 

A diagram showing how programs are executed in the Ethereum Virtual Machine (EVM). [Source]

How the zkEVM works 

The zkEVM generates zero-knowledge proofs to verify various elements in each computation:

1. Bytecode access: Was the appropriate program code loaded correctly, from the right address? 

2. Read-write operations: a. Did the program fetch the right values from stack/memory/storage before the computation? b. Did the program write the correct output values to the stack/memory/storage after completing execution? 

3. Computation: Were the opcodes executed correctly (i.e., one after the other, without skipping steps)? 

The architecture of a zkEVM

The zkEVM is divided into three parts: an execution environment, proving circuit, and verifier contract. Each component contributes to the zkEVM’s program execution, proof generation, and proof verification. 

1. The execution environment 

As the name suggests, the execution environment is where programs (smart contracts) are run in the zkEVM. The zkEVM’s execution environment functions much like the EVM: it takes the initial state and current transaction to output a new (final) state.

2. The proving circuit 

The proving circuit produces zero-knowledge proofs verifying the validity of transactions computed in the execution environment. The proof generation process is completed using the pre-state, transaction inputs, and post-state information as inputs. After that, the prover obtains a succinct proof of the validity of that particular state transition. 

A diagram showing how the zkEVM generates validity proofs for programs. [Source]
3. The verifier contract 

ZK-rollups submit validity proofs to a smart contract deployed on the L1 chain (Ethereum) for verification. The input (pre-states and transaction information) and output (final states) are also submitted to the verifier contract. Then the verifier runs computation on the provided proof and confirms that the submitted outputs were correctly computed from the inputs. 

What are zkEVM opcodes?

ZkEVM opcodes are low-level machine instructions used for executing programs in an EVM-compatible ZK-rollup. As with the EVM, contracts written in high-level languages must be compiled to low-level language the VM can interpret (bytecode). This bytecode specifies the opcodes used in executing the program when it’s deployed in the VM.

We need zkEVM opcodes because regular EVM opcodes are inefficient for use in zero-knowledge proving circuits. There are generally two approaches to creating opcodes for zkEVMs:

  1. Building ZK circuits for native EVM opcodes
  2. Creating new languages for ZK proof computation

Build zero-knowledge circuits for native EVM opcodes 

This approach requires implementing all EVM instruction sets in an arithmetic circuit—a complex and time-intensive task. The benefit is that developers can create smart contracts using existing blockchain developer tooling or port existing Ethereum contracts to ZK-rollups without extensive modifications.  

Create new languages 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 to custom zkEVM opcodes. 

While this method is often simpler to implement than the first approach, it has drawbacks. For instance, developers may be unable to access existing Ethereum infrastructure and resources. 

A classification of zero-knowledge virtual machines according to EVM compatibility. [Source]

What makes building a zkEVM difficult?

Because the EVM wasn’t built with zk-proof computation in mind, it has features that are unfriendly for proving circuits. Here is a brief overview of four things that make building zkEVMs difficult:

  1. Special opcodes
  2. Stack-based architecture
  3. Storage overhead
  4. Proving costs

1. Special opcodes 

Unlike a regular VM, the EVM uses special opcodes for program execution (CALL, DELEGATECALL) and error handling (REVERT, INVALID), amongst other operations. This adds complexity to the process of designing the proving circuit for EVM operations. 

2. Stack-based architecture 

The EVM uses a stack-based architecture which, although simpler than a register-based structure, increases the difficulty of proving computation. This is why prominent 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 Keccak hashing functions and a Merkle Patricia Trie, both of which have a high proving overhead. Some zkVMs, like ZkSync, attempt to sidestep this problem by replacing the KECCAK256 function—but this can break compatibility with existing Ethereum tooling and infrastructure.

4. Proving costs 

Even if the aforementioned problems are solved, there's still the proof-generation process to contend with. Generating zero-knowledge proofs requires specialized hardware along with considerable investment in time, money, and effort. 

Although not exhaustive, this list presents some of the problems that hamper efforts to build EVM-compatible zkEVMs. Nonetheless, several breakthroughs in zero-knowledge technology have made it possible to mitigate those problems—leading to renewed interest in zkEVM solutions. 

Why is a zkEVM important?

Building a fully functional zkEVM will encourage the development of EVM-compatible ZK-rollup projects. This presents several advantages:

  1. Secure scalability
  2. Cheaper costs
  3. Faster finality and capital efficiency
  4. Network effects

1. Secure scalability

Per protocol rules, all validating nodes must re-execute all computations performed in the Ethereum Virtual Machine. This approach ensures security since Ethereum nodes can independently verify the correctness of programs, but it places limits on scalability the Ethereum network can manage just ~ 15-20 transactions).

EVM-compatible ZK-rollups can fix Ethereum’s throughput issues without undermining network security. Like other scaling protocols, ZK-rollups are not burdened by Ethereum’s consensus protocol rules and can optimize for execution speed. Some estimates suggest ZK-rollups can process ~ 2000 transactions per second without incurring Ethereum’s high fees. 

However, ZK-rollups have higher security guarantees compared to other scaling projects; they verify correctness of off-chain computation with validity proofs. It means transactions performed by smart contracts on L2 can be reliably verified on L1 (Ethereum) without nodes having to re-execute the operations. This can significantly increase Ethereum’s processing speed without reducing security. 

2. Cheaper costs

Rollups derive security from Ethereum Mainnet by writing transaction data to Ethereum as CALLDATA. However, optimistic rollups and ZK-rollups differ in how much data they must post on Ethereum. 

Because optimistic rollups don’t provide proof of validity for off-chain transactions, they need to publish all transaction-related data on-chain (including signatures and transaction parameters). Without putting all data on-chain, challengers cannot construct fraud proofs used to dispute invalid rollup transactions. 

Conversely, ZK-rollups can afford to post minimal data to Ethereum because validity proofs already guarantee the trustworthiness of state transitions. The zkEVM may even omit transaction inputs and publish only final state changes, further reducing CALLDATA requirements. 

This is beneficial for developers and users because a large percentage of rollup costs come from posting data on-chain. By reducing CALLDATA to a minimum, ZK-rollups can make it cheaper to use dApps, like decentralized exchanges, NFT marketplaces, prediction markets, and many more. 

3. Faster finality and capital efficiency 

Besides better security, ZK-rollups have another advantage over optimistic rollups: faster finality. Finality in blockchains is the time it takes for a transaction to become irreversible; a transaction can only be finalized if network participants have objective proof of its validity. 

With ZK-rollups, transactions executed in the zkEVM are often finalized immediately after they are posted on Ethereum. Since each transaction batch comes with an instantly verifiable proof of validity, the main Ethereum chain can quickly apply state updates. 

Since optimistic rollups only post VM transactions without proofs, the challenge period must elapse before transactions achieve finality. The challenge period is a 1-2 week period during which anyone can challenge a transaction after it is submitted to Ethereum. 

Slower finality has many implications for the user experience. For example, users cannot withdraw assets from the rollup until the delay period expires. Liquidity providers may solve the problem but may be ineffective if the withdrawal involves high-value assets or even NFTs. 

A zkEVM has none of those problems described above. Faster finality is great for power users, such as NFT traders, DeFi investors, or arbitrage traders who need to move around assets seamlessly (especially between L1 and L2). 

4. Network effects

The most important reason for building EVM-compatible zkVMs is to leverage Ethereum's network effects. As the world's biggest smart contracts platform, Ethereum has a large ecosystem that provides value to both developers and projects. 

For instance, developers can access battle-tested and audited code libraries, extensive tooling, documentation, and so on. Creating a new zkVM that is incompatible with Ethereum's infrastructure would cut off projects and development teams from harnessing Ethereum's network effects. 

What types of zkEVMs exist?

Current zkEVM projects fall into two main categories: zkVMs supporting native EVM opcodes and zkVMs using customized 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 opcodes" and executed in the 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 is strategic. 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. 

The Polygon Hermez zkEVM uses a STARK proving circuit to generate proofs of validity for state transitions. A STARK proof verifies the correctness of STARK proofs (think of it as generating "proof of a proof") and is 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. Compiling contract code written in Solidity to Yul, an intermediate language that can be compiled into bytecode for different virtual machines. 

2. Re-compiling the Yul bytecode (using the LLVM framework) to a custom, circuit-compatible bytecode set specially designed for zkSync's zkEVM. 

Like Polygon Hermez, the zkSync zkEVM achieves EVM compatibility at the language level, not the bytecode level. For example, traditional multiplication and addition opcodes (ADDMOD, SMOD, MULMOD) are not supported by zkSync's zkEVM. 

Scroll zkEVM

Scroll is a new zero-knowledge EVM implementation under development. The Scroll team plans to design zero-knowledge circuits for each EVM opcode. This would allow developers to deploy Ethereum-native smart contracts EVM on Scroll without needing to modify the underlying EVM bytecode. 

Among other things, the Scroll zkEVM will use a "cryptographic accumulator" to verify the correctness of storage. This is used to prove that the contract bytecode was loaded correctly from the given address. 

It also provides a circuit for linking the bytecode with the execution trace. The execution trace is a sequence specifying what VM instructions were executed and in what order. Provers will submit the execution trace during proof generation to verify that the computation was consistent with the original bytecode. 

AppliedZKP zkEVM

Applied ZKP is a project funded by the Ethereum Foundation to develop an EVM-compatible ZK-rollup and a mechanism for generating validity proofs for Ethereum blocks. The last part is critical because pairing blocks with validity proofs would remove the need for nodes to re-execute blocks. 

Applied ZKP's innovation is the separation of computation from storage. It uses two types of validity proofs—state proofs and EVM proofs: 

State proofs‍

Checks that operations touching storage, memory, and stack happened correctly. State proofs essentially verify the accuracy of read-write operations. 

EVM proofs

Checks that the computation called the accurate opcode at the right time. The EVM proofs verify the computation itself and also confirms that the state proof executed the right operation for each opcode. 

The AppliedZKP zkEVM uses a bus mapping to link the state proof and EVM proof. Also, both proofs must be verified before the Ethereum block is deemed valid.

Where are we in the development progress of zkEVMs?

Except for zkSync, most zero-knowledge EVMs are still under production. Nevertheless, growing development in zero-knowledge technology means the prospect of a fully functional zkEVMs is better than ever. 

In the meantime developers can leverage the benefits of  zero-knowledge applications with the StarkNet zero-knowledge VM. StarkNet is not EVM-compatible, but can compile Solidity source code to custom ZK-friendly bytecode. You can also choose to write contracts in Cairo (StarkNet's language). 

Sign up with Alchemy for free to start building on StarkNet today.

ALCHEMY SUPERNODE - ETHEREUM NODE API

Scale to any size, without any errors

Alchemy Supernode finally makes it possible to scale blockchain applications without all the headaches. Plus, our legendary support will guide you every step of the way.

Get started for free
Supernode footer
Layer 2
ZKEVM OVERVIEW

What is a zkEVM?

Types of zkEVMs, How They Work, and Why They Matter
Last Updated:
June 21, 2022
Don't miss an update
Sign up for our newsletter to get alpha, key insights, and killer resources.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

A zero-knowledge Ethereum Virtual Machine (zkEVM) is a virtual machine that generates zero-knowledge proofs to verify the correctness of programs. ZkEVMs are designed to execute smart contracts in a manner that supports zero-knowledge technology. 

ZkEVMs are part of zero-knowledge (ZK) rollups, Ethereum layer 2 scaling solutions that improve throughput by transferring computation and state storage off-chain. A ZK-rollup submits transaction data to Ethereum along with zero-knowledge proofs verifying the validity of off-chain transaction batches. 

Early ZK-rollups lacked the ability to execute smart contracts and were constrained to simple token swaps and payments. But, with the introduction of EVM-compatible zero-knowledge virtual machines, ZK-rollups are starting to support Ethereum dApps.

In this article, we explore how a zkEVM works, why it matters, and what types of zkEVM exist. 

What is a zkEVM?

A zkEVM is an EVM-compatible virtual machine that supports zero-knowledge proof computation. Unlike regular virtual machines, a zkEVM proves the correctness of program execution, including the validity of inputs and outputs used in the operation. 

We’ll break down this definition further to make it easier to understand:

EVM compatibility 

The EVM (Ethereum Virtual Machine) is the runtime environment in which smart contracts deployed on the Ethereum network are executed. The EVM functions as a “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 VMs can execute smart contracts written in Solidity or other high-level languages used in Ethereum development. ZkEVMs are EVM-compatible because they can execute Ethereum smart contracts without extensive modifications of the underlying logic

Support for zero-knowledge technology 

The EVM was never designed to support zero-knowledge proofs, which makes building EVM-compatible, zero-knowledge-friendly virtual machines difficult. However, advances in research have made it possible—to some extent—to wrap EVM computation in zero-knowledge proofs.

Different zkEVM projects adopt different approaches to combining EVM execution with zero-knowledge proof computation. Each method has unique tradeoffs, which we explore in a later section of this guide. 

How does a zkEVM work?

Like the EVM, a zkEVM is a virtual machine that transitions between states as a result of program operations. But the zkEVM goes further by producing a proof to attest to the correctness of every part of the computation. Essentially, a zkEVM uses a mechanism to prove that the execution steps (described earlier) followed rules. 

To understand how a zkEVM works (and why it’s different), let's review how the EVM works currently. 

How the EVM works

The Ethereum Virtual Machine is a state machine that moves from an old state to a new state in response to some inputs. Every smart contract execution triggers a change in the EVM’s state (called a “state transition”). Here’s a high-level overview of what happens during a smart contract transaction:

1. Contract bytecode (compiled from the source code) is loaded from the EVM’s storage and executed by peer-to-peer nodes on the EVM. Nodes use the same transaction inputs, which guarantees that each node arrives at the same result (or else they cannot reach consensus). 

2. EVM Opcodes (contained in the bytecode) interact with different parts of the EVM’s state (memory, storage, and stack). Opcodes perform read-write operations—reading (getting) values from state storage and writing (sending) new values to the EVM’s storage. 

3. EVM opcodes perform computation on the values obtained from state storage before returning the new values. This update results in the EVM transitioning to a new state (transactions are called “state transitions” for this reason). This new state is replicated by other nodes and remains until another transaction is executed. 

A diagram showing how programs are executed in the Ethereum Virtual Machine (EVM). [Source]

How the zkEVM works 

The zkEVM generates zero-knowledge proofs to verify various elements in each computation:

1. Bytecode access: Was the appropriate program code loaded correctly, from the right address? 

2. Read-write operations: a. Did the program fetch the right values from stack/memory/storage before the computation? b. Did the program write the correct output values to the stack/memory/storage after completing execution? 

3. Computation: Were the opcodes executed correctly (i.e., one after the other, without skipping steps)? 

The architecture of a zkEVM

The zkEVM is divided into three parts: an execution environment, proving circuit, and verifier contract. Each component contributes to the zkEVM’s program execution, proof generation, and proof verification. 

1. The execution environment 

As the name suggests, the execution environment is where programs (smart contracts) are run in the zkEVM. The zkEVM’s execution environment functions much like the EVM: it takes the initial state and current transaction to output a new (final) state.

2. The proving circuit 

The proving circuit produces zero-knowledge proofs verifying the validity of transactions computed in the execution environment. The proof generation process is completed using the pre-state, transaction inputs, and post-state information as inputs. After that, the prover obtains a succinct proof of the validity of that particular state transition. 

A diagram showing how the zkEVM generates validity proofs for programs. [Source]
3. The verifier contract 

ZK-rollups submit validity proofs to a smart contract deployed on the L1 chain (Ethereum) for verification. The input (pre-states and transaction information) and output (final states) are also submitted to the verifier contract. Then the verifier runs computation on the provided proof and confirms that the submitted outputs were correctly computed from the inputs. 

What are zkEVM opcodes?

ZkEVM opcodes are low-level machine instructions used for executing programs in an EVM-compatible ZK-rollup. As with the EVM, contracts written in high-level languages must be compiled to low-level language the VM can interpret (bytecode). This bytecode specifies the opcodes used in executing the program when it’s deployed in the VM.

We need zkEVM opcodes because regular EVM opcodes are inefficient for use in zero-knowledge proving circuits. There are generally two approaches to creating opcodes for zkEVMs:

  1. Building ZK circuits for native EVM opcodes
  2. Creating new languages for ZK proof computation

Build zero-knowledge circuits for native EVM opcodes 

This approach requires implementing all EVM instruction sets in an arithmetic circuit—a complex and time-intensive task. The benefit is that developers can create smart contracts using existing blockchain developer tooling or port existing Ethereum contracts to ZK-rollups without extensive modifications.  

Create new languages 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 to custom zkEVM opcodes. 

While this method is often simpler to implement than the first approach, it has drawbacks. For instance, developers may be unable to access existing Ethereum infrastructure and resources. 

A classification of zero-knowledge virtual machines according to EVM compatibility. [Source]

What makes building a zkEVM difficult?

Because the EVM wasn’t built with zk-proof computation in mind, it has features that are unfriendly for proving circuits. Here is a brief overview of four things that make building zkEVMs difficult:

  1. Special opcodes
  2. Stack-based architecture
  3. Storage overhead
  4. Proving costs

1. Special opcodes 

Unlike a regular VM, the EVM uses special opcodes for program execution (CALL, DELEGATECALL) and error handling (REVERT, INVALID), amongst other operations. This adds complexity to the process of designing the proving circuit for EVM operations. 

2. Stack-based architecture 

The EVM uses a stack-based architecture which, although simpler than a register-based structure, increases the difficulty of proving computation. This is why prominent 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 Keccak hashing functions and a Merkle Patricia Trie, both of which have a high proving overhead. Some zkVMs, like ZkSync, attempt to sidestep this problem by replacing the KECCAK256 function—but this can break compatibility with existing Ethereum tooling and infrastructure.

4. Proving costs 

Even if the aforementioned problems are solved, there's still the proof-generation process to contend with. Generating zero-knowledge proofs requires specialized hardware along with considerable investment in time, money, and effort. 

Although not exhaustive, this list presents some of the problems that hamper efforts to build EVM-compatible zkEVMs. Nonetheless, several breakthroughs in zero-knowledge technology have made it possible to mitigate those problems—leading to renewed interest in zkEVM solutions. 

Why is a zkEVM important?

Building a fully functional zkEVM will encourage the development of EVM-compatible ZK-rollup projects. This presents several advantages:

  1. Secure scalability
  2. Cheaper costs
  3. Faster finality and capital efficiency
  4. Network effects

1. Secure scalability

Per protocol rules, all validating nodes must re-execute all computations performed in the Ethereum Virtual Machine. This approach ensures security since Ethereum nodes can independently verify the correctness of programs, but it places limits on scalability the Ethereum network can manage just ~ 15-20 transactions).

EVM-compatible ZK-rollups can fix Ethereum’s throughput issues without undermining network security. Like other scaling protocols, ZK-rollups are not burdened by Ethereum’s consensus protocol rules and can optimize for execution speed. Some estimates suggest ZK-rollups can process ~ 2000 transactions per second without incurring Ethereum’s high fees. 

However, ZK-rollups have higher security guarantees compared to other scaling projects; they verify correctness of off-chain computation with validity proofs. It means transactions performed by smart contracts on L2 can be reliably verified on L1 (Ethereum) without nodes having to re-execute the operations. This can significantly increase Ethereum’s processing speed without reducing security. 

2. Cheaper costs

Rollups derive security from Ethereum Mainnet by writing transaction data to Ethereum as CALLDATA. However, optimistic rollups and ZK-rollups differ in how much data they must post on Ethereum. 

Because optimistic rollups don’t provide proof of validity for off-chain transactions, they need to publish all transaction-related data on-chain (including signatures and transaction parameters). Without putting all data on-chain, challengers cannot construct fraud proofs used to dispute invalid rollup transactions. 

Conversely, ZK-rollups can afford to post minimal data to Ethereum because validity proofs already guarantee the trustworthiness of state transitions. The zkEVM may even omit transaction inputs and publish only final state changes, further reducing CALLDATA requirements. 

This is beneficial for developers and users because a large percentage of rollup costs come from posting data on-chain. By reducing CALLDATA to a minimum, ZK-rollups can make it cheaper to use dApps, like decentralized exchanges, NFT marketplaces, prediction markets, and many more. 

3. Faster finality and capital efficiency 

Besides better security, ZK-rollups have another advantage over optimistic rollups: faster finality. Finality in blockchains is the time it takes for a transaction to become irreversible; a transaction can only be finalized if network participants have objective proof of its validity. 

With ZK-rollups, transactions executed in the zkEVM are often finalized immediately after they are posted on Ethereum. Since each transaction batch comes with an instantly verifiable proof of validity, the main Ethereum chain can quickly apply state updates. 

Since optimistic rollups only post VM transactions without proofs, the challenge period must elapse before transactions achieve finality. The challenge period is a 1-2 week period during which anyone can challenge a transaction after it is submitted to Ethereum. 

Slower finality has many implications for the user experience. For example, users cannot withdraw assets from the rollup until the delay period expires. Liquidity providers may solve the problem but may be ineffective if the withdrawal involves high-value assets or even NFTs. 

A zkEVM has none of those problems described above. Faster finality is great for power users, such as NFT traders, DeFi investors, or arbitrage traders who need to move around assets seamlessly (especially between L1 and L2). 

4. Network effects

The most important reason for building EVM-compatible zkVMs is to leverage Ethereum's network effects. As the world's biggest smart contracts platform, Ethereum has a large ecosystem that provides value to both developers and projects. 

For instance, developers can access battle-tested and audited code libraries, extensive tooling, documentation, and so on. Creating a new zkVM that is incompatible with Ethereum's infrastructure would cut off projects and development teams from harnessing Ethereum's network effects. 

What types of zkEVMs exist?

Current zkEVM projects fall into two main categories: zkVMs supporting native EVM opcodes and zkVMs using customized 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 opcodes" and executed in the 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 is strategic. 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. 

The Polygon Hermez zkEVM uses a STARK proving circuit to generate proofs of validity for state transitions. A STARK proof verifies the correctness of STARK proofs (think of it as generating "proof of a proof") and is 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. Compiling contract code written in Solidity to Yul, an intermediate language that can be compiled into bytecode for different virtual machines. 

2. Re-compiling the Yul bytecode (using the LLVM framework) to a custom, circuit-compatible bytecode set specially designed for zkSync's zkEVM. 

Like Polygon Hermez, the zkSync zkEVM achieves EVM compatibility at the language level, not the bytecode level. For example, traditional multiplication and addition opcodes (ADDMOD, SMOD, MULMOD) are not supported by zkSync's zkEVM. 

Scroll zkEVM

Scroll is a new zero-knowledge EVM implementation under development. The Scroll team plans to design zero-knowledge circuits for each EVM opcode. This would allow developers to deploy Ethereum-native smart contracts EVM on Scroll without needing to modify the underlying EVM bytecode. 

Among other things, the Scroll zkEVM will use a "cryptographic accumulator" to verify the correctness of storage. This is used to prove that the contract bytecode was loaded correctly from the given address. 

It also provides a circuit for linking the bytecode with the execution trace. The execution trace is a sequence specifying what VM instructions were executed and in what order. Provers will submit the execution trace during proof generation to verify that the computation was consistent with the original bytecode. 

AppliedZKP zkEVM

Applied ZKP is a project funded by the Ethereum Foundation to develop an EVM-compatible ZK-rollup and a mechanism for generating validity proofs for Ethereum blocks. The last part is critical because pairing blocks with validity proofs would remove the need for nodes to re-execute blocks. 

Applied ZKP's innovation is the separation of computation from storage. It uses two types of validity proofs—state proofs and EVM proofs: 

State proofs‍

Checks that operations touching storage, memory, and stack happened correctly. State proofs essentially verify the accuracy of read-write operations. 

EVM proofs

Checks that the computation called the accurate opcode at the right time. The EVM proofs verify the computation itself and also confirms that the state proof executed the right operation for each opcode. 

The AppliedZKP zkEVM uses a bus mapping to link the state proof and EVM proof. Also, both proofs must be verified before the Ethereum block is deemed valid.

Where are we in the development progress of zkEVMs?

Except for zkSync, most zero-knowledge EVMs are still under production. Nevertheless, growing development in zero-knowledge technology means the prospect of a fully functional zkEVMs is better than ever. 

In the meantime developers can leverage the benefits of  zero-knowledge applications with the StarkNet zero-knowledge VM. StarkNet is not EVM-compatible, but can compile Solidity source code to custom ZK-friendly bytecode. You can also choose to write contracts in Cairo (StarkNet's language). 

Sign up with Alchemy for free to start building on StarkNet today.

A zero-knowledge Ethereum Virtual Machine (zkEVM) is a virtual machine that generates zero-knowledge proofs to verify the correctness of programs. ZkEVMs are designed to execute smart contracts in a manner that supports zero-knowledge technology. 

ZkEVMs are part of zero-knowledge (ZK) rollups, Ethereum layer 2 scaling solutions that improve throughput by transferring computation and state storage off-chain. A ZK-rollup submits transaction data to Ethereum along with zero-knowledge proofs verifying the validity of off-chain transaction batches. 

Early ZK-rollups lacked the ability to execute smart contracts and were constrained to simple token swaps and payments. But, with the introduction of EVM-compatible zero-knowledge virtual machines, ZK-rollups are starting to support Ethereum dApps.

In this article, we explore how a zkEVM works, why it matters, and what types of zkEVM exist. 

What is a zkEVM?

A zkEVM is an EVM-compatible virtual machine that supports zero-knowledge proof computation. Unlike regular virtual machines, a zkEVM proves the correctness of program execution, including the validity of inputs and outputs used in the operation. 

We’ll break down this definition further to make it easier to understand:

EVM compatibility 

The EVM (Ethereum Virtual Machine) is the runtime environment in which smart contracts deployed on the Ethereum network are executed. The EVM functions as a “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 VMs can execute smart contracts written in Solidity or other high-level languages used in Ethereum development. ZkEVMs are EVM-compatible because they can execute Ethereum smart contracts without extensive modifications of the underlying logic

Support for zero-knowledge technology 

The EVM was never designed to support zero-knowledge proofs, which makes building EVM-compatible, zero-knowledge-friendly virtual machines difficult. However, advances in research have made it possible—to some extent—to wrap EVM computation in zero-knowledge proofs.

Different zkEVM projects adopt different approaches to combining EVM execution with zero-knowledge proof computation. Each method has unique tradeoffs, which we explore in a later section of this guide. 

How does a zkEVM work?

Like the EVM, a zkEVM is a virtual machine that transitions between states as a result of program operations. But the zkEVM goes further by producing a proof to attest to the correctness of every part of the computation. Essentially, a zkEVM uses a mechanism to prove that the execution steps (described earlier) followed rules. 

To understand how a zkEVM works (and why it’s different), let's review how the EVM works currently. 

How the EVM works

The Ethereum Virtual Machine is a state machine that moves from an old state to a new state in response to some inputs. Every smart contract execution triggers a change in the EVM’s state (called a “state transition”). Here’s a high-level overview of what happens during a smart contract transaction:

1. Contract bytecode (compiled from the source code) is loaded from the EVM’s storage and executed by peer-to-peer nodes on the EVM. Nodes use the same transaction inputs, which guarantees that each node arrives at the same result (or else they cannot reach consensus). 

2. EVM Opcodes (contained in the bytecode) interact with different parts of the EVM’s state (memory, storage, and stack). Opcodes perform read-write operations—reading (getting) values from state storage and writing (sending) new values to the EVM’s storage. 

3. EVM opcodes perform computation on the values obtained from state storage before returning the new values. This update results in the EVM transitioning to a new state (transactions are called “state transitions” for this reason). This new state is replicated by other nodes and remains until another transaction is executed. 

A diagram showing how programs are executed in the Ethereum Virtual Machine (EVM). [Source]

How the zkEVM works 

The zkEVM generates zero-knowledge proofs to verify various elements in each computation:

1. Bytecode access: Was the appropriate program code loaded correctly, from the right address? 

2. Read-write operations: a. Did the program fetch the right values from stack/memory/storage before the computation? b. Did the program write the correct output values to the stack/memory/storage after completing execution? 

3. Computation: Were the opcodes executed correctly (i.e., one after the other, without skipping steps)? 

The architecture of a zkEVM

The zkEVM is divided into three parts: an execution environment, proving circuit, and verifier contract. Each component contributes to the zkEVM’s program execution, proof generation, and proof verification. 

1. The execution environment 

As the name suggests, the execution environment is where programs (smart contracts) are run in the zkEVM. The zkEVM’s execution environment functions much like the EVM: it takes the initial state and current transaction to output a new (final) state.

2. The proving circuit 

The proving circuit produces zero-knowledge proofs verifying the validity of transactions computed in the execution environment. The proof generation process is completed using the pre-state, transaction inputs, and post-state information as inputs. After that, the prover obtains a succinct proof of the validity of that particular state transition. 

A diagram showing how the zkEVM generates validity proofs for programs. [Source]
3. The verifier contract 

ZK-rollups submit validity proofs to a smart contract deployed on the L1 chain (Ethereum) for verification. The input (pre-states and transaction information) and output (final states) are also submitted to the verifier contract. Then the verifier runs computation on the provided proof and confirms that the submitted outputs were correctly computed from the inputs. 

What are zkEVM opcodes?

ZkEVM opcodes are low-level machine instructions used for executing programs in an EVM-compatible ZK-rollup. As with the EVM, contracts written in high-level languages must be compiled to low-level language the VM can interpret (bytecode). This bytecode specifies the opcodes used in executing the program when it’s deployed in the VM.

We need zkEVM opcodes because regular EVM opcodes are inefficient for use in zero-knowledge proving circuits. There are generally two approaches to creating opcodes for zkEVMs:

  1. Building ZK circuits for native EVM opcodes
  2. Creating new languages for ZK proof computation

Build zero-knowledge circuits for native EVM opcodes 

This approach requires implementing all EVM instruction sets in an arithmetic circuit—a complex and time-intensive task. The benefit is that developers can create smart contracts using existing blockchain developer tooling or port existing Ethereum contracts to ZK-rollups without extensive modifications.  

Create new languages 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 to custom zkEVM opcodes. 

While this method is often simpler to implement than the first approach, it has drawbacks. For instance, developers may be unable to access existing Ethereum infrastructure and resources. 

A classification of zero-knowledge virtual machines according to EVM compatibility. [Source]

What makes building a zkEVM difficult?

Because the EVM wasn’t built with zk-proof computation in mind, it has features that are unfriendly for proving circuits. Here is a brief overview of four things that make building zkEVMs difficult:

  1. Special opcodes
  2. Stack-based architecture
  3. Storage overhead
  4. Proving costs

1. Special opcodes 

Unlike a regular VM, the EVM uses special opcodes for program execution (CALL, DELEGATECALL) and error handling (REVERT, INVALID), amongst other operations. This adds complexity to the process of designing the proving circuit for EVM operations. 

2. Stack-based architecture 

The EVM uses a stack-based architecture which, although simpler than a register-based structure, increases the difficulty of proving computation. This is why prominent 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 Keccak hashing functions and a Merkle Patricia Trie, both of which have a high proving overhead. Some zkVMs, like ZkSync, attempt to sidestep this problem by replacing the KECCAK256 function—but this can break compatibility with existing Ethereum tooling and infrastructure.

4. Proving costs 

Even if the aforementioned problems are solved, there's still the proof-generation process to contend with. Generating zero-knowledge proofs requires specialized hardware along with considerable investment in time, money, and effort. 

Although not exhaustive, this list presents some of the problems that hamper efforts to build EVM-compatible zkEVMs. Nonetheless, several breakthroughs in zero-knowledge technology have made it possible to mitigate those problems—leading to renewed interest in zkEVM solutions. 

Why is a zkEVM important?

Building a fully functional zkEVM will encourage the development of EVM-compatible ZK-rollup projects. This presents several advantages:

  1. Secure scalability
  2. Cheaper costs
  3. Faster finality and capital efficiency
  4. Network effects

1. Secure scalability

Per protocol rules, all validating nodes must re-execute all computations performed in the Ethereum Virtual Machine. This approach ensures security since Ethereum nodes can independently verify the correctness of programs, but it places limits on scalability the Ethereum network can manage just ~ 15-20 transactions).

EVM-compatible ZK-rollups can fix Ethereum’s throughput issues without undermining network security. Like other scaling protocols, ZK-rollups are not burdened by Ethereum’s consensus protocol rules and can optimize for execution speed. Some estimates suggest ZK-rollups can process ~ 2000 transactions per second without incurring Ethereum’s high fees. 

However, ZK-rollups have higher security guarantees compared to other scaling projects; they verify correctness of off-chain computation with validity proofs. It means transactions performed by smart contracts on L2 can be reliably verified on L1 (Ethereum) without nodes having to re-execute the operations. This can significantly increase Ethereum’s processing speed without reducing security. 

2. Cheaper costs

Rollups derive security from Ethereum Mainnet by writing transaction data to Ethereum as CALLDATA. However, optimistic rollups and ZK-rollups differ in how much data they must post on Ethereum. 

Because optimistic rollups don’t provide proof of validity for off-chain transactions, they need to publish all transaction-related data on-chain (including signatures and transaction parameters). Without putting all data on-chain, challengers cannot construct fraud proofs used to dispute invalid rollup transactions. 

Conversely, ZK-rollups can afford to post minimal data to Ethereum because validity proofs already guarantee the trustworthiness of state transitions. The zkEVM may even omit transaction inputs and publish only final state changes, further reducing CALLDATA requirements. 

This is beneficial for developers and users because a large percentage of rollup costs come from posting data on-chain. By reducing CALLDATA to a minimum, ZK-rollups can make it cheaper to use dApps, like decentralized exchanges, NFT marketplaces, prediction markets, and many more. 

3. Faster finality and capital efficiency 

Besides better security, ZK-rollups have another advantage over optimistic rollups: faster finality. Finality in blockchains is the time it takes for a transaction to become irreversible; a transaction can only be finalized if network participants have objective proof of its validity. 

With ZK-rollups, transactions executed in the zkEVM are often finalized immediately after they are posted on Ethereum. Since each transaction batch comes with an instantly verifiable proof of validity, the main Ethereum chain can quickly apply state updates. 

Since optimistic rollups only post VM transactions without proofs, the challenge period must elapse before transactions achieve finality. The challenge period is a 1-2 week period during which anyone can challenge a transaction after it is submitted to Ethereum. 

Slower finality has many implications for the user experience. For example, users cannot withdraw assets from the rollup until the delay period expires. Liquidity providers may solve the problem but may be ineffective if the withdrawal involves high-value assets or even NFTs. 

A zkEVM has none of those problems described above. Faster finality is great for power users, such as NFT traders, DeFi investors, or arbitrage traders who need to move around assets seamlessly (especially between L1 and L2). 

4. Network effects

The most important reason for building EVM-compatible zkVMs is to leverage Ethereum's network effects. As the world's biggest smart contracts platform, Ethereum has a large ecosystem that provides value to both developers and projects. 

For instance, developers can access battle-tested and audited code libraries, extensive tooling, documentation, and so on. Creating a new zkVM that is incompatible with Ethereum's infrastructure would cut off projects and development teams from harnessing Ethereum's network effects. 

What types of zkEVMs exist?

Current zkEVM projects fall into two main categories: zkVMs supporting native EVM opcodes and zkVMs using customized 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 opcodes" and executed in the 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 is strategic. 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. 

The Polygon Hermez zkEVM uses a STARK proving circuit to generate proofs of validity for state transitions. A STARK proof verifies the correctness of STARK proofs (think of it as generating "proof of a proof") and is 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. Compiling contract code written in Solidity to Yul, an intermediate language that can be compiled into bytecode for different virtual machines. 

2. Re-compiling the Yul bytecode (using the LLVM framework) to a custom, circuit-compatible bytecode set specially designed for zkSync's zkEVM. 

Like Polygon Hermez, the zkSync zkEVM achieves EVM compatibility at the language level, not the bytecode level. For example, traditional multiplication and addition opcodes (ADDMOD, SMOD, MULMOD) are not supported by zkSync's zkEVM. 

Scroll zkEVM

Scroll is a new zero-knowledge EVM implementation under development. The Scroll team plans to design zero-knowledge circuits for each EVM opcode. This would allow developers to deploy Ethereum-native smart contracts EVM on Scroll without needing to modify the underlying EVM bytecode. 

Among other things, the Scroll zkEVM will use a "cryptographic accumulator" to verify the correctness of storage. This is used to prove that the contract bytecode was loaded correctly from the given address. 

It also provides a circuit for linking the bytecode with the execution trace. The execution trace is a sequence specifying what VM instructions were executed and in what order. Provers will submit the execution trace during proof generation to verify that the computation was consistent with the original bytecode. 

AppliedZKP zkEVM

Applied ZKP is a project funded by the Ethereum Foundation to develop an EVM-compatible ZK-rollup and a mechanism for generating validity proofs for Ethereum blocks. The last part is critical because pairing blocks with validity proofs would remove the need for nodes to re-execute blocks. 

Applied ZKP's innovation is the separation of computation from storage. It uses two types of validity proofs—state proofs and EVM proofs: 

State proofs‍

Checks that operations touching storage, memory, and stack happened correctly. State proofs essentially verify the accuracy of read-write operations. 

EVM proofs

Checks that the computation called the accurate opcode at the right time. The EVM proofs verify the computation itself and also confirms that the state proof executed the right operation for each opcode. 

The AppliedZKP zkEVM uses a bus mapping to link the state proof and EVM proof. Also, both proofs must be verified before the Ethereum block is deemed valid.

Where are we in the development progress of zkEVMs?

Except for zkSync, most zero-knowledge EVMs are still under production. Nevertheless, growing development in zero-knowledge technology means the prospect of a fully functional zkEVMs is better than ever. 

In the meantime developers can leverage the benefits of  zero-knowledge applications with the StarkNet zero-knowledge VM. StarkNet is not EVM-compatible, but can compile Solidity source code to custom ZK-friendly bytecode. You can also choose to write contracts in Cairo (StarkNet's language). 

Sign up with Alchemy for free to start building on StarkNet today.

Build web3 with Alchemy

Alchemy combines the most powerful web3 developer products and tools with resources, community and legendary support.

Get started for free