Off-chain Computing Innovation: An In-depth Look at ZK Co-processors and Their Application Prospects in DeFi and DAO

Original Title: Kernel Ventures: Empowering Dapps with Off-Chain Computing Capabilities --- ZK Co-Processors

Original Author: Turbo Guo, Kernel Ventures

Original Reviewers: Mandy, Joshua, Kernel Ventures

TL;DR

ZK co-processors are a solution that allows dApps to utilize off-chain computing resources. This article mainly discusses the implementation methods of co-processors, various applications, and future development directions, with key points including:

1. RISC Zero's zkVM is a ZK co-processor solution that allows on-chain contracts to call off-chain zkVM to run specific Rust code and return the results to the chain, while providing zkps for contract verification of the correctness of the computation.
2. ZK co-processors have different implementation methods. In addition to zkVM, users can also write customized ZK circuits for their programs or use pre-built frameworks to write circuits, enabling contracts to utilize off-chain computing resources.
3. ZK co-processors can play a role in DeFi, such as moving AMM computations off-chain, allowing protocols to capture MEV-like value, or enabling AMMs to implement complex and computation-intensive operational logic. ZK co-processors can also allow lending protocols to calculate interest rates in real-time, making margin calculations more transparent, etc. zkAMM has two implementation methods: one using zkVM and the other using zkOracle.
4. ZK co-processors have other potential uses, such as wallets using ZK co-processors to perform identity verification off-chain, and co-processors enabling on-chain games to execute more complex computations, reducing gas costs required for DAO governance, etc.
5. The landscape of ZK co-processors is still uncertain, but compared to users writing circuits themselves, using a project to interface with off-chain resources is more user-friendly. However, what computing service providers (traditional cloud vendors, decentralized resource sharing) are integrated behind that "interface" project is another topic worth discussing.

1. Meaning and Applications of ZK Co-Processors

The core of ZK co-processors is to move on-chain computations off-chain, using ZK proofs to ensure the reliability of the off-chain computation process, allowing smart contracts to easily handle large amounts of computation while enabling contracts to verify the reliability of the computations. This is similar to the idea of zkRollup, but Rollup utilizes off-chain computing resources at the chain protocol layer, while ZK co-processors allow dApps to utilize off-chain resources.

Here, RISC Zero is used to explain one implementation method of ZK co-processors, but there are many ways to implement ZK co-processors, which will be further introduced later. RISC Zero has developed the Bonsai ZK co-processor architecture, with the core being RISC Zero's zkVM, where developers can generate zkps for the "correct execution of a certain Rust code" in the zkVM. With zkVM, the specific process of implementing ZK co-processors is as follows:

1. Developers send a request to Bonsai's relay contract to run the requested program in the zkVM.
2. The relay contract forwards the request to the off-chain request pool.
3. Bonsai executes the request in the off-chain zkVM, performing large-scale off-chain computations, and then generates a receipt.
4. These proofs, also called "receipts," are published back to the chain by Bonsai through the relay contract.

In Bonsai, the program being proven is called a Guest Program, and the receipt is used to prove that the guest program was executed correctly. The receipt includes a journal and a seal. Specifically, the Journal carries the public output of the zkVM application, while the seal is used to prove the validity of the receipt, i.e., to prove that the guest program was executed correctly. The seal itself is also a zkSTARK generated by the prover. Verifying the receipt ensures that the journal was constructed using the correct circuit, etc.

Bonsai simplifies the process for developers from Rust code to zkVM bytecode compilation, program upload, execution in the VM, and proof feedback, allowing developers to focus more on the logical design of the program. Moreover, not only part of the contract logic but the entire contract logic can be run off-chain. RISC Zero also uses continuations, which break down the generation of a large proof into many parts, with each part being proven separately. This allows for generating proofs for large programs without consuming too much memory. In addition to RISC Zero, there are several other projects like IronMill, =nil; Foundation, and Marlin that also provide similar general solutions.

2. Applications of ZK Co-Processors in DeFi

