Vitalik just lately had a really informative speak about zkEVMs, their differing types, and their relationship with Ethereum as a complete but I haven’t seen anybody right here speak about it (hyperlink me to a put up if I’m fallacious, I’d recognize an excellent learn)
This is perhaps simply me, however I really feel like not many right here nonetheless totally perceive zkEVM and their totally different sort so let’s speak a bit about it, particularly from Vitalik’s viewpoint
To begin with, let’s deal with the various kinds of zkEVMs with their execs and cons:
– Sort 1 (totally Ethereum-equivalent):
Sort 1 ZK-EVMs attempt to be totally and uncompromisingly Ethereum-equivalent.
Devs don’t should double-check the code once they migrate contracts. They will actually simply copy paste
Firstly, this creates a form of laziness for devs as a result of no matter whether or not there’s 100% equivalence or not, an excellent dev ought to all the time double-check their work
The second and extra vital drawback is that this can be very gradual in comparison with different sorts of zkEVMs. “Ethereum was not initially designed round ZK-friendliness, so there are various elements of the Ethereum protocol that take a considerable amount of computation to ZK-prove. Sort 1 goals to copy Ethereum precisely, and so it has no approach of mitigating these inefficiencies” Vitalik concluded.
– Sort 2 (totally EVM-equivalent):
“Sort 2 ZK-EVMs attempt to be precisely EVM-equivalent, however not fairly “Ethereum-equivalent” Vitalik stated. This mainly implies that from a developer’s viewpoint, a Sort 2 zkEVM seems and acts precisely like Ethereum however with underlying minuet modifications. These modifications are there to make the event course of a lot simpler and very sooner than what Sort 1 zkEVM would provide.
That is the principle distinction. It mainly there to unravel the principle challenge of Ethereum being gradual and inefficient however not altering the Ethereum code (at the very least not solely)
Some folks would argue in opposition to this as they assume that solely equivalence is the best technique to migrate good contracts however as of now, the Ethereum roadmap is concentrated on these sort 2 zkEVMs as a result of they arrive very near whole equivalence (but not utterly 100%)
One of many main names to say who’s growing this kind 2 zkEVM proper is Polygon.
What I like about their zkEVM is that not like others it’s at Bytecode-level. To shorten this and never get too technical, a Bytecode-level zkEVM goals to interpret EVM Bytecode. Polygon Hermez is at present bytecode equal. They run stated bytecode a customized zkASM of their very own. This permits direct compatibility with already current dApps. These dApps ought to be capable to run with none form of downside since they’re utterly bytecode equal (not Ethereum equal although). This may be further work for the nodes to place in to validate and write the block that is not equal however it actually shouldn’t be an issue.
Scroll and Consensys are additionally engaged on Bytecode equal zkEVMs nonetheless they’re nonetheless a piece in progress (so is Hermez however it’s nearly achieved 60% by means of).
One of these zkEVM is way sooner than the primary sort we talked about. It’s greater than 99% equal to Ethereum so its protected to say that they’re nearly (however not solely) the identical which might make issues a lot simpler for devs to work with in comparison with the following sorts that I’ll speak about in a bit
Bear in mind how I stated that this kind is greater than 99% appropriate with Ethereum? Nicely, that further 1% is modifications which are there to enhance prover time.
The principle disadvantage nonetheless is that whereas these modifications do certainly enhance stated prover time, in addition they don’t resolve each downside. The slowness from having to show the EVM as-is, with all the inefficiencies and ZK-unfriendliness inherent to the EVM, nonetheless stays.
– Sort 3 (nearly EVM-equivalent):
This sort is similar to the beforehand talked about sort 2 nonetheless it sacrifices much more equivalence with a view to enhance prover instances much more
Quicker than the beforehand talked about
A Sort 3 ZK-EVM goals to be appropriate with ***most*** purposes. They require very minimal rewriting for the remainder. Nonetheless, there’ll all the time be purposes that should be utterly rewritten.
– Sort 4 (high-level-language equal)
One of these EVM is arguably the most well-liked proper now with
What it mainly means is that it takes a high-level coding language (like Vyper or Solidity) and mainly transpile it all the way down to SNARK-friendly VM.
An in depth analogy could be discovering languages of comparable roots (Spanish and Portuguese) and translating one to a different.
A number of the main names that use any such EVM are Zksync, Matterlabs, and Starkware.
Whereas these scaling options nonetheless use a kind 4 system, this doesn’t cease them from implementing EVM Bytecode sooner or later.
Extraordinarily quick prover instances.
“There’s numerous overhead which you could keep away from by not ZK-proving all of the totally different elements of every EVM execution step, and ranging from the higher-level code instantly” as Vitalik famous about any such EVM” as Vitalik commented
One of these EVM can’t compile down all kinds of purposes. Which means that builders must rewrite A LOT of good contracts and code them again from scratch.
And that will be all! I actually assume that the Ethereum group needs to be as educated as doable about this matter as a result of as I discussed in my earlier posts on this sub, the Ethereum blockchain itself won’t ever be low-cost and won’t scale by itself. The way forward for Ethereum is in L2s and rollups and extra particularly zero-knowledge rollups.
