Blockchain's GPU: Comprehensive Analysis of ZK Co-Processors

Author: YBB Capital Researcher Zeke

TLDR

• ZK Coprocessor can be seen as an off-chain computing plugin derived from the modular concept, similar to how GPUs share graphic computing tasks with CPUs in traditional computers, specifically designed to offload computing tasks in certain scenarios;

• It can be used to handle complex computations and heavy data, reduce gas fees, and expand the functionality of smart contracts;

• Difference from Rollup: ZK Coprocessors are stateless, can be used across chains, and are suitable for complex computing scenarios;

• The development of ZK Coprocessors is challenging, with high performance overhead and insufficient standardization. Additionally, the hardware aspect requires significant costs. Although this field has matured considerably compared to a year ago, it is still in its early stages;

• As infrastructure enters a modular era of fractal scaling, blockchains face various issues such as liquidity shortages, user dispersion, lack of innovation, and cross-chain interoperability, creating a paradox with vertically scaling L1s. ZK Coprocessors may provide strong support for both, helping them escape their predicaments and offering performance support for both legacy applications and emerging heavy applications, bringing fresh narratives.

I. Another Branch of Modular Infrastructure: ZK Coprocessor

1.1 Overview of ZK Coprocessor

ZK Coprocessor can be viewed as an off-chain computing plugin derived from the modular concept, functioning similarly to how GPUs assist CPUs with graphic computing tasks in traditional computers, specifically designed to offload computing tasks in certain scenarios. Within this design framework, tasks involving "heavy data" and "complex computational logic," which public chains are not adept at, can be computed using ZK Coprocessors. The blockchain only needs to receive the returned computation results, whose correctness is guaranteed by ZK proof, ultimately achieving trustworthy off-chain computation for complex tasks.

Currently, popular applications such as AI, SocialFi, DEX, and GameFi have an urgent need for high performance and cost control. In traditional solutions, these high-performance "heavy applications" often choose to use asset on-chain + off-chain applications, or design a dedicated application chain. However, both approaches have inherent issues; for instance, the former suffers from black box problems, while the latter faces high development costs, detachment from the original chain ecosystem, and liquidity fragmentation. Additionally, the main chain's virtual machine imposes significant limitations on the development and operation of such applications (e.g., lack of application layer standards, complex programming languages).

The existence of ZK Coprocessors aims to address these issues. To illustrate with a more detailed example, we can view the blockchain as a terminal (like a phone or computer) that cannot connect to the internet. In this case, we can run some relatively simple applications, such as DeFi applications like Uniswap, entirely on-chain. However, when more complex applications arise, such as running an application similar to ChatGPT, the performance and storage of public chains become completely insufficient, leading to gas explosions. In the Web2 context, we encounter similar situations when running ChatGPT; common terminals cannot handle large language models like GPT-4o. We need to connect to the internet to relay questions to OpenAI's servers, and after the server computes the reasoning results, we receive the answers directly. ZK Coprocessors are akin to remote servers for blockchains; however, in the case of different types of projects, the designs of different coprocessor projects may vary slightly, but the underlying logic remains largely the same, relying on off-chain computation + ZK proof or Storage proofs for verification. Taking the deployment of Rise Zero's Bonsai as an example, we can understand that this architecture's logic is quite straightforward. Developers only need to follow two simple steps to integrate Bonsai as a coprocessor:

• Write a zkVM application to handle application logic;

• Write a Solidity contract that requests Bonsai to run your zkVM application and process the results.

1.2 How is it different from Rollup?

In the definitions above, we find that Rollup seems to overlap significantly with ZK Coprocessors in terms of implementation logic and goals. However, Rollup is more akin to the multi-core processing of the main chain, with the specific differences between the two as follows:

1. Main Purpose:

• Rollup: Increase the transaction throughput of the blockchain and reduce transaction fees.

• ZK Coprocessor: Expand the computational capabilities of smart contracts to handle more complex logic and larger amounts of data.

1. Working Principle:

• Rollup: Aggregates on-chain transactions to the main chain through fraud proofs or ZK proofs.

