TLDR

• ZK Coprocessors can be seen as off-chain computing plugins derived from the modular concept, similar to GPUs in traditional computers that offload graphics computing tasks from the CPU, handling specific computational tasks.
• They can be used to handle complex computations and heavy data, reducing gas fees and extending smart contract functionality.
• Unlike Rollups, ZK Coprocessors are stateless, can be used across chains, and are suitable for complex computational scenarios.
• Developing ZK Coprocessors is challenging, with high performance costs and a lack of standardization. Hardware costs are also substantial. Although the field has matured significantly compared to a year ago, it is still in the early stages.
• As the modular era progresses into fractal scaling, blockchain faces issues like liquidity shortages, dispersed users, lack of innovation, and cross-chain interoperability problems, creating a paradox with vertically scaled L1 chains. ZK Coprocessors may offer a way to overcome these challenges, providing support for both existing and emerging applications and bringing new narratives to the blockchain space.

I. Another Branch of Modular Infrastructure: ZK Coprocessors

1.1 Overview of ZK Coprocessors

ZK Coprocessors can be considered as off-chain computing plugins derived from the modular concept, similar to how GPUs offload graphical computing tasks from CPUs in traditional computers, handling specific computational tasks. In this design framework, tasks that public chains are not adept at, such as “heavy data” and “complex computational logic,” can be computed by ZK Coprocessors, with the chain only receiving the returned computation results. Their correctness is guaranteed by ZK proofs, ultimately achieving trusted off-chain computation for complex tasks.

Currently, popular applications like AI, SocialFi, DEX, and GameFi have a pressing need for high performance and cost control. In traditional solutions, these “heavy applications” requiring high performance often opt for asset on-chain + off-chain application models or design a separate application chain. However, both approaches have inherent issues: the former has a “black box,” and the latter faces high development costs, detachment from the original chain ecosystem, and fragmented liquidity. Additionally, the main chain virtual machine imposes significant limitations on the development and operation of such applications (e.g., lack of application layer standards, complex development languages).

ZK Coprocessors aim to solve these issues. To provide a more detailed example, we can think of the blockchain as a terminal (such as a phone or computer) that cannot connect to the internet. In this scenario, we can run relatively simple applications, like Uniswap or other DeFi applications, fully on-chain. But when more complex applications appear, such as running a ChatGPT-like application, the public chain’s performance and storage will be completely insufficient, leading to gas explosions. In the Web2 scenario, when we run ChatGPT, our common terminal itself cannot handle the GPT-4o large language model; we need to connect to OpenAI’s servers to relay the question, and after the server computes and infers the result, we directly receive the answer. ZK Coprocessors are like blockchain’s remote servers. While different coprocessor projects might have slight design differences depending on the project type, the underlying logic remains broadly similar — off-chain computation + ZK proofs or Storage proofs for validation.

Taking Rise Zero’s Bonsai deployment as an example, this architecture is very straightforward. The project seamlessly integrates into Rise Zero’s own zkVM, and developers only need two simple steps to use Bonsai as a coprocessor:

• Write a zkVM application to handle application logic.
• Write a Solidity contract to require Bonsai to run your zkVM application and handle the results.

1.2 Differences from Rollups

From the definitions above, it may appear that Rollups and ZK Coprocessors have highly overlapping implementation logic and goals. However, Rollups are more like multi-core expansions of the main chain, with the specific differences between the two as follows:

1.Primary Purpose:

• Rollups: Enhance blockchain transaction throughput and reduce transaction fees.
• ZK Coprocessors: Extend smart contract computational capabilities to handle more complex logic and larger data volumes.

2.Operating Principle:

• Rollups: Aggregate on-chain transactions and submit them to the main chain with fraud proofs or ZK proofs.
• ZK Coprocessors: Similar to ZK Rollups, but designed for different application scenarios. ZK Rollups, due to chain-specific constraints and rules, are not suitable for coprocessor tasks.

3.State Management:

