TL;DR
Zero-knowledge proof technology can guarantee the integrity, correctness and privacy of calculations, and has applications in blockchain expansion and privacy.
Both zk-SNARK and zk-STARK have their own advantages, and their reasonable combination has more potential.
zkVM can endow applications with zero-knowledge proof capabilities, and zkVM can be divided into mainstream, EVM or new instruction sets.
The adaptation of EVM includes EVM compatibility, equivalence and adaptation on Specification.
zkEVM is an EVM-compatible and zero-knowledge proof-friendly environment, mainly divided into native and compiled genres.
The native zkEVM is the future of Ethereum and blockchain.
Universal zkVM supporting Solidity ecology is the future of Web3.
0. Zero-knowledge proof Not rigorous but easy to understand to introduce zero-knowledge proof:
You are in elementary school. The teacher is the verifier, and you as the student are the certifier. How do you prove that you have mastered the solution formula of the quadratic equation in one variable? Then you need a math test.
The teacher will randomly select 10 related questions, and if you have mastered them, you can solve them all. In this process, you did not recite or write down the specific content of the solution formula, but the teacher can easily verify your degree of knowledge mastery.
In fact, this is the method used by Tartaglia and Cardano (yes, that’s the name) to compete for who is the discoverer of the unary cubic equation. They don’t want to tell each other the content of their formula, but by doing the questions, they can easily verify and Without revealing knowledge in the process, judge whether they have mastered this knowledge.
What is the use of zero-knowledge proof? The use is that the whole process can save computing power and compress space on the chain, and at the same time protect privacy, which is in line with the trustless characteristics of blockchain and the genes of cryptography.
1. SNARKs and STARKs The "zk" used or mentioned in the blockchain field is usually not a true zero-knowledge proof, but often a Validity Proof. Due to the confusion of related vocabulary, some places in this article will continue these "misuses".
In the current blockchain landscape, zk can be said to be the most cutting-edge and optimal solution for blockchain expansion (Validity Proof without zk) and privacy technology (real zk). In Tornado.cash, ZCash, zkSync, It is used in projects such as zk.money, Filecoin, and Mina.
The current technical solutions are mainly divided into two categories: SNARK and STARK. The S in STARK stands for scalable, which means that the proven statement has a repeated structure, while SNARK supports arbitrary circuits, which are preprocessed to achieve concise proofs Among them, the technical practice of SNARK occupies a dominant position, and STARK is mainly adopted by StarkWare in the products that have been launched on a large scale. The following is a comparison between them.
From a Meme perspective, STARKs are better than SNARKs (?, Star Wars, Star Trek).
If SNARK is the future of Ethereum 2.0, then STARK will be the future of Ethereum 3.0. Seriously speaking, the advantage of STARK is
Lower gas (more scalable)
Larger batch size (more scalable * 2)
Faster proofs (more scale * 3)
No trusted setup (the generated parameters are only valid for the current application, if there is a modification, you need to re-setup)
post-quantum security
However, the volume of the proof generated by STARK is larger, and it is quite large. Due to some limitations of WASM, for example, additional operations may be required during construction (here is SNARK). Mir gave an AIR-based The practice of STARK is a part of Plonky2 (the relationship between Plonky2 and Starky is more complicated...). I personally think that the large size can be optimized by various methods, but the time complexity of the algorithm itself is difficult to further compress.
These zero-knowledge proof technologies can be combined reasonably to build more powerful applications. For example, Polygon Hermez uses SNARK to verify the correctness of STARK, thereby reducing the gas fee when the proof is finally issued.
To sum up, both SNARK and STARK are excellent zero-knowledge proof technologies, each with its own advantages and disadvantages, and their reasonable combination has more potential.
2. zkVM The aforementioned Tornado.cash and zk.money are both zero-knowledge proof applications that only support transfer operations, and do not support general-purpose calculations. Analogously, these applications only have the functions of Bitcoin , which is far inferior to that of Ethereum Turing is complete, not to mention building an ecology (smart contracts on Bitcoin have never been built).
zkVM is a virtual machine that guarantees security, verifiable and trustworthy features by zero-knowledge proofs. Simply put, it inputs old states and programs and returns new states. It allows all applications to be endowed with the superpowers of zero-knowledge proofs.
Miden's talk at ETH Amsterdam gave a good overview of what zkVM really is.
Advantages of zkVM:
Ease of use: Developers can use zkVM to run programs without learning cryptography or zero-knowledge development to ensure computing security (does not mean that there is no threshold at all)
General: zkVM can generate proofs for any program and computation.
Conciseness: A relatively small number of constraints can describe the entire VM (without repeating the circuit of the entire VM).
Recursion: Free recursive feature. Like universality, the verification of VM can be done through VM. This is very interesting. For example, you can put a zkVM in zkVM, which is similar to the concept of L3 mentioned by StarkWare.
Disadvantages of zkVM:
Special computing architecture: Not all zero-knowledge proof systems can be used as zkVM.
Performance issues: The circuit needs to be optimized, and it can be optimized for specific calculations.
Now there are three main types of mainstream zkVM, and their instruction sets are in parentheses: mainstream (WASM, RISC-V), EVM (EVM bytecode), ZK-Optimized (new instruction set, optimized for zero-knowledge proof, such as Cairo and zkSync ). The following is a type comparison chart compiled according to Miden’s speech at ETH Amsterdam:
Most of the things that zero-knowledge proof development ecology does are to allow developers to use Circom library (and snarkyjs) or other newly created languages (languages like Leo or Cairo have strange restrictions) to do general-purpose zk The development of DApp is not as straightforward and easy to learn as Solidity on Ethereum.
In addition, there are many projects, such as zkSync, Scroll, or many companies under Polygon are trying to make zkEVM or other zkVM.
3. EVM EVM is the virtual machine of Ethereum, which can also be understood as an execution environment for running smart contracts.
Over the years, various public chains have been trying to be compatible with EVM, so as to be connected to the development ecology of Ethereum. For this concept, EVM compatibility, equivalence and other definitions have been derived.
EVM Compatibility: Adaptation at the language level such as Solidity.
EVM Equivalence: Adaptation at the EVM bytecode level.
EVM Specification Adaptation: The so-called real zkEVM, in most cases even an optimized superset of backward compatibility, can provide account abstraction (that is, each account is a smart contract) and other things that EVM does not provide characteristic.
4. zkEVM Let's interpret zkEVM again. By definition, zkEVM is a virtual machine that is compatible with EVM and friendly to zero-knowledge proofs, and can guarantee the complete correctness of programs, operations, and input and output.
For the realization of general computing, to do zkEVM mainly need to solve two difficulties:
a) The circuit is complex Different contracts need to generate different circuits, and these circuits are "complex".
This aspect mainly depends on various optimizations, such as Aleo (but it is not a type of direct ZK... just to illustrate optimization) through distributed Cluster to concurrently calculate Proof, or through various hardware optimizations to accelerate .
b) Difficult to design zkEVM not only needs to reconstruct the EVM, but also reconstructs the overall state transition of Ethereum with zero-knowledge proof technology.
When EVM was designed, I didn’t expect to do zkEVM in the future, which caused great difficulties. It led to the routes of two sects, all of which are in the picture.
Or according to the architecture of the VM, it looks like this (thanks to Scroll Tech for the original picture summary!). Opcode refers to EVM Opcode. The StarkWare part uses Warp to convert Solidity into Cairo contracts, or write directly in Cairo contract, you can also get a good development experience and a full set of tools.
At the level of developers and users, I think there is basically no difference between these solutions, but in terms of infrastructure, the farther to the right the better the EVM compatibility, and can seamlessly connect to infrastructure such as Geth, but the development progress Basically slower.
5. zkEVM and zkVM I think the existence of zkEVM is to renovate and patch the Ethereum ecology, which can contribute to the prosperity of Ethereum and its ecology, but the existence of zkVM does not necessarily strengthen Ethereum, but also has greater imagination.
Although StarkNet's Cairo VM may not be the perfect zkVM in my imagination, it can do more things than EVM or zkEVM, and these are not just functional expansions at the EIP level. Machine learning models can be run on Cairo VM, and even There is also a machine learning model platform being built on StarkNet.
Compared with zkEVM, a zkVM will be easier to build (no need to worry about the technical debt of EVM), more flexible (no need to worry about EVM update), easier to optimize (the hardware and software optimization of circuits and provers is much simpler and cheaper than building zkEVM ).
Of course, one of the smallest but fatal shortcomings of zkVM is that if zkVM cannot support EVM compatibility (Solidity language level), then it is difficult for zkVM to have the most complete and mature Web3 development ecosystem like EVM.
ZkVM may be a bigger trend, which can turn the vertical optimization of EVM into the horizontal expansion of EVM ecology, breaking out of the limitation of EVM.
6. The future of zkVM What if there is a general-purpose zkVM that allows smart contracts in all programming languages, not just Solidity, not just Cairo, but Rust, C++, Go, to run safely with the blessing of zero-knowledge proof? (Stellar tried, but failed up.)
As @kelvinfichter said: Why zkEVM if zkMIPS? As @KyleSamani said: EVM is a bug not a feature. Why zkEVM if zkVM?
zkVM such as Winterfall or Distaff or Miden VM are not very friendly to development. Nervos has RISC-V VM, but Nervos does not use zero-knowledge proof technology.
The optimal solution under the current situation is to build a WASM or RISC-V zkVM, preferably supporting languages such as Rust, Go, C++, and even Solidity (zkSync seems to be able to make great contributions). If there is such a general zkVM, then for zkEVM It will be a dimensionality reduction blow.
The number of Web3 developers accounts for about 0.07% of all developers, and it can be inferred that the number of Solidity developers will actually be less than 0.07%, and even fewer will use Cairo to write contracts or use Leo to write circuits. In this way The perfect zkVM is aimed at almost 100% of developers, and any developer can get a perfect zero-knowledge operating environment with almost any language.
If Web3 and Crypto have a day to rule the world, I think it will definitely not be that the EVM ecology occupies 100% of all developers, but all developers will slowly transform into Web3 and Crypto developers. This is the wonderfulness of the general zkVM place.
Native zkEVM is the future of blockchain.
Universal zkVM is the future of Web3.
Author: Suning Yao @ Foresight Ventures