2.1 AMM - Bonsai as Co-Processor

zkUniswap is an AMM that utilizes off-chain computing resources, with its core being to move part of the swap computation off-chain, and it uses Bonsai. Users initiate a swap request on-chain. The Bonsai relay contract receives the request, initiates off-chain computation, and after completing the computation, returns the result and proof to the callback function in the EVM. If the proof is verified as successful, the swap will be executed.

However, the swap is not completed in one go; the request and execution processes occur in different transactions, which brings certain risks, as the state of the pool may change between submitting the request and completing the swap. This is because the verification is based on the state of the pool at the time the request was submitted. If a request is still pending and the pool's state changes, the verification will fail.

To solve this problem, developers designed a pool lock. When a user initiates a request, all operations except for settling the swap are locked until the off-chain swap is successfully triggered on-chain or the swap times out (a preset time will be established). With a time limit, even if the relay or zkp encounters issues, the pool will not remain locked indefinitely. The specific time limit could be a few minutes.

zkUniswap has a special design for MEV, as the developers hope to capture MEV value for the protocol. In theory, zkAMMs also have MEV because the first person to submit a transaction can lock it, so there will still be competition for gas, and builders can also prioritize transaction requests. However, zkUniswap will consume the MEV profits itself, using a method called variable rate gradual Dutch auction (VRGDA).

zkUniswap takes the lock and auctions it off at a lower price; if the lock sells quickly, the protocol knows there is high demand and will automatically raise the price. If the speed of selling the lock slows down, the protocol will lower the price. This will become a new source of income. Essentially, the protocol provides a new mechanism to determine transaction order, and the money from competitive pricing goes directly to the project through this new mechanism, which is quite imaginative.

2.2 AMM - zkOracle as Co-Processor

In addition to using zkVM, some have proposed using zkOracle to leverage off-chain computing resources, and zkOracle is an oracle that handles both input and output. Generally, oracles come in two types: input oracles and output oracles. Input oracles organize (compute) off-chain data and place it on-chain, while output oracles organize (compute) on-chain data and provide it off-chain. I/O (input and output) oracles (zkOracle) first perform output and then input, allowing on-chain systems to utilize off-chain computing resources.

On one hand, zkOracle uses on-chain data as a data source, and on the other hand, it uses ZK to ensure that the computations performed by oracle nodes are legitimate, thus achieving the functionality of a co-processor. Therefore, the core computations of AMMs can be placed in zkOracle, enabling the implementation of traditional AMM functions while also allowing zkOracle to perform more complex and computation-intensive operations.

2.3 Other Applications such as Lending Rate Calculation and Margin Calculation

Setting aside the implementation methods, having ZK co-processors enables many functionalities. For example, lending protocols can adjust interest rates based on real-time lending conditions instead of preset parameters. For instance, they can raise interest rates to attract supply during periods of high borrowing demand and lower rates when demand decreases. This requires lending protocols to obtain real-time on-chain data while performing a large number of computations to derive suitable parameters, which necessitates off-chain computation (unless on-chain costs are extremely low).

Complex calculations for margin balances, unrealized profits and losses, liquidation amounts, etc., can also be transferred to co-processors for execution. The advantage of using co-processors is that it makes these applications more transparent and verifiable, ensuring that the logic of the margin engine is no longer a secret black box. Although the computations are performed off-chain, users can fully trust the correctness of the execution. Additionally, this approach is also applicable to options calculations.

3. Other Applications of ZK Co-Processors

3.1 Wallet - Using Bonsai as Co-Processor

Bonfire Wallet uses zkVM to move identity verification computations off-chain. The goal of this wallet is to allow users to create burner wallets using biometric information (fingerprints) or encrypted hardware like yubikey.

Specifically, Bonfire Wallet utilizes WebAuthn, a universal web authentication standard, allowing users to complete web-based identity verification directly with their devices without passwords. Thus, in the Bonfire wallet, users generate a public key (not on-chain, used for WebAuthn) through WebAuthn and then use it to create their wallet.

