Introduction of ZKVM solutions, landscape and its future

Author: YOLO SHEN (Cipholio Ventures)

TL;DR

1. ZK technology has two main usage scenarios: privacy and scaling. When we discuss privacy, we use ZK technology to protect off-chain data from leaking; when we discuss Scaling, we use ZK Save on-chain computing space. For example, if I want to verify that an account has 100 yuan, the traditional blockchain method is to let each node confirm it once, but now I only need one node. On the premise of ensuring data integrity, find the nearest node. A certificate of net inflow of 100 yuan can prove that the account has 100 yuan. The difference is that the former requires a lot of calculation and verification, while the latter only requires off-chain verification.
2. The core trade-off of ZKVM development is whether it is important to give full play to the potential of ZK, or to give full play to the current developer resources. Revolving around the potential of ZK means hardware acceleration of CPU registers, reorganization of IR language and assembly language; and around the use of developer resources, it means how to perform ZK verification on the opcode mapped by Bytecode after Solidity converts bytecode.
3. The special-purpose ZKapp that is independently designed for ZK verification in assembly language will face great obstacles in the future development process due to its low composability and decoupling capabilities. These schemes are incompatible with other ZK schemes due to their incompatibility with VM, language, and verification, so there is a greater difficulty in calling.
4. According to the viewpoint of modular blockchain, L1 solves the consensus problem, L2 solves the calculation and execution problem, and the DA layer solves the problem of data availability and integrity. Due to the L2 verification dependency of the Zk class, the transaction log of the time series, the data security and the integrity of the verification determine the reliability of its execution. In the current state where most of the ZK solutions are closed-source, ZK security auditing has great prospects for development.
5. Since ZKP relies on off-chain data, the privacy of the data will be lost if it is handed over to the DA chain. To be compatible with data privacy and ZK validating nodes not to do evil, new solutions are needed. We are optimistic about future secure computing solutions such as MPC/FHE.
6. With the continuous maturity of different Circuit verifications, Zk verification may also usher in efficiency improvement and division of labor. ZK verification hardware speed-up solutions and professional ZK miners may also emerge as the times require.
7. The limitation of ZKP experience. Typical problems include: the constraint system cannot effectively constrain data, and when verifying some complex and intersecting propositions, the constraints are insufficient; private data is leaked, and private data is treated as public data; attacks on off-chain data, contracts Layer’s “metadata-attack”; ZK validating node’s evildoing, etc.
8. In the short term, the security of the ZK solution has limitations. At present, a large amount of consensus is still based on the self-discipline of off-chain nodes, and there is a lack of a series of necessary tools (testing, verification, etc.) to ensure the security of the off-chain environment.

Overview

ZK technology has always made it difficult to fully discuss this topic due to its lingering jargon. This article will focus on analyzing ZK technology and its application scenarios from the perspective of ecological development, describe the current ZK-related competitive landscape, and make some ideas for the future development direction. This article focuses on:

1. What are we talking about when we talk about ZK technology? (institutional investors can start reading from the second part.)
2. View the development law and structure of gzkvm (generalized zk vm) from the perspective of technological development?
3. Comparison of the current main ZKvm technical solutions?
4. Analysis and Outlook

Virtual machine ABC — from the daily computer

Before introducing the knowledge related to ZKEVM, I would like to start with the structure of our daily computer. We all know that the computer is divided into two parts: software and hardware. In order for the software to run smoothly on the hardware, we need to match the appropriate operating environment for the software . From the structural point of view, the operating environment consists of two parts: [hardware + operating system].

From the graph below, we can see the yellow part is the hardware, and the green part is the operating system. Some may wonder: why the operating environment is not equivalent to the operating system, this is mainly because the operating system is difficult to be compatible with all hardware, and only the matching of the operating system and the hardware can provide services for the software. This issue will be mentioned later in the development route of ZKVM.

With the operating environment, we also need specific software (program/app) to achieve specific requirements. So how does the program run?

From the same graph above, we can see that the software is handed over to the hardware layer by the operating system for the entire process of calculation. During the process, the programming language has undergone three stages of changes. The high-level language is used to write programs to complete the actual requirements, and the assembly language is used to Communicate with the computer, and the underlying native code (hexadecimal number) is specifically executed by the computer.

