TL; DR

• Zero-knowledge proof technology ensures the integrity, correctness, and privacy of computations, with applications in blockchain scalability and privacy.
• zk-SNARK and zk-STARK each have their advantages, and their reasonable combination holds even more potential.
• zkVM empowers applications with zero-knowledge proof capabilities and is categorized into mainstream, EVM, or new instruction set-based implementations.
• EVM adaptation includes EVM compatibility, equivalence, and specification compliance.
• zkEVM is a zero-knowledge proof-friendly environment compatible with EVM and is divided into native and compiled variants.
• Native zkEVM is the future of Ethereum and blockchain.
• A general-purpose zkVM that supports the Solidity ecosystem is the future of Web3.

0. Zero-Knowledge Proofs

Here is a simple and easy-to-understand introduction to zero-knowledge proofs:

Imagine you are in primary school. The teacher is the verifier, and you, as a student, are the prover. How can you prove that you understand the formula for solving quadratic equations? That’s where a math exam comes in.

The teacher will randomly give you 10 related questions, and if you truly understand the concept, you will be able to solve all of them. During this process, you don’t need to recite or write down the specific content of the formula, but the teacher can easily verify your level of knowledge.

Actually, this is the method used by Tartaglia and Cardano (yes, that’s the name) to compete for who discovered the solution to the cubic equation. They both didn’t want to reveal the content of their formulas to each other, but through problem-solving, they could easily verify and determine whether they had mastered this knowledge without disclosing the details.

What is the purpose of zero-knowledge proofs? The purpose is to save computational power and reduce on-chain space in the entire process. Additionally, it can provide privacy protection, aligning with the characteristics of trustlessness in blockchain and the principles of cryptography.

1. SNARK and STARK

In the field of blockchain, the term “zk” used or mentioned is usually not referring to actual zero-knowledge proofs, but often refers to validity proofs. Due to the confusion in terminology, certain parts of this text will continue to use these “misused” terms.

In the current landscape of blockchain, zk can be considered as the forefront and optimal solution for blockchain scalability (not true zk but rather Validity Proof), and privacy technology (true zk) which utilized in projects such as Tornado.cash, ZCash, zkSync, zk.money, Filecoin, and Mina.

The current technical solutions are mainly divided into two categories: SNARK and STARK. In STARK, the “S” stands for scalable, which means that the proven statements have repetitive structures, while SNARK supports arbitrary circuits that are preprocessed to achieve concise proofs. Among them, the practical implementation of SNARKs has taken the leading position, while STARKs are mainly adopted on a large scale in the products launched by StarkWare. The following is a comparison between them.

From the perspective of Meme, STARK is better than SNARK (😊, Star Wars, Star Trek).

If SNARK is the future of Ethereum 2.0, then STARK will be the future of Ethereum 3.0. Seriously, the advantages of STARK are:

• Lower gas fees (better scalability)
• Larger batch size (much better scalability)
• Faster proofs (more than better scalability)
• No trusted setup (the generated parameters are only valid for the current application, and if any modifications occur, a new setup is required)
• Post-quantum security

However, the proofs generated by STARK are significantly large in size. Due to certain limitations, such as those imposed by WASM, additional operations may be required during the construction (here, we are referring to SNARK). Recently, Mir provided a practical implementation of an AIR-based STARK using Starky, which is part of Plonky2 (the relationship between Plonky2 and Starky is quite complex…). In my personal opinion, while the size can be optimized using various techniques, it is difficult to further compress the time complexity of the algorithm itself.

These zero-knowledge proof technologies can be combined in a reasonable way to build more powerful applications. For example, Polygon Hermez uses SNARK to verify the correctness of STARK, thereby reducing the gas fee when publishing the proof.

Overall, SNARK and STARK are both excellent zero-knowledge proof technologies, each with their own strengths, and their reasonable combination has even more potential.

2. zkVM

The previously mentioned Tornado.cash and zk.money are similar applications that only support transfer operations using zero-knowledge proofs. They do not support general-purpose computation. In comparison, these applications only have the functionality of Bitcoin, far less than the Turing-complete Ethereum, let alone building an ecosystem (The smart contracts on Bitcoin have yet to establish a thriving ecosystem.).

zkVM is a virtual machine that ensures secure, verifiable, and trustworthy properties using zero-knowledge proofs. In simple terms, it takes an old state and a program as input and returns a new state. It empowers all applications with the superpower of zero-knowledge proofs.

Miden’s presentation at ETH Amsterdam effectively summarized what zkVM is with a single slide.

Advantages of zkVM:

• Easy to use: Developers can use zkVM to run programs and ensure computational security without having to learn cryptography or zero-knowledge development (this does not mean there are no entry barriers).
• Universal: zkVM can generate proofs for any program and computation.
• Concise: The entire VM can be described with relatively few constraints, without having to generate the entire VM circuit repeatedly.
• Recursion: Free recursion feature. Similar to its universality, verification of the VM can be done using the VM itself. This is quite interesting, for example, you can have a zkVM within a zkVM, similar to the concept of L3 mentioned by StarkWare.

Disadvantages of zkVM:

• Specific computational architecture: Not all zero-knowledge proof systems can be used for zkVM.
• Performance issues: Circuits need to be optimized and can be specifically optimized for certain computations.

Currently, there are three main types of zkVM, with their respective instruction sets in parentheses: Mainstream (WASM, RISC-V), EVM (EVM bytecode), ZK-Optimized (a new instruction set optimized for zero-knowledge proofs, such as Cairo and zkSync). The following is a comparison chart of these types based on Miden’s presentation at ETH Amsterdam.

