Kernel Ventures: Empowering DApps with Off-Chain Computing Ability — ZK Coprocessors

Author: Kernel Ventures Turbo Guo

Editor(s): Kernel Ventures Rose, Kernel Ventures Mandy, Kernel Ventures Joshua

TLDR:

The ZK coprocessor is a solution for dApps to utilize off-chain computing resources. This article explores the existing solutions, various applications, and future development of coprocessors. The main topics covered are as follows:

• RISC Zero's zkVM is a ZK coprocessor solution that allows on-chain contracts which call off-chain zkVM to run specific Rust code and return the results to the chain, while providing zkp for on-chain verification of the correctness of the computation.
• There are different solutions for ZK coprocessors. Besides zkVM, users can also write customized ZK circuits for their programs, or use pre-made frameworks to write circuits, thereby enabling contracts to utilize off-chain computing resources.
• ZK coprocessor can play a role in DeFi, such as offloading AMM calculations off-chain to capture value similar to MEV or enabling complex and computationally intensive logic for AMMs. ZK coprocessor can also facilitate real-time interest rate calculations for lending protocols, making margin calculations transparent, among other things. zkAMM has two implementation approaches, one using zkVM, and the other using zkOracle.
• ZK coprocessor also has other potential use cases, such as wallets using it to perform off-chain identity verification. It can enable more complex computations for on-chain games and reduce the gas required for DAO governance, among other applications.
• The landscape for ZK coprocessors is still uncertain, but compared to users writing their own circuits, using a solution for off-chain resource interfacing is more user-friendly. However, the question of which computation service providers are integrated behind that "interface" solution, whether traditional cloud providers or decentralized resource-sharing networks, is another important topic for discussion.

The Purpose and Application of ZK Coprocessors

<figure class="image"> <figcaption> Source: Kernel Ventures </figcaption> </figure>

The core of ZK coprocessor is to move on-chain computation off-chain, using ZK proofs to ensure the reliability of off-chain computation, allowing smart contracts to easily handle a large amount of computation while verifying the reliability of the computation. This is similar to the idea of zkRollups, but Rollups use off-chain computing resources at the chain protocol layer, while ZK coprocessors are used by dApps to utilize off-chain resources.

Using RISC Zero as an example to explain one solution of ZK coprocessors, RISC Zero has developed the Bonsai ZK coprocessor architecture, whose core is RISC Zero's zkVM. Developers can generate zkp on zkVM for "a certain Rust code being correctly executed". With zkVM, the specific process of implementing a ZK coprocessor is:

• Developers send a request to Bonsai's relay contract, i.e., to run the developer's required program in zkVM.
• The relay contract sends the request to the off-chain request pool.
• Bonsai executes the request in off-chain zkVM, performs large-scale computations, and then generates a receipt.
• These proofs, also known as "receipts", are published back to the chain by Bonsai through the relay contract.

<figure class="image"> <figcaption> Source: RISC Zero </figcaption> </figure>

In Bonsai, the proven program is called the Guest Program, and the receipt is used to prove that the guest program has been 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 has been executed correctly. The seal itself is a zkSTARK generated by the prover. Verifying the receipt ensures that the journal is constructed using the correct circuit, etc.

Bonsai simplifies the process for developers to compile Rust code into zkVM bytecode, upload programs, execute them in the VM, and receive proof feedback, allowing developers to focus more on logical design. It enables not only partial contract logic but the entire contract logic to run off-chain. RISC Zero also utilizes continuations, breaking down the generation of a large proof into smaller parts, enabling proof generation for large programs without consuming excessive memory. In addition to RISC Zero, there are other projects like IronMill, =nil; Foundation, and Marlin that provide similar general solutions.

Application of ZK Coprocessors in DeFi

AMM - Bonsai as a Coprocessor

zkUniswap is an AMM that leverages off-chain computing resources. Its core feature is to offload part of the swap computation off-chain, using Bonsai. Users initiate a swap request on-chain. Bonsai's relay contract obtains the request, initiates off-chain computation, and upon completion, returns the computation result and proof to the EVM's callback function. If the proof is successfully verified, the swap is executed.

However, the swap is not completed in one go. The request and execution processes are in different transactions, which brings certain risks. That is, between the submission of the request and the completion of the swap, the state of the pool may change. As the verification is based on the state of the pool at the time of request submission, if a request is still pending, and the pool's state changes, then the verification will be invalid. This is an important consideration in the design and security of such systems.

