DEVELOPMENT
This article is based on Vitalik Buterin’s article on ZK-EVM.
Earlier in the channel, several future gem projects based on ZK (zero-disclosure proofs) technology were considered.
What are these projects?
For those who haven’t read the project reviews or want to “refresh your memory,” see the links:
- Post about Starknet
- Post about zkSync
- Post about Scroll
Let’s start from the beginning!
Zero Disclosure (ZK) technology is one of the best known and most promising ways to scale Ethereum. One of the popular ways to use ZK evidence to scale Ethereum is what is known as ZK-EVM (Zero Disclosure Ethereum Virtual Machine).
So what is ZK-EVM and how does it help make Ethereum cheaper and more efficient to use?
Understanding the Ethereum Virtual Machine
To understand the power of ZK’s evidence for scaling the Ethereum Virtual Machine (EVM), we first need to understand what an EVM is. In a sense, EVM is simple: it is the mechanism by which the Ethereum blockchain performs transactions.
Every blockchain needs a set of rules to determine which transactions are valid. In the case of Ethereum, EVM performs this function. Think of it as the computer controlling the Ethereum network, tasked with ensuring the integrity of changes in the state of the blockchain.
The EVM takes the collective input of all the individual computers participating in the Ethereum network and creates an environment in which transactions can be made and smart contracts deployed. Thus, EVM is a supercomputer that provides the functionality we value in Ethereum.
But Ethereum, and by extension EVM, has one big problem: it needs to scale! Ethereum’s bandwidth is too low and transactions cost too much. So what to do about it?
The power of ZK-EVM
A common approach to using ZK proofs to scale Ethereum is to create what is known as a ZK convolution.
This is an L2 protocol that “collapses” a large packet of transactions and then uses ZK proofs to validate them in Ethereum. Many transactions become a single convolution, which reduces costs and increases throughput.
The problem, of course, is that EVM is a special environment in which a wide range of activities take place. Anyone who wants to scale Ethereum while preserving all of its features should consider how the EVM environment can be preserved, even as we seek to leverage the power of ZK proofs. Such an attempt to preserve the recognizability of EVM operation in the ZK convolution is known as “ZK-EVM.”
Vitalik Buterin has described the trade-offs associated with ZK-EVM. Vitalik’s vision is given below, with all technical terms and problem-solving approaches removed as much as possible.
Vitalik about different ZK-EVMs
The main goal of all ZK projects is the same: to use ZK-SNARK technology to create cryptographic proof of execution for Ethereum-like transactions, either to simplify validation of the Ethereum chain itself, or to create ZK convolutions that are (closely) equivalent to what Ethereum provides, but much more scalable. But there are subtle differences and trade-offs between practicality and speed between such projects.
An attempt will be made here to describe the different “types” of EVM equivalence and what the benefits and costs of trying to achieve each type are.
Overview (in diagram form)
Type 1 (fully equivalent to Ethereum)
Type 1 ZK-EVMs strive to be fully and uncompromisingly equivalent to Ethereum. They do not modify any part of the Ethereum system to simplify proof creation. They do not replace hashes, state trees, transaction trees, pre-compilations, or any other inconsistent logic, no matter how peripheral.
The advantage: perfect interoperability
The goal is to be able to verify Ethereum blocks as they are today.
A Type 1 ZK-EVM is what we ultimately need to make Ethereum’s L1 itself more scalable. In the long run, Ethereum modifications tested in ZK-EVM type 2 or type 3 can be introduced into Ethereum itself, but such a rearchitecture comes with its own complexities.
Type 1 ZK-EVMs are also ideal for aggregation, as they allow most of the infrastructure to be reused.
Disadvantage: Proof Time
Ethereum was not originally designed with ZK friendliness in mind, so many parts of the Ethereum protocol require a large amount of computation for ZK proving. Type 1 seeks to replicate Ethereum exactly, so it has no way to mitigate this inefficiency. Currently, it takes many hours to get proofs for Ethereum blocks.
Who builds it?
ZK-EVM Community Edition (run by community members including Privacy and Scaling Explorations, Team Scroll, Taiko and others) is ZK-EVM L1.
Type 2 (fully equivalent to EVM)
Type 2 ZK-EVMs aim to be exactly equivalent to EVMs, but not fully equivalent to Ethereum. That is, they look exactly like Ethereum “on the inside,” but have some differences on the outside, particularly in data structures such as the block structure and state tree.
The goal is to be fully compatible with existing applications, but to make some minor changes to Ethereum to simplify development and speed up proof creation.
The advantage: perfect equivalence at the VM level
Type 2 ZK-EVMs make changes to data structures that contain things like Ethereum state. Fortunately, these are structures that the EVM itself can’t directly access, so applications running on Ethereum will almost always run on a Type 2 ZK-EVM convolution.
You won’t be able to use Ethereum executable clients as is, but you will be able to use them with some modifications, and you will still be able to use EVM debugging tools and much of the other infrastructure for developers.
Disadvantage: Improved, but still slow pruver time*
Type 2 ZK-EVMs provide faster verification times than Type 1, mainly by removing parts of the Ethereum stack that rely on overly complex and ZK-unfriendly cryptography.
The slowness of having to prove EVMs as is, with all the inefficiencies and ZK-unfriendliness inherent in EVMs, still remains.
*Pruver (Prover) is a proof generator for transactions.
Who builds it?
The Scroll ZK-EVM project is built on ZK-EVM type 2, as is Polygon Hermez . However, neither project is yet complete; in particular, many of the more complex precompilations have not yet been implemented.
Consequently, for the time being, both projects are best considered as Type 3.
Type 2.5 (equivalent to EVM, except for the cost of gas)
Changing the cost of gas can reduce developer tool compatibility and disrupt some applications, but is generally considered less risky than “deeper” EVM changes.
Type 3 (almost EVM equivalent)
Type 3 ZK-EVMs are almost equivalent to EVMs, but make some sacrifices for exact equivalence to further reduce validation time and simplify EVM development.
The advantage: easier to assemble and less pruver time
Type 3 ZK-EVMs can remove several features that are exceptionally difficult to implement in a ZK-EVM implementation. In addition, Type 3 ZK-EVMs sometimes also have minor differences in how they handle contract code, memory, or stack.
Disadvantage: great incompatibility
The goal of ZK-EVM type 3 is to be compatible with most applications and to minimally rewrite the rest of the applications. However, there will be some applications that will need to be rewritten, either because they use pre-compilations that ZK-EVM type 3 removes, or because of subtle dependencies from edge cases that virtual machines handle differently.
Who builds it?
Scroll and Polygon are Type 3 in their current forms, although they are expected to improve compatibility over time.
No ZK-EVM team today wants to be Type 3; Type 3 is just a transitional phase until the hard work of adding precompilation is complete and the project can move to Type 2.5.
However, in the future, ZK-EVM Type 1 or Type 2 may voluntarily become ZK-EVM Type 3 by adding new ZK-SNARK-friendly precompilations that provide functionality for developers with little checking time and gas cost.
Type 4 (high level language equivalent)
A Type 4 system works by taking smartcontract source code written in a high-level language (such as Solidity, Vyper, or some middleware that compiles to both) and compiling it in some language that is explicitly designed to support ZK-SNARK.
The advantage: very fast pruver time
There is a lot of overhead that can be avoided by not ZK-proofing all the different parts of each EVM execution step, but starting directly with higher level code.
I describe this advantage in just one sentence in this post (compared to the large list of compatibility-related disadvantages below), but it should not be interpreted as a value judgment! Direct compilation from high-level languages can indeed significantly reduce costs and help decentralization by simplifying the work of the proof-reader.
Disadvantage: great incompatibility
A “normal” application written in Vyper or Solidity can be compiled and it will “just work,” but there are several important points where very many applications are not “normal.”
- Contracts may not have the same addresses in a Type 4 system as they do in EVM.
- EVM handwritten bytecode is more difficult to use. Many applications use handwritten EVM bytecode in some parts to increase efficiency. Type 4 systems may not support it, although there are ways to implement limited EVM bytecode support to meet these use cases without making the effort to become a full ZK-EVM Type 3.
- Much of the debugging infrastructure cannot be ported because such infrastructure works with EVM bytecode. However, this drawback is mitigated by better access to the debugging infrastructure from “traditional” high-level languages or intermediate languages (e.g., LLVM).
Who builds it?
ZKSync is a Type 4 system, although it may eventually add compatibility with EVM bytecode.
Nethermind’s Warp project is building the Solidity compiler for Starkware Cairo, which will de facto turn StarkNet into a Type 4 system.
The future of ZK-EVM types
Types are not unambiguously “better” or “worse” than other types.
Rather, they are different points in the trade-off space: lower-numbered types are more compatible with existing infrastructure but slower, and higher-numbered types are less compatible with existing infrastructure but faster. Overall, it’s helpful that all of these types are explored.
In addition, ZK-EVM projects can easily start with higher-numbered types and move to lower-numbered types over time (or vice versa). For example:
- ZK-EVM can start out as type 3, choosing not to include some features that are particularly difficult to test with ZK. Later, they may add these features over time and move to type 2.
- The ZK-EVM could start out as Type 2 and then become a hybrid ZK-EVM Type 2/Type 1, providing the ability to work either in full Ethereum compatibility mode or with a modified state tree that can be verified faster. Scroll is considering moving in that direction.
- What started out as a Type 4 system may eventually become Type 3 by adding the ability to process EVM code later (though developers will still be encouraged to compile directly from high-level languages to reduce costs and verification time).
- ZK-EVM type 2 or type 3 could become ZK-EVM type 1 if Ethereum itself adopts its modifications to become more ZK-friendly.
- A Type 1 or Type 2 ZK-EVM could become a Type 3 ZK-EVM if it added pre-compilation to check code in a very ZK-SNARK-friendly language. This would give developers a choice between compatibility with Ethereum and speed. It would be type 3 because it breaks the perfect EVM equivalence, but for practical purposes and purposes it would have many of the advantages of types 1 and 2. The main disadvantage may be that some developer tools do not understand the ZK-EVM user interface.
Personally, I hope that eventually things will become Type 1 through a combination of improvements to ZK-EVM and improvements to Ethereum itself to make it more ZK-SNARK friendly. In that future, we will have several implementations of ZK-EVM that can be used for both ZK convolution as well as Ethereum chain validation itself. In theory, Ethereum does not need to standardize on a single ZK-EVM implementation to use L1; different clients can use different proofs, so we still use code redundancy.
However, it will be a long time before we get to that future. In the meantime, we will see many innovations in different ways of scaling Ethereum and Ethereum-based ZK-collapses.
Conclusion
The previously considered projects such as Starknet, zkSync, Scroll on Vitalik’s scale can be categorized into the following stages:
Scroll belongs to type 3 -> tends to type 2.5/2.
zkSync, Starknet are of type 4 -> tend to type 3.
Like Vitalik said, the division into types is very relative: there are subtle differences and tradeoffs between practicality and speed between similar projects.
It’s just a set of tradeoffs. Some compromises get closer to the ideal target type 1 (fully equivalent to Ethereum), others do not.
At the same time, we can say that the Scroll project is the most technically perfect, relative to the benchmark.
