About one year ago, a wave of ZK-EVMs announced the upcoming launch of testnets. These initiatives piqued curiosity within the Ethereum community, prompting questions about the nuances behind terms like Ethereum-equivalence and EVM-equivalence.
To create clarity, Vitalik wrote a seminal article titled “The Different Types of ZK-EVMs”, which classifies various ZK-EVMs into four types and explains their distinctions.
The central idea is this: Type 1 (e.g. Taiko) is exactly Ethereum-equivalent, while Type 4 (e.g. zkSync) excels at efficient proof generation. All other types, Type 2, Type 2.5, and Type 3, fall between these two extremes (e.g. Polygon zkEVM, Scroll, Linea).
Most ZK-EVMs initially started as Type 3 or Type 2.5, and broadcasted some intentions to move towards Type 1 or Type 2, although no specific timing or commitments were provided by these projects.
This article primarily focuses on the differences between Type 1 and Type 2/2.5, and describes the possible consequences of breaking Ethereum-equivalence. We will also briefly touch on the other types.
The primary objective of ZK-EVM is to scale Ethereum — to enhance Ethereum’s throughput while retaining its other attributes (security, developer experience, etc.) In an ideal scenario, ZK-EVM would:
prove the execution of unmodified, native bytecode in accordance with the Ethereum VM specification as specified in the yellow paper (covering 100% of Ethereum opcodes).
quickly generate proofs at a low cost.
enable the reuse of 100% of tooling and infrastructure developed for Ethereum.
allow redeployment of any Ethereum dApp “as is” on ZK-EVM (”as is” meaning no changes needed, uncompromisingly).
Distinctions Among ZK-EVM Types
In the ZK-EVM domain, distinctions arise from Ethereum/EVM-equivalence levels, the influence of ZK-unfriendly elements on proof generation costs and speed, and the intricacy of circuit implementation (such as VM building or state trees).
Let’s analyze these differences, specifically focusing on separating Type 1 from Type 2/2.5. We’ll also touch on use cases most relevant to each type.
When comparing the various types, the diagram below is commonly used:
This table may appear cryptic for those who don’t work full-time in the ZK-EVM space, so let’s take a closer look in plain English.
This graphic brings more clarity to what the practical consequences are for each Type, but it can still be a bit cryptic. Let’s connect the dots by explaining each type separately and explore the ZK-EVM landscape in its entirety!
Type 1 — Ethereum-equivalent
“Type 1 ZK-EVMs are what we ultimately need make the Ethereum layer 1 itself more scalable”
Type 1 denotes no changes to any part of the Ethereum system to make it easier to generate proofs. No changes to Ethereum means uncompromising security, as most cryptographic primitives (e.g. hash functions), developer infrastructure (e.g. debugger), or chain infrastructure (e.g. execution clients) have been battle tested for over 9 years.
A Type 1 ZK-EVM doesn’t replace anything: hashes, state trees, transaction trees, precompiles, or any other in-consensus logic. Everything is exactly as it is in Mainnet’s EVM.
Type 1 is the only type capable of verifying the Ethereum chain itself — from whole blocks to transaction execution, smart contracts, and account logic.
Type 2 — EVM-equivalent
Note: Ethereum-equivalent and EVM-equivalent are not the same. While Ethereum-equivalent means no Ethereum parts were changed, that is, perfect compatibility with all Ethereum dApps, EVM-equivalent allows changing data structures (e.g. block structure or state tree).
Although these adjustments might appear minor, they impact Ethereum compatibility. Altering data structures could render Ethereum dApps incompatible with a Type 2 ZK-EVM, particularly when verifying Merkle proofs of historical Ethereum blocks for claims about past transactions, receipts, or state (as seen in bridges, for instance).
Removing ZK-unfriendly Elements
The modifications made to Ethereum aim to streamline development and boost proof generation speed. The goal is to trim parts of Ethereum that rely on ZK-unfriendly cryptography. In more technical terms, it’s those demanding numerous gates (addition and multiplication operations) due to non-native fields (e.g. hash functions); a large amount of multiscalar multiplications and/or FFTs; or just a large number of required operations.
Specific Examples of ZK-unfriendly Elements Type 2 ZK-EVM Might Modify
Hash function: While Ethereum employs the Keccak hash function, many ZK-EVMs utilize the Poseidon hash function, which requires significantly fewer gates.
For example, let’s estimate how many hash functions of each type can be calculated per second (i.e. proof generation speed comparison).
The Poseidon hash function holds a significant speed advantage in proof generation.
However, it’s important to note that newer cryptography primitives are less preferred than established ones endorsed by a broad community across industries. While Poseidon may offer speed, the battle-tested nature of Keccak makes it more robust and secure, given its widespread adoption.
That is why, Keccak, despite being older and a standard adopted by a wider community (also in other industries, e.g. for sensors in security systems or smart devices), can be considered more battle tested and therefore more robust and secure than Poseidon, a new hash function created and used within the ZK community.
State tree for data storage: For instance, while Ethereum employs Merkle Patricia Trees (using Keccak hash), some Type 2 ZK-EVMs opt for Sparse Merkle Trees (using Poseidon hash). Changing the state tree might result in some incompatibilities. For example, the Ethereum Merkle tree has different node types and encodes the data using RLP which is a difficult thing to do in ZK.
Block structure: Blocks contain a lot of information. However, when exploring L2s, we care only about execution_payload_header (i.e. block hash). In the graph below, there is the structure of all data contained in the execution_payload_header (block hash).
Changing even one of these components breaks Ethereum equivalence
Type 2.5 ZK-EVM (EVM-equivalent, With Gas Cost Considerations)
A Type 2.5 ZK-EVM increases the gas cost of specific operations in the EVM that are difficult to prove with ZK technology.
Given Ethereum’s gas limit per block (30M gas), increasing gas cost per opcode leads to fewer opcodes per block. As a result, less complex opcodes can be included in one block. Less complex opcodes make their circuit smaller, and the proof is generated faster.
Gas is a measure of work.
Opcodes are priced in gas.
Opcode specifies the operation in a machine language instruction.
A program is a static list of opcodes. Program execution is execution trace.
Execution trace is a specific ordered list of opcodes executed for a program execution.
Parts That Are Hard to ZK-prove:
Keccak opcode and some other opcodes depending on Keccak.
Precompiles — functions accessible to the EVM. Some provide complex or mathematically sophisticated tasks such as cryptographic functions (e.g. blake2f or sha256). They are not executed inside the EVM. Instead, they are functions hardcoded in execution clients and are exposed to the EVM using a CALL to a special address.
Memory access: for example, increased memory slot size (e.g., while Ethereum uses byte-aligned memory, Polygon zkEVM uses 32 byte memory slots). To make this change possible, the internal logic of some opcodes (e.g. MLOAD) must be changed.
Storage (i.e. changing hash function or state tree as mentioned above).
Changing gas costs may reduce developer tooling compatibility and break some dApps. For instance, a smart contract that frequently executes an opcode with increased gas costs might exceed the block gas limit and be unable to execute.
Type 3 (Almost EVM-equivalent)
Type 3 ZK-EVMs omit ZK-unfriendly precompiles and potentially tweak memory and storage access.
dApps reliant on removed precompiles need rewriting. Differences in how Type 3 ZK-EVM and original EVM handle edge cases might entail dApp adjustments too in uncommon circumstances.
Type 4 (High-level-language equivalent)
Type 4 is already pretty far from EVM.
Smart contract source code written in a high-level language (e.g. Solidity, Zinc) is compiled into Intermediate Representation, generating opcodes for the ZK-friendly VM.
This approach avoids generating ZK-proofs for each EVM execution step, reducing prover work substantially.
Even though the contracts can be compiled, further work is needed if the dApps use EVM handwritten bytecode.
Type 4 ZK-EVMs also require their own developer tools (only those that work on the opcode level), such as debuggers and tracers.
In the ZK circuit proving the execution trace, constraints are implemented for each step, and the cost of each step is the sum of all opcodes. Therefore, Type 4 ZK-EVMs aim to use as few complex opcodes as possible to optimize efficiency.
On the positive note, custom opcodes (not covered by Ethereum) enable the implementation of new features not available on Ethereum by default. For example, multiple call execution for Account Abstraction features, or initiating smart-contract wallets using out-of-the-box solutions like Argent.
Summing Up the Taxonomy
Different ZK-EVM Types prioritize different goals and characteristics. Type 1 focuses on Ethereum equivalence, while Type 4 prioritizes efficient proof generation. Other types fall in between these extremes, and many Type 2 and 3 ZK-EVM protocols have announced their intentions to move towards Ethereum equivalence. This four-type taxonomy might not be the final state for ZK-rollups; further modifications could occur in the future. For example, some ZK-EVMs might become hybrid: Type 1 and 2 might develop Type 4 solutions (with the highest efficiency possible) and offer dApps both options, while Type 3 and 4 ZK-EVMs might add Ethereum-equivalent options.
Author Bio
Lisa Akselrod is a math-lover excited by building robust systems and in love with the Ethereum Infinite Garden culture.
Editor Bio
Hiro Kennelly is a writer, editor, and coordinator at BanklessDAO, an Associate at Bankless Consulting, and is now and forever a DAOpunk.
trewkat is a writer, editor, and designer at BanklessDAO. She’s interested in learning about web3, with a particular focus on how best to communicate this knowledge to others.
Designer Bio
Chameleon is a designer and creator in the web3 space.
BanklessDAO is an education and media engine dedicated to helping individuals achieve financial independence.
This post does not contain financial advice, only educational information. By reading this article, you agree and affirm the above, as well as that you are not being solicited to make a financial decision, and that you in no way are receiving any fiduciary projection, promise, or tacit inference of your ability to achieve financial gains.
Bankless Publishing is always accepting submissions for publication. We’d love to read your work, so please submit your article here!
