What are different types of zkEVMs? Why you should care about zkEVM?

Table of Contents

We already discussed the definition of zkEVMs, how it works and named some leaders in the battle for zkEVMs. In this article, we will dive a little deeper into different types of zkEVMs and why you should care about them.

Different types of zkEVMs

There are different types of zkEVMs sharing the same goals but different in approach. Vitalik Buterin, the Ethereum founder, has grouped zkEVMs into four types and a fifth. Here is a summary chart of the types of zkEVMs:

zkEVM types comparison by Vitalik (Source)

Type-1 zkEVMs: fully equivalent to Ethereum

zkEVM Types-1s have no modifications made to their state or transaction trees, hash codes, or any other part of their consensus algorithm, Type-1s are anticipated to be totally equivalent to Ethereum. All Ethereum-native applications will run flawlessly with Type-1 zkEVMs, but they will take more prover time because no special rewriting is done to speed up proof production.

Type-2 zkEVMs: EVM (not Ethereum) equivalence

Type-2 zkEVMs will aim for EVM-equivalence rather than Ethereum-equivalence, lowering the bar a little. On the appearance, zkEVM Type-2s would resemble Ethereum, but they would internally differ slightly in order to promote development and accelerate proof creation.

Some applications in these rollups might not be compatible with one another. Slower prover times will nonetheless be an issue for type-2 zkEVMs. Therefore, Type-2.5 zkEVMs could reduce prover time by raising gas prices.

Type-3 zkEVMs: departing from EVM

Given that this type promotes the simplicity of integrating an EVM-like system into ZK-rollups, zkEVM Type-3s would not be entirely EVM-equivalent. This entails precise adjustments that will simplify building and enhance proof generating. Although Type-3 zkEVMs might work with most programs, some of them might need to be rewritten.

Type-4 zkEVMs: Relatives of the EVM

Only high-level languages, not the EVM itself, would be comparable to zkEVM Type-4s. Therefore, avoiding the need for zero-knowledge proofs for each phase of EVM execution will save costs, promote decentralization, and speed up proof generation.

Nevertheless, this would reduce the compatibility of Type-4 zkEVMs with a number of applications. When transferring apps to the EVM, contract addresses will probably change, making it hard to transfer multiple debugging infrastructures.

In the future, Ethereum will experience modifications that will make it more Zk-SNARK friendly. The categorization approach above is not absolute because any zkEVM that fits into either of these categories will probably be upgraded by these improvements. This only serves as a method to reflect the practical differences of real-world products into an understandable framework, as Buterin states.

The architecture of zkEVM

A proving circuit, a verifier contract, and an execution environment make up the zkEVM. Each component facilitates the zkEVM’s program execution, proof generation, and proofs confirmation.

The execution environment

The execution environment is where zkEVM programs (smart contracts) operate. The zkEVM's execution environment works similarly to the EVM in that it inputs the initial state and current transaction to output a new (final) state.

The proving circuit

The zero-knowledge proofs generated by the proving circuit serve to confirm the accuracy of the transactions computed in the execution environment. The pre-state, transaction inputs, and post-state data are used as inputs to complete the proof creation process. The prover then receives a clear demonstration of the validity of that specific state transition.

An illustration of how the zkEVM produces program validity proofs (Source)

The verifier contract

ZK-rollups send verification requests for their validity proofs to a smart contract running on the Ethereum L1 chain. The verifier contract also receives the input (pre-states and transaction information) and output (final states). The verifier then performs computation on the proof that has been supplied and verifies that the outputs that have been delivered were appropriately computed from the inputs.

What are the difficulties of building a zkEVM?

The EVM was designed without consideration for zk-proof computing, and as a result, it has features that make it difficult for proving circuits. Here is a quick rundown of the four issues that make creating zkEVMs challenging:

Special opcodes

The EVM, in contrast to a standard VM, uses unique opcodes for a variety of tasks, including the execution of programs (CALL, DELEGATECALL) and error management (REVERT, INVALID). The process of developing the proving circuit for EVM operations becomes more difficult as a result.

