Trusted Infrastructure for Verifiable Computing.
ZKPool's Aggregation of Multi-Prover
What's a multi-prover system?In a ZKP (Zero Knowledge Proof) system, multiple types of proofs can be generated for the same proving task. The verifier can only verify a state transition when all the generated proofs are verified. The types of proofs include ZK-SNARK, ZK-STARK, SGX, and so on.Multi-prover system (From Taiko's blog)Vitalik proposed the multi-prover design in a speech.Vitalik's multi-prover proposal (From Vitalik's share)Especially, SGX proof is a type of pro...

Introducing FidCore: Trusted Infrastructure for Verifiable Computing
zkVM and its Continuation Technology
Firstly, welcome to the zkML demo, which operates on ZKPool and is built on RISC Zero's zkVM solution.BackgroundIncreasingly, projects such as RISC Zero are building zkVM, while others like Taiko and Optimism are utilizing zkVM to develop applications for Ethereum Layer 2. The zkVM solution is gaining more recognition. Previously, there were concerns about its performance. However, teams have continually optimized it from both the ZKP protocol and hardware perspectives. It's getting...

Subscribe to FidCore
ZKPool's Aggregation of Multi-Prover
What's a multi-prover system?In a ZKP (Zero Knowledge Proof) system, multiple types of proofs can be generated for the same proving task. The verifier can only verify a state transition when all the generated proofs are verified. The types of proofs include ZK-SNARK, ZK-STARK, SGX, and so on.Multi-prover system (From Taiko's blog)Vitalik proposed the multi-prover design in a speech.Vitalik's multi-prover proposal (From Vitalik's share)Especially, SGX proof is a type of pro...

Introducing FidCore: Trusted Infrastructure for Verifiable Computing
zkVM and its Continuation Technology
Firstly, welcome to the zkML demo, which operates on ZKPool and is built on RISC Zero's zkVM solution.BackgroundIncreasingly, projects such as RISC Zero are building zkVM, while others like Taiko and Optimism are utilizing zkVM to develop applications for Ethereum Layer 2. The zkVM solution is gaining more recognition. Previously, there were concerns about its performance. However, teams have continually optimized it from both the ZKP protocol and hardware perspectives. It's getting...
<100 subscribers
<100 subscribers
This document introduces how new or existing ZKP projects can access ZKPool's prover resources. It covers the background, the module structure, the interface, and the flow. The goal is to make it easier for ZKP projects to access ZKPool and utilize its open and decentralized proving system with an economical design.
Currently, many ZKP applications still use a centralized proving system. However, decentralizing the proving system has significant advantages for ZKP projects.

In particular, it is challenging for small ZKP projects to maintain their prover clusters. Additionally, we can achieve a higher utilization rate for the provers by sharing a prover pool among various ZKP projects via ZKPool.
To migrate from a centralized proving system to a decentralized proving system for a ZKP project, the ZKPool proposes the following steps:
Design an interface to separate ZKP requesters and ZKP provers. The ZKP Requester-Prover-Separation (RPS) model is a framework that we use.
Design prove tokenomics, which involves the following components:
(1) Define a proving task distribution strategy. Here are several strategies to consider:
* POW (not recommended).
* Multiple provers competing based on certain metrics.
* Single prover assigned to a single task (recommended for overall cost savings).
(2) Define a reward mechanism. Once the prover submits the correct proof, they should be rewarded.
(3) Define a penalty mechanism. The prover will be penalized if it fails to generate the correct proof.
Designing such proving tokenomics is not an easy task. In this case, ZKPool provides a common contract to implement this type of proving tokenomics, while the ZKP project's contract only needs to provide its verification interface to the ZKPool contract.
The architecture consists of the following modules:
ZKP Requester: This module represents the ZKP project or ZKP applications from the partner who sends the ZKP proving tasks to ZKPool.
ZKP Requester Contract: This module represents the contract of the ZKP Requester.
ZKPool Service: This module represents ZKPool's service, which provides price quotations, resource scheduling, and other functionalities.
ZKPool Contract: This module represents ZKPool's contract.
Prover: This module represents the prover, which connects to the ZKPool service and generates the proof for the ZKP requester.

The ZKPool contract is located outside the ZKP requester contract and serves as an optional entry point for the partner. It does not interfere with the ZKP requester contract.
When submitting a proof using the ZKPool contract, no verification is performed (or optional verification), instead, the contract directly calls the functions of the ZKP requester contract. If the function execution is successful, it indicates that the proof has been successful.
Because it involves economic responsibility (e.g., ZKP requester must submit within 24 hours or face penalties), the ZKPool and ZKP requester need to agree on liability and assume certain responsibilities through liability. If the proof is submitted within a specific time frame, the liability will be returned. The requester can claim the liability if the proof is not submitted within the specified time frame.
On the ZKPool side, when a task is confirmed, it will schedule a prover to handle this task.
The ZKPool service stakes liability into the ZKPool contract.
The requester that needs to generate proof communicates with ZKPool Service off-chain to negotiate tasks and obtain the corresponding information like a reward, completion time, and a signature of the task fulfillment responsibility.
The requester publishes the task to the ZKPool contract. The contract returns an identifier for the task (e.g., task1) to easily retrieve information about the task. The ZKPool service immediately receives the proof task's reward in advance.
The ZKPool service schedules a prover to do such a proving task.
The prover submits the proof to the ZKPool service.
The ZKPool service submits the proof to the ZKPool contract within the specified time (less than LiabilityWindow).
The ZKPool contract performs a simple check and calls the corresponding function of the ZKP requester contract. If the function runs successfully, the task status is changed to "done".
The ZKPool contract transfers liability to the ZKPool service and provides it with a reward based on the negotiated price.
The ZKPool shares rewards with the prover.
The ZKP requester monitors the ZKPool contract and is aware when the proof is successfully verified.
Note: If the proof is not submitted after the LiabilityWindow, the requester can claim all the liability through the ZKPool contract.

