The Mechanics of zkEVM: How It Works and Why It Matters

There has been a lot of research and development on various Ethereum scaling solutions because of the high network fees and slow transaction speed. Enter Zero Knowledge Rollups (ZK Rollups) which is the best scaling solution right now because of its high transaction throughput and reduced gas costs.

Zk rollups batch multiple transactions in a single block, execute them, and generate a proof which is verified by the smart contract deployed on the mainnet. So the smart contract only needs to verify the generated proof and apply the updated state, without the need to re-execute all of the batched transactions, thus saving gas fees and time!

Although Zk rollups are very efficient, it's hard to build general-purpose apps on them because different Zk rollup apps can’t interact with each other in layer-2 (Composability). But why’s that a problem you ask? This is a serious issue because if you want to develop an app on Zk rollup, you need to write the smart contract in R1CS, not only the syntax is complicated but it also demands a strong knowledge of Zk proofs.

There are two approaches to solve this: creating special circuits for each Dapps or building a universal EVM circuit for smart contract execution. (circuit refers to a program in zero-knowledge proofs). The first approach needs every Ethereum Developer to have knowledge of Zk rollups but it lacks composability. So, it's obvious that we are not going to use the first approach and that’s where ZkEVM comes into the picture.

What is ZkEVM?

ZkEVM stands for Zero-knowledge Ethereum Virtual Machine. It executes the smart contract transactions in such a way that they are compatible with Zero Knowledge Proof Computations and the EVM. This helps the transactions to be executed in Zero Knowledge Rollups, which are a layer-2 scaling solution that reduces gas costs and increases transaction speed.

Architecture of ZkEVM

Before understanding how ZkEVM works, let’s get a brief idea of how an EVM (Ethereum Virtual Machine) works.

After deploying your contract on ethereum, the contract bytecode is stored in EVM storage and executed in the peer-to-peer network with the same input data to reach consensus. The EVM opcodes present in the bytecode are responsible for changing the EVM’s state as they are capable of performing read, compute and write operations.

A ZkEVM’s architecture can be divided into 3 parts:

1. Execution layer

It functions similar to EVM, i.e. it executes the smart contract and generates a new state.

2. Proving Circuit

The proving circuit is responsible for producing zero-knowledge proof of the state changes, not only that but it also verifies if the previous computation led to the current state changes. This helps to verify and validate the updated state.

3. Verifier Contract

In Ethereum every smart contract is executed in a peer-to-peer network to reach a consensus, similarly, here a validity proof is submitted to the verifier contract, to validate the state changes produced by the execution environment.

Subscribe to Matic (Polygon) on-chain information in real-time including transactions, dex trades, NFT, and balance updates.

Challenges in building a ZkEVM

That’s it, that's the architecture of ZkEVM, seems simple doesn’t it then why are gas fees still so high? Well that’s because it is not easy of build a ZkEVM it requires very good knowledge of cryptography and of course EVM too. So let’s understand what are the challenges while designing one.

1. Special Opcodes

The EVM wasn’t designed keeping zero-knowledge computation in mind and therefore it has features that make proving a circuit very difficult. For example, opcodes like CALL, DELEGATECALL, REVERT, and INVALID are very difficult to design for proving circuits for such EVM operations.

2. Storage Overhead

EVM uses Keccak hashing functions and Merkle Patricia Trie, both of which are not zk-friendly and have high computational costs when proving the validity of data. For example, Keccak hash is a thousand times larger than poseidon hash in circuit. ZkSync solves this problem by replacing the Keccak function, although this can break the compatibility with the existing Ethereum infrastructure.

3. Stack-based Architecture

EVM has a stack-based architecture (LIFO - last in first out) which is simple but increases the difficulty of proving computation and that’s most of the ZkEVM’s use a register-based model where data is stored in virtual CPU registers which leads to high performance computing. This approach is language compatible instead of EVM compatible.

4. Proving Costs

Even if we solve all of the above-mentioned problems, the process of generating a zero-knowledge proof is resource intensive and requires specialized hardware.

Types of ZkEVM

Ethereum’s founder Vitalik Butarin categorized EVM’s into these types:

1. Fully Ethereum Equivalent (Consensus level equivalence)

These ZkEVM can be considered equivalent to Ethereum as they don’t make any changes at the consensus level to make the proof generation process easier and that’s why they require longer proving times compared to other types. Projects building these types of ZkEVM are Taiko

2. EVM Equivalent (Bytecode level equivalence)

Type 2 EVMs are completely equivalent to EVM but not Ethereum because it introduce some modifications that are ZK-friendly like deleting some stack operations and different data structures compared to Ethereum. Although it is compatible with the existing Dapps, it is still slower than the succeeding types. Consensys ZkEVM and Linea are good examples of type 2 ZkEVMs.

3. Almost EVM Equivalent

Type 3 ZkEVMs are those which are almost EVM equivalent meaning they sacrifice EVM compatibility to improve ZK efficiency. It removes precompiles, VM memory, Stack. This may require rewriting your smart contracts. Although this type exists today, the end goal is to switch to type 2, because it not only hurts developer experience but also users will have to interact with different versions of the same Dapp. Type 3 ZkEVMs include Polygon ZkEVM and Scroll, although this might change in near future.

4. High-level language equivalent to EVM

These types of ZkEVMs compile the solidity code to their own designed language which is more ZK-friendly resulting in faster proof generation. Examples include ZkSync Era, Nethermind’s Warp.

Advantages of ZkEVM over EVM

1. Secure Scalability

All Ethereum computations must be executed on the validator nodes resulting in slow finality but with ZkEVM we don’t need to rely on other participants for verifying the transactions, the Zk-rollup does that for us while maintaining the same security.

2. Reduced Costs

Since ZkEVM’s are capable of verifying transactions on their own, they don’t need to publish all transactional data onchain which results in reduced gas costs

3. Faster Finality

Zk-Rollups can bundle multiple transactions and verify them as soon as they are posted resulting in faster finality

4. Network Effects

Ethereum is the most widely used smart contract platform and has a lot of existing Dapps, EVM compatibility enables zkEVMs to leverage Ethereum’s existing developer ecosystem, extensive tooling, documentation, code libraries, and battle-tested infrastructure.

---

Blog written by Deepak Shah