To address this issue, developers have designed a pool lock. When a user initiates a request, all operations other than settling the swap are temporarily locked until off-chain computing successfully triggers the on-chain swap or the swap times out (the time limit will be preset). With a time limit in place, even if there are problems with the relay or zkp, the pool will not be locked indefinitely. The specific time limit might be a few minutes.

zkUniswap has a unique design to capture MEV, as developers aim to have the protocol benefit from MEV. Theoretically, zkAMMs also have MEV, as the first person to submit a swap can lock it and front-run others, leading to gas wars, and builders can still prioritize transaction sequencing. However, zkUniswap takes the MEV profits for itself using a method known as the Variable Rate Gradual Dutch Auction (VRGDA). This approach allows zkUniswap to extract MEV value for the protocol.

zkUniswap's concept is quite interesting. It involves lowering the price of locked assets in an auction, and if the locked assets are sold quickly, the protocol recognizes high demand and raises the price automatically. If the sale of locked assets slows down, the protocol lowers the price. This innovative approach could potentially become a new source of revenue. Essentially, the protocol introduces a unique mechanism for prioritizing transactions, and the competition for pricing benefits the project directly through this mechanism.

AMM - zkOracle as a Coprocessor

Besides using zkVM, some have proposed using zkOracle to utilize off-chain computing resources, it is worth noting that zkOracle is an I/O (input and output) oracle that handles both input and output. Generally, there are two types of oracles, one is the input oracle, and the other is the output oracle. The input oracle processes (computes) off-chain data and puts it on-chain, while the output oracle processes (computes) on-chain data and provides it off-chain. The I/O oracle (zkOracle) first does the output, then the input, allowing the chain to utilize off-chain computing resources.

On the one hand, zkOracle uses on-chain data as a data source, and on the other hand, it uses ZK to ensure that the oracle nodes' computations are honest, thus achieving the function of a coprocessor. Therefore, the core computation of AMM can be placed within zkOracle, allowing for traditional AMM functionality while also enabling more complex and computationally intensive operations using zkOracle.

<figure class="image"> <figcaption> Source: github fewwwww/zkAMM </figcaption> </figure>

Lending Rate Calculation, Margin Calculation, and Other Applications

Setting aside the implementation method, with the addition of ZK coprocessors, many functionatlities can be achieved. For example, lending protocols can adjust interest rates according to real-time parameters instead of pre-defined conditions. For instance, increasing the interest rate to attract supply when the demand for borrowing is strong, and lowering the interest rate when demand decreases. This requires the lending protocol to obtain a large amount of on-chain data in real-time, preprocess the data, and calculate the parameters off-chain (unless the on-chain cost is extremely low).

Complex calculations such as determining margin balances, unrealized profits/losses and etc., can also use coprocessors for execution. The advantage of using coprocessors is that it make these applications more transparent and verifiable. The logic of the margin engine is no longer a secret black box. Although the calculations are performed off-chain, users can fully trust the correctness of their execution. This approach is also applicable to options calculations.

Other Applications of ZK Coprocessors

Wallet - Using Bonsai as a Coprocessor

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

Specifically, Bonfire Wallet uses WebAuthn, a common web authentication standard, to allow users to complete web identity verification directly with devices without a password. So in Bonfire Wallet, users generate a public key with WebAuthn (not on-chain, but for WebAuthn), and then use it to create a wallet. Each Burner wallet has a contract on-chain, which contains the public key of WebAuthn. The contract needs to verify the user's WebAuthn signature. But this computation is large, so Bonsai is used to offload this computation off-chain, through a zkVM guest program to verify the signature off-chain, and produce zkp for on-chain verification.

<figure class="image"> <figcaption> Source: Bonfire Wallet </figcaption> </figure>

On-Chain Data Retrieval - ZK Circuits Written by Users

Axiom is an application that does not use zkVM but uses a different coprocessor solution. Let's first introduce what Axiom aims to do. It leverages a ZK coprocessors to allow contracts to access historical on-chain information. In reality, enabling contracts to read historical data is quite challenging, because smart contracts typically obtain real-time on-chain data, which can be very expensive. It is hard for contracts to access valuable on-chain data such as historical account balances or transaction records.

<figure class="image"> <figcaption> Source: Axiom demo </figcaption> </figure>

