What Are the Different Types of zkEVMs?
What Are the Different Types of zkEVMs?
zkEVMs are what power zk rollups, a smart contract technology used for Ethereum transactions.
by Thomas Thang, senior investment associate
What are zero-knowledge rollups?
Zero-knowledge rollups (zkRUs) are a layer 2 Ethereum scaling solution that allows for increased transaction throughput by aggregating multiple transactions into a single block. Instead of submitting all transaction data to the blockchain, zkRUs use zero-knowledge proofs (ZKPs) to verify the validity of the transactions off-chain and only submit the updated state data along with the proof to the Ethereum blockchain. This process reduces the amount of data that needs to be stored on the blockchain, increasing scalability and privacy.
Early problems with zkRUs
Early implementations of ZKRs, however, faced limitations in their functionality. These early ZKRs were mainly designed to handle simple token swaps and payments, and were unable to perform general-purpose computations or execute smart contracts. This was because it was impractical for developers to write their dApps in specialized circuit language.
Solution: Universal Virtual Machine
The proposed solution to this problem is to develop a universal virtual machine (VM) circuit that allows for smart contract execution and produces ZKPs to verify it. However, this was not always feasible due to the complexity of circuits and the need for specialized hardware acceleration to efficiently compute proofs. In fact, many researchers were uncertain if this was even possible.
It was only recently that the combination of polynomial commitment schemes, optimized lookup tables, new recursive proofs and developments in hardware acceleration have made the development of a universal VM a practical reality.
So what has stalled the development of a universal VM? Firstly, let's dive into what the EVM does to explain why.
Ethereum virtual machine
The Ethereum virtual machine (EVM) allows developers to create smart contracts in a programming language called Solidity. It is responsible for computing the state changes that are a result of executing the code of smart contracts. The EVM cannot directly execute Solidity so first the source code must be compiled to contract bytecode which contains EVM opcodes. These opcodes perform read-write operations. Currently, there are roughly 150 opcodes that the EVM can execute.
A universal VM for zkRUs would need an execution environment to execute smart contracts, generate ZKPs for each step, and a verifier contract to compute the validity proofs. The process of creating such a VM is not simple and there are difficulties encountered at each step. This is where the differences between various implementations of zkVMs begin to appear.
Solution 1: Create a new language designed for ZK proof computation
The EVM was not designed to support zero-knowledge proofs. It uses special opcodes (CALL), error types and gas, and relies on special hashing functions (Keccak) and data structures (Merkle Patricia Trie) that have massive storage overheads. In August of 2022, Vitalik Buterin introduced his taxonomy for zkEVM types and the zkEVM ‘dilemma’, where greater compatibility with Ethereum comes at the cost of longer proof times and thereby lower performance.
One potential solution to this issue is the development of a new programming language specifically designed for the computation of zero-knowledge proofs. This language would address the limitations of the EVM and its inability to support ZKPs natively. This new language could include specialized opcodes and data structures optimized for the efficient computation of ZKPs, reducing the storage overheads and proof times associated with existing solutions. Additionally, it could also eliminate the need for the use of specialized hashing functions and error types, further improving performance and compatibility with Ethereum.
One example of this approach is the implementation of type 4 zkEVMs such as StarkWare’s Cairo zkVM and zkSync’s zinc zkVM. These solutions introduce a new language that is optimized for supporting validity proofs and custom opcodes. They use custom transpilers to convert Solidity into their native higher-level languages such as Cairo or Yul respectively. While this approach may be easier to build and optimize, it does not support existing Ethereum developer tooling and may not support certain functionality. Furthermore, it introduces further complexity as developers and auditors may need to learn Cairo or Yul, resulting in high barriers to entry. Furthermore, it would result in poor maintainability as teams would need to constantly rework or update their zkEVM as the EVM continues to evolve.
Solution 2: Build ZK circuits for native EVM opcodes
An alternative approach is to build ZK circuits for native EVM opcodes. However, the difficulty is that zkVMs must prove the entire Ethereum state transition function, including functions beyond the EVM opcodes.
Type 3 zkEVM
In their current forms, both Polygon and Scroll zkEVMs are ‘almost EVM-equivalent’, meaning that both have yet to implement some more complicated precompiles. These precompiled contracts offer more advanced functionality and are a special kind of contract that are bundled with the EVM at fixed addresses with predetermined gas costs.
Type 2 zkEVM
Consensys, Polygon and Scroll zkEVMs are all working towards being ‘fully EVM-equivalent’ or bytecode compatible, meaning they can execute unaltered native bytecode in accordance with EVM specification and provide full coverage of opcodes and precompiles. This allows developers to use their existing code and utilize existing Ethereum infrastructure (Geth) and tooling (Remix/Hardhat/Foundry). However, they all differ in the way they internally manage the L2 state. For example, Consensys’ zkEVM will not use the keccak256 hash function as it is not zk-friendly.
Polygon’s zkEVM also features a different data structure, they use a special merkle tree where each leaf only stores a single property (i.e. balance / nonce / codeHash / storageRoot) and uses a different hash function called Poseidon. They also utilize 256 bits of memory instead of 8 bits, which slightly alters the logic for querying memory. Lastly, they introduce a ZK assembly compiler (zkASM) to interpret transactions. You can find out more about Polygon zkEVM’s difference here.
It is important to note that using zk-friendly hash functions like Poseidon might break compatibility for smart contracts that rely on the block hash. For example, a bridge contract might use a Merkle proof for verification or when Verkle trees are introduced.
Type 1 zkEVM
These are ‘fully Ethereum equivalent’ or theoretically indistinguishable from Ethereum itself. Taiko’s zkEVM makes no changes to the Ethereum architecture, whether it be the hash function, state trees, or gas costs. This equivalency allows them to seamlessly support smart contracts being migrated between Taiko and Ethereum without modification. It also means that existing Ethereum infrastructure such as execution clients can be easily repurposed as Taiko nodes.
Taiko’s approach utilizes Privacy & Scaling Explorations’ implementation (previously AppliedZKP), where the zkEVM is broken into a 2-part zkSNARK that consists of a state proof which validates accuracy of read-write operations and a EVM proof which validates the computation and EVM execution. The primary concern with type 1 zkEVM is the impractically large proof sizes and the feasibility of computing them in a timely and efficient manner. Generating these proofs quickly would require extremely powerful GPU and ASIC/FPGA accelerators, which might limit the parties who can perform prover function and hamper decentralization.
Why are there so many zkEVMs?
There are nuances to each implementation, with each team working to tackle EVM compatibility in a slightly different way, these incentivize experimentation for different proving schemes. These multiple zkEVMs also introduce diversity and security to the L2 layer. Vitalik has introduced the concept of multi-prover zkEVM rollups where any single bug does not impact the integrity of any zkRU, but will introduce redundancy and resiliency.