Layer 2 Review Issue #5
Understanding ZK-EVM Types | Layer 2 Review
Quick Reads and Hot Links Covering the People and Projects Who Are Scaling Ethereum
Dear Frens,
In recent months we’ve been working in BanklessDAO to fulfill our obligations as part of Optimism’s Collective Intent 3: Spread Awareness of the Optimistic Vision. To celebrate, we shipped eight of our Optimism-focused articles on BanklessDAO’s Mirror page. These articles are available as free, open-edition, digital collectibles, helping you to curate writings on one of the most impactful ecosystems in web3.
Even before that Mission, we’d written a lot about Optimism, and it’s time to turn our attention to different scaling solutions. Last week, Bankless Publishing shipped an article entitled Understanding ZK-EVM Types, and it’s gone a bit crypto viral, with more than 163 (update) likes. Given the demand for this knowledge, we’re going to ship the same article in this newsletter too. If you want more of this type of easy-to-understand technical content, please let us know in this issue’s Poll Station 🗳️!
In addition to ZK-EVM upskilling, this issue is packed with our regular sections, including Governance, Airdrop Station, Data, Project Watch, and Ecosystems update. We’re aiming to make this newsletter your fortnightly source for L2 news and trends. If you have any hot tips or just want to let us know how we’re doing, please DM Bankless Publishing on X. Thank you for being on this journey with us. ❤️
[subscribe button]
✅ Action Items
🏃♀️ Catch up
🌶️ Spicy Takes
From the OP Forum:
🔥 Hot News
Arbitrum Odyssey is Back
After an abrupt halt 16 months ago, Arbitrum announced that Odyssey is back! There are seven weeks of questing, with many hoping that there is a pot of ARB at the end of the journey. Good luck frens, and happy adventuring!
Arbitrum Claws Back Tokens for DAO Treasury
Also in Arbitrum news, nearly 70M unclaimed ARB tokens were clawed back by the ArbitrumDAO. Not to throw shade on Arbitrum, but there are other ways to get tokens to users.
Optimism Disburses Unclaimed Tokens to Wallets
Optimism sent unclaimed funds from Airdrop #1 directly to wallets who were eligible to receive that airdrop. Check your wallets frens, and take note Aribitrum!
Optimism Airdrop #3!
Also in airdrop news, Optimism sent Airdrop #3 directly to wallets so there are no scammy links to click or confusing claims processes.
In Airdrop #3 Optimism rewarded the practice of delegating tokens to active delegates, so if you delegated but did not receive the drop, your chosen delegate may not have been active enough!!!
Optimism Opens RPGF 3 Application Portal
In other exciting Optimism news, applications are open for RetroPGF 3, with 30M OP tokens allocated for distribution. The Round 3 application window will close on October 23, 2023.
🏛 Governance
🗳️ On Snapshot
Arbitrum as Official Sponsor of Ethereum Mexico 2023
From the proposal: “Ethereum Mexico is a driving force for Ethereum growth in Mexico, educating individuals on blockchain technology and promoting Ethereum values. Serving as a link between the Ethereum community, the Ethereum Foundation, and Mexico’s local communities.
Our organization offers IRL Meetups, Twitter Spaces, Workshops, and educational content. One of their major 2023 initiatives is a large event in Mexico City, set for October 21st, expecting over 800 attendees. This event aims to foster education and innovation within the Ethereum community.”
⭐ Featured Proposals
PIP-18: Polygon 2.0 Phase 0 — Frontier
From the proposal, in relevant parts: “This proposal specifies Phase 0 of Polygon 2.0, a multi-phased upgrade to the Polygon Ecosystem.
Polygon 2.0 envisions a network of interconnected ZK-powered L2 chains that, on aggregate, expand Ethereum blockspace and create the Value Layer of the Internet. This environment is seamlessly interoperable, offering access to unified blockspace across all Polygon chains as well as infinite scalability.
The end goal is to extend Ethereum blockspace in a fashion that more resembles a mesh network topology like the internet. With ZK technology, Ethereum blockspace can scale to the size of the Internet for the first time in blockchain history.
This proposal represents the next step in this journey, defining the initial tasks to bring the Polygon 2.0 vision to life.”
💬 Proposals in Discussion
Arbitrum
Optimism
Polygon
Starknet
🗳️ Polling Station
Drop Substack poll
How should we use our editorial space in the Layer 2 Review?
- Covering emerging L2 narratives
- Making the tech easy-to-understand
- In-depth coverage of a particular L2
Most Important Consideration When Using an L2?
- Tech (speed, security, cost)
- Ethos
- Offramping time
- dApp Availability
🪂 Airdrop Station
📈 Data
Total Value Locked on L2s Surpasses $10 Billion Again!
Top Ten Projects by Total Value Locked:
🔭 Project Watch
Arbitrum
Top Projects by TVL in the Last 7 Days
Trending NFT Collections
Optimism
Top Projects by TVL in the Last 7 Day
Top/trending NFT Collections
Source: https://zapper.xyz/nft/optimism
Top Projects by Interaction
zkSync
Top Projects by TVL in the Last 7 Days
zkEVM
Top Projects by TVL in the Last 7 Days
Understanding ZK-EVM Types
Author: Lisa Akselrod
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 Buterin 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 — Vitalik Buterin
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
Type 2 removes some ZK-unfriendly parts to make proof generation faster and circuit development easier. However, as a consequence of the latter, it might make the development of other parts of the ZK-rollup (e.g. node software) more complicated. These complications may arise because of established best practices and testing tools that might be incompatible with the implemented changes (e.g. changed state tree).
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.
The following are 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.
🔥 L2 Fees and Costs Update
Transaction Fees as of September 27, 2023:
Security Costs as of September 27, 2023:
🗞️ Ecosystem Updates