• ZK Coprocessor: Similar to ZK Rollup, but the application scenarios differ; ZK Rollup is constrained by the chain's form and rules, making it unsuitable for ZK Coprocessor tasks.

1. State Management:

• Rollup: Needs to maintain its own state and periodically synchronize with the main chain.

• ZK Coprocessor: Does not maintain persistent state; each computation is stateless.

1. Application Scenarios:

• Rollup: Primarily aimed at C-end users, suitable for high-frequency trading.

• ZK Coprocessor: Primarily aimed at B-end users, suitable for scenarios requiring complex computations, such as advanced financial models and big data analysis.

1. Relationship with the Main Chain:

• Rollup: Can be seen as an extension of the main chain, usually focused on specific blockchain networks.

• ZK Coprocessor: Can provide services for multiple blockchains, not limited to a specific main chain, and can also serve Rollups.

Thus, the two are not inherently contradictory but rather 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 range of ZK Coprocessors is very broad, covering projects across various blockchain sectors. The existence of ZK Coprocessors allows Dapps to function more like centralized Web2 applications. Here are some example use cases collected from the internet:

Data-Driven DApp Development

ZK Coprocessors enable developers to create data-driven DApps that utilize full-chain historical data and perform complex computations without additional trust assumptions. This brings unprecedented possibilities for DApp development, such as:

1. Advanced Data Analysis: On-chain data analysis capabilities similar to Dune Analytics.

2. Complex Business Logic: Implementing complex algorithms and business logic found in traditional centralized applications.

3. Cross-Chain Applications: Building cross-chain DApps based on multi-chain data.

VIP Trader Programs for DEX

A typical application scenario is implementing a volume-based fee discount program in decentralized exchanges (DEX), known as "VIP Trader Loyalty Programs." Such programs are common in centralized exchanges (CEX) but rare in DEX.

With ZK Coprocessors, DEX can:

1. Track users' historical trading volumes.

2. Calculate users' VIP levels.

3. Dynamically adjust trading fees based on levels.

This functionality can help DEX improve user retention, increase liquidity, and ultimately boost revenue.

Data Augmentation for Smart Contracts

ZK Coprocessors can serve as powerful middleware, providing data capture, computation, and verification services for smart contracts, thereby reducing costs and increasing efficiency. This enables smart contracts to:

1. Access and process large amounts of historical data.

2. Execute complex off-chain computations.

3. Implement more advanced business logic.

Cross-Chain Bridge Technologies

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

1.4 ZK Coprocessors Are Not Perfect

While we have listed many advantages, ZK Coprocessors at the current stage are not perfect and face many challenges. I have summarized the following points:

1. Development: The concept of ZK is difficult for many developers to understand, requiring relevant cryptographic knowledge and mastery of specific programming languages and tools;

2. High Hardware Costs: The ZK hardware used for off-chain computation must be fully borne by the project team. ZK hardware is expensive and rapidly evolving, making it likely to become obsolete at any time. Whether this can form a closed-loop in business logic is also a question worth considering;

3. Crowded Field: Technically, there are not significant differences in implementation, and it is likely to resemble the current Layer2 landscape, with a few standout projects but most being ignored;

4. zk Circuits: Executing off-chain computations in ZK Coprocessors requires converting traditional computer programs into zk circuits, making it very complex to write custom circuits for each application. Additionally, using zkvm to write circuits in the virtual machine incurs significant overhead due to differing computational models.

II. The Key Puzzle to Large-Scale Applications

