Vitalik Buterin explains one of the Ethereum technologies he likes the most

Ethereum co-creator Vitalik Buterin detailed in his personal blog the different types of ZK-EVM (zero-knowledge verification technique for Ethereum virtual machine used to run smart contracts) and their features. The main difference between the different ZK projects is the balance each makes between practicality and speed, says the developer.

Beyond their particularities, all ZKs share a goal, buterin says. This is to “use the ZK-SNARK technology to do cryptographic checks of transaction executions in Ethereum”, either on the main chain itself or in second layers, through rollups of zero knowledge (ZK). These are a type of scalability solution that bundles transactions and then mints them all together in the parent layer.

Next, we will list the different types of ZK projects that the Russian-Canadian developer differentiated. In addition, the main pros and cons of each will be included.

ZK type 1

The first type of ZK-EVM that Vitalik Buterin points out is the one “fully equivalent” with Ethereum. These “do not change any part of the system” to make it easier.

Its main advantage is compatibility, and projects of this type are necessary “to make Ethereum more scalable”. According to the Russian-Canadian expert, Type 1 ZKs are ideal for rollups because they allow them to use a large amount of infrastructure.

As for the disadvantages of these ZK projects, the most important is the time and resource demand for transaction verification. This is because, he explains, they aim to replicate the Ethereum network exactly, and so there is no way to “mitigate those inefficiencies.”

ZK type 2

The second type of ZK is that “fully equivalent to the Ethereum EVM”. That is, Although it is not fully compatible with Ethereum, it is compatible with the smart contracts created on this network..

They differ from the main layer of the network in the structure of the blocks, among other technical data. Basically, they make small modifications to Ethereum for applications to be able to confirm transactions more easily.

The weak point that Buterin detects in these ZKs is that they do not eliminate the slowness for the confirmation of operations in the EVMas well as “its inefficiency and hostility”.

There is a class of “intermediate” ZK (or 2.5, as Vitalik Buterin calls it) which is also equivalent with the EVM, except for gas costs). These have the advantage of improving commit times, but reduce compatibility and can “break some applications,” he explains.

ZK type 3

The third type of ZK that the etherean leader describes is one “partially equivalent with the EVM”. These ZKs make “a few sacrifices” to improve test times and development possibilities.

The downside of these ZK projects, of which Polygon is an exponent, is that their app compatibility is less. This happens because many use resources (such as precompiles) that ZK type 3 removes.

Ultimately, Buterin asserts that no ZK-EVM development team intends to create a type 3 project, rather it is a transition stage until they manage to complete their step towards type 2.5. However, in the future, several type 1 and 2 ZKs could “voluntarily” become type 3 to optimize their operation in terms of delays and costs, he clarifies.

ZK type 4

This last category includes those ZK that are equivalent to Ethereum in its high level language. These ZKs “take smart contract source code written in a high-level language, such as Solidity or Vyper, and pass it into a language explicitly designed to be compatible with ZK-SNARK.”

The positive result of this process is that very fast test times are achieved. Such efficiency is achieved by skipping certain steps of the ZK check from different steps of the execution in the EVM and starting “directly with the high-level code”. This is a big step towards cost reduction and decentralization, says Buterin.

Its disadvantages, meanwhile, have to do with the incompatibility of certain applications due to differences in their smart contracts, greater difficulty in the use of certain bytecodes in the EVM and fewer options in terms of “debugging” or fault correction. In short, compatibility is significantly reduced.

The future of the ZK

To end his article, Buterin assures that no ZK is better or worse than other types. They are different, she explains, and it all has to do with the balance mentioned earlier.

Likewise, it is possible for a ZK project to start out low numbered (more compatible but less efficient) and eventually become high numbered (more efficient but less compatible). “Personally, my wish is for everyone to become type 1 one day, through a combination of improvements to the ZK-EVMs and to Ethereum itself,” the developer concludes, further clarifying that “it will take time to get to that future.”

See also  Ethereum 2.0 merger was successful in a second testnet

Leave a Comment

Your email address will not be published.