Does zk-EVM just prove EVM execution?

Published in

Tokamak Network

6 min readJul 24, 2024

You can check the Korean version of the article here.

About zk-EVM

The goal of zk-EVM is to generate cryptographic proofs that validate transaction execution. The cryptographic proof here refers to zero-knowledge proofs (ZKP). In other words, given an initial world state S, a transaction T, and a resulting world state S’, zk-EVM must generate a ZKP that proves f(S, T) = S’. Here, f is the state transition function specified in the Ethereum yellow paper.

Many zk-EVM projects(Scroll, Polygon, Kakarot, Tokamak, etc.) exist, but all share the same core objective: to create cryptographic proofs of Ethereum-like transaction execution using ZKP technology. This explanation references the Scroll blog and Vitalik’s blog. (For more details, please refer to the blog links.)

However, as the name suggests, zk-EVM is often introduced as a system that proves the correct execution of the EVM. Can you find any differences from the previous introduction?

Let’s consider a simple transaction that transfers Ether between accounts(specifically EOA). This transaction changes the state by deducting the sender’s Ether balance and increasing the receiver’s balance. But is this really what the EVM does? Let’s explore this slowly.

EVM: Ethereum Virtual Machine

https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf

EVM stands for Ethereum Virtual Machine, the execution engine of Ethereum that runs programs known as smart contracts. The EVM is a stack-based virtual machine with its own set of instructions(opcodes) and operates on a series of instructions(Bytecode) that it can understand. In other words, without Bytecode input, the EVM does not operate. However, it was said that the world state changes through transactions, so isn’t the world state included in the EVM as shown in the diagram above? To answer this question, it is necessary to understand the world state accurately.

World state

The world state is like the brain of Ethereum, permanently storing all account information within Ethereum. Each account has a state. More specifically, Ethereum accounts (EOA: Externally Owned Account) used with private keys, and smart contracts deployed on the Ethereum network (CA: Contract Account) both have account states, but with clear differences. EOA has valid values only for nonce, which prevents double-spending, and balance, which indicates Ethereum balance. CA additionally has “storage” for the smart contract’s permanent storage and “code” representing the immutable bytecode of the smart contract. (The term ‘hash’ refers to a cryptographic method used to summarize long codes or large amounts of data, but it is omitted here for intuitive explanation.)

The world state referred to in the previous EVM diagram is the account storage of the CA. Storage can only be changed through the EVM, which executes smart contracts, but the balance of EOA is a bit more flexible.

Returning to the question, the transaction that transfers Ether between EOA accounts is neither a creation nor a call of a smart contract. This means there is no Bytecode to execute, and the EVM is not involved.

EVM ⊂ Execution client

Many people often think of Ethereum’s execution client and EVM as the same. However, the EVM is merely a subset of the Execution client responsible for code execution. For those unfamiliar with the Execution client, let’s explain the structure of Ethereum a bit more.

https://ethereum.org/en/developers/docs/nodes-and-clients/node-architecture/

As shown in the diagram, the Ethereum network consists of distributed local nodes. Each node is composed of two types of clients that communicate with each other:

Execution client: Processes and validates transactions propagated through the network and manages state. (e.g., Geth, Reth)
Consensus client: Maintains synchronization with the actual Ethereum network through the consensus process. (e.g., Prysm, Lighthouse)

Before “The Merge”, which brought the most significant change in Ethereum in 2022, Ethereum nodes performed both execution and consensus roles as a single client. After The Merge, these roles were completely separated. The Consensus client handles network consensus through the proof-of-stake (PoS) algorithm, while the Execution client handles all tasks related to transaction execution.

All transactions are processed and validated by the Execution client, and if code execution is required, the Execution client runs the EVM internally. Therefore, if zk-EVM aims to prove the validity of transaction execution, it must do more than what the EVM does. This means ensuring the accuracy of the entire transaction processing process, not just the execution of smart contract code.

Real world zk-EVM

Now it is time to answer the question posed in this article’s title. Is zk-EVM just about proving the correct execution of the EVM? No, it is not. The commonly used term zk-EVM is closer to zk-Execution client. zk-EVM projects aim to emulate the functions of the Execution client and prove the validity of all transactions, including simple Ether transfers. Let’s take a closer look at the processes of Scroll zk-EVM and Polygon zk-EVM.

Scroll zk-EVM

Note: In reality, it processes a bundle of transactions rather than a single transaction.

Scroll zk-EVM uses a geth-based execution client to execute transactions and generate proofs based on these executions. As previously mentioned, simple Ether transfers do not involve executing EVM opcodes, so no steps are found in the EVM execution trace provided by the execution client. Scroll’s zk-EVM adds virtual steps called begin_tx and end_tx to prove these transactions separately from smart contract execution. In other words, Scroll zk-EVM proves not only the execution of EVM bytecode but also virtual steps, thus ensuring the correct execution of all transactions.

Polygon zk-EVM

Polygon zk-EVM uses a new assembly language called zkASM (Zero-Knowledge Assembly). Programs written in zkASM (referred to as ROM) emulate the operation of the execution client, creating a more detailed execution trace for transactions. This execution trace includes basic EVM execution tracking and changes in account nonce and balance, proving the execution of all transactions, including simple Ether transfers (related content). However, this execution trace is in the form of zkASM instructions rather than EVM bytecode. Polygon zk-EVM has chosen this method to make proof generation more efficient.

This article has examined only two projects, but many more zk-EVM projects exist. Depending on the zero-knowledge proof system used (e.g., Scroll — halo2, Polygon — plonky2) and the approach to balancing “proof generation efficiency” and “Ethereum equivalence,” various approaches are possible. If you find this content interesting, reading Vitalik’s blog post mentioning more zk-EVM projects might help satisfy your curiosity.

Due to the diverse approaches, it is difficult to make an objective comparison to determine which method is absolutely better. However, the core value that all zk-EVMs share is the common goal of researching for Ethereum scalability.

Conclusion

This article addressed the question of whether zk-EVM simply proves the correct execution of the EVM. In conclusion, the goal of zk-EVM is to ensure the accuracy of the entire transaction processing process, not just the execution of the EVM. This means that in addition to executing smart contract code, zk-EVM must prove the validity of all transaction processing tasks handled by the Ethereum Execution client through zero-knowledge proofs. As seen in the approaches of Scroll and Polygon, zk-EVM encompasses the entire transaction processing process, not only proving EVM execution but also adding internal logic to cover all transactions. I hope this article has helped you understand zk-EVM better.