(This chapter is highly subjective and represents the author's personal views)

This cycle is dominated by modular infrastructure. If the modular path is correct, this cycle may be the final step toward large-scale applications. However, at the current stage, we all share a common feeling: why can we only see some old wine in new bottles, why are there far more chains than applications, and why can new token standards like inscriptions be called the biggest innovation of this cycle?

The lack of fresh narratives fundamentally stems from the current modular infrastructure being insufficient to support super applications, especially lacking some prerequisites (full-chain interoperability, user thresholds, etc.), which has indirectly led to the largest fragmentation in blockchain history. As the core of the modular era, Rollup has improved speed, but it has also brought many corresponding issues, namely the liquidity fragmentation, user dispersion, and the limitations imposed by chains or virtual machines on application innovation. On the other hand, another "key player" in modularity, Celestia, has pioneered the idea that DA does not have to be on Ethereum, further exacerbating fragmentation. Whether starting from ideology or DA costs, the result is that BTC is forced to do DA, while other public chains must pursue more cost-effective DA. The current situation is that each public chain has at least one, and often dozens, of Layer2 projects. Additionally, all infrastructure and ecosystem projects have deeply learned from the points system pioneered by Blur (Tieshun), requiring users to stake tokens within the project. This model, which benefits whales in multiple ways (interest, appreciation of ETH or BTC, and free tokens), further compresses on-chain liquidity.

In the previous bull market, funds would circulate within a few to dozens of public chains, even concentrating on Ethereum. Now, funds are dispersed across hundreds of public chains, staked in thousands of similar projects, leading to a decline in on-chain prosperity, with even Ethereum lacking on-chain activity. Thus, Eastern players engaging in PVP in the BTC ecosystem and Western players in Solana is a helpless choice. Therefore, I am currently most concerned with how to promote full-chain liquidity aggregation and support the emergence of new play styles and super applications. In the full-chain interoperability track, traditional leading projects have consistently underperformed, still resembling traditional cross-chain bridges. New interoperability solutions, as discussed in our previous research reports, mainly aggregate multiple chains into a single chain, with current projects including AggLayer, Superchain, Elastic Chain, and JAM, which will not be elaborated on here.

In summary, aggregating the full chain is a hurdle that must be overcome under the modular structure, but it will take a long time to clear this hurdle. ZK Coprocessors are a more critical piece of the puzzle at this stage. Besides strengthening Layer2, they can also bolster Layer1. Is there a way to temporarily escape the full-chain and triangular paradox? Can we realize some applications that align with the current context on certain Layer1 or Layer2 with broad liquidity? After all, the current blockchain application narrative is indeed lacking. On the other hand, achieving diversity in play styles, controlling gas fees, the emergence of large-scale applications, and even cross-chain capabilities while lowering user thresholds through integrated coprocessor solutions would be a more ideal approach than relying on centralization.

III. Project Overview

The ZK Coprocessor track has emerged around 2023 and is now relatively mature. 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 in total. Most of these projects are supported by leading VCs. Below, we describe some projects from different vertical fields.

3.1 Giza

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 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 integrate AI capabilities while maintaining the decentralization and verifiability of the blockchain.

Giza completes its workflow through the following three steps:

1. Model Conversion: Giza converts commonly used ONNX format AI models into a format that can run in zero-knowledge proof systems. This allows developers to train models using familiar tools and then deploy them to the Giza network.

2. Off-Chain Inference: When a smart contract requests AI model inference, Giza performs the actual computation off-chain. This avoids the high costs of directly running complex AI models on the blockchain.

3. 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 the inference results without needing to repeat 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 with a logical closed loop in the current Web3 x AI landscape and demonstrates a clever application of coprocessors in the AI field.

3.2 Risc Zero

Risc Zero is a coprocessor project supported by several leading VCs and stands out in this track. The project focuses on enabling arbitrary computations 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 allows developers to build complex on-chain applications while maintaining the decentralization and verifiability of the blockchain.

We have briefly discussed the deployment and workflow in the previous sections; here we will elaborate on two key components:

Bonsai: RISC Zero's Bonsai is the coprocessor component of the project, seamlessly integrated into the zkVM based on 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 a few days, providing direct calls to smart contracts, verifiable off-chain computations, cross-chain interoperability, and general rollup functionality. It adopts a decentralized-first distributed architecture design, combining recursive proofs, custom circuit compilers, state continuity, and continuously improving proof algorithms, enabling anyone to generate high-performance zero-knowledge proofs for various applications.

zkVM: zkVM is a verifiable computer that operates similarly to a real embedded RISC-V microprocessor. This virtual machine is based on the RISC-V instruction set architecture, allowing developers to use various programming languages, including Rust, C++, Solidity, and Go, to write programs that can generate zero-knowledge proofs. It supports over 70% of popular Rust crates, achieving a seamless combination of 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 employs ZK technologies, including STARK and SNARK, to achieve efficient proof generation and verification through components such as Recursion Prover and STARK-to-SNARK Prover, supporting off-chain execution and on-chain verification.

Risc Zero has already integrated with multiple ETH-based Layer2s and demonstrated several use cases for Bonsai, one of the more interesting being Bonsai Pay. This demonstration uses RISC Zero's zkVM and Bonsai to allow users to send or withdraw ETH and tokens on Ethereum using their Google accounts. It showcases how RISC Zero seamlessly integrates on-chain applications with OAuth2.0 (the standard used by major identity providers like Google), representing an integration use case that lowers the Web3 user threshold through traditional Web2 applications. Additionally, there are examples based on DAO and other applications.

3.3 =nil;

=nil; is backed by well-known projects and institutions such as Mina, Polychain, Starkware, and Blockchain Capital. Notably, projects like Mina and Starkware, which are at the forefront of zk technology, are involved, indicating a high level of technical recognition for the project. =nil; was also mentioned in our research report on the "Computing Power Market." At that time, it primarily focused on =nil;'s Proof Market (a decentralized proof generation market), but the project also has a sub-product, zkLLVM.

zkLLVM is an innovative circuit compiler developed by the =nil; Foundation that can automatically convert application code written in mainstream development languages like C++ and Rust into efficient provable circuits on Ethereum without requiring a specialized zero-knowledge domain-specific language (DSL). This significantly simplifies the development process and lowers the development threshold while improving performance by not involving zkVM (zero-knowledge virtual machine). It supports hardware acceleration to speed up proof generation and is applicable to various ZK application scenarios, including rollups, cross-chain bridges, oracles, machine learning, and gaming, closely 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

This project is a sub-project of Celer Network. Brevis is a smart zero-knowledge (ZK) coprocessor for blockchains, enabling 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 mainly consists of three parts:

1. zkFabric: zkFabric is the relay of the Brevis architecture. Its main task is to collect and synchronize block header information from all connected blockchains, ultimately generating consensus proofs for each collected block header through ZK light client circuits.

2. 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 (e.g., calculating trading volumes on DEX over specific periods) to highly generalized data indexing abstractions and advanced query languages, catering to various application needs.

3. zkAggregatorRollup: Acts as the aggregation and storage layer between zkFabric and zkQueryNet. It verifies the proofs of these two components, stores the proven data, and submits the state root of its ZK proofs to all connected blockchains, allowing dApps to directly access proven query results in their on-chain smart contract business logic.

Through this modular architecture, Brevis can provide trustless, efficient, and flexible access methods for all supported public chain on-chain smart contracts. The project has also been adopted in the V4 version of UNI, integrating with Hooks (a system for integrating custom logic for various users) in the protocol to facilitate reading historical blockchain data, reduce gas fees, and ensure decentralization. This is an example of how ZK coprocessors drive 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 complex computations with large 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 Lagrange, responsible for processing and verifying cross-chain data and generating relevant 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 infinite 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 integration feature allowing developers to access historical data using SQL queries directly from smart contracts without writing complex circuits, collectively forming 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 states of optimized rollups. The State Committee integrates with EigenLayer's AVS, enhancing security through a restaking mechanism and supporting an unlimited number of nodes, achieving superlinear security growth. It also provides a "fast mode," allowing users to perform cross-chain operations without waiting for the challenge window, significantly improving user experience. The combination of these two technologies enables Lagrange to efficiently handle large-scale data, execute complex computations, and securely transfer and verify results across different blockchains, providing support for developing complex cross-chain applications.

Lagrange has already integrated with EigenLayer, Mantle, Base, Frax, Polymer, LayerZero, Omni, AltLayer, and will serve as the first ZK AVS in the Ethereum ecosystem.

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 Coprocessors Break Down Smart Contract Data Barriers: https://foresightnews.pro/article/detail/48239