Many things done in the zero-knowledge proof development ecosystem are mostly about enabling developers to use Circom library (and snarkyjs, for instance) or other newly created languages (like Leo or Cairo, which have their unique limitations) for the development of general zk DApps. However, this is not as straightforward and easy to learn as using Solidity on Ethereum.

In addition to that, there are many projects such as zkSync, Scroll, or several under Polygon’s umbrella that are experimenting with zkEVM or other zkVM solutions.

3. EVM

The EVM is Ethereum’s virtual machine, which can also be understood as a set of execution environments for running smart contracts.

Over the years, various public blockchains have been continuously trying to become compatible with the EVM, thereby integrating into Ethereum’s development ecosystem. This concept has led to the derivation of terms like EVM compatibility, EVM equivalence, and other definitions.

• EVM Compatibility: Adaptation at the language level, such as with Solidity.
• EVM Equivalence: Adaptation at the EVM bytecode level.
• EVM Specification Adaptation: This is what is usually referred to as the real zkEVM. In most cases, it’s even a backward-compatible, optimized superset that can offer features not provided by the EVM, such as account abstraction (where each account is a smart contract).

4. zkEVM

Let’s further interpret zkEVM. By definition, zkEVM is a virtual machine that is compatible with EVM and also friendly to zero-knowledge proofs, ensuring the complete correctness of programs, operations, and input/output.

To achieve universal computation, there are two main challenges in developing zkEVM:

a) Circuit Complexity

Different contracts require the generation of different circuits, and these circuits are quite ‘complex’.

This aspect mainly relies on various optimizations. For instance, Aleo (though it’s not of the direct ZK type… just an example for optimization) uses distributed clusters for concurrent proof computations, or various hardware optimizations for acceleration.

b) Design Difficulties

zkEVM requires not just a reconstruction of the EVM but also a reconstruction of the entire state transition of Ethereum using zero-knowledge proof technology.

The original design of EVM did not anticipate the development of zkEVM, leading to significant difficulties. This has resulted in two schools of approaches, as illustrated in the diagram.

Or, to distinguish according to the architecture of a Virtual Machine (VM), like in the diagram below (huge thanks to Scroll Tech for the original image summary!). Opcode refers to EVM Opcode. The StarkWare section uses Warp to convert Solidity contracts into Cairo contracts, or can directly write contracts in Cairo, and still obtain a good development experience and a full set of tools.

At the developer and user level, these solutions are basically indistinguishable in my opinion. However, in terms of infrastructure, the further to the right the solution is, the better the EVM compatibility. It can seamlessly integrate with infrastructure such as Geth, but the development progress is generally slower.

5. zkEVM and zkVM

The existence of zkEVM, in my opinion, is to innovate and patch the Ethereum ecosystem, contributing to the prosperity of Ethereum and its ecosystem. On the other hand, the existence of zkVM may not necessarily strengthen Ethereum, but it provides greater imagination.

Although StarkNet’s Cairo VM may not be the perfect zkVM I had imagined, it can do more than EVM or zkEVM. These functionalities go beyond the level of EIP extensions. On Cairo VM, machine learning models can be run, and there is even a machine learning model platform being built on StarkNet.

Compared to zkEVM, building a zkVM is easier (without worrying about EVM’s technical debt), more flexible (without worrying about EVM’s updates), and easier to optimize (circuit and proof optimizer are much simpler and cheaper than building zkEVM).

However, zkVM has one minor but potentially fatal drawback. If zkVM cannot provide EVM compatibility at the Solidity language level, it will be difficult for zkVM to establish a comprehensive and mature Web3 development ecosystem similar to that of EVM.

zkVM may be a bigger trend that can enable vertical optimization of the EVM and horizontal expansion of the EVM ecosystem, breaking free from the limitations of the EVM.

6. The Future of zkVM

If there could be a universal zkVM that allows smart contracts of all programming languages, not just Solidity, not just Cairo, but Rust, C++, Go, to run securely with zero-knowledge proof, wouldn’t that be great? (Stellar tried, but failed.)

As @kelvinfichter mentioned: Why zkEVM if zkMIPS? As @KyleSamani mentioned: EVM is a bug not a feature. Why zkEVM if zkVM?

Winterfall, Distaff, Miden VM, and other zkVMs have not achieved a high level of developer friendliness. Nervos has a RISC-V VM, but it does not utilize zero-knowledge proof technology.

The optimal solution in the current situation is to build a WASM or RISC-V zkVM, even better if it could supports languages such as Rust, Go, C++, and even Solidity (zkSync seems to be able to make significant contributions). If there is such a universal zkVM, it would be a significant blow to zkEVM.

The number of Web3 developers accounts for approximately 0.07% of all developers. This implies that the number of Solidity developers is even smaller than 0.07%, and even fewer developers would use Cairo for writing contracts or Leo for writing circuits. As a result, the perfect zkVM aims to cater to almost 100% of developers, as any developer can obtain a perfect zero-knowledge execution environment using nearly any programming language.

If Web3 and Crypto were to dominate the world one day, I believe it would definitely not be the EVM ecosystem occupying 100% of all developers, but rather all developers gradually transitioning into Web3 and Crypto developers. This is where the brilliance of the universal zkVM lies.

Native zkEVM is the future of blockchain.

Universal zkVM is the future of Web3.

Disclaimer：

1. This article is reprinted from [Foresight Research]. All copyrights belong to the original author [msfew @ Foresight Ventures]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.