ZK-EVMs are protocols used by Level 2 networks to increase scalability on Ethereum (ETH). In practice, they allow the creation of Zero-Knowledge rollups to aggregate the validation of transactions on the network without disclosing sensitive information. By doing so, they ensure faster and cheaper exploitation of Ethereum dApps while preserving decentralization and security.
Polygon Hermez, zkSync and Scroll are competing for a monopoly on this market. Currently, the question is who will offer the most attractive offer between performance and compatibility with the Ethereum Virtual Machine (EVM). In this context of frenzy, Vitalik Buterin, the founder of Ethereum, published a article which establishes a typology of existing solutions and their specificities. He identified five of them.
Type 1 – fully equivalent to Ethereum
The type 1 ZK-EVMs have the particularity of offering an absolute equivalence with the EVM. That said, they are espousing Ethereum in its entirety. Their operation is based on the desire to facilitate the generation of evidence on the network, without changing the properties of its execution layer.
Obviously, Type 1 ZK-EVMs are likely to stimulate the rise in Ethereum. Indeed, they offer many advantages, including the possibility for rollups to exploit the majority of the network’s infrastructure and tools (execution clients, block explorers, etc.).
However, at its core, Ethereum was not designed to integrate Zero-Knowledge (ZK) protocols. This explains why, currently, the production of ZK proofs requires a lot of time and calculations on the part of the network. Moreover, since the ZK-EVM was developed based on Ethereum, it will be difficult to fill these gaps, at least in the short term.
A challenge that Privacy and Scaling Explorations, an organization from the Ethereum community, decided to take up. Indeed, the members of this association work currently working on the creation of a type 1 ZK-EVM.
Type 2 – fully equivalent to an EVM
The ZK-EVM type 2 are partially compatible with Ethereum but in perfect equivalence with the EVM. More precisely, it has the same intrinsic characteristics as Ethereum, with main differences at the level of data structures. The aim here is to ensure maximum consistency with the applications in use, while slightly adapting the system to reduce the block verification time.
Moreover, unlike type 1 protocols, Type 2 ZK-EVMs limit the use of certain execution resources specific to Ethereum. On the other hand, the other aspects of the network architecture remain accessible. In addition, this model offers reduced proof generation times compared to the previous one. That said, there remains a certain heaviness in the execution.
The ZK-EVMs of Scroll and Polygon Hermez tend to become type 2 ZK-EVMs. However, this orientation has not yet fully materialized.
Type 2.5 – EVM equivalent, except for gas costs
Inspired by the ZK-EVM type 2, this typology is intended to solve the problem of slowness. It consists in defining certain restrictions to optimize the process of generating evidence.
One solution is to increase the gas fees for high-complexity transactions. This may possibly compromise the operation of some applications. However, this approach has limited risks. Nevertheless, to ensure a certain consistency, certain rules must be observed. This is, among other things, the fact that developers should never claim higher fees for a transaction than what is in a block.
The second method is to impose a cap on the number of requests allowed for each transaction. Although simple to implement, the effectiveness of this technique is greatly reduced by the safety requirements of the EVM.
Type 3 – almost equivalent to the EVM
The ZK-EVM type 3 protocols correspond to a model in partial equivalence with the EVM. On the other hand, they make relatively minor changes (hash function, memory management, removal of pre-compilation, etc.) that have repercussions on the application layer.
They still offer many advantages. In particular, the ease of developing Ethereum dApps, compatibility with the majority of applications and shorter lead times.
The problem is that the changes made can cause some applications to malfunction. This phenomenon can be explained by the removal of pre-compilations as well as by subtle dependencies concerning extreme cases of different processing of virtual machines.
Scroll and Polygon Hermez currently offer Type 3 ZK-EVMs. A model that they plan to abandon in favor of Type 2.
Type 4 – equivalent to high-level languages
The ZK-EVM Type 4 protocols have the ability to directly compile the source code of applications written with high-level languages (Solidity, Vyper, etc.) in order to obtain an intelligible script for the EVM. That said, they are not compatible with a good part of Ethereum applications and do not allow using the network infrastructure. However, they significantly reduce the time and cost of generating evidence. In addition, this approach contributes to decentralization by lightening the validator’s work. To date, ZKSync is a Type 4 system, which should soon be the case for StarkNet too.
At this stage, it is difficult to decide on the relevance of either of these approaches. First of all, it is necessary to determine to what extent we are ready to reconcile speed and compatibility with the Ethereum infrastructure. “Personally, I hope that everything will become Type 1 over time. […] However, it will be some time before we come to such a future”, concludes Vitalik Buterin. Interestingly, protocols may have to evolve from one type to another depending on the needs they wish to meet.
Receive a digest of the news in the world of cryptocurrencies by subscribing to our new daily and weekly newsletter service so you don’t miss anything essential Cointribune!
I came to blockchain out of curiosity and I stayed there 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.