Stack-based architectures

The stack-based architecture of the EVM makes computation proof more challenging, although being simpler than a register-based structure. This is why most of the zero-knowledge virtual machines employ a register-based model.

Storage overhead

The storage architecture of the EVM uses a Merkle Patricia Trie and Keccak hashing functions, both of which have a significant proving overhead. Some zkVMs, like ZkSync, make an effort to avoid this issue by swapping out the KECCAK256 function, however doing so may cause issues with the existing Ethereum tooling and infrastructure.

Proving costs

Even if all the issues mentioned above are resolved, the proof-generation process still needs to be considered. Specialized hardware, as well as a significant time, money, and effort investment, are needed to generate zero-knowledge proofs.

Why should you care about zkEVM?

Secure Scalability

The Ethereum Virtual Machine's computations must be repeated by all validating nodes in accordance with protocol requirements. This method assures security because Ethereum nodes can independently check that programs are proper, but it has scalability restrictions because the Ethereum network can only handle about 15-20 transactions.

Ethereum's throughput problems can be resolved via EVM- compatible ZK-rollups without sacrificing network security. ZK-rollups can be optimized for execution speed and are not constrained by Ethereum's consensus protocol, unlike other scaling protocols. ZK-rollups, according to some estimations, can process around 2000 transactions per second without paying Ethereum's hefty fees.

Lower costs

By publishing transaction data to Ethereum as CALLDATA, rollups obtain security from the Mainnet of Ethereum. The amount of data that optimistic rollups and ZK-rollups must post on Ethereum, however, varies.

Optimistic rollups must disclose all transaction-related data on-chain since they cannot prove the authenticity of off-chain transactions. By not putting all data on-chain, challengers cannot create fraud proofs required to contest invalid rollup transactions.

In contrast, ZK-rollups may afford to only post a small amount of information to Ethereum because validity proofs already provide assurance that state transitions are reliable. The zkEVM may even skip transaction inputs and publish only final state changes, which lowers the need for CALLDATA.

Faster finality and greater capital efficiency

While providing better security, ZK-rollups also have an edge over optimistic rollups, which is faster finality. Blockchain finality refers to the period of time it takes for a transaction to become irreversible; a transaction can only be finalized if network users can independently verify its authenticity.

Transactions carried out in the zkEVM with ZK-rollups are frequently processed right away after being uploaded on Ethereum. Since each batch of transactions includes a proof that can be instantaneously verified, state updates can be applied to the main Ethereum chain immediately.

Conversely, optimistic rollups only push VM transactions without proofs, the challenge period must pass before transactions reach the finality. After a transaction is published to Ethereum, there is a time window of one to two weeks known as the challenge period during which anyone may contest the transaction.

The slower finality can significantly harm the user experience. For instance, until the delay period has passed, users cannot remove assets from the rollup. In case the withdrawal involves high-value assets or NFTs, even liquidity providers might not be able to remedy the issue.

All of those issues are not present in a zkEVM. Power users who require smooth asset transferring, such as NFT traders, DeFi investors, or arbitrage traders, will benefit from faster finality (especially between L1 and L2).

Network effects

Utilizing Ethereum's network effects is the main motivation for creating EVM-compatible zkVMs. Being the largest smart contract platform in the world, Ethereum offers a sizable ecosystem that benefits both developers and projects.

For instance, developers have access to a wealth of tooling, documentation, and code libraries that have been rigorously tested and verified. The network effects of Ethereum cannot be utilized by projects or development teams if a new zkVM is built that is incompatible with Ethereum's infrastructure.

About Orochi Network

Orochi Network is a cutting-edge zkOS (An operating system based on zero-knowledge proof) designed to tackle the challenges of computation limitation, data correctness, and data availability in the Web3 industry. With the well-rounded solutions for Web3 Applications, Orochi Network omits the current performance-related barriers and makes ways for more comprehensive dApps hence, becoming the backbone of Web3's infrastructure landscape.

Blog