Ethereum (ETH): Vitalik explains ZK-EVMs

Ethereum (ETH): Vitalik explains ZK-EVMs

ZK-EVMs are protocols used by Layer 2 networks to increase scalability on Ethereum (ETH). In practice, they enable the creation of Zero-Knowledge rolls to aggregate transaction validation across the network without exposing sensitive information. By doing so, they ensure faster and cheaper operation of Ethereum Apps while maintaining decentralization and security.

Polygon, zkSync, Scroll and Matter Labs are competing for a monopoly in this market. Currently, the question is who will offer the most attractive performance and compatibility with the Ethereum Virtual Machine (EVM). In this context of frenzy, Vitalik Buterin, the founder of Ethereum, published an article that establishes the typology of existing solutions and their specificities. He recognized five.

Type 1 – completely identical to Ethereum

ZK-EVMs Type 1 have the distinction of offering full equivalence to the EVM. That said, they accept Ethereum as a whole. Their operation is based on the desire to facilitate the creation of proofs on the network, without modifying the properties of its execution layer.

Clearly, Type 1 ZK-EVMs have the potential to drive scalability on Ethereum. In fact, they offer many advantages, especially the possibility for rollups take advantage of the majority of network infrastructure and tools (runtime clients, block explorers, etc.).

However, Ethereum was not originally designed to integrate Zero-Knowledge (ZK) protocols. This explains why, at present, the production of ZK proofs requires a lot of time and calculations on the network side. Also, since the ZK-EVM was developed based on Ethereum, it will be difficult to fill those gaps, at least in the short term.

Type 2 – completely identical to EVM

The type 2 ZK-EVM is partially compatible with Ethereum but in perfect equivalence with the EVM. Specifically, it has the same intrinsic characteristics as Ethereum, with key differences in terms of data structure. This is done to ensure full consistency with the applications in use, and to adapt the system slightly to reduce block verification time.

Additionally, unlike type 1 protocols, ZK-EVM type 2 limits the use of certain Ethereum-specific execution resources. On the other hand, the other aspects of the network architecture are still accessible. In addition, this model offers reduced proof generation times compared to the previous one. That said, there is still a certain heaviness in the execution.

Type 2.5 – EVM equivalent, excluding gas charges

Inspired by the ZK-EVM type 2, this typology is intended to solve the curse problem. It consists of defining certain constraints to optimize the proof generation process.

One solution is to significantly increase gas fees for high-complexity transactions. This may affect the performance of certain applications. However, this approach has limited risks. However, in order to ensure a certain consistency, certain rules must be observed. Among these is the fact that developers should not charge higher fees for a transaction than what is in a block.

The second method is to limit the number of requests allowed for each transaction. Although simple to implement, the effectiveness of this technique is greatly reduced by the security requirements of the EVM.

Type 3 – almost identical to EVM

ZK-EVM type 3 protocols correspond to a partially equivalent model to the EVM. On the other hand, they bring relatively small changes (hash function, memory management, elimination of pre-compilation, etc.) that have consequences on the application layer.

However, they offer many advantages. Especially the ease of developing Ethereum DApps, compatibility with most applications and shorter deadlines.

The problem is that the changes made can cause some applications to malfunction. This phenomenon can be explained by a dependence on an inactive process or the need for complete equivalence with the EVM.

Type 4 – equivalent to high-level languages

ZK-EVM type 4 protocols have the ability to directly compile the source code of applications written with high-level languages ​​(Solidity, Vyper, etc.) to obtain an intelligible script for the EVM. That said, they are not compatible with many Ethereum applications and do not allow the use of network infrastructure. However, they greatly reduce the times and costs involved in creating proofs. In addition, this approach promotes decentralization by reducing the work of the validator.

“Personally, I hope everything becomes Type 1 over time. […] However, it will be some time before we reach such a future.”Vitalik Buterin concludes.

At this stage, it is difficult to comment on the relevance of one or the other of these approaches. Above all, it is necessary to determine the extent to which one is ready to settle for speed and compatibility with the Ethereum infrastructure. Interestingly, protocols can change from one type to another depending on the needs they want to meet.

Get a summary of news in the world of cryptocurrencies by subscribing to our new daily and weekly newsletter service so you don’t miss any of the essential Cointribune!

Junie Maffock avatar


I came to blockchain out of curiosity and stayed with it out of passion. I was amazed by the possibilities it offers through its various use cases. With my pen, I hope to help democratize this technology and show how it can help make the world a better place.


Dogecoin disclaims any connection with the Dogechain project

NFL team accepts bitcoin to buy tickets

NFL team accepts bitcoin to buy tickets