Axiom nodes access the required on-chain data and perform the specified computation off-chain, then generate a zero-knowledge proof for the computation, proving that the result is correctly calculated based on valid on-chain data. This proof is verified on-chain, ensuring that the contract can trust this result.

To generate zkp for off-chain computation, it is necessary to compile programs into ZK circuits. Previously we also mentioned using zkVM for this, but Axiom suggested that there are many solutions for this, and it's necessary to balance performance, flexibility, and development experience:

• Customized Circuits: if developers customize circuits for their programs, the performance will definitely be the best, but it takes time to develop;
• eDSL/DSL: developers still write their circuits, but there are some optional frameworks to help developers solve zk-related problems, thus balancing performance and development experience.
• zkVM: developers directly run ZK on an existing virtual machine, which is very convenient, but Axiom believes it's inefficient.

Therefore, Axiom chose the second option, and provides users with a set of optimized ZK modules, allowing them to design their own circuits.

Projects similar to Axiom include Herodotus, which aims to be a middleware for cross-chain messaging. Since information processing is off-chain, it's reasonable to allow different chains to obtain processed data. Another project, Space and Time, uses a similar architecture to implement data indexing.

On-Chain Games, DAO Governance and Other Applications

In addition to the above, on-chain games, DAO governance can also use ZK coprocessors. RISC Zero believes that any computation requiring more than 250k gas would be cheaper using a ZK coprocessor, but how this is calculated remains to be further investigated. DAO governance can also use ZK coprocessors, as it involves multiple people and multiple contracts, which is very computationally intensive. RISC Zero claims that using Bonsai can reduce gas fees by 50%. Many ZKML projects, such as Modulus Labs and Giza, are using the same solution as ZK coprocessors, but the concept of ZK coprocessors is broader.

It's worth mentioning that there are some auxiliary projects in the field of ZK coprocessors, such as ezkl, which provides compilers for ZK circuits, toolkits for deploying ZK, and tools for offloading on-chain computation off-chain.

Future Outlook

Coprocessors provide on-chain applications with external computational resources akin to the "cloud", offering cost-effective and abundant computation, while on-chain processing focuses on essential calculations. In practice, zkVM can also run on the cloud. Essentially, ZK coprocessors is an architectural approach that moves on-chain computation off-chain, with an unlimited source of off-chain computational resources.

Essentially, off-chain computing resources can be provided by traditional cloud providers, even decentralized computing resource sharing, and local devices. These three directions each have their characteristics. Traditional cloud providers can provide relatively mature off-chain computing solutions, the "robustness" of future decentralized computing resources may be stronger, and local computing also holds a lot of potential. But currently, many ZK coprocessor projects are in a closed-source service provider stage because the ecosystem for these services has not fully formed and service specialization among different projects is yet to be defined. Two possible scenarios for the future are:

• Every part of the ZK coprocessor has a large number of projects competing with each other.
• A single project with excellent service experience may dominate the market.

From a developer's perspective, when using ZK coprocessors, they might only interact with a single "interface" project. This is similar to the reason why Amazon Web Services has a substantial market share, as developers tend to become accustomed to a specific deployment method. However, the question of which computing service providers (traditional cloud companies, decentralized resource sharing) are integrated behind this off-chain computational resource "interface" project is another topic worth discussing.

REFERENCE：

• A Guide to ZK Coprocessors for Scalability：https://www.risczero.com/news/a-guide-to-zk-coprocessors-for-scalability
• Defining zkOracle for Ethereum：https://ethresear.ch/t/defining-zkoracle-for-ethereum/15131
• zkUniswap: a first-of-its-kind zkAMM：https://ethresear.ch/t/zkuniswap-a-first-of-its-kind-zkamm/16839
• What is a ZK Coprocessor?：https://blog.axiom.xyz/what-is-a-zk-coprocessor/
• A Brief Intro to Coprocessors：https://crypto.mirror.xyz/BFqUfBNVZrqYau3Vz9WJ-BACw5FT3W30iUX3mPlKxtA
• Latest Applications Building on Hyper Oracle (Bonus: Things You Can Build Now)：https://mirror.xyz/hyperoracleblog.eth/Tik3nBI9mw05Ql_aHKZqm4hNxfxaEQdDAKn7JKcx0xQ
• Bonfire Wallet：https://ethglobal.com/showcase/bonfire-wallet-n1dzp