• Rollups: Maintain their state and periodically sync with the main chain.
• ZK Coprocessors: Stateless, each computation is stateless.

4.Application Scenarios:

• Rollups: Primarily serve end-users, suitable for high-frequency transactions.
• ZK Coprocessors: Primarily serve businesses, suitable for scenarios requiring complex computations, such as advanced financial models and big data analysis.

5.Relationship with the Main Chain:

• Rollups: Viewed as extensions of the main chain, usually focused on specific blockchain networks.
• ZK Coprocessors: Can serve multiple blockchains, not limited to specific main chains, and can also serve Rollups.

Thus, the two are not mutually exclusive but complementary. Even if a Rollup exists in the form of an application chain, ZK Coprocessors can still provide services.

1.3 Use Cases

Theoretically, the application scope of ZK Coprocessors is extensive, covering projects across various blockchain sectors. ZK Coprocessors enable Dapps to have functionalities closer to those of centralized Web2 apps. Here are some example use cases collected from online sources:

Data-Driven DApp Development:

ZK Coprocessors enable developers to create data-driven Dapps that utilize full on-chain historical data for complex computations without additional trust assumptions. This opens up unprecedented possibilities for Dapp development, such as:

• Advanced Data Analysis: On-chain data analysis functions similar to Dune Analytics.
• Complex Business Logic: Implementing complex algorithms and business logic found in traditional centralized applications.
• Cross-Chain Applications: Building cross-chain Dapps based on multi-chain data.

VIP Trader Program for DEXs:

A typical application scenario is implementing a fee discount program based on trading volume in DEXs, known as the “VIP Trader Loyalty Program.” Such programs are common in CEXs but rare in DEXs.

With ZK Coprocessors, DEXs can:

• Track users’ historical trading volumes.
• Calculate users’ VIP levels.
• Dynamically adjust trading fees based on VIP levels. This functionality can help DEXs improve user retention, increase liquidity, and ultimately enhance revenue.

Data Augmentation for Smart Contracts:

ZK Coprocessors can act as powerful middleware, providing 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.
• Implement more advanced business logic.

Cross-Chain Bridge Technology:

Some ZK-based cross-chain bridge technologies, such as Herodotus and Lagrange, can also be considered applications of ZK Coprocessors. These technologies focus primarily on data extraction and verification, providing a trusted data foundation for cross-chain communication.

1.4 ZK Coprocessors Are Not Perfect

Despite the numerous advantages, ZK Coprocessors at the current stage are far from perfect and face several issues. I have summarized the following points:

1. Development: The concept of ZK is difficult for many developers to grasp. Development requires related cryptographic knowledge and proficiency in specific development languages and tools.
2. High Hardware Costs: The ZK hardware used for off-chain computations must be entirely borne by the project itself. ZK hardware is expensive and rapidly evolving, making it likely to become obsolete at any time. Whether this can form a closed commercial loop is a question worth considering.
3. Crowded Field: Technically, there won’t be much difference in implementation, and the end result may resemble the current Layer2 landscape, where a few prominent projects stand out while the rest are largely overlooked.
4. ZK Circuits: Executing off-chain computations in ZK Coprocessors requires converting traditional computer programs into ZK circuits. Writing custom circuits for each application is cumbersome, and using zkVMs in virtual machines to write circuits presents significant computational overhead due to differing computational models.

II. A Critical Piece for Mass Adoption

(This section is highly subjective and represents only the author’s personal views.)

This cycle is primarily led by modular infrastructure. If modularization is the correct path, this cycle might be the final step toward mass adoption. However, at the current stage, we all share a common sentiment: why do we only see some old applications repackaged, why are there more chains than applications, and why is a new token standard like inscriptions being hailed as the greatest innovation of this cycle?

