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:

1. Design an interface to separate ZKP requesters and ZKP provers. The ZKP Requester-Prover-Separation (RPS) model is a framework that we use.

2. 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.

1. The ZKPool service stakes liability into the ZKPool contract.

2. 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.

3. 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.

4. The ZKPool service schedules a prover to do such a proving task.

5. The prover submits the proof to the ZKPool service.

6. The ZKPool service submits the proof to the ZKPool contract within the specified time (less than LiabilityWindow).

7. 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".

8. The ZKPool contract transfers liability to the ZKPool service and provides it with a reward based on the negotiated price.

9. The ZKPool shares rewards with the prover.

10. 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:

1. Design an interface to separate ZKP requesters and ZKP provers. The ZKP Requester-Prover-Separation (RPS) model is a framework that we use.

2. 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.

1. The ZKPool service stakes liability into the ZKPool contract.

2. 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.

3. 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.

4. The ZKPool service schedules a prover to do such a proving task.

5. The prover submits the proof to the ZKPool service.

6. The ZKPool service submits the proof to the ZKPool contract within the specified time (less than LiabilityWindow).

7. 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".

8. The ZKPool contract transfers liability to the ZKPool service and provides it with a reward based on the negotiated price.

9. The ZKPool shares rewards with the prover.

10. 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.