This document introduces the interface and flow for ZKP projects to access ZKPool prover resources. It is particularly helpful for the centralized proving system.
Thanks to the ZKPool contract, modifications to ZKP projects are minimal.
In the future, we will provide more details on managing the ZKPool Service's prover using a contract to achieve the internal reward-penalty mechanism and transparent revenue allocation. We will also explain how to run the ZKPool service in a decentralized manner. With these design considerations, the entire proving system can operate purely decentralized.
This document introduces how new or existing ZKP projects can access ZKPool's prover resources. It covers the background, the module structure, the interface, and the flow. The goal is to make it easier for ZKP projects to access ZKPool and utilize its open and decentralized proving system with an economical design.
Currently, many ZKP applications still use a centralized proving system. However, decentralizing the proving system has significant advantages for ZKP projects.

In particular, it is challenging for small ZKP projects to maintain their prover clusters. Additionally, we can achieve a higher utilization rate for the provers by sharing a prover pool among various ZKP projects via ZKPool.
To migrate from a centralized proving system to a decentralized proving system for a ZKP project, the ZKPool proposes the following steps:
Design an interface to separate ZKP requesters and ZKP provers. The ZKP Requester-Prover-Separation (RPS) model is a framework that we use.
Design prove tokenomics, which involves the following components:
(1) Define a proving task distribution strategy. Here are several strategies to consider:
* POW (not recommended).
* Multiple provers competing based on certain metrics.
* Single prover assigned to a single task (recommended for overall cost savings).
(2) Define a reward mechanism. Once the prover submits the correct proof, they should be rewarded.
(3) Define a penalty mechanism. The prover will be penalized if it fails to generate the correct proof.
Designing such proving tokenomics is not an easy task. In this case, ZKPool provides a common contract to implement this type of proving tokenomics, while the ZKP project's contract only needs to provide its verification interface to the ZKPool contract.
The architecture consists of the following modules:
ZKP Requester: This module represents the ZKP project or ZKP applications from the partner who sends the ZKP proving tasks to ZKPool.
ZKP Requester Contract: This module represents the contract of the ZKP Requester.
ZKPool Service: This module represents ZKPool's service, which provides price quotations, resource scheduling, and other functionalities.
ZKPool Contract: This module represents ZKPool's contract.
Prover: This module represents the prover, which connects to the ZKPool service and generates the proof for the ZKP requester.

The ZKPool contract is located outside the ZKP requester contract and serves as an optional entry point for the partner. It does not interfere with the ZKP requester contract.
When submitting a proof using the ZKPool contract, no verification is performed (or optional verification), instead, the contract directly calls the functions of the ZKP requester contract. If the function execution is successful, it indicates that the proof has been successful.
Because it involves economic responsibility (e.g., ZKP requester must submit within 24 hours or face penalties), the ZKPool and ZKP requester need to agree on liability and assume certain responsibilities through liability. If the proof is submitted within a specific time frame, the liability will be returned. The requester can claim the liability if the proof is not submitted within the specified time frame.
On the ZKPool side, when a task is confirmed, it will schedule a prover to handle this task.
The ZKPool service stakes liability into the ZKPool contract.
The requester that needs to generate proof communicates with ZKPool Service off-chain to negotiate tasks and obtain the corresponding information like a reward, completion time, and a signature of the task fulfillment responsibility.
The requester publishes the task to the ZKPool contract. The contract returns an identifier for the task (e.g., task1) to easily retrieve information about the task. The ZKPool service immediately receives the proof task's reward in advance.
The ZKPool service schedules a prover to do such a proving task.
The prover submits the proof to the ZKPool service.
The ZKPool service submits the proof to the ZKPool contract within the specified time (less than LiabilityWindow).
The ZKPool contract performs a simple check and calls the corresponding function of the ZKP requester contract. If the function runs successfully, the task status is changed to "done".
The ZKPool contract transfers liability to the ZKPool service and provides it with a reward based on the negotiated price.
The ZKPool shares rewards with the prover.
The ZKP requester monitors the ZKPool contract and is aware when the proof is successfully verified.
Note: If the proof is not submitted after the LiabilityWindow, the requester can claim all the liability through the ZKPool contract.

This document introduces the interface and flow for ZKP projects to access ZKPool prover resources. It is particularly helpful for the centralized proving system.
Thanks to the ZKPool contract, modifications to ZKP projects are minimal.
In the future, we will provide more details on managing the ZKPool Service's prover using a contract to achieve the internal reward-penalty mechanism and transparent revenue allocation. We will also explain how to run the ZKPool service in a decentralized manner. With these design considerations, the entire proving system can operate purely decentralized.
Share Dialog
Share Dialog
No activity yet