Foresight Ventures: A Detailed Explanation of zk, zkVM, zkEVM and Their Future

Author: Suning Yao, Foresight Ventures

TL; DR

• Zero-knowledge proof technology can ensure 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 can empower applications with zero-knowledge proof capabilities, and zkVM can be categorized into mainstream, EVM, or entirely new instruction sets.
• EVM adaptation includes EVM compatibility, equivalence, and specification adaptation.
• zkEVM is an environment that is EVM-compatible and friendly to zero-knowledge proofs, mainly divided into native and compiled schools.
• Native zkEVM is the future of Ethereum and blockchain.
• A general zkVM supporting the Solidity ecosystem is the future of Web3.

Zero-Knowledge Proofs

A simple and not rigorous introduction to zero-knowledge proofs:

You are in elementary school. The teacher is the verifier, and you, as the student, are the prover. How do you prove that you have mastered the solution formula for quadratic equations? You need a math exam.

The teacher will randomly generate 10 related questions, and if you have mastered the material, you can solve them all. In this process, you do not recite or write down the specific content of the solution formula, but the teacher can easily verify your level of knowledge.

This is actually the method used by Tartaglia and Cardano (yes, that’s the name) when they competed over who discovered the cubic equation. They did not want to reveal the content of their formulas to each other, but by solving problems, they could easily verify without disclosing knowledge whether they had mastered it.

What is the use of zero-knowledge proofs? The utility lies in the fact that the entire process can save computational power and compress on-chain space, while also protecting privacy, aligning with the trustless nature of blockchain and the essence of cryptography.

SNARK and STARK

In the blockchain field, the term "zk" often refers not to true zero-knowledge proofs but frequently to validity proofs. Due to the confusion of related terminology, some parts of this article will continue to use these "misuses."

In the current blockchain landscape, zk can be said to be at the forefront and the optimal solution for blockchain scalability (non-zk validity proofs) and privacy technology (true zk), used in projects such as Tornado.cash, ZCash, zkSync, zk.money, Filecoin, and Mina.

Current technical solutions are mainly divided into two categories: SNARK and STARK. The "S" in STARK stands for scalable, meaning that the proven statements have a repetitive structure, while SNARK supports arbitrary circuits, which are preprocessed to achieve concise proofs. The technical practice of SNARK dominates, while STARK is mainly adopted on a large scale by StarkWare in its launched products. Below is a comparison between them.

From a meme perspective, STARK is superior to SNARK (? Star Wars, Star Trek).

If SNARK is the future of Ethereum 2.0, then STARK will be the future of Ethereum 3.0. To be serious, the advantages of STARK include:

• Lower gas (more scalable)
• Larger batch size (more scalable * 2)
• Faster proofs (more scalable * 3)
• No trusted setup (the generated parameters are only valid for the current application; if modifications occur, a new setup is needed)
• Post-quantum security

However, the proofs generated by STARK are larger in size, and significantly so. Due to certain limitations like WASM, additional operations may be required during construction (this is where SNARK comes in). Recently, Mir provided a practical AIR-based STARK in Starky, which is part of Plonky2 (the relationship between Plonky2 and Starky is quite complex…). Personally, I believe that while the larger size can be optimized through various methods, the time complexity of the algorithm itself is difficult to compress further.

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 publishing the final proof.

In summary, both SNARK and STARK are excellent zero-knowledge proof technologies, each with its strengths, and their reasonable combination holds even more potential.

zkVM

The previously mentioned Tornado.cash and zk.money are similar in that they are zero-knowledge proof applications that only support transfer operations and do not support general computation. Comparatively, these applications only have the functionality of Bitcoin, far from Ethereum's Turing completeness, let alone building an ecosystem (smart contracts on Bitcoin have not yet created an ecosystem).

zkVM is a virtual machine that ensures secure, verifiable, and trustworthy characteristics through 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 summarized what zkVM is with a single image.

Advantages of zkVM:

