BLOG — Gelato University

55 days ago

What are Zero Knowledge (ZK) EVMs?

Ethereum's scalability issues have spurred the use of Layer 2 (L2) scaling methods, such as rollups- or ZK rollups specifically- which use validity proofs to confirm off-chain computations.

However, they are not easily compatible with the EVM. To address this, the zkEVM was created to execute smart contracts in a way that is compatible with both zero-knowledge-proof computations and the Ethereum infrastructure. This allows it to be used in zero-knowledge rollups and L2 scaling solutions, improving transaction throughput while lowering costs.

Scalability Solutions

Before we delve deeper into this topic, here's a brief explainer of the different types of scaling solutions:

Layer 1 scaling solutions

L1 scaling involves increasing the transaction processing capacity of the base layer of a blockchain network.

Layer 2 scaling solutions

L2 scaling involves changing how users interact with the blockchain by moving the bulk of activity off-chain into a L2 protocol.They are implemented separately from L1 mainnet and require no changes to the existing Ethereum protocol. One popular L2 scaling method is known as a rollup.

Rollups bundle (or 'roll up') transactions into batches to be executed off-chain. The data is then posted to L1 where a consensus is reached.

We currently have two rollups: Optimistic and ZK rollups. Optimistic rollups assume transactions are valid by default and only run computation, via a fraud proof, in the event of a challenge whilst ZK rollups run computation off-chain and submit a validity proof to the chain.

How do ZK rollups work?

Suppose Alice wants to send 10 ETH to Bob using a ZK rollup-based wallet. Here are the steps involved:

ZK rollup transactions involve a third-party operator that processes transactions off-chain and creates cryptographic proofs to verify the validity of the updated state on-chain.

Alice sends her transaction to the ZK rollup operator who collects it, along with pending transactions from other users.

The operator then creates a ZK proof that summarizes all the transactions, including Alice's 10 ETH transfer to Bob. The ZK proof proves that the new state of the system is correct without revealing any details about Alice's transaction.

The ZK proof is submitted to the on-chain contract by the operator.

The on-chain contract verifies the ZK proof and checks the validity, ensuring that the new state is correct and that no invalid transactions were included. If everything is valid, the contract accepts the new state, which includes the updated Merkle root.

Bob can now check that he has received the 10 ETH by looking at the updated Merkle root. He can also use the ZK proof to verify that the transaction was processed correctly without revealing any sensitive details.

ZK rollups are considered the best way to scale ethereum for all purpose applications but they are not easily compatible with the EVM. However, advances in zero-knowledge technology are igniting renewed interest in wrapping EVM computation in zero-knowledge proofs. These efforts are geared towards creating a zero-knowledge EVM (zkEVM) .

ZK rollups use validity proofs to confirm the correctness of off-chain. These proofs can come in the form of a ZK-SNARK or ZK-STARK. For more information check out our other blog post.

What is a zkEVM?

A zkEVM is an EVM-compatible virtual machine that allows you to execute smart contract transactions in a way that’s compatible with both ZK proof computations and existing Ethereum infrastructure.

This enables them to be part of both ZK rollups and L2 scaling solutions that increase transaction throughput while lowering costs.

The zkEVM is a new layer on top of the Ethereum blockchain that provides a more efficient way to process transactions. This is achieved by using a different processing method for transactions on L1 and L2.

In L1, the smart contract code is stored on the Ethereum blockchain, and when a transaction is made, each full node has to load the code and execute it to reach the same state. This process can be slow and resource-intensive.

In L2, the smart contract code is also stored on the blockchain but when a user initiates a transaction, it is sent off-chain to a centralized zkEVM node instead of being broadcasted on the P2P network like in L1. A zkEVM node generates a proof that proves the correctness of the updated state.This proof is generated using a cryptographic technique called ZK-SNARKs.

The L1 contract verifies the validity of the ZK proof and updates the state of the contract without re-executing the transaction. This means that the state of the contract is updated on the blockchain, but the actual transaction is processed off-chain.

Now, let's take a deeper look at the ZK proof generation process.

Layer 1: the EVM reads and executes the smart contract code one step at a time. Each step involves reading some data, doing some computations, and storing the result. For example, when the EVM encounters an "add" instruction, it reads two numbers, adds them together, and stores the result.

Layer 2: with the zkEVM, instead of re-executing the smart contract on the EVM, a succinct proof is generated that ensures that the smart contract would have executed correctly.

Types of zkEVMs

Ethereum equivalence means making no changes to the Ethereum architecture.

EVM equivalence means changing some parts of the ethereum stack which are too complex to prove.

Type 1 (fully Ethereum-equivalent)

Type 1 zkEVMs aim to be fully equivalent to Ethereum, allowing for perfect compatibility. However, because Ethereum was not designed to be ZK-friendly, the ZK proof process requires significant computation, resulting in larger prover time.

Type 2 (fully EVM-equivalent)

Type 2 zkEVMs are EVM Equivalent, they look exactly like Ethereum from “within” but with some minor changes to make development easier and to make proof generation faster. While these modifications may affect some Ethereum applications, most should still be compatible with a Type 2 zkEVM rollup. However, the inefficiencies and ZK-unfriendliness of the EVM still slow down the proving process.

Type 2.5 (EVM-equivalent, except for gas costs)

Type 2.5 zkEVMs increase gas costs of difficult-to-prove EVM operations to improve worst-case prover times. This may cause some developer tooling compatibility issues but is less risky than deeper EVM changes. Another alternative to manage resource constraints is to simply set hard limits on the number of times each operation can be called.This is easier to implement in circuits, but plays much less nicely with EVM security assumptions.

Type 3 (almost EVM-equivalent)

Type 3 zkEVMs are almost equivalent to the EVM, with a few key differences. They are easier to build and have faster prover times, as it removes certain difficult-to-implement features, but this can lead to compatibility issues with some applications.

Type 4 (high-level-language equivalent)

Type 4 systems use smart contract source code written in high-level languages (Solidity and Vyper) and compile it to a language specifically designed to be ZK-SNARK-friendly. To avoid overhead, some parts of EVM execution steps can be skipped from ZK proofing by starting directly from higher-level code. However, some applications may not be compatible with Type 4 zkEVMs.


In conclusion, with the development of the zkEVM, Ethereum is now better positioned to address scalability issues without compromising decentralization and security.

To learn more about the different projects implementing zkEVMs, check out our guide here.