Demystifying zkEVMs: Understanding the Differences Between ETH Equivalence, EVM Equivalence, Bytecode Compatibility, and Language Level Compatibility
Introduction
Happy new week to all my readers! To all Slytherins, it's a new week to get it! Today, we'll be looking at an interesting topic. Yes, I haven't been writing my zk series as much as before, but I'll come back to it soon. Today is the zk day, and we'll try to understand two new concepts and dispose of old ones.
For old readers, you should be able to understand what zkEVMs are. I've written a lot about that. For new readers, this article should help:
I'll just freestyle in this article and keep it simple. There's a particular misconception, especially in CT. In fact, there is a behavioral pattern where an industry leader can make a mistake in using a term to describe a concept, and that term gets accepted easily without being verified before assimilation just because it's from a particular expert in that field.
For example, in zkTech, when it comes to zkRs, the property of zk used is succinctness, which is why it's called validity rollups. Aztec is the only zk that includes privacy as a feature, making it a zkR.
However, zkR, zkEVM, and zk are now consensual terms used by both experts and noobs in the web3 space. Until further notice, when we all agree on a accurate terminology, I'll continue to use "zk" for a wider readership, but I will remind my readers that the term "validity" is more precise."
The same issue arises in the equivalence and compatibility of zkEVMs with the EVM. It's more like a PR war on zkEVMs, but fortunately, the problem has been corrected before the bad terminology spreads among the zk enthusiasts in the market.
Previously, most zkEVMs claimed to be EVM equivalent or compatible, but that's incorrect, as no one is that at the moment, but can be said to aim for it. I'll delve into that in this article.
There are four zkEVMs to consider: Scroll, Polygon, zksync, and Starknet. Scroll and Polygon are bytecode-compatible zkEVMs, while zksync and Starknet are language-level compatible. These are the two different approaches to achieving EVM compatibility.
This is the execution of both comparing with Eth standard
We can't go further without knowing what an EVM is. An EVM, or Ethereum Virtual Machine, is a Turing-complete machine that executes smart contracts and computes the state of the Ethereum network after each new block is added to the chain.
Now, what is a bytecode-compatible zkEVM? Before we proceed, it's important to note that there are trade-offs that need to be considered when trying to achieve EVM compatibility. Vitalik has illustrated this trade-off in the following diagram:
As we delve further, we will explore why performance tends to decline as EVM compatibility increases.
bytecode-compatibility
A bytecode-compatible zkEVM is one that has the same bytecode level as the EVM. However, zk is very unfriendly to EVMs, so building a bytecode-compatible zkEVM isn’t an easy task. In this EVM compatibility approach, developers don’t need extra tooling or a special version of a compiler. They can transpile Solidity or Vyper code into a bytecode level and prove the validity of the execution in the zk circuit, all while enjoying improved scalability from zk circuits.
To achieve EVM equivalence, developers will transpile bytecode and prove its validity into the zk circuit. Then, for Ethereum-equivalent zkEVMs, developers will prove the validity of execution in the zk circuit.
The performance tradeoff from the previously shown image is due to the fact that the EVM is zk-unfriendly and slow. Many parts of Ethereum require a large amount of computation to validate a zk circuit. However, this can be mitigated by ZKP hardware like GPUs, FPGAs, and ASICs. You can read more about this in-depth here:
Language level Compatibility
I’ll keep it simple, this is 🐍 arena, in thee Slytherin house, all peoples must understand: elite and noob. Lang level compatibility is less EVM compatible than bytecode, lang level involves extra tooling, which can be a bit of a pain for devs. Lang level compatibility targets LLVM unlike byte code which targets the EVM. The LLVM (low level virtual machine) is a compiler infrastructure that is designed to optimize code across different programming languages.
They do this by using an interpreter or compiler that mirrors all the functions of EVM bytecode but is not complete EVM equivalent bytecode. Hence, lang compatible zkEVMs compiles Solidity/Vyper into a bytecode targeting a LLVM.
Why matters?
Security and Tooling- these two get trade offs because lang level compatibility adds different layers of complexities.
Conclusion
From what you read, you can conclude that ETH equivalence, EVM equivalence, bytecode compatibility, and language-level compatibility are all different concepts. 🐍 helps you to understand difficult concepts, hence you stay ahead of the curve.
Resources:
https://medium.com/neworderdao/an-overview-on-zk-rollups-and-zkevm-33ee5ffb2f6a
https://pseudotheos.mirror.xyz/b_696drhG1k6Nc89RHBHFuoC0IF6g88q-fjJw9dDbKQ
https://vitalik.eth.limo/general/2022/08/04/zkevm.html
https://mobile.twitter.com/0xPolygonZK/status/1612547349406011392