ZK-EVMs are protocols used by Tier 2 networks to increase scalability on Ethereum (ETH). In practice, they enable the creation of Zero-Knowledge rollups to aggregate transaction validation across the network without disclosing sensitive information. By doing so, they ensure faster and cheaper operation of Ethereum dApps 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 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.
Type 1 – fully equivalent to Ethereum
Type 1 ZK-EVMs have the particularity of offering absolute equivalence with the EVM. That said, they espouse Ethereum in its entirety. Their operation is based on the desire to facilitate the generation of proofs on the network, without modifying the properties of its execution layer.
Clearly, Type 1 ZK-EVMs are likely to drive scalability on Ethereum. Indeed, they offer many advantages, in particular the possibility for rollups exploit 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, currently, the production of ZK proofs requires a lot of time and calculations on the part of the network. Also, since the ZK-EVM was developed based on Ethereum, it will be difficult to fill these gaps, at least in the short term.
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 specifically, it has the same intrinsic characteristics as Ethereum, with main differences in terms of data structures. This is to ensure total consistency with the applications in use, while slightly adapting the system to reduce block verification time.
In addition, 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.
Type 2.5 – EVM equivalent, except for gas charges
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 proof generation process.
One solution is to significantly increase gas fees for high complexity transactions. This may possibly compromise the functioning of certain applications. However, this approach has limited risks. Nevertheless, to ensure a certain consistency, certain rules must be respected. These include the fact that developers should not charge 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 security requirements of the EVM.
Type 3 – almost equivalent to EVM
The ZK-EVM type 3 protocols correspond to a model in partial equivalence with the EVM. On the other hand, they bring relatively minor changes (hash function, memory management, elimination of pre-compilation, etc.) which have repercussions on the application layer.
However, they offer many advantages. In particular the ease of developing Ethereum DApps, compatibility with the majority of applications and shorter deadlines.
The problem is that the changes made can cause some applications to malfunction. This phenomenon can be explained by the dependence on an inactive process or the need for total 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.) 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 the use of network infrastructure. However, they considerably reduce the times and costs of proof generation. In addition, this approach contributes to 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 get to such a future.”concludes Vitalik Buterin.
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 to what extent one is ready to reconcile speed and compatibility with the Ethereum infrastructure. Interestingly, protocols can evolve from one type to another depending on the needs they wish to meet.
Receive a digest 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 Tremplin.io!