Vitalik recently had a very informative talk about zkEVMs, their different types, and their relationship with Ethereum as a whole yet I haven’t seen anyone here talk about it (link me to a post if I’m wrong, I’d appreciate a good read)
This might be just me, but I feel like not many here still fully understand zkEVM and their different type so let’s talk a bit about it, especially from Vitalik’s point of view
First of all, let’s address the different types of zkEVMs with their pros and cons:
– Type 1 (fully Ethereum-equivalent):
Type 1 ZK-EVMs strive to be fully and uncompromisingly Ethereum-equivalent.
Devs don’t have to double-check the code when they migrate contracts. They can literally just copy paste
Firstly, this creates a sort of laziness for devs because regardless of whether there’s 100% equivalence or not, a good dev should always double-check their work
The second and more important disadvantage is that it is extremely slow compared to other types of zkEVMs. “Ethereum was not originally designed around ZK-friendliness, so there are many parts of the Ethereum protocol that take a large amount of computation to ZK-prove. Type 1 aims to replicate Ethereum exactly, and so it has no way of mitigating these inefficiencies” Vitalik concluded.
– Type 2 (fully EVM-equivalent):
“Type 2 ZK-EVMs strive to be exactly EVM-equivalent, but not quite “Ethereum-equivalent” Vitalik said. This basically means that from a developer’s point of view, a Type 2 zkEVM looks and acts exactly like Ethereum but with underlying minuet changes. These changes are there to make the development process much easier and extremely faster than what Type 1 zkEVM would offer.
This is the main difference. It basically there to solve the main issue of Ethereum being slow and inefficient but not altering the Ethereum code (at least not entirely)
Some people would argue against this as they think that only equivalence is the right way to migrate smart contracts but as of now, the Ethereum roadmap is focused on these type 2 zkEVMs because they come very close to total equivalence (yet not completely 100%)
One of the major names to mention who is developing this type 2 zkEVM right is Polygon.
What I like about their zkEVM is that unlike others it is at Bytecode-level. To shorten this and not get too technical, a Bytecode-level zkEVM aims to interpret EVM Bytecode. Polygon Hermez is currently bytecode equivalent. They run said bytecode a custom zkASM of their own. This enables direct compatibility with already existing dApps. Those dApps should be able to run without any sort of problem since they are completely bytecode equivalent (not Ethereum equivalent though). This would be extra work for the nodes to put in to validate and write the block that isn’t equivalent but it really shouldn’t be a problem.
Scroll and Consensys are also working on Bytecode equivalent zkEVMs however they’re still a work in progress (so is Hermez but it’s almost done 60% through).
This type of zkEVM is much faster than the first type we talked about. It is more than 99% equivalent to Ethereum so its safe to say that they are almost (but not entirely) the same which would make things much easier for devs to work with compared to the next types that I will talk about in a bit
Remember how I said that this type is more than 99% compatible with Ethereum? Well, that extra 1% is modifications that are there to improve prover time.
The main drawback however is that while these modifications do indeed improve said prover time, they also do not solve every problem. The slowness from having to prove the EVM as-is, with all of the inefficiencies and ZK-unfriendliness inherent to the EVM, still remains.
– Type 3 (almost EVM-equivalent):
This type is very similar to the previously mentioned type 2 however it sacrifices even more equivalence in order to improve prover times even more
Faster than the previously mentioned
A Type 3 ZK-EVM aims to be compatible with ***most*** applications. They require very minimal rewriting for the rest. However, there will always be applications that need to be completely rewritten.
– Type 4 (high-level-language equivalent)
This type of EVM is arguably the most popular right now with
What it basically means is that it takes a high-level coding language (like Vyper or Solidity) and basically transpile it down to SNARK-friendly VM.
A close analogy would be finding languages of similar roots (Spanish and Portuguese) and translating one to another.
Some of the major names that use this type of EVM are Zksync, Matterlabs, and Starkware.
While these scaling solutions still use a type 4 system, this doesn’t stop them from implementing EVM Bytecode in the future.
Extremely fast prover times.
“There is a lot of overhead that you can avoid by not ZK-proving all the different parts of each EVM execution step, and starting from the higher-level code directly” as Vitalik noted about this type of EVM” as Vitalik commented
This type of EVM can’t compile down all sorts of applications. This means that developers will have to rewrite A LOT of smart contracts and code them back from scratch.
And that would be all! I really think that the Ethereum community should be as knowledgeable as possible about this topic because as I mentioned in my previous posts on this sub, the Ethereum blockchain itself will never be cheap and will not scale on its own. The future of Ethereum is in L2s and rollups and more specifically zero-knowledge rollups.
