I’ve already posted a similar post here although it didn’t contain as much detail so I’m expanding on this one and going into further detail

There’s been a flurry of recent developments in the zero-knowledge sector on Ethereum with some L2s even launching zkEVM testnets which enticed me to rewrite about this subject.

Again, ZK is still incredibly new tech and not many fully understand it (and this is normal considering it’s a very complicated concept to fully grasp)

Although getting to understand the technology entirely involves complicated coding knowledge and references that not many will understand, I’ll try my best to break down the tech without delving too deep into complex terminology

A couple of months back Vitalik shared his thoughts about zkEVMs and the difference that comes with each level. So let’s dissect his thoughts into a somehow-brief post so that people on this sub better understand ZK tech and zkEVM:

We need to first understand the different levels that zkEVMs come in and how each level has its own pros and cons

-Type 1 (fully Ethereum-equivalent):

Type 1 ZK-EVMs strive to be fully and uncompromisingly Ethereum-equivalent.

The pros:

Devs don’t have to double check the code when they migrate contracts. They can literally just copy paste

The cons:

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 minute 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. Its basically there to solve the main issue of Ethereum being slow and inefficient but not altering the Ethereum code (at least not entirely)

Some major names developing such tech are Polygon and Zksync (although they differ slightly)

Polygon actually just released their zkEVM testnet a couple of hours ago which was one of the reasons that made me revisit this subject.

So now both Polygon and Zksync have zkEVM testnets but I think it’s known by now that I’m one to lean more towards Polygo for multiple reasons

First of all, Polygon’s zkEVM testnet is fully open source meaning that literally anyone can access it and even improve upon it.

Zksync’s zkEVM, although an impressive feat, is still closed source which I think completely defeats the purpose of a zkEVM in the first place

Another reason is that Polygon’s zkEVM is at Bytecode-level which is unlike any other zkEVM as of now. 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 that bytecode using 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.

The pros:

This type of zkEVM is much faster than the first type we talked about. It is more than 99% equivalent with Ethereum so it's 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

The cons:

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

The pros:

Faster than the previously mentioned

The cons:

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.

What it basically means is that it takes a high level coding language (like Vyper or Solidity) and transpile it down to a SNARK-friendly VM.

A close analogy would be finding two languages of similar roots (Spanish and Portuguese) and translating one to another.

Some of the major names that use this type of EVM are Matterlabs, and Starkware.

The pros:

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

The cons:

This type of EVM can’t compile all sorts of applications. This means that developers will have to rewrite A LOT of smart contracts and code them back from scratch.

I think I’ll end the post here. There are of course many more details to be studied and talked about however I’m pretty sure that not many would be familiar with the keywords and I personally think that this is more than enough for a normal Ethereum user to get a general idea of what zkEVM is and what it does

Delving deeper into detail would be overkill unless you’re a developer or want to be one. If that’s the case then sure knock yourself out and study more about Ethereum, Bytecode, zkEVM, and Solidity

I really hope that this post helps some of you in the community understand and appreciate Ethereum and the various L2s trying to improve the blockchain.

I’ll be happy to answer any questions in the comment section.