Understanding ZK-EVM Types | Layer 2 Review

Quick Reads and Hot Links Covering the People and Projects Who Are Scaling Ethereum

Sep 28, 2023

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 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 Polling Station! 🗳️

In addition to ZK-EVM upskilling, this issue is packed with our regular sections, including Governance, Data, Project Watch, and Ecosystem Updates. 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. ❤️

Contributors: Warrior, Chameleon, Boluwatife, jengajojo, Lisa Akselrod, thinkDecade, trewkat, HiroKennelly

This is an official newsletter of BanklessDAO. To unsubscribe, edit your settings.

✅ Action Items

🏃‍♀️ Catch up on Ecosystem Updates at the end of the newsletter!

🗳️ Vote to decide whether Arbitrum becomes an official sponsor of Ethereum Mexico 2023.

🌶️ Spicy Takes

From the OP Forum:

SEED Latam | Regarding the selection of the new badgeholders for our members

🔥 Hot News

Arbitrum Odyssey is Back

After an abrupt halt 16 months ago, Arbitrum has 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 get the bonus, your chosen delegate may not have been active enough and it’s time to rethink your delegation.

Optimism Opens RetroPGF 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.”

There’s been little activity on the post to date, but it’s worth your attention.

💬 Proposals in Discussion

Arbitrum

Optimism

Polygon

Starknet

Analyzing StarkNet’s Adoption Lag Compared to Other L2 Solutions: Why and How to Drive Adoption?

🗳️ Polling Station

🪂 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

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.

This article was first published on the Bankless Publishing website.