Opside ZK-PoW V2.0: ZKP Mining Supporting Multi-Chain and Multi-Rollup
1. Introduction to Opside ZK-PoW
Opside is a decentralized ZK-RaaS (ZK-Rollup as a Service) platform and a leading ZKP (Zero-Knowledge Proof) mining network in the industry. ZK-RaaS (ZK-Rollup as a Service) provides a one-click service to generate ZK-Rollup for anyone. Opside provides a universal ZK-Rollup launchbase, allowing developers to easily deploy different types of ZK-Rollups on different base chains.
Base chain, including Ethereum/Opside chain/BNB chain/Polygon PoS and other public chains.
Types of ZK-Rollup, including zkSync, Polygon zkEVM, Scroll, StarkNet, and other types of ZK-Rollups.
Opside ZK-PoW Cloud will be deployed on multiple chains, including but not limited to Ethereum, BNB Chain, Polygon PoS, and Opside Chain itself. In Opside's design, developers can deploy ZK-Rollups on the aforementioned base chains. With the gradual maturity of ZK-Rollup technology, there may be hundreds or even thousands of ZK-Rollups in the future, which will bring enormous demands for ZKP computational power. Opside uses the ZK-PoW mechanism to incentivize Miners to provide ZKP computational power, thus providing a complete hardware infrastructure for ZK-Rollup.
2. ZK-PoW V 2.0 Overall Architecture
The overall architecture of ZK-PoW V 2.0 includes several key components:
ZK-PoW Cloud: This is the cloud infrastructure provided by Opside for ZKP calculations. It is deployed on multiple chains, including Ethereum, BNB Chain, Polygon PoS, and Opside Chain. ZK-PoW Cloud is responsible for coordinating and managing ZKP calculation tasks.
Miner Nodes: These are the nodes operated by miners who contribute their computational power to perform ZKP calculations. Miners can participate in the ZK-PoW network by running dedicated software on their mining hardware.
ZKP Task Distribution: ZK-PoW Cloud distributes ZKP calculation tasks to miner nodes. The distribution is done in a decentralized manner to ensure fairness and efficiency. ZKP tasks include generating and verifying zero-knowledge proofs for various ZK-Rollups.
ZKP Calculation: Miner nodes receive ZKP calculation tasks and perform necessary computations to generate the required proofs. This involves executing cryptographic algorithms and performing complex calculations.
Proof Submission and Verification: Once ZKP calculation is completed, miner nodes submit the generated proofs to ZK-PoW Cloud for verification. The cloud infrastructure verifies the correctness of the proofs to ensure their validity and integrity.
Incentive Mechanism: Miners are motivated to participate in the ZK-PoW network by receiving rewards for their computational contributions. The reward system aims to incentivize miners and maintain the security and stability of the network.
In general, ZK-PoW V 2.0 combines miners' computational resources with cloud infrastructure to provide efficient and scalable ZKP computation capabilities for various ZK-Rollups.
The Aggregator is an important component of the Prover. It is responsible for distributing ZKP proof tasks, receiving task results (ZKP proofs), managing ZKP proofs, and submitting ZKP proofs to the Base Chain to obtain rewards. Based on functionality, the new version of Aggregator is divided into three sub-modules: Proof Generator, Proof Manager, and Proof Sender.
The Proof Generator module in the dashed box in the above figure will be responsible for issuing proof tasks to the prover (PoW miner) and accepting the task results: ZKP proofs, and then saving the ZKP proofs to the DB database. The Proof Manager is responsible for managing the completed ZKP proofs and packaging the ZKP proofs to be included in the chain into tasks to be transferred to the Proof Sender module. The Proof Sender module completes the process of adding the ZKP proofs to the chain, which means submitting the proofs to the zkevm contract deployed on the Base Chain.
The following introduces these three modules separately:
Proof generator
The Rollup Chain packages a certain number of transactions into a batch, and then packages several batches into a sequence based on factors such as the frequency of the transactions. Then it submits the sequence to the Base Chain, so we can say that the unit of data added to the chain each time is a sequence. Each sequence includes one or more batches, and the ZKP proof is the proof of the validity of the submitted sequence, so the batch is the smallest unit of the proof task.
Depending on the different batches included in the sequence, different proof tasks need to be completed, as follows:
Number of batches equals 1, proof process: BatchProofTask ----> FinalProofTask. The BatchProofTask and FinalProofTask proof tasks need to be completed in order.
sequence contains more than one batch, indicating that there are multiple BatchProofTask ----> AggregatorproofTask ---> FinalProofTask in the process, which need to be completed sequentially: BatchProofTask, AggregatorproofTask, FinalProofTask proof tasks.
In order to maximize the efficiency of proof generation and improve the income of PoW miners, we generate proofs concurrently as much as possible. This is manifested in the following two aspects:
Proof generation for each sequence does not have context or state dependencies, and can be done concurrently.
Multiple BatchProofTasks within the same sequence can be executed concurrently.
This better utilizes the computing resources of the prover and enables more efficient proof generation.
Proof manager
This module is responsible for managing ZKP proofs and controlling the on-chain verification of ZKP proofs. It is mainly divided into three modules:
submitPendingProof: This module is only executed once when the Aggregator is started, with the purpose of submitting the unfinished ZKP proofs from the previous Aggregator service shutdown. This is in the case where proofHash has been submitted and other miners have submitted proof. For more information about proofHash and proof, please refer to Proof Sender.
tryFetchProofToSend: Executed in a coroutine, this module adds the newly generated ZKP proof (whose corresponding sequence has not been verified) to the cache of Proof Sender, waiting to be placed on the chain.
processResend: In the execution of the coroutine, the purpose is to resubmit the sequence that has not been successfully verified within the time window back to the chain.
Proof sender
Opside has proposed a ZKP two-step submission algorithm to achieve decentralization of the prover. This algorithm can both prevent ZKP race attacks and allow more miners to receive rewards, thereby encouraging more miners to be online and providing stable and continuous ZKP computational power.
Step 1: For a certain sequence, the production of PoW proof is recorded as proof. First, calculate Hash(proof / address), recorded as proofHash, and submit it to the contract. If no proofHash has been submitted for this sequence before, the submission time window T1 for proofHash is opened. Within the next T1 blocks, miners are eligible to submit this sequence, and proof can only be submitted after T1 blocks.
Step 2: Submit proof after block T 1 and before block T 2, submit proof and limit it to be submitted within 2 blocks. If after block T 2, none of the submitted proof by the miners pass the verification, then all the miners who previously submitted proofHash will be punished. If proofHash was successfully submitted within the time window T 1, but failed to submit proof within the time window T 2 while other miners successfully submitted proof within the T 2 time window, then the proof can still be submitted. In addition to the above scenarios, repeat the two-step submission process.
As shown in the figure below, Proof Sender implements two-step submission based on three thread-safe and priority sorted caches. These three caches are sorted based on the starting height of the sequence, guaranteeing that the element obtained from these three caches corresponds to the lowest sequence height, and the elements in these three caches are unique. The lower the sequence height, the higher the priority for processing.
finalProofMsgCahce: Stores the finalProof message sent by Proof Manager, which is the completion of ZKP proof.
monitPHTxCache: Stores the proofHash transactions to be monitored.
ProofHashCache: Stores proof messages for on-chain proof.
As shown in the figure below:
Proof Sender module will start and run 3 coroutines to consume these three cached data.
The simple process is:
Coroutine 1 is responsible for consuming the finalProof messages in finalProofMsgCache, calculating the proofHash. If it meets the on-chain criteria (within condition T1), the proofHash will be uploaded to the chain and the proofHash transaction will be put into monitPHTxCache.
Coroutine 2 consumes the proofHash transaction messages in monitPHTxCache. If it satisfies the proof on-chain criteria within the T2 time window, it constructs the proof message and stores it in ProofHashCache.
Coroutine 3 consumes the proof messages and uploads the proof to the chain.
Compared to the old module, the structure is clearer and resource consumption is reduced.
III. Summary
Compared to Version 1.0:
V 2.0 splits the original service into three sub-modules, each responsible for proof generation, proof management, and proof on-chain. The structure is clearer, and the three modules have low coupling and strong robustness.
Proof Generator module has added the startBatch parameter to the relative old version to facilitate the faster catch-up of newly added miners to the mining progress.
Proof Manager module is improved compared to the old version: if the miner restarts the service or for any other reason the proof is not submitted or submission fails, it will be resent as soon as possible to ensure the miner's interest. At the same time, the resend mechanism is not only for proof submission failures, but also for all failed or unsubmitted proofs during the restart time window, ensuring the security of the Rollup Chain.
Proof Sender module implements a two-step submission of transactions based on three threads with different safety priority caches, reducing the use of global locks compared to previous versions and ensuring that proofs with low heights can be submitted promptly to benefit the miners. Meanwhile, the entire service process is clearer, with reduced thread numbers and reduced resource consumption during program execution.
Performance test results:
Using 10 machines with 64 cores each, Version 2.0 completed 566 batch proofs in 7 hours, 38 minutes, and 40 seconds, with an average time of 48.62 seconds per proof. In the multi-miner scenario, the efficiency of zk proofs generation in V 2.0 is overall improved by 50% compared to V 1.0
In summary, Opside ZK-PoW V 2.0 optimizes the process of multi-miner participation in ZKP calculations, improves hardware utilization, enhances service availability, and is more friendly to miners. More importantly, in the multi-miner scenario, the computation time for ZKP is reduced to less than a minute, greatly accelerating the confirmation time of ZK-Rollup.
