Author: Kernel Ventures Turbo Guo
Reviewers: Kernel Ventures Mandy, Kernel Ventures Joshua
TLDR：
The ZK coprocessor is a solution that allows dApps to utilize off-chain computing resources. This article mainly discusses the implementation of the coprocessor, various applications and future development directions. The main contents are:
RISC Zero's zkVM is a ZK coprocessor 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 zkp for the contract to verify whether the calculation is correct.
ZK coprocessors have different implementation methods. In addition to zkVM, users can also write customized ZK circuits for their own programs, or use prefabricated frameworks to write circuits, allowing contracts to utilize off-chain computing resources.
The ZK coprocessor can play a role in DeFi, such as placing AMM calculations off-chain, allowing the protocol to capture MEV-like value, or allowing AMM to implement complex and computationally intensive operating logic. The ZK coprocessor can also allow lending protocols to calculate interest rates in real time, making margin calculations transparent, etc. There are two implementations of zkAMM, one is using zkVM and the other is using zkOracle.
There are other potential uses of the ZK coprocessor. For example, wallets can use the ZK coprocessor to perform identity verification off-chain. The coprocessor can also enable on-chain games to perform more complex calculations and reduce the gas required for DAO governance. wait.
The pattern of the ZK coprocessor is undecided, but compared to users writing their own circuits, it is more friendly to use a project as an interface to call off-chain resources. But what computing service providers (traditional cloud vendors, traditional cloud vendors, etc.) are connected behind the "interface" project? Decentralized resource sharing) is another issue worth discussing.
1. The meaning and application of ZK coprocessor
Image source: Kernel Ventures
The core of the ZK coprocessor is to move on-chain calculations off-chain, and use ZK to prove the reliability of the off-chain calculation process, allowing smart contracts to easily handle large amounts of calculations, and at the same time allowing contracts to verify the reliability of calculations. This is similar to the idea of zkRollup, but Rollup is a chain protocol layer that utilizes off-chain computing resources, while the ZK coprocessor is a dApp that utilizes off-chain resources.
RISC Zero is used here to explain a ZK coprocessor implementation, but there are many implementations of ZK coprocessors, which will be introduced later. RISC Zero developed the Bonsai ZK coprocessor architecture, the core of which is RISC Zero's zkVM. Developers can generate zkp on zkVM for the event that "a certain piece of Rust code is executed correctly". With zkVM, the specific process for implementing the ZK coprocessor is:
The developer initiates a request to Bonsai's relay contract, that is, the program requested by the developer is run in zkVM.
The relay contract sends the request to the off-chain request pool
Bonsai executes the request in off-chain zkVM, performs off-chain large-scale operations, and then generates a receipt for it.
These proofs, also called "receipts," are posted back to the chain by Bonsai via a relay contract.
Image source: RISC Zero
The program certified in Bonsai is called a Guest Program, and the receipt is used to prove that the guest program was executed correctly. Credentials include a journal and a seal. Specifically, the Journal carries the public output of the zkVM application, and the seal is used to prove the validity of the certificate, that is, to prove that the guest program is executed correctly. The seal itself is also a zkSTARK generated by the certifier. Verifying credentials ensures that the journal was built with the correct circuitry, etc.
Bonsai simplifies the process for developers from compiling Rust code to zkVM bytecode, program uploading, execution in VM, and proof feedback, allowing developers to focus more on the logical design of the program. And not only part of the contract logic, but the entire contract logic can be run off-chain. RISC Zero also uses continuations, which split a large proof generation into many parts and then prove each part independently. This allows proofs to be generated for large programs without taking up too much memory. In addition to RISC Zero, several projects such as IronMill, =nil; Foundation and Marlin also provide similar general solutions.
2. Application of ZK coprocessor in DeFi
2.1 AMM - Bonsai as coprocessor
zkUniswap is an AMM that utilizes off-chain computing resources. Its core is to put part of the swap calculations off-chain, and it uses Bonsai. The user initiates a swap request on the chain. Bonsai's relay contract obtains the request and initiates off-chain calculation. After Bonsai completes the calculation, it returns the calculation result and proof to the callback function in the EVM. If the proof is verified successfully, swap will be executed.
However, swap is not completed at once. The request and execution processes are in different transactions. This brings certain risks, that is, the status of the pool may change after the request is submitted and before the swap is completed. Because validation is based on the state of the pool when the request is submitted. If the pool status changes while a request is still waiting, the verification will fail.
To solve this problem, developers designed a pool lock. When a user initiates a request, all operations except settlement swap are locked until the off-chain successfully triggers the on-chain swap or the swap times out (this time will be preset). If there is a time limit, even if there is a problem with the relay or zkp, the pool will not be locked forever. The specific time limit may be a few minutes.
zkUniswap has a special design for MEV, that is, the developers want the protocol to capture the MEV value. In theory, zkAMMs also have MEV, because the first person to submit a transaction can lock it, so everyone will still compete for gas, and builders can also sort requested transactions. But zkUniswap will eat up the MEV income itself, using the variable interest rate gradient Dutch auction (VRGDA).
zkUniswap takes out the lock and auctions it at a reduced price. If the lock is sold quickly, the protocol will know that the demand is currently high, and then it will automatically increase 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. Equivalently, the agreement provides a new thing to determine the order of transactions, and the money from the competitive price is directly given to the project party through the new thing. This is very imaginative.
2.2 AMM - zkOracle as coprocessor
In addition to using zkVM, some people have proposed using zkOracle to realize the utilization of off-chain computing resources, and zkOracle is an oracle that takes into account both input and output. There are generally two types of oracles, one is the input oracle, and the other is the output oracle. The input oracle sorts (computes) the off-chain data and puts it on the chain, and the output oracle sorts (calculates) the on-chain data. ) and then provided to the off-chain. The I/O (input and output) oracle (zkOracle) performs output first and then input, allowing the chain to utilize off-chain computing resources.
On the one hand, zkOracle uses on-chain data as the data source; on the other hand, it uses ZK to ensure that the calculations of the oracle node are not fraudulent, and can realize the function of a co-processor. Therefore, the core calculations of AMM can be placed in zkOracle. While realizing the traditional AMM functions, zkOracle can also be used to implement more complex and computational resource-consuming operations.
Image source: github fewwwww/zkAMM
2.3 Lending interest rate calculation, margin calculation and other applications
Regardless of the implementation, many functions can be achieved with the ZK coprocessor. For example, the lending agreement can no longer preset parameters, but adjust the interest rate based on real-time lending conditions. For example, raising interest rates to attract supply when demand for borrowing money is high, and then lowering interest rates when demand is low. This requires the lending protocol to obtain on-chain data in real time and perform a large number of calculations to obtain appropriate parameters, which requires off-chain calculations (unless the on-chain cost is extremely low).
Complex operations such as calculating margin balances, unrealized profits and losses, liquidation amounts, etc. can also be transferred to the co-processor for execution. The advantage of using a coprocessor is that it makes these applications more transparent and verifiable, and the logic of the margin engine is no longer a secret black box. Although the computation is done off-chain, users can have complete trust in the correctness of its execution. Additionally, this approach also applies to option calculations.
3. Other applications of ZK coprocessor
3.1 Wallet-using Bonsai as co-processor
Bonfire Wallet uses zkVM to move identity verification calculations off-chain. The goal of this wallet is to allow users to create burner wallets with biometric information (fingerprints), or cryptographic hardware yubikey.
Specifically, Bonfire Wallet uses WebAuthn, a common web page authentication standard, allowing users to directly use their devices to complete authentication on web pages without passwords. So in the Bonfire wallet, the user generates a public key through WebAuthn (not on the chain, for WebAuthn), and then uses it to create a wallet.
Each Burner wallet has a contract on the chain, which contains the WebAuthn public key. The contract needs to verify the user's WebAuthn signature. But the amount of calculation is very large, so Bonsai is used to put the calculation off-chain, verify the signature off-chain through a zkVM guest program, and produce zkp for on-chain verification.
Image source: Bonfire Wallet
3.2 On-chain data retrieval - users write ZK circuits by themselves
Axiom is an application that does not use zkVM but uses another coprocessor solution. Let’s first introduce what Axiom wants to do. It hopes to use the ZK coprocessor to allow contracts to access historical chain information. In fact, it is difficult for contracts to read historical data, because smart contracts generally obtain real-time on-chain data, and it is very expensive. It is difficult for contracts to obtain valuable on-chain data such as past account balances or transaction records.
Image source: Axiom demo
Axiom nodes access the required on-chain data and perform specified calculations off-chain, then generate a zero-knowledge proof for the calculation proving that the result was correctly calculated based on valid on-chain data. This proof is verified on-chain, ensuring that the contract can trust the result.
To generate zkp for off-chain calculations, you need to compile the program into the ZK circuit. We also mentioned using zkVM to do this, and Axiom officially pointed out that there are many solutions for this matter, which need to weigh performance, flexibility and development experience. :
Customized circuits: Developers customize circuits for the program, which will definitely have the best performance, but it will take time to develop;
eDSL/DSL: Developers still write their own circuits, but there are some optional frameworks that help developers solve ZK-related problems, which can balance performance and development experience.
zkVM: Developers directly use ready-made virtual machines to run ZK. This is very convenient, but Axiom officials believe that the efficiency is very low.
Therefore, Axiom chose the second option, and the project team also provided users with a set of optimized ZK modules so that they can design their own circuits.
A project similar to Axiom is Herodotus, but what it wants to do is a middleware for cross-chain information transmission. Since information processing is off-chain, it is a reasonable idea to let different chains obtain processed data. Another project, Space and Time, uses a similar architecture to implement data indexing.
3.3 On-chain games, DAO governance and other applications
In addition, ZK coprocessors can be used for on-chain games and DAO governance. RISC Zero believes that any calculation requiring more than 250k gas will be cheaper using the ZK coprocessor, but how this is determined remains to be seen. DAO governance can also use the ZK coprocessor, because it involves multiple people and multiple contracts, which consumes computing resources. RISC Zero claims that gas fees can be reduced by 50% after using Bonsai. ZKML is essentially the idea of ZK coprocessor, so Modulus Labs and Giza are also projects in this field, but the concept of ZK coprocessor is larger.
In addition, there are some auxiliary projects in the field of ZK coprocessors, such as ezkl, which provides compilers for making ZK circuits, tool suites for ZK deployment, tools for moving on-chain calculations off-chain, etc.
4. Future prospects
The coprocessor allows on-chain applications to have external computing resources like a "cloud", which provides relatively cheap large amounts of calculations, while only the necessary calculations are processed on the chain. In actual situations, zkVM can also run on the cloud. The ZK coprocessor is essentially an architecture, a way of putting on-chain computing off-chain, and there is no limit on who provides off-chain computing resources.
Essentially, off-chain computing resources are shared by traditional large manufacturers, even decentralized computing resources, and local devices. Each of these three directions is different. Traditional major manufacturers can provide relatively mature off-chain computing solutions. In the future, the "robustness" of decentralized computing resources may be stronger, and users' local computing also has great imagination. However, many ZK coprocessor projects currently choose to provide services in a closed source stage, because the upstream and downstream of this track have not yet been formed, and the services cannot be refined and handed over to different projects. There are two possibilities in the future:
There are a large number of projects competing for each aspect of the ZK coprocessor
A project with good service experience occupies most of the market
From a developer's perspective, they may only use one "interface" project when using the ZK coprocessor. This is why Amazon Cloud occupies a large amount of the market, and developers will be accustomed to one deployment method. But as an "interface" project for off-chain computing resources, what computing service providers (traditional cloud vendors, decentralized resource sharing) are connected behind it is another issue worthy of discussion.
Kernel Ventures is a crypto venture capital fund driven by the research and development community with over 70 early-stage investments focused on infrastructure, middleware, dApps, especially ZK, Rollup, DEX, modular blockchains, and onboarding Vertical areas for billions of crypto users in the future, such as account abstraction, data availability, scalability, etc. For the past seven years, we have been committed to supporting the growth of core development communities and university blockchain associations around the world.
References:
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
