Introduction

ZKPool aims to build a decentralized prover pool that supports various zero knowledge proof (ZKP) projects, including ZK-rollup projects like Taiko, Scroll, ZK-bridge projects like Orbiter Finance and other ZKP projects. In this document, we present a demo that demonstrates how to send ZKML proof tasks based on RiscZero's ZKVM to ZKPool and generate the proof correctly. Additionally, ZKPool has the capability to split proof tasks into smaller ones using RiscZero's continuation technology and distribute them to multiple provers to be processed in parallel. This allows for faster proof generation and enables lower-performance devices, including consumer devices like MacBooks, to participate.

This flow serves as an example for other ZKP requesters who need to access ZKPool's prover resources.

ZKPool Proving Flow

We use a ZKML demo to explain the proving flow.

The proving flow can be described by the following diagram:

The flow involves the following participants:

1. User: The person who initiates proof tasks through the user interface (UI).

2. ZKP requesters: Those who generate ZKML proof tasks and request proofs.

3. ZKPool, which consists of several components:

   - Aoraki node: Receives, splits, and aggregates proof tasks, and submits the proofs. It will be open-source and decentralized.

   - Aoraki ZKP provers: Receive proof tasks from the Aoraki node, and generate proofs.

   - Aoraki contract: Publishes proof tasks and receives proofs.

The overall proving flow is as follows:

1. The user triggers a proof task from the UI.

2. The ZKP requester receives the user's input, generates a ZKML proof task, and inquires about the price with ZKPool's Aoraki node.

3. The Aoraki node provides the price quote for the proof, along with its signature and address.

4. The ZKP requester submits the tasks and proof bond to the Aoraki contract.

5. The Aoraki contract publishes the proof tasks, indicating which prover will handle each task.

6. The Aoraki node retrieves the proof tasks from the contract.

7. If the proof tasks are related to ZKVM, the Aoraki node splits them and dispatches smaller tasks to connected ZKP provers.

8. The ZKP provers generate the proofs and send them back to the Aoraki nodes.

9. The Aoraki nodes verify the proofs and submit them to the contract (verification will be based on verifiers' consensus in the future).

10. The Aoraki contract calls the requester's contract for verification or publishes proof information that can be fetched by the ZKP requester's off-chain module for verification.

ZKML

When ZK technology is applied to generate proofs for machine learning computations, it is referred to as ZKML. For more information, you can refer to this article: link

Several teams, such as Modulus Labs and EZKL, are working in this area. Machine learning encompasses traditional algorithms (classification, regression), CNN image recognition, and LLM models, which have gained popularity in recent years.

Generating proofs for machine learning computations is challenging due to their complexity. In this ZKML demo, we use the decision tree classifier as an example, referring to the smartcore-ml repository.

The prover needs to generate a proof demonstrating the correct classifier result and the correct usage of the machine learning model.

We will provide a more detailed technical document soon, including the API, and the open-source code will be available on our Github.

ZKVM & Continuation

Several ZKVM (Zero-Knowledge Virtual Machine) solutions are currently under development, such as Risc Zero, Powdr, zkWasm, and more.

ZKVM compiles target code into a specific instruction set and uses ZKP to prove the execution trace. It differs from ZKEVM, which proves the execution of the Ethereum Virtual Machine (EVM).

RiscZero has developed a proving system that compiles any computation code written in Rust, C/C++, or other languages using the popular RISC-V instruction set. It runs the RISC-V image in its virtual machine, generates traces, and uses zero-knowledge proof technology to prove the execution of these traces.

Notably, RiscZero utilizes continuation technology to split proving sessions into segments. Each segment can be independently proved and verified. By using recursion technology to prove the transition between segments, a single succinct proof can be generated for the entire session.

Running a ZKP prover is a challenging task that typically requires high-performance devices. Here are some examples:

Currently, most ZKP provers use GPUs for acceleration. However, these algorithms require large DDR memory to store proving keys, witness data, point values, etc. This makes it difficult to run the proving system on low-end GPU devices or consumer devices, which hinders decentralization.

Additionally, some ZKP tasks are integral and cannot be easily split. For example, the Halo2 plonk backend needs to generate proofs for each circuit, and when the circuit is large, the proving time and memory requirements are high.

However, ZKVM-based solutions show potential for splitting proof tasks into smaller segments and running them on lower-performance devices, such as RiscZero, Powdr, and Delphinus Labs' zkWasm.

This feature has significant advantages for decentralization, as it allows for the splitting of large proof tasks into smaller ones. These smaller tasks can be executed in parallel, and each task has lower device requirements. This means that more low-end devices can participate, and the proving process can be completed in a shorter time.

ZKPool is committed to decentralizing ZKP provers, and the zkVM solution is an ideal approach to split, dispatch, and aggregate proof tasks, ultimately improving overall proving performance and decentralizing ZKP provers.

For more details about RiscZero's continuation technology, please refer to RiscZero News.

In this demo, we split the proof tasks into four segments, with each segment's tasks being executed on MacBook GPUs, NVIDIA 3080 GPUs, etc.

By having more than four provers participating in parallel, the proof can be generated within a few seconds.

This demonstrates the potential of using continuation technology to complete more complex ZKML tasks for machine learning models.

Conclusion

In summary:

1. We illustrate a flow for accessing ZKPool's proving resources.

2. A ZKML demo is used as an example of how to utilize ZKPool's proving resources.

3. RiscZero's continuation technology is employed to split proof tasks through ZKPool's Aoraki nodes, achieving faster proving finality and compatibility with consumer devices.