Note: the original author is vitalik buterin, the co-founder of Ethereum.
Special thanks to PSE, polygon HERMEZ, zksync, scroll, matter labs and starkware team for their discussion and review.
Recently, many "zk-evm" projects have issued gorgeous announcements, such as polygon open source their zk-evm project, zksync released their zksync 2.0 plan, and the relatively new scroll recently announced their zk-evm. Privacy and expansion exploration team（Privacy and Scaling Explorations）、The team of Nicolas liochon et alFrom EVM to starkware's Cairo language Alpha compilerI'm also working hard. Of course, there are still some I missed.
The core objectives of all these projects are the same: to use zk-snark technology to make cryptological proof similar to Ethereum transaction execution, or to verify the Ethereum blockchain itself more easily, or to build ZK rollup that has the same (similar) functions as those provided by Ethereum but is more scalable. But there are subtle differences between these projects, and they make a trade-off between practicality and speed. This article will try to describe the classification of different "types" equivalent to EVM, and the benefits and costs of trying to realize each type system.
Zk-evm of type 1 strives to be completely and uncompromisingly equivalent to Ethereum, and they will not change any part of the Ethereum system to make it easier to generate proofs. They do not replace hashes, state trees, TX trees, precompiles, or any other consensus logic, however minor.
Advantages: perfect compatibility
The goal is to be able to verify the Ethereum block as today, or at least the execution layer (therefore, it does not include the beacon chain consensus logic, but includes all transaction execution and smart contract and account logic).
Zk-evm of type 1 is our final need, which makes Ethereum L1 layer more scalable. In the long run, the Ethereum modification tested in type 2 or type 3 zk-evm may be introduced into Ethereum itself, but this re architecture also has its own complexity.
Zk-evm of type 1 is also an ideal choice for rollup because they allow rollup to reuse a large amount of infrastructure. For example, Ethereum execution clients can generate and process rollup blocks as is (or at least, they can be used once withdrawal is realized, and this function can be reused to support the storage of eth in rollup). Therefore, tools such as block browser and block production are very easy to reuse.
Ethereum was not originally designed around ZK friendliness, so many parts of the Ethereum protocol require a lot of computing to prove ZK. Zk-evm of type 1 is designed to accurately replicate Ethereum, so it cannot alleviate these inefficiencies. At present, the proof of Ethereum block takes many hours to produce. This can be alleviated by the ingenious prover of large-scale parallelization of engineering, and it can also be alleviated by zk-snark ASIC in the long run.
Who is building zk-evm of type 1?
The privacy and scaling explorations team is building a zk-evm of type 1. （Translator's note: the privacy and scaling explorations team is the renamed appliedzkp）
Zk-evm of type 2 strives to be completely equivalent to EVM, but not completely equivalent to Ethereum. In other words, they look exactly the same as Ethereum "from the inside", but they have some external differences, especially in the data structures such as block structure and state tree.
The goal is to be fully compatible with existing applications, but Ethereum has some minor modifications to make development easier and generate proofs faster.
Advantages: perfect equivalence at VM level
Zk-evm of type 2 changes the data structures that store the Ethereum status. Fortunately, these structures are not directly accessible by EVM itself. Therefore, applications working on Ethereum can almost always run on zk-evm rollup of type 2. You will not be able to use Ethereum execution clients as is, but you can use them with some modifications, and you can still use EVM debugging tools and most other developer infrastructures.
Of course, there are a few exceptions. For applications that verify Merkle certificates of Ethereum historical blocks to verify historical transactions, receipts, or status statements, an incompatibility occurs (for example, bridges sometimes do this). Replacing keccak's zk-evm with a different hash function destroys these proofs. However, I generally recommend not to build applications in this way, because future Ethereum changes (such as the verkle tree) will even destroy such applications of Ethereum itself. A better choice is to let Ethereum itself add historical access precompiled that can stand the test of the future.
Disadvantages: although improved, the certifier（prover）Time is still very slow
Zk-evm of type 2 provides faster prover time than zk-evm of type 1, mainly by deleting the cryptographic parts that rely on unnecessary complexity and are not friendly to ZK in the Ethereum stack. In particular, they may change the Ethereum keccak and RLP based Merkle Patricia trees, and may also change the block and receipt structures. Type 2 may use different hash functions for zk-evm, such as Poseidon。 Another natural modification is to modify the state tree to store code hashes and keccaks, so that hashes do not need to be verified for processing
These modifications significantly improved the prover time, but did not solve all the problems. Due to all the inefficiencies and ZK unfriendliness inherent in EVM, it is proved that the speed of EVM is still very slow. A simple example is memory: because a
MLOAD You can read any 32 bytes, including "misaligned" chunk blocks (the start and end are not multiples of 32), so you cannot simply
MLOAD Interpreted as reading a block; Instead, it may need to read two consecutive blocks and perform bit operations to combine the results.
Who is building zk-evm of type 2?
Scroll's zk-evm The project is developing towards zk-evm of type 2,Polygon HermezThe same is true for. Of course, neither of these two projects has been completed. In particular, many more complex precompiles have not yet been implemented. Therefore, it is better for these two projects to be classified as zk-evm of type 3.
One way to significantly improve the time of the worst-case certifier is to significantly increase the gas cost of specific operations in EVM that are difficult to ZK prove. This may involve precompiling, keccak opcodes, and possible specific modes of calling contracts or accessing memory or storage or recovery.
Changing the cost of gas may reduce the compatibility of developers' tools and destroy some applications, but generally we think it is less risky than "deeper" EVM changes. Developers should pay attention not to require more than one block of gas in a transaction, and never use hard coded gas to call (this has been a standard recommendation for a long time).
Another way to manage resource constraints is to simply set a hard limit on the number of times each operation can be invoked. This is easier to implement in the circuit, but it performs much worse under the EVM safety assumption. I call this method type 3 instead of type 2.5.
Zk-evm of type 3 is almost equivalent to EVM, but in order to further improve the prover time and make EVM easier to develop, some sacrifices need to be made in terms of accurate equivalence.
Advantages: easy to build and faster prover time
Zk-evm of type 3 may delete some features that are very difficult to implement in zk-evm implementation, and precompiling is usually at the top of the list. In addition, zk-evm of type 3 sometimes has subtle differences in processing contract code, memory or stack.
Disadvantages: there will be more incompatibilities
The goal of type 3 zk-evm is to be compatible with most applications, while the rest requires minimal rewriting. In other words, some applications need to be rewritten because they use precompiling deleted by type 3 zk-evm, or because of the subtle dependence on the edge of different VM processing.
Who is building zk-evm of type 3?
The zk-evm currently built by scroll and polygon is of type 3, although they are expected to improve compatibility over time. Polygon has a unique design for their own internal language zkASMPerform ZK verification and use zkasm implementation to interpret zk-evm code. Despite the implementation details, I still call it the true type 3 zk-evm. It can still verify EVM code, and it only uses some different internal logic to complete it.
Today, the goal of the team without zk-evm is to become zk-evm of type 3. Type 3 is just a transitional stage until the complex work of adding precompile is completed, and then the project can be transferred to zk-evm of type 2.5. However, in the future, zk-evm of type 1 or type 2 may automatically become zk-evm of type 3 by adding a new zk-snark friendly precompile to provide developers with low prover time and gas cost.
The working principle of type 4 system is to compile the smart contract source code written in high-level language (such as solidity, Vyper or intermediate language) into a language explicitly designed to be zk-snark friendly.
Advantages: very fast prover time
By not ZK proving all the different parts of each EVM execution step and starting directly from the higher level code, you can avoid a lot of overhead.
In this article, I only use one sentence to describe this advantage of the type 4 system (compared with the compatibility related disadvantages listed below), but this should not be interpreted as a value judgment! Compiling directly from a high-level language can indeed greatly reduce costs and help achieve decentralization by making it easier to become a prover.
Disadvantages: compatibility will be worse
"Normal" applications written with Vyper or solidity can "work normally" by compiling, but there are some important ways that make many applications unable to "work normally".
Developers should pay attention to these issues.
Who is building a type 4 system?
Zksync is a type 4 system, although over time, it may increase compatibility with EVM bytecode. Nethermind's warp project is building a compiler for Cairo language from solidity to starkware, which will make starknet a de facto type 4 system.
This paper does not clearly judge which of the above types of zk-evm is "better" or "worse". On the contrary, they only weigh on different points:Lower numbered types are more compatible with existing infrastructure, but will be slower, while higher numbered types are less compatible with existing infrastructure, but they will be faster。 In general, the exploration of all types of zk-evm is beneficial.
In addition, zk-evm projects can easily start with higher numbered types and jump over time to lower numbered types (and vice versa)。 For example:
Personally, I hope that with the passage of time, through the improvement of zk-evm and Ethereum itself (making it more friendly to zk-snark), everything will become zk-evm of type 1. In this future, we will have multiple zk-evm implementations, which can be used for both ZK rollup and verification of the Ethereum blockchain itself. Theoretically, Ethereum does not need to standardize on a single zk-evm implementation for L1 use. Different clients can use different proofs, so we continue to benefit from code redundancy.
However, it will take quite a long time to realize such a future. At the same time, we will see many innovations in the different paths of extending Ethereum and ZK rollup based on Ethereum.