Shiva 🦇🔊
Shiva 🦇🔊

@ShivanshuMadan

17 Tweets 4 reads Jan 26, 2023
zkEVMs are the future of Ethereum
They are being developed at a breakneck pace. But not all zkEVMs are created equal!
Your guide to different types of zkEVMs:
1/17
If this is the first time you're hearing the word zkEVM, here's a quick refresher:
2/17
There are varying degrees to which a zkEVM can be compatible with Ethereum
Let's look at each of these:
3/17
1. Ethereum Equivalent
Type-1 zkEVMs look and operate precisely like Ethereum
They make NO changes to the Ethereum execution infrastructure (hashes, state trees, etc.)
In this, the developer experience is virtually indistinguishable from developing on Ethereum itself
4/17
Devs can basically copy-paste the existing code for their apps from the Ethereum mainchain to the zkEVM
Ethereum-equivalence also means that the zkEVM can draft on upgrades to Ethereum itself with minimal extra work needed
So what's the catch?
5/17
Ethereum was not originally designed around ZK-friendliness
So the inefficiencies of Ethereum carry over to the zkEVMs too
Type-1 zkEVMs require a very high prover time, as no unique reworking is done to make proof generation faster
This makes them extremely costly!
6/17
2. EVM Equivalent
Type-2 zkEVMs look exactly like Ethereum "from within", but they have some differences on the outside
This is done to facilitate development and speed up the proof generation
@0xPolygonHermez and @Scroll_ZKP are building Type-2 solutions
7/17
Most applications that work on Ethereum would still work on Type-2 zkEVM rollups
And others would work with slight modifications to the code
So does Type-2 get us the best of both worlds?
Not exactly.
8/17
These modifications significantly improve prover times, but they do not solve every problem
The slowness from the inefficiencies and ZK-unfriendliness inherent to the EVM still remains in Type-2
9/17
3. *Almost" EVM Equivalent
Type-3 zkEVMs are almost EVM-equivalent, but make a few sacrifices to further improve prover times
These prioritize the ease of development and remove a few EVM features that are exceptionally hard to implement in the zk environment
10/17
As is the case with Type-2, most Ethereum applications are compatible with Type-3 zkEVMs and others require slight modification
However, there will be some apps that would need to be rewritten entirely because they use features that the Type-3 zkEVM removes
11/17
4. EVM compatible
Type-4 zkEVMs look & operate nothing like the EVM
Instead, they create a new Virtual Machine that makes development and proof generation extremely easy in the zk environment
@zksync and @StarkNetEco are building "EVM compatible" Type-4 solutions
12/17
A Type-4 system works by taking source code written in a high-level language like Solidity and compiling that to some language that is explicitly designed to be zkSNARK-friendly
By doing this, Type-4s drastically reduce costs and improve proof-generation time
13/17
Naturally, this comes at the cost of a few challenges:
- Most apps are not compatible and need to be rewritten entirely
- It may not be easy to carry over future Ethereum upgrades to Type 4 zkEVMs
14/17
As @VitalikButerin pointed out, no one type of zkEVMs is better or worse than the others
There is development happening in all 4 areas that will lead to more innovation in this space
15/17
At any point, zkEVMs can decide to transition from one type to another by simply adding/removing certain features
In the future, Ethereum itself will undergo changes that will make it more zkSNARK friendly
16/17
Irrespective of which solution wins in the future, zkEVMs are a welcome development in solving the Ethereum scalability solution
I hope you learned something new from this thread. Help spread the word by retweeting the first tweet (linked below)
Follow me for more alfa!
17/17

Loading suggestions...