• Easy to use: Developers can run programs using zkVM to ensure computational security without needing to learn cryptography or zero-knowledge development (this does not mean it is completely barrier-free).
• General: zkVM can generate proofs for any program and computation.
• Concise: A relatively small number of constraints can describe the entire VM (there is no need to repeatedly generate the entire VM's circuit).
• Recursive: Free recursive features. Similar to generality, verification of the VM can be performed through the VM itself. This is quite interesting; for example, you can place a zkVM inside a zkVM, similar to the L3 concept mentioned by StarkWare.

Disadvantages of zkVM:

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

Currently, mainstream zkVMs can be categorized into three major types, with their instruction sets in parentheses: mainstream (WASM, RISC-V), EVM (EVM bytecode), and ZK-Optimized (entirely new instruction sets optimized for zero-knowledge proofs, such as Cairo and zkSync). Below is a comparison chart based on Miden's presentation at ETH Amsterdam:

Many of the developments in the zero-knowledge proof ecosystem aim to enable developers to use libraries like Circom (and snarkyjs) or other newly created languages (languages like Leo or Cairo have various peculiar limitations) to develop general zk DApps, but they are not as straightforward and easy to learn as Solidity on Ethereum.

In addition, many projects, such as zkSync, Scroll, or several under Polygon, are attempting to create zkEVM or other zkVMs.

EVM

EVM is Ethereum's virtual machine and can be understood as a set of execution environments for running smart contracts.

For years, various public chains have been trying to be compatible with EVM to integrate into Ethereum's development ecosystem. This concept has led to the derivation of EVM compatibility, equivalence, and other definitions.

• EVM compatibility: Adaptation at the language level, such as Solidity.
• EVM equivalence: Adaptation at the EVM bytecode level.
• EVM Specification adaptation: This is what is commonly referred to as true zkEVM, which is often an optimized superset that is backward compatible and can provide features like account abstraction (where each account is a smart contract) that EVM does not offer.

zkEVM

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

To achieve general computation, two main challenges need to be addressed to create zkEVM:

a) Circuit complexity

Different contracts require generating different circuits, and these circuits are quite "complex."

This aspect mainly relies on various optimizations, such as Aleo (although it is not a direct ZK type… just an example of optimization) using distributed clusters to compute proofs concurrently or accelerating through various hardware optimizations.

b) Design difficulties

zkEVM not only needs to reconstruct EVM but also requires the overall state transition of Ethereum to be reconstructed using zero-knowledge proof technology.

When EVM was designed, it did not consider the need to create zkEVM later, resulting in significant difficulties. This has led to two factions, both illustrated in the diagram.

Alternatively, if we categorize by VM architecture, it looks like this (super thanks to Scroll Tech for the original summary!). Opcode refers to EVM Opcode. The StarkWare part uses Warp to convert Solidity into Cairo contracts, or directly write contracts in Cairo, achieving a good development experience and a full set of tools.

At the developer and user levels, I believe these solutions are essentially indistinguishable. However, in terms of infrastructure, the further right the solution is, the better the EVM compatibility, allowing seamless integration with infrastructure like Geth, but the development progress is generally slower.

zkEVM and zkVM

I believe the existence of zkEVM is to innovate and patch the Ethereum ecosystem, contributing to the prosperity of Ethereum and its ecosystem, while the existence of zkVM does not necessarily strengthen Ethereum and possesses greater imagination.

Although StarkNet's Cairo VM may not be the perfect zkVM I envision, it can do much more than EVM or zkEVM, and these capabilities extend beyond just EIP-level feature expansions. Machine learning models can run on the Cairo VM, and there are even machine learning model platforms being built on StarkNet.

Compared to zkEVM, a zkVM would be easier to construct (without worrying about EVM's technical debt), more flexible (without worrying about EVM updates), and easier to optimize (optimizing the circuits and provers' hardware and software is much simpler and cheaper than building zkEVM).

Of course, a very minor but critical drawback of zkVM is that if zkVM cannot support EVM compatibility (at the Solidity language level), then zkVM will struggle to have the most complete and mature Web3 development ecosystem like EVM.

zkVM may represent a larger trend, allowing vertical optimization of EVM to become horizontal expansion of the EVM ecosystem, breaking free from EVM's limitations.

The Future of zkVM

What if there were a universal zkVM that could allow smart contracts in all programming languages, not just Solidity, not just Cairo, but also Rust, C++, Go, to run securely under the support of zero-knowledge proofs? (Stellar tried but failed.)

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

zkVMs like Winterfall, Distaff, or Miden VM have not achieved very good developer friendliness. Nervos has a RISC-V VM, but it does not use zero-knowledge proof technology.

The optimal solution under the current situation is to build a zkVM based on WASM or RISC-V, ideally supporting languages like Rust, Go, C++, and even Solidity (zkSync seems to be able to achieve great things). If such a universal zkVM exists, it would be a dimensionality reduction attack on zkEVM.

The number of Web3 developers accounts for about 0.07% of all developers, which implies that the number of Solidity developers is likely even less than 0.07%, and those who can write contracts in Cairo or circuits in Leo are even fewer. This perfect zkVM would target almost 100% of developers, allowing any developer to achieve a perfect zero-knowledge runtime environment using almost any language.

If Web3 and Crypto ever dominate the world, I believe it will not be that the EVM ecosystem occupies 100% of all developers, but rather that all developers will gradually transition into Web3 and Crypto developers. This is the brilliance of a universal zkVM.

Native zkEVM is the future of blockchain.

General zkVM is the future of Web3.