The fundamental reason for the lack of fresh narratives is that the current modular infrastructure is insufficient to support super applications, especially lacking some prerequisites (cross-chain interoperability, user barriers, etc.), leading to the most significant fragmentation in blockchain history. Rollups, as the core of the modular era, have indeed sped things up, but they have also brought numerous issues, such as liquidity fragmentation, user dispersion, and limitations imposed by the chain or virtual machine itself on application innovation. Additionally, another “key player” in modularization, Celestia, has pioneered the path of DA not necessarily being on Ethereum, further exacerbating fragmentation. Whether driven by ideology or DA costs, the result is that BTC is forced to become DA, and other public chains aim to provide more cost-effective DA solutions. The current situation is that each public chain has at least one, if not dozens, of Layer2 projects. Adding to this, all infrastructure and ecosystem projects have deeply learned the token staking strategy pioneered by Blur, demanding users to stake tokens within the project. This mode, which benefits whales in three ways (interest, ETH or BTC appreciation, and free tokens), further compresses on-chain liquidity.

In the past bull markets, funds would only flow within a few to a dozen public chains, even concentrating mainly on Ethereum. Now, funds are dispersed across hundreds of public chains and staked in thousands of similar projects, leading to a decline in on-chain activity. Even Ethereum lacks on-chain activity. As a result, Eastern players engage in PVP in the BTC ecosystem, while Western players do so in Solana, out of necessity.

Therefore, my current focus is on how to promote aggregated liquidity across all chains and support the emergence of new playstyles and super applications. In the cross-chain interoperability sector, traditional leading projects have consistently underperformed, still resembling traditional cross-chain bridges. New interoperability solutions we discussed in previous reports primarily aim to aggregate multiple chains into a single chain. Examples include AggLayer, Superchain, Elastic Chain, JAM, etc., which will not be elaborated on here. In summary, cross-chain aggregation is a necessary hurdle in modular infrastructure but will take a long time to overcome.

ZK Coprocessors are a critical piece in the current phase. They can strengthen Layer2 and complement Layer1. Is there a way to temporarily overcome cross-chain and trilemma issues, allowing us to realize some current-era applications on certain Layer1s or Layer2s with extensive liquidity? After all, blockchain applications lack fresh narratives. Furthermore, enabling diverse playstyles, gas control, large-scale applications, cross-chain capabilities, and reducing user barriers through integrated coprocessor solutions might be more ideal than relying on centralization.

III. Project Overview

The ZK Coprocessor field emerged around 2023 and has become relatively mature at this stage. According to Messari’s classification, this field currently encompasses three major vertical domains (general computing, interoperability and cross-chain, AI and machine training) with 18 projects. Most of these projects are supported by leading VCs. Below, we describe several projects from different vertical domains.

3.1 Giza

Giza is a zkML (zero-knowledge machine learning) protocol deployed on Starknet, officially supported by StarkWare. It focuses on enabling AI models to be verifiably used in blockchain smart contracts. Developers can deploy AI models on the Giza network, which then verifies the correctness of model inference through zero-knowledge proofs and provides the results to smart contracts in a trustless manner. This allows developers to build on-chain applications that combine AI capabilities while maintaining the decentralization and verifiability of the blockchain.

Giza completes the workflow through the following three steps:

• Model Conversion: Giza converts commonly used ONNX format AI models into a format that can run in a zero-knowledge proof system. This allows developers to train models using familiar tools and then deploy them on the Giza network.
• Off-Chain Inference: When a smart contract requests AI model inference, Giza performs the actual computation off-chain. This avoids the high costs of running complex AI models directly on the blockchain.
• Zero-Knowledge Verification: Giza generates ZK proofs for each model inference, proving that the computation was executed correctly. These proofs are verified on-chain, ensuring the correctness of inference results without repeating the entire computation process on-chain.

Giza’s approach allows AI models to serve as trusted input sources 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 projects in the current Web3 x AI space with a logical closed loop and a clever use of coprocessors in the AI field.

3.2 Risc Zero

