作者: YBB Capital Researcher Zeke
TL;DR
The ZK coprocessor can be seen as an off-chain computing plug-in derived from the concept of modularity. Its function is similar to the GPU in our traditional computers that shares graphics computing tasks with the CPU, that is, a processor that shares computing tasks in specific scenarios.
It can be used to process complex calculations and heavy data, reduce gas fees, and expand smart contract functions;
Difference from Rollup: ZK coprocessor is stateless, can be used across chains, and is suitable for complex computing scenarios;
The development of ZK coprocessors is difficult, has high performance overhead, and lacks standardization. The hardware also requires a lot of cost. Although this track has matured a lot compared to a year ago, it is still in its early stages.
As infrastructure enters the era of modularization with fractal expansion, blockchain is faced with a variety of problems such as lack of liquidity, scattered users, lack of innovation and cross-chain interoperability, which creates a paradox with vertical expansion of L1. In the future, the ZK coprocessor may be able to provide a good reinforcement for both, allowing both to jump out of the predicament, and provide performance support for old applications and emerging heavy applications, bringing more fresh narratives.
1. Another branch of modular infrastructure, ZK coprocessor
1.1 ZK Coprocessor Overview
The ZK coprocessor can be seen as an off-chain computing plug-in derived from the concept of modularization. Its function is similar to the GPU in our traditional computers that shares graphics computing tasks with the CPU, that is, a processor that shares computing tasks in specific scenarios. Under this design framework, the "heavy data" and "complex computing logic" tasks that the public chain is not good at can be calculated through the ZK coprocessor. The chain only needs to receive the returned calculation results, and its correctness is guaranteed by the ZK proof, ultimately realizing the trusted off-chain computing of complex tasks.
At present, popular applications such as AI, SocialFi, DEX, and GameFi have an urgent need for high performance and cost control. In traditional solutions, these "heavy applications" that require high performance often choose the form of asset on-chain + off-chain application, or design an application chain for the application alone. However, both have some inherent problems, such as the former has a black box, and the latter has high development costs, separation from the original chain ecology, and liquidity fragmentation. In addition, the main chain virtual machine also has great restrictions on the development and operation of such applications (for example, lack of application layer standards and complex development languages).
The existence of ZK coprocessor is to solve such problems. To give a more detailed example, we can regard the blockchain as a terminal (mobile phone, computer, etc.) that cannot be connected to the Internet. In this case, we can run some relatively simple applications, such as DeFi applications such as Uniswap, which can run completely on the chain. But when more complex applications appear, such as running an application like ChatGPT, the performance and storage of the public chain will be completely insufficient, and the gas will explode. In the case of Web2, the same is true when we run ChatGPT. The common terminal itself cannot handle a large language model such as GPT-4o. We need to communicate the problem to OpenAI's server through the Internet. After the server calculates the inference result, we will receive the answer directly. The ZK coprocessor is similar to the remote server of the blockchain, but in the case of different types of projects, the design of different coprocessor projects may have some deviations, but the underlying logic will not be too different. They are all verified by off-chain calculation + ZK proof or Storage proofs. Taking Rise Zero’s Bonsai deployment as an example, we can see that the logic of this architecture is very simple. The project is seamlessly integrated into Rise Zero’s own zkVM. Developers only need two simple steps to use Bonsai as a coprocessor:
Write a zkVM application to handle the application logic;
Write a Solidity contract that asks Bonsai to run your zkVM application and process the results.
1.2 What is the difference from Rollup?
In the above definition, we can find that Rollup seems to have a high degree of overlap with the ZK coprocessor in terms of both implementation logic and goals. But in fact, Rollup is more like the multi-core of the main chain. The specific differences between the two are as follows:
1. Main purpose:
Rollup: Improve the transaction throughput of the blockchain and reduce transaction fees.
ZK Coprocessor: Expands the computing power of smart contracts, enabling them to handle more complex logic and larger amounts of data.
2. Working principle:
Rollup: Aggregate on-chain transactions and submit them to the main chain through fraud proof or ZK proof.
ZK coprocessor: Similar to ZK Rollup, but the application scenarios are different. ZK Rollup is limited by the form and rules of the chain and is not suitable for the work of ZK coprocessor.
3. State management:
Rollup: Need to maintain its own status and synchronize with the main chain regularly.
ZK coprocessor: does not maintain persistent state, and each calculation is stateless.
4. Application scenarios:
Rollup: Mainly aimed at the C-end, suitable for high-frequency trading.
ZK coprocessor: mainly for the B-side, suitable for scenarios requiring complex calculations, such as advanced financial models, big data analysis, etc.
5. Relationship with the main chain:
Rollup: can be seen as an extension of the main chain, usually focused on a specific blockchain network.
ZK coprocessor: It can provide services for multiple blockchains and is not limited to a specific main chain, so it can also provide services for Rollup.
Therefore, the two are not mutually exclusive in essence, and even have a complementary relationship. Even if a Rollup exists in the form of an application chain, the ZK coprocessor can still provide services.
1.3 Use Cases
Theoretically, the application scope of ZK coprocessor is very broad, and it can basically cover projects in all tracks of blockchain. The existence of ZK coprocessor can make the functions of Dapp closer to the functions of Web2 centralized apps. The following are some demonstration use cases collected from the Internet:
Data-driven DApp development
The ZK coprocessor enables developers to create data-driven DApps that leverage historical data from the entire chain and perform complex calculations without the need for additional trust assumptions. This brings unprecedented possibilities to DApp development, such as:
Advanced Data Analysis: On-chain data analysis capabilities similar to Dune Analytics.
Complex business logic: Implement complex algorithms and business logic in traditional centralized applications.
Cross-chain applications: Build cross-chain DApps based on multi-chain data.
VIP Trader Program for DEX
A typical application scenario is to implement a volume-based fee discount program in a decentralized exchange (DEX), namely the "VIP trader loyalty program". Such programs are common in centralized exchanges (CEX), but rare in DEX.
Using the ZK coprocessor, DEX can:
Tracking historical transaction volume of users
Calculate the user's VIP level
Dynamically adjust transaction fees based on tier
This functionality can help DEX improve user retention, increase liquidity, and ultimately boost revenue.
Data Augmentation for Smart Contracts
The ZK coprocessor can serve as a powerful middleware to provide data capture, computation, and verification services for smart contracts, thereby reducing costs and improving efficiency. This enables smart contracts to:
Access and process large amounts of historical data
Perform complex off-chain computations
Implementing more advanced business logic
Cross-chain bridge technology
Some ZK-based cross-chain bridge technologies, such as Herodotus and Lagrange, can also be considered as an application of ZK coprocessors. These technologies focus on data extraction and verification, providing a trusted data foundation for cross-chain communication.
1.4 ZK coprocessor is not perfect
Although we have listed many advantages, the current ZK coprocessor is not perfect and still faces many problems. I personally summarize the following points:
1. Development: The concept of ZK is difficult for many developers to understand. Development also requires relevant cryptographic knowledge and mastery of specific development languages and tools.
2. High hardware cost: The ZK hardware used for off-chain computing needs to be fully borne by the project party itself. ZK hardware is expensive and is still undergoing rapid development and iteration. The hardware may be eliminated at any time. Whether this can form a closed loop in business logic is also a question worth considering;
3. Crowded track: There will not be much difference in technical implementation, and the final situation is likely to be similar to the current Layer 2 situation, with a few outstanding projects but most of them being ignored;
4. zk circuits: Executing off-chain computations in a zk coprocessor requires converting traditional computer programs into zk circuits. Writing custom circuits for each application is cumbersome, and using zkvm to write circuits in a virtual machine has the problem of high overhead due to different computational models.
2. Key pieces of the puzzle leading to large-scale applications
(This chapter is highly subjective and only represents the author's personal views)
This round is dominated by modular infrastructure. If the modular path is correct, then this cycle may be the last step towards large-scale applications. However, at the current stage, we all have a common feeling: why can we only see some old wine in new packaging applications, why are there many more chains than applications, and why new token standards such as inscriptions can be called the biggest innovation of this round?
The reason why there is such a lack of fresh narratives is that the current modular infrastructure is not enough to support super applications, especially the lack of some prerequisites (full-chain interoperability, user threshold, etc.), which has indirectly contributed to the biggest split in the history of blockchain. As the core of the modular era, Rollup is faster, but it also brings many corresponding problems, that is, the liquidity split, user dispersion, and the chain or virtual machine itself that we have repeatedly emphasized above still limit application innovation. On the other hand, Celestia, another "key man" of modularization, pioneered the precedent that DA does not have to be on Ethereum, and this idea has further aggravated the split. Whether it starts with ideology or DA cost, the result is that BTC is forced to do DA, and other public chains have to do more cost-effective DA. The current situation is that there are at least one and dozens of Layer2 projects on each public chain. Finally, all infrastructure and ecological project parties have deeply learned the gameplay of points dragon slaying (OpenSea) pioneered by Blur (Tieshun), requiring users to pledge tokens in the project. This model of killing three birds with one stone for whales (interest, ETH or BTC rise, free tokens) has further compressed the liquidity on the chain.
In the previous bull market, funds would only flow in a few to a dozen public chains, and it can even be said that they were only concentrated in Ethereum. But now funds are scattered across hundreds of public chains and pledged in thousands of similar projects. The prosperity on the chain is no longer there, and even Ethereum has no on-chain activities. So it is helpless for Eastern players to PVP in the BTC ecosystem and Western players to PVP in Solana. So what I am most concerned about at the moment is how to promote the aggregation of full-chain liquidity and how to support the birth of new gameplay and super applications. In the full-chain interoperability track, the traditional head projects have actually been performing poorly, and they are still more like traditional cross-chain bridges. The new interoperability solution has also been discussed in our previous research report, mainly by aggregating multiple chains into a single chain. Currently, there are AggLayer, Superchain, Elastic Chain, JAM, etc., which will not be expanded here.
In short, the aggregation of the entire chain is a hurdle that must be overcome under the modular structure, but this hurdle will take a long time to overcome. The ZK coprocessor is a more critical puzzle in the current stage. In addition to strengthening Layer2, it can also strengthen Layer1. Is it possible to temporarily jump out of the two problems of the entire chain and the triangle paradox, and implement some applications that are in line with the current situation on some Layer1 or Layer2 with extensive liquidity in the future? After all, the current blockchain application narrative is really scarce. On the other hand, to achieve the diversification of gameplay, the control of Gas, the emergence of large-scale applications, and even cross-chain, and to lower the user threshold, the integrated coprocessor solution will also be a more ideal solution than relying on centralization.
3. Project List
The ZK coprocessor track basically emerged around 2004 and is relatively mature at the current stage. According to Messari's classification, the existing projects in this track can be divided into three major vertical fields (general computing, interoperability and cross-chain, AI and machine training), with 18 projects. Most of these projects are supported by top VCs. We will select some projects in different vertical fields for description below.
3.1 Human
Giza is a zkML (zero-knowledge machine learning) protocol deployed on Starknet and officially supported by StarkWare, focusing on enabling AI models to be verifiably used in blockchain smart contracts. Developers can deploy AI models to the Giza network, which then verifies the correctness of the model's reasoning through zero-knowledge proofs and provides the results to smart contracts in a trustless manner. This enables developers to build on-chain applications that incorporate AI capabilities while maintaining the decentralization and verifiability of the blockchain.
Giza completes the workflow by performing the following three steps:
Model conversion: Giza converts the commonly used ONNX format AI model into a format that can be run in a zero-knowledge proof system. This allows developers to train the model using familiar tools and then deploy it to the Giza network.
Off-chain reasoning: When a smart contract requests AI model reasoning, Giza performs the actual computation off-chain. This avoids the high cost of running complex AI models directly on the blockchain.
Zero-knowledge verification: Giza generates a ZK proof for each model inference to prove that the calculation was performed correctly. These proofs are verified on the chain to ensure the correctness of the inference results without repeating the entire calculation process on the chain.
Giza's approach allows AI models to be used as a trusted input source for smart contracts without relying on centralized oracles or trusted execution environments. This opens up new possibilities for blockchain applications, such as AI-based asset management, fraud detection, and dynamic pricing. It is one of the few logically closed-loop projects in the current Web3 x AI, and is also a great use of co-processing in the field of AI.
3.2 Zero Heating
Risc Zero is a coprocessor project supported by several top VCs and is one of the best in this field. The project focuses on enabling arbitrary calculations to be verifiably executed in blockchain smart contracts. Developers can write programs in Rust and deploy them to the RISC Zero network, which then verifies the correctness of program execution through zero-knowledge proofs and provides the results to smart contracts in a trustless manner. This enables developers to build complex on-chain applications while maintaining the decentralization and verifiability of the blockchain.
We have briefly described the deployment and work process above. Here we will describe two key components in detail:
Bonsai: RISC Zero's Bonsai is a coprocessor component in the project. It is seamlessly integrated into the zkVM of the RISC-V instruction set architecture, allowing developers to quickly integrate high-performance zero-knowledge proofs into Ethereum, L1 blockchain, Cosmos application chain, L2 rollups and dApps within a few days, providing direct smart contract calls, verifiable off-chain computing, cross-chain interoperability and general rollup functions. At the same time, it adopts a decentralized first distributed architecture design, combined with recursive proofs, custom circuit compilers, state continuation and continuously improved proof algorithms, enabling anyone to generate high-performance zero-knowledge proofs for various applications.
zKVM: zkVM is a verifiable computer that works like a real embedded RISC-V microprocessor. Based on the RISC-V instruction set architecture, the virtual machine allows developers to use multiple programming languages such as Rust, C++, Solidity, Go and other high-level programming languages to write programs that can generate zero-knowledge proofs. It supports more than 70% of popular Rust crates, and realizes the seamless combination of general computing and zero-knowledge proofs. It can generate efficient zero-knowledge proofs for calculations of arbitrary complexity while maintaining the privacy of the calculation process and the verifiability of the results. zkVM uses ZK technologies including STARK and SNARK, and realizes efficient proof generation and verification through components such as Recursion Prover and STARK-to-SNARK Prover, supporting off-chain execution and on-chain verification modes.
Risc Zero has integrated with multiple ETH Layer2s and demonstrated multiple Bonsai use cases, among which the more interesting one is Bonsai Pay. The demonstration uses RISC Zero's zkVM and Bonsai proof service to allow users to send or withdraw ETH and tokens on Ethereum using a Google account. It shows how RISC Zero can seamlessly integrate on-chain applications with OAuth2.0 (the standard used by major identity providers such as Google), which is an integrated use case that reduces the threshold for Web3 users through traditional Web2 applications. In addition, there are examples based on applications such as DAO.
3.3 =nil;
=nil; is invested by well-known projects and institutions such as Mina, Polychain, Starkware, and Blockchain Capital. It is worth noting that Mina and Starkware, which are at the forefront of zk technology, are also among them, indicating that the technical recognition of the project is still relatively high. =nil; is also a project mentioned in our research report "Computing Power Market". At that time, it was mainly focused on =nil;'s Proof Market (decentralized proof generation market). The project actually has a sub-product, zkLLVM.
zkLLVM is an innovative circuit compiler developed by the =nil; Foundation. It can automatically convert application code written in mainstream development languages such as C++ and Rust into efficient provable circuits on Ethereum without the use of specialized zero-knowledge domain-specific languages (DSL), thereby greatly simplifying the development process and lowering the development threshold. At the same time, it improves performance by not involving zkVM (zero-knowledge virtual machine), supports hardware acceleration to speed up proof generation, and is suitable for a variety of ZK application scenarios such as Rollups, cross-chain bridges, oracles, machine learning, and games. It is tightly integrated with the =nil; Foundation's Proof Market to provide developers with end-to-end support from circuit creation to proof generation.
3.4 Brevis
The project is a sub-project of Celer Network. Bervis is an intelligent zero-knowledge (ZK) coprocessor for blockchains that enables dApps to access, compute, and utilize arbitrary data across multiple blockchains in a completely trustless manner. Like other coprocessors, Brevis also has a wide range of use cases, such as data-driven DeFi, zkBridges, on-chain user acquisition, zkDID, and social account abstraction.
The architecture of Brevis consists of three main parts:
zkFabric: zkFabric is the repeater of the Brevis architecture. Its main task is to collect and synchronize block header information from all connected blockchains, and finally generate consensus proofs for each collected block header through the ZK light client circuit.
zkQueryNet: zkQueryNet is an open ZK query engine market that can directly accept data queries from on-chain smart contracts and generate query results and corresponding ZK query proofs through ZK query engine circuits. These engines range from highly specialized (such as calculating the transaction volume of a DEX in a specific time period) to highly general data indexing abstractions and high-level query languages to meet a variety of application needs.
zkAggregatorRollup: Acts as the aggregation and storage layer for zkFabric and zkQueryNet. It verifies the proofs of these two components, stores the proven data, and submits its ZK-proven state root to all connected blockchains, allowing dApps to access proven query results directly in the business logic of their on-chain smart contracts.
Through this modular architecture, Brevis can provide trustless, efficient and flexible access to smart contracts on all supported public chains. This project was also adopted in the V4 version of UNI and integrated with Hooks in the protocol (a system for integrating customized logic for various users) to facilitate reading historical blockchain data, reduce Gas fees, and ensure decentralized properties. This is an example of how the zk coprocessor promotes DEX.
3.5 Lagrange
Lagrange is an interoperable zk coprocessor protocol led by 1kx and Founders Fund. The main purpose of the protocol is to provide trustless cross-chain interoperability and innovation support for applications that require complex computing of big data. Unlike traditional node bridges, Lagrange's cross-chain interoperability is mainly achieved through its innovative ZK Big Data and State Committee mechanisms.
ZK Big Data: This product is the core of Langrange and is mainly responsible for processing and verifying cross-chain data and generating related ZK proofs. This component includes a highly parallel ZK Coprocessor for performing complex off-chain calculations and generating zero-knowledge proofs, a specially designed verifiable database that supports unlimited storage slots and direct SQL queries for smart contracts, a dynamic update mechanism that only updates changed data points to reduce proof time, and an integrated function that allows developers to access historical data directly from smart contracts using SQL queries without writing complex circuits, together forming a large-scale blockchain data processing and verification system.
State Committee: This component is a decentralized verification network consisting of multiple independent nodes, each of which pledges ETH as collateral. These nodes act as ZK light clients and specialize in verifying the status of specific optimized rollups. State Committee is integrated with EigenLayer's AVS, using a heavy pledge mechanism to enhance security, supporting an unlimited number of nodes to participate, and achieving superlinear security growth. It also provides a "fast mode" that allows users to perform cross-chain operations without waiting for the challenge window, greatly improving the user experience. The combination of these two technologies enables Lagrange to efficiently process large-scale data, perform complex calculations, and securely transmit and verify results between different blockchains, providing support for the development of complex cross-chain applications.
Lagrange has been integrated with EigenLayer, Mantle, Base, Frax, Polymer, LayerZero, Omni, AltLayer, etc., and will also be linked as the first ZK AVS in the Ethereum ecosystem.