Specifically, after the programmer completes the APP code, it is translated into obj (target language) through the translator. These discrete target languages will be linked through the Linker in the operating system, and the output executable exe files of the two are stored in the on the hard disk. When running, the exe file will put the data into the memory, and convert the Obj into native code (bytecode) through the CPU for computing operations to realize the I/O of the app.

In this process, there are a lot of choices, a variety of languages, a variety of operating systems, and a variety of hardware. From a commercial point of view, there are a lot of tradeoffs, and these choices are finally reflected in the compiler kernel LLVM (low level virtual machine) improvement. As we can see in the figure below, there are various correspondences and constraints between the hardware (yellow) and the operating system:

1. The same type of hardware can install multiple operating systems, and different hardware needs to match different types of operating systems. For example, in the same AT compatible machine A, both Windows and LinuxB and other operating systems can be installed. For another example, the hardware of the X86 chip needs the x86 version of windows to match. This is mainly due to the fact that the underlying assembly language of the operating system needs to match the chip.
2. The successful operation of the App needs to match the CPU and the operating system. For example: 1. In order to ensure the normal operation of Office 2017, an x86C CPU is required; 2. Some APPs can only run on Windows XP, but not on 2000.
3. The CPU can only interpret its own inherent machine language. Different CPUs can interpret different kinds of machine language. That is to say, if APPs written in different high-level languages cannot be compiled into a language that the CPU can operate on through the [operating system], the CPU will not be able to execute them.

What is Zk VM?

Usually when we discuss ZK, it is usually in three contexts:

1. One, using ZK as the scaling scheme RollupL2.
2. Second, applications that use zkp for verification, dydx, Zklink, etc.
3. Third, zkproof as a cryptographic algorithm.

In what language, in what environment, with what hardware to execute? This is the problem to be solved by generalized VMs.

Earlier we just introduced the traditional operating system (also a kind of VM). When we look at ZKVM again, we can find that ZKVM has also completed similar functions, completing the hardware layer (native chain + ZK verification system) and high-level language (solidity). or native ZK language) communication. Its core is data verification and status update. When the system receives two types of input, original data (status and instructions) and verification (for related verification of status and instructions), after the comparison calculation, output instructions (update status) and ZKP ( Verify the proof), submit L1 for consensus broadcast.

3. Workflow of ZKVM

According to JP Aumasson, Taurus , ZK verification goes through several parts:

1. Local computing.
2. The definition of operator/circuit. For example, verifying that your wallet has money, verify that the information is complete, and verify that the signature is correct.
3. Arithmetic verification. Use mathematical methods to verify that the calculation is executable.
4. Compare the arithmetic verification result with the actual result.
5. Submit the result to the chain.

Taking the Scroll solution as an example, we can see that starting from Geth, the system completes the local calculation, disassembles the transaction Trace (the historical log of the transaction) and converts it into a Circuits operator to wait for verification, and then uses an arithmetic method (such as polynomial disassembly). , cryptography) to obtain a proof of verification. Then compare the data and verify the proof, and if it is correct, it can be broadcast on the chain.

This involves many key technologies, such as how to set up Circuits, and what types of Circuits are there? How to verify Circuits? Common ones are CustomGate and Lookup Argument. The entire verification method can be imagined as a huge table, each variable has its parameters, in the context of known historical data, to find the inevitability of a specific result.

For example, if I want to verify that an account has 100 Yuan, the traditional blockchain method is to let each node confirm it once, but now I only need one node. On the premise of ensuring data integrity, find the nearest node. Net inflow of 100 yuan of vouchers, and then verify (the situation in the case is relatively simple, you can see at a glance, the actual situation requires mathematical operations.)

After the verification is completed, it can be proved that the account has 100 yuan, the difference is that the former requires a lot of Computation and verification, the latter only requires off-chain verification. In this example, the verification is “how to prove that the account has sufficient balance off-chain”, and the constraint required for verification is “when the net inflow of the account in the recent historical time axis is greater than 100, the balance reorganization is proved.” The Circuit operator is “ Check with the naked eye”.

The Principle of ZKVM design