Risc Zero is a leading coprocessor project supported by multiple top VCs. It focuses on enabling any computation to be verifiably executed in blockchain smart contracts. Developers can write programs in Rust and deploy them on the RISC Zero network. RISC Zero then verifies the correctness of program execution through zero-knowledge proofs and provides the results to smart contracts in a trustless manner. This allows developers to build complex on-chain applications while maintaining the decentralization and verifiability of the blockchain.

We briefly mentioned the deployment and workflow earlier. Here, we detail two key components:

• Bonsai: Bonsai is the coprocessor component within RISC Zero, seamlessly integrated into the zkVM of the RISC-V instruction set architecture. It allows developers to quickly integrate high-performance zero-knowledge proofs into Ethereum, L1 blockchains, Cosmos application chains, L2 rollups, and dApps within days. It offers direct smart contract calls, verifiable off-chain computation, cross-chain interoperability, and general rollup functionality, all while adopting a decentralized-first distributed architecture. Combining recursive proofs, custom circuit compilers, state continuation, and continuously improving proof algorithms, it enables anyone to generate high-performance zero-knowledge proofs for various applications.
• zkVM: The zkVM is a verifiable computer that operates similarly to a real embedded RISC-V microprocessor. Based on the RISC-V instruction set architecture, it allows developers to write programs in high-level programming languages like Rust, C++, Solidity, Go, etc., that can generate zero-knowledge proofs. Supporting over 70% of popular Rust crates, it seamlessly combines general computing and zero-knowledge proofs, capable of generating efficient zero-knowledge proofs for computations of any complexity while maintaining the privacy of the computation process and the verifiability of the results. The zkVM utilizes ZK technologies, including STARK and SNARK, and achieves efficient proof generation and verification through components like Recursion Prover and STARK-to-SNARK Prover, supporting off-chain execution and on-chain verification.

Risc Zero has integrated with multiple ETH Layer2 solutions and demonstrated various use cases for Bonsai. One interesting example is Bonsai Pay. This demonstration uses RISC Zero’s zkVM and Bonsai proof service, allowing users to send or withdraw ETH and tokens on Ethereum using their Google accounts. It showcases how RISC Zero can seamlessly integrate on-chain applications with OAuth2.0 (the standard used by major identity providers like Google), providing a use case that lowers the Web3 user barrier through traditional Web2 applications. Other examples include applications based on DAOs.

3.3 =nil;

=nil; is an investment project supported by renowned entities such as Mina, Polychain, Starkware, and Blockchain Capital. Notably, zk technology pioneers like Mina and Starkware are among the backers, indicating high technical recognition for the project. =nil; was also mentioned in our report “The Computing Power Market,” primarily focusing on the Proof Market (a decentralized proof generation market). Additionally, =nil; has another sub-product called zkLLVM.

zkLLVM, developed by the =nil; Foundation, is an innovative circuit compiler that automatically converts application code written in mainstream programming languages such as C++ and Rust into efficient, provable circuits for Ethereum without the need for specialized zero-knowledge domain-specific languages (DSL). This significantly simplifies the development process, lowers the entry barrier, and improves performance by avoiding zkVM. It supports hardware acceleration to speed up proof generation, making it suitable for various ZK application scenarios such as rollups, cross-chain bridges, oracles, machine learning, and gaming. It is closely integrated with =nil; Foundation’s Proof Market, providing developers with end-to-end support from circuit creation to proof generation.

3.4 Brevis

Brevis is a sub-project of Celer Network and is a smart zero-knowledge (ZK) coprocessor for blockchain, enabling dApps to access, compute, and utilize arbitrary data across multiple blockchains in a fully trustless manner. Like other coprocessors, Brevis has a wide range of use cases, such as data-driven DeFi, zkBridges, on-chain user acquisition, zkDID, and social account abstraction.

Brevis architecture consists of three main components:

• zkFabric: The zkFabric is the relay component of Brevis architecture. Its main task is to collect and synchronize block header information from all connected blockchains and then generate consensus proofs for each collected block header through the ZK light client circuit.
• zkQueryNet: zkQueryNet is an open ZK query engine marketplace that can directly accept data queries from on-chain smart contracts and generate query results and corresponding ZK query proofs through the ZK query engine circuit. These engines range from highly specialized (e.g., calculating the trading volume of a DEX over a specific period) to highly general data indexing abstractions and advanced query languages to meet various application needs.
• zkAggregatorRollup: It serves as the aggregation and storage layer for zkFabric and zkQueryNet. It verifies the proofs of these two components, stores the proven data, and submits the state roots of their ZK proofs to all connected blockchains, allowing dApps to directly access proven query results in their on-chain smart contract business logic.

With this modular architecture, Brevis can provide all supported public blockchain smart contracts with a trustless, efficient, and flexible access method. UNI’s V4 version also adopts this project and integrates it with Hooks (a system for integrating various user custom logic) to facilitate reading historical blockchain data, reduce gas fees, while ensuring decentralization. This is an example of a zk coprocessor promoting a DEX.

3.5 Lagrange

Lagrange is an interoperability zk coprocessor protocol led by 1kx and Founders Fund, primarily aimed at providing trustless cross-chain interoperability and supporting applications requiring large-scale data complex computation. 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 is the core product of Lagrange, responsible for processing and verifying cross-chain data and generating related ZK proofs. This component includes a highly parallel ZK coprocessor for executing complex off-chain computations and generating zero-knowledge proofs, a specially designed verifiable database supporting unlimited storage slots and direct SQL queries from smart contracts, a dynamic update mechanism that only updates changed data points to reduce proof time, and an integrated function allowing developers to use SQL queries directly from smart contracts to access historical data without writing complex circuits. Together, they form a large-scale blockchain data processing and verification system.
• State Committee: This component is a decentralized verification network composed of multiple independent nodes, each staking ETH as collateral. These nodes act as ZK light clients specifically verifying the state of certain optimized rollups. The State Committee integrates with EigenLayer’s AVS, leveraging the re-staking mechanism to enhance security, supporting an unlimited number of participating nodes to achieve superlinear security growth. It also provides a “fast mode,” allowing users to perform cross-chain operations without waiting for the challenge window, greatly improving user experience. The combination of these two technologies enables Lagrange to efficiently process large-scale data, perform complex computations, and securely transmit and verify results across different blockchains, supporting the development of complex cross-chain applications.

Lagrange has already integrated with EigenLayer, Mantle, Base, Frax, Polymer, LayerZero, Omni, AltLayer, among others, and will be the first ZK AVS to link within the Ethereum ecosystem.

About YBB

YBB is a web3 fund dedicating itself to identify Web3-defining projects with a vision to create a better online habitat for all internet residents. Founded by a group of blockchain believers who have been actively participated in this industry since 2013, YBB is always willing to help early-stage projects to evolve from 0 to 1.We value innovation, self-driven passion, and user-oriented products while recognizing the potential of cryptos and blockchain applications.

Website | Twi: @YBBCapital

References:

1.ABCDE：A Deep Dive into ZK Coprocessor and Its Future：https://medium.com/ABCDE.com/en-abcde-a-deep-dive-into-zk-coprocessor-and-its-future-1d1b3f33f946

2.“ZK” Is All You Need：https://medium.com/gate_ventures/zk-is-all-you-need-238886062c52

3.Risc zero：https://www.risczero.com/bonsai

4.Lagrange：https://www.lagrange.dev/blog/interoperability-for-modular-blockchains-the-lagrange-thesis

5.AxiomBlog：https://blog.axiom.xyz/

6.Nitrogen Acceleration! How ZK Coprocessor Breaks Down Smart Contract Data Barriers：https://foresightnews.pro/article/detail/48239

Disclaimer：

1. This article is reprinted from [medium], Forward the Original Title‘The GPU of Blockchain: Comprehensive Analysis of ZK Coprocessors’, All copyrights belong to the original author [YBB Capital Researcher Zeke]. 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.