Tier 2 networks use ZK-EVM protocols to make Ethereum more scalable (ETH). They really make it possible to build Zero-Knowledge rollups that aggregate transaction validation throughout the network without revealing private data. They achieve speedier and less expensive functioning of Ethereum dApps while preserving decentralization and security by doing this.
In this market, Polygon, zkSync, Scroll, and Matter Labs are vying for a monopoly. Who will provide the most alluring offer between performance and compatibility with the Ethereum Virtual Machine is the current debate (EVM). The creator of Ethereum, Vitalik Buterin, released a piece in this frenzy-filled environment that develops a typology of existing solutions and their unique characteristics. He pointed out five.
An explainer of the different types of ZK-EVMs and ZK-EVM-like projects out there, and the tradeoffs between them.https://t.co/HAYpNfCHRH
— vitalik.eth (@VitalikButerin) August 4, 2022
Type 1 – exactly comparable to Ethereum
The unique feature of Type 1 ZK-EVMs is that they provide complete equivalence to the EVM. They support Ethereum in its totality, despite this. Their operation is motivated by the aim to speed up proof generation on the network while maintaining the execution layer’s functionality.
Undoubtedly, Type 1 ZK-EVMs will contribute to Ethereum’s scalability. Indeed, they provide a number of benefits, such as the ability for rollups to utilize the bulk of network resources and tools (runtime clients, block explorers, etc.).
However, incorporating Zero-Knowledge (ZK) protocols was not part of the original plan for Ethereum. This explains why the network now needs to spend a lot of time and energy performing calculations in order to provide ZK proofs. Additionally, since the ZK-EVM was built on the Ethereum platform, it will be challenging to close these gaps in the near future.
Type 2 – completely comparable to an EVM
The ZK-EVM type 2 is perfectly equivalent to the EVM and only partially compatible with Ethereum. It shares many intrinsic properties with Ethereum, with the key distinctions being in the data structures, to be more precise. In addition to slightly modifying the system to speed up block verification, this is done to assure complete consistency with the apps now in use.
Type 2 ZK-EVMs further restrict the use of certain Ethereum execution resources, in contrast to type 1 protocols. The other components of the network design, however, are still reachable. Additionally, compared to the prior model, this one offers faster evidence creation times. Nevertheless, there is still some weight in the execution.
Type 2.5 – equal to an EVM, except gas charges
This typology, which was inspired by the ZK-EVM type 2, aims to address the issue of slowness. To optimize the evidence generating process, it entails specifying a few limits.
One solution is to drastically raise gas prices for transactions with high levels of complexity. It’s possible that this will make some applications less functional. This strategy, though, poses few dangers. But there are some principles that must be followed in order to guarantee some consistency. One of them is that developers shouldn’t charge more for a transaction than what is included in a block in terms of fees.
The second strategy is to set a limit on the total number of requests that can be made for a single transaction. The security requirements of the EVM significantly decrease this technique’s usefulness even though it is easy to implement.
Type 3 – nearly identical to an EVM
The ZK-EVM type 3 protocols are analogous to an EVM and EVM partial equivalence model. The application layer is affected by very minor changes they introduce, however, such as memory management, the elimination of pre-compilation, and hash function.
They do, however, have a lot of benefits. The simplicity of creating Ethereum DApps, compatibility with the majority of applications, and lower deadlines stand out in particular.
The issue is that some applications may stop working as a result of the changes made. The need for complete equivalence with the EVM or dependence on an inactive process can both be used to explain this situation.
Type 4, which is comparable to high level languages
In order to provide an understandable script for the EVM, ZK-EVM type 4 protocols have the ability to immediately compile the source code of applications created in high-level languages (such as Solidity, Vyper, etc.). However, they do not support the utilization of network infrastructure and are incompatible with a large number of Ethereum applications. However, they significantly cut the time and expense associated with evidence generation. Additionally, by lessening the labor required of the validator, this strategy promotes decentralization.
“I personally want everything to eventually become Type 1. […] But until we reach such a future, it will take some time,” Vitalik Buterin adds.
It is challenging to remark at this point on the applicability of either one of these approaches. Above all, one must decide how much they are willing to compromise between performance and compliance with the Ethereum infrastructure. It’s interesting to note that protocols can change from one type to another to accommodate different needs.
. They really make it possible to build Zero-Knowledge...){kind=link}