According to the summary of MidenVM, the main tools used by Zkapp on the market are assembly languages based on WASM and RISC V, and some toolkits can make applications quickly labelled with the concept or label of “ZK”. However, if we dismantle the structure a little, we will find that the security of traditional smart contracts is guaranteed by L1, and the security of consensus formed by the whole network broadcast has been tested by history. However, with off-chain ZKP verification, there is a problem of whether the ZKP verification node is malicious.

Regardless of whether Devs can reasonably set up constraints, it is undoubtedly more important to prevent the malicious intention of ZKP verification nodes. For example, some ZK dex is more like finding a balance between Cex and Dex. Compared with Cex, users can keep funds in their L1 account; compared with Dex, they can have better efficiency performance.

However, in practice, a large number of projects have security risks of off-chain verification. In addition, since the APP layer to the IR layer is independently developed by the zkAPP team, every household has its own programming habits and wheel library, which also makes it difficult to form composability between teams, and is not conducive to accelerating the market division of labor and hardware. Acceleration of the device.

Therefore, market cracking looks for a common divisor between cryptography and high-level languages. To provide a general framework for various applications, and ZK-VM is an important part of adapting the entire system and linking the previous and the next.

EVM is quite similar to JVM in terms of execution model. Both are stack machines executing bytecodes. EVM adds a concept of storage and its bytecode instructions are more suited for contract development.

In the figure, we take ETH as an example. Traditional ETH consists of three parts, ETH network (node + consensus mechanism), EVM, and Dapp development ecology. Here we can clearly feel the role of ZK connecting the previous and the next:

1. From the perspective of the ZK circuit hardware layer, EVM may not be fully compatible. Since EVM has some variable-length instructions, such as CALL, DATACOPY, EXP, CREATE, etc., these are not friendly to ZK circuits.
2. From the developer’s point of view, whether it is not necessary to re-learn the language (Solidity is still compatible) and retain the API features of EVM. In this case, the entire ecosystem may lose support for some ZK algorithms.

In addition, ZKVM also needs to consider many technical compatibility, such as:

1. Register compatibility. Machine Type. The traditional EVM is a stack-based state machine, so a large number of computations are connected in series and cannot be parallelized, which ensures the atomicity of the entire computer. This architecture is very unfavorable for ZK. If you want to use the full efficiency of the ZK algorithm, you need to do a Register-Based, that is, to design the VM with the CPU-register as the core architecture.
2. Language compatibility. Function Calls. The VM system encapsulates the underlying features into an API, how to make the API support dynamic calls and support high-level languages like Python.
3. Compatibility with the bottom layer of the computer. Native Field. Different CPUs have different numbers of bits and perform differently on different algorithms. Need to plan for the ZK special computer.
4. Compatibility with traditional public chain structure. Sequencer/Roller/Miner. Since the tracer after log sorting has a greater impact on verification, Seqer is similar to the existence of DA in the ZK verification system (data custodian off-chain), and Roller is equivalent to a verification miner who is proficient in operator cryptography. Miner refers to traditional on-chain miners. How to position the division of labor among the three, maintain system flexibility, and prepare for future expansion requires careful planning.

How to design the architecture of ZKVM:

Typical Solutions

In what language, in what environment, with what hardware to execute? This is the problem to be solved by generalized VMs.

The most important kernel in the VM is LLVM (low-level-virtual-machine), which can be regarded as the most important kernel of the compiler. The picture shows the operation scheme of the original EVM. The smart contract is converted into Bytecode through the intermediate code of LLVM IR. These Bytecodes will be stored on the blockchain. When the smart contract is called, the Bytecode will be converted into the corresponding Opcode, and then executed by the EVM and node hardware.

Combined with ZK, how are the various solutions implemented?

Starkware:

Because Starkware started early in the entire ZK field, and has accumulated sufficient technology, Starkware has a certain technological leadership. He is a representative ZK-centric technical architecture, building the Cairo VM and Cairo’s language around ZK. But because it is closed source, some technical details are not clear. The downside is the learning cost of Cairo. Although the official has also developed some frameworks for Solidity to convert Cairo, but because its underlying core is built on CairoVM, it means that a considerable number of Solidity-EVM compatible features will be lost.

ZKsync:

ZKsync framework is compatible with the features of both EVM and ZK , Solidity and its own development of the circuit language Zinc to do a fusion , the compiler internal unification of the two at the IR level . The advantage is that the compiler kernel LLVM can be compatible with multiple languages. zksync is also closed source framework.

Hermez by Polygon

Scroll

• The two technical solutions of HermZ and Scroll are more focused on the Ethereum ecosystem. They have integrated with the ETH ecosystem on Bytecode. Since EVM naturally supports bytecode and its corresponding opcode, the two have a higher integration with the ETH ecosystem. Solidity can fully call the API of EVM on these two Zkvms, and retain the architectural advantages of EVM to the greatest extent.
• The difference between the two schemes is that Hermz will unify the opcode internally and then verify it; while Scroll will disassemble the Opcode circuit for verification and then integrate it. Why Choose Compatible EVM? Because some of the architectures in the EVM have been tested, the security is better and the compatibility is better. For example, the Geth model and the RPC architecture, these APIs have been well encapsulated by EVM and have been historically tested.

In summary, the bottom layer of Starkware is unified at the WASM and machine code levels, ZKsync is unified at the IR level at the shallowest level, and Hermz and Scroll are unified at the Bytecode level.

Starkware has the most thorough technological transformation, but also has the highest learning threshold for users; while Zksync is relatively balanced, retaining some solidity features and exerting local ZK performance;

Hermz and Scroll are relatively easy to apply and disassemble, fully integrate Bytecode, integrate EVM, Especially Scroll, which opens ZK verification, also gives more space for hardware acceleration. Relatively speaking, whether it is driven by technology or driven by ecological integration, both have their own development space in the future. Both “trade, industry and technology” and “technology, industry and trade” have the opportunity to find their own scenarios and exert greater value.

If we look back at the history of Windows, before the emergence of a powerful operating system, different developers needed to master different development tools for different hardware. Developers who do not master assembly and do not understand the underlying computer will encounter many setbacks in the development process. The operating system looks for the largest common divisor in the hardware and encapsulates the I/O system other than the CPU into a unified interface.

The accumulation of these technologies greatly reduces the threshold for software development, and also makes most programmers only need to understand advanced The language is enough, even if you don’t have assembly and low-level code knowledge, you can still write beautiful apps. Looking at the development of ZKVM, we can see some clues. If the current ZKapp requires traditional programmers + assembly + cryptography knowledge reserves to develop, in the future, with the maturity of ZKVM, more and more underlying technologies will be packaged into advanced Among languages, the development threshold is gradually lowered, and ecological prosperity is conceivable.

For Founder, there are two tips:

1. ZK technology converts on-chain consensus to off-chain verification. At present, the verification technology is not mature, and relevant audit institutions and testing tools are blank.
2. The usacase of ZK technology are yet to be explored. The general-purpose ZKVM is in full swing, and the high-level language corresponding to ZK also needs to be learned by technicians. It will take a long time from the maturity of the technology to solving the problem. If you want to use ZK to solve the problem, the founder needs to answer: If it is a sub-scenario, do you need to use WASM to build it yourself? Once ZKVM matures, will your own technology accumulation still have a first-mover advantage? Does it support modularity?

Outlook and Conclusion

ZK’s technology has two main usage scenarios: privacy and expansion. When we discuss privacy, we are actually protecting off-chain data from being acquired; and when we discuss expansion, we use ZK to save the chain. computing space.