Each Burner wallet has a contract on-chain that contains the WebAuthn public key, and the contract needs to verify the user's WebAuthn signature. However, this computation is quite intensive, so Bonsai is used to perform the computation off-chain, verifying the signature through a zkVM guest program and producing zkps for on-chain verification.

3.2 On-Chain Data Retrieval - Users Write ZK Circuits Themselves

Axiom is an application that does not use zkVM but employs another co-processor solution. First, let’s introduce what Axiom aims to do; it hopes to utilize ZK co-processors to allow contracts to query historical on-chain information. In fact, allowing contracts to read historical data is quite challenging because smart contracts generally obtain real-time on-chain data, which is expensive, making it difficult for contracts to access valuable on-chain data such as past account balances or transaction records.

Axiom nodes access the required on-chain data and perform specified computations off-chain, then generate a zero-knowledge proof to demonstrate that the results were correctly computed based on valid on-chain data. This proof is verified on-chain, ensuring that the contract can trust the result.

Generating zkps for off-chain computation requires compiling the program into ZK circuits. The earlier text mentioned using zkVM for this purpose, while Axiom's official stance is that there are many solutions for this task, requiring a balance between performance, flexibility, and developer experience:

1. Custom Circuits: Developers customize circuits for their programs, which ensures the best performance but requires time to develop;

2. eDSL/DSL: Developers still write circuits themselves but have some optional frameworks to help solve ZK-related issues, balancing performance and developer experience.

3. zkVM: Developers run ZK directly in a ready-made virtual machine, which is very convenient, but Axiom's officials believe it is inefficient.

Therefore, Axiom chose the second option, and the project team also provides users with a set of optimized ZK modules, allowing them to design circuits themselves.

Similar projects to Axiom include Herodotus, which aims to serve as middleware for cross-chain information transfer. Since information processing occurs off-chain, allowing different chains to obtain processed data is a reasonable approach. Another project, Space and Time, has implemented data indexing using a similar architecture.

3.3 On-Chain Games, DAO Governance, and Other Applications

In addition, on-chain games and DAO governance can also utilize ZK co-processors. RISC Zero believes that any computation requiring over 250k gas would be cheaper using ZK co-processors, although the specifics of this claim still need to be examined. DAO governance can also benefit from ZK co-processors, as it involves multiple parties and contracts, which is resource-intensive. RISC Zero claims that using Bonsai can reduce gas fees by 50%. ZKML is essentially also based on the idea of ZK co-processors, so projects like Modulus Labs and Giza are also in this field, but the concept of ZK co-processors is broader.

Additionally, there are some auxiliary projects in the field of ZK co-processors, such as ezkl, which provides compilers for creating ZK circuits, toolkits for ZK deployment, and tools for moving on-chain computations off-chain.

4. Future Outlook

Co-processors provide on-chain applications with external computing resources akin to "cloud" computing, offering relatively inexpensive large-scale computation while only processing necessary computations on-chain. In practice, zkVM can also run on the cloud; ZK co-processors are essentially an architecture that moves on-chain computations off-chain, and who provides the off-chain computing resources is not restricted.

In essence, off-chain computing resources could come from traditional large vendors, decentralized computing resource sharing, or local devices. Each of these three directions has its differences; traditional large vendors can provide relatively mature off-chain computing solutions, while decentralized computing resources may have stronger "robustness" in the future, and local user computing also holds significant potential. However, many current ZK co-processor projects choose to provide services in a closed-source manner because the upstream and downstream of this track have not yet formed, making it impossible to refine services and assign them to different projects. There are two possible futures:

1. Each segment of ZK co-processors has a large number of competing projects.
2. A single project with a good service experience occupies a large portion of the market.

From a developer's perspective, when using ZK co-processors, they may only use one "interface" project, which is also a significant reason why Amazon Web Services dominates the market; developers tend to get accustomed to a particular deployment method. However, as that "interface" project for off-chain computing resources, what computing service providers (traditional cloud vendors, decentralized resource sharing) are integrated behind it is another track worth discussing.