1. The core trade-off technology and devs of ZKVM development. Revolving around the potential of ZK means hardware acceleration of CPU registers, reorganization of IR language and assembly language; and around the use of developer resources, it means how to perform ZK verification on the opcode mapped by Bytecode after Solidity converts bytecode The problem.
2. The special-purpose ZKapp independently designed for ZK verification in assembly language will face great obstacles in the future development process due to its low composability and decoupling capabilities. These schemes are incompatible with other ZK schemes due to their incompatibility with VM, language, and verification, so there is a greater difficulty in calling.
3. According to the viewpoint of modular blockchain, L1 solves the consensus problem, L2 solves the calculation and execution problem, and the DA layer solves the problem of data availability and integrity. Due to the L2 verification dependency of the Zk class, the transaction log of the time series, the data security and the integrity of the verification determine the reliability of its execution. Then we found a pair of contradictions. If we do not trust the off-chain nodes and want to hand over the data to DA for independent storage, the off-chain data may lose its privacy characteristics; if it exists locally, if the data is guaranteed not to be tampered with, the verification node will not go do evil. Both of these requirements place higher demands on the practice of MPC/FHE.
4. In the current state of most closed-source ZK solutions, a large amount of consensus is still based on the self-discipline of off-chain nodes, lacking a series of necessary tools (testing, verification, etc.) to ensure the security of the off-chain environment sex. In the future, constraint design and algebraic verification will become the two most important audit links.
5. The main risks of ZK ecology and the typical problems include: the constraint system cannot effectively constrain data, and when verifying some complex and intersecting propositions, the constraints are insufficient; private data is leaked, and private data is treated as public data; attacks on off-chain data, contracts Layer’s “metadata-attack”; ZK validating node’s evildoing, etc.
6. With the continuous maturity of different Circuit verifications,Sequencer/Roller/Miner will also usher in efficiency improvement and division of labor. We look forward to the hardware acceleration opportunity of ZK verification.

References

1. Shize J. & Li F. How program works. (Ren min you dian chu ban she, 2015).
2. https://zhuanlan.zhihu.com/p/39141067
3. The Zero Knowledge Frontier: On SNARKs, STARKs, and Future Applications. https://research.thetie.io/zero-knowledge-starks-snarks/
4. ZK Identity: Why and How (Part 1). https://0xparc.org/blog/zk-id-1
5. ZK Identity: Why and How (Part 2). https://0xparc.org/blog/zk-id-2
6. https://twitter.com/LuozhuZhang/status/1523603947809693697
7. Hermez Team. Jordi Baylina : ZK-EVM. https://www.youtube.com/watch?v=17d5DG6L2nw
8. Introducing Hermez zkEVM. https://blog.hermez.io/introducing-hermez-zkevm/
9. ZKEVM EVM Circuit Explore. https://hackmd.io/@liangcc/zkvmbook/%2Fq8EhMIp_TimpPWWFXtwOVw
10. Ethereum EVM illustrated. Exploring some mental models and implementations. https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf
11. Introduction to ZKPs slides video. https://www.youtube.com/watch?v=AaEPRKmVazk&list=PLOEty2U8Y69UWNCoQbe__zs4Fiv4J9DAe&index=4
12. Fundamentals of Zero Knowledge: Scaling Ethereum with STARKs. https://www.youtube.com/watch?v=AaEPRKmVazk&list=PLOEty2U8Y69UWNCoQbe__zs4Fiv4J9DAe&index=4
13. ZK HACK #5 — Introduction to Aztec Connect. https://www.youtube.com/watch?v=Cs9cI2v1hdE
14. zkStudyClub: Zero-Knowledge Proofs Security, in Practice [JP Aumasson, Taurus]. https://www.youtube.com/watch?v=l_pIrHVz87I
15. https://twitter.com/LuozhuZhang/status/1521124870385405953?s=20&t=tAtoypY5N_lbOBYKd86dlQ
16. Zero knowledge, from proofs to rollups. https://github.com/thecryptofruit/education/blob/master/zk-proofs-rollups.md.
17. ZK7: Structuring Computation for Privacy-Preserving Apps — Wei Dai — Bain Capital Crypto. https://www.youtube.com/watch?v=W93SMLywRT4
18. ZK Hack Mini #1 — Introduction to Miden VM https://www.youtube.com/watch?v=Q8xYSOx82U0
19. Polygon Hermez Fireside Chat. https://www.youtube.com/watch?v=dcR1lbJCqP8
20. Navigating Privacy on Public Blockchains. https://wdai.us/posts/navigating-privacy/

Disclaimer: This research article is opinion/insights only, it should not be viewed as financial or investment advices in any form. Readers are advised to do their own research and analyze the market on their own.

Author: Yolo Shen, and special thanks to Nicole and ZhangYe for their valuable inputs throughout the writing process.

Contact Us: Website | Email Us |Twitter