Flash Depth Data Forum

Forum

Search Extension

Opside ZK-PoW V2.0: ZKP mining supporting multiple chains and Rollups.

2023-07-05 15:00

Read this article in 16 Minutes

Opside ZK-PoW V2.0 optimizes the process of multiple miners participating in ZKP calculations, improving hardware utilization and availability. In a multi-miner scenario, the calculation of ZKP is shortened to less than one minute, greatly accelerating th

一、Opside ZK-PoW Introduction

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) can provide a one-click service for anyone to generate ZK-Rollup. Opside provides a universal ZK-Rollup launchbase, and developers can easily deploy different types of ZK-Rollup to different base chains through the launchbase.

Base chain, including Ethereum/Opside chain/BNB chain/Polygon PoS and other public chains.

ZK-Rollup types, 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 different base chains. As ZK-Rollup technology gradually matures, hundreds or even thousands of ZK-Rollups may be born in the future, which will bring great demand for ZKP computing power. Opside uses the ZK-PoW mechanism to incentivize miners to provide ZKP computing power, thereby providing a complete hardware infrastructure for ZK-Rollup.

二、ZK-PoW V2.0 Overall Architecture

The overall architecture of ZK-PoW V2.0 includes several key components:

ZK-PoW Cloud: This is a cloud infrastructure provided by Opside for ZKP computation. 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 computation tasks.

Miner Nodes: These are nodes operated by miners who contribute their computing power to perform ZKP calculations. Miners can participate in the ZK-PoW network by running specialized software on their mining hardware.

ZKP Task Distribution: ZK-PoW Cloud distributes ZKP computation tasks to mining 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 calculations to generate the required proofs. This involves executing cryptographic algorithms and performing complex computations.

Proof submission and verification: Once the ZKP calculation is completed, the mining node will submit the generated proof to ZK-PoW Cloud for verification. The cloud infrastructure verifies the correctness of the proof to ensure its validity and integrity.

Incentive Mechanism: Miners are incentivized to participate in the ZK-PoW network by earning rewards for their computational contributions. The reward system is designed to motivate miners and maintain the security and stability of the network.

Overall, ZK-PoW V2.0 combines the computing resources of miners with cloud infrastructure to provide efficient and scalable ZKP computing power for various ZK-Rollups.

Aggregator is an important component module of Prover. It is responsible for distributing ZKP proof tasks and receiving task results, i.e. ZKP proofs, managing ZKP proofs, and submitting ZKP proofs to the Base Chain to obtain rewards. Therefore, based on its functions, the new version of Aggregator is divided into three sub-modules: Proof Generator, Proof Manager, and Proof Sender.

As shown in the dotted box above, the Proof Generator module will be responsible for issuing proof tasks to the prover (PoW miner) and accepting 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 sent to the Proof Sender module for delivery. The Proof Sender module completes the ZKP proof on the chain, that is, submitting the proof to the zkevm contract deployed on the Base Chain.

Below are the introductions of these three modules:

Proof generator

Rollup Chain packages a certain number of transactions into a batch, and then packages several batches (based on multiple factors such as transaction frequency) into a sequence, which is then submitted to the Base Chain. Therefore, we can say that the unit of data uploaded to the chain each time is a sequence. Each sequence includes one or more batches, and ZKP proof is used to prove the legitimacy of the submitted sequence, so batch is the smallest unit of proof task.

batch number equals 1, indicating that the process BatchProofTask ----> FinalProofTask needs to complete the proof tasks of BatchProofTask and FinalProofTask in sequence.

Sequence containing batch number greater than 1 indicates that there are multiple BatchProofTask -> AggregatorproofTask -> FinalProofTask processes that need to be completed sequentially for the proof tasks.

In order to maximize the efficiency of proof generation and increase the profits of PoW miners, we generate proofs in parallel as much as possible. This is reflected in two specific aspects:

Each sequence proves that the generation is independent of context or state, and can be performed concurrently.

Multiple BatchProofTasks within the same sequence can be executed concurrently.

In order to better utilize the computing resources of the prover, proofs can be generated more efficiently.

Proof manager

This module is mainly 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 each time the Aggregator is started, with the purpose of completing the submission of ZKP proofs that were not completed before the last Aggregator service shutdown. This is specifically for the case where proofHash has been submitted and other miners have submitted proof. For more information on proofHash and proof, please refer to Proof Sender.

tryFetchProofToSend: In coroutine execution, add the latest generated ZKP proof whose corresponding sequence has not been verified to the Proof Sender's cache and wait for it to be added to the chain.

processResend: Executed in a coroutine to allow sequences that have not been successfully verified within the time window to be resubmitted to the chain.

Proof sender

Opside proposed a ZKP two-phase commit algorithm to achieve decentralization of the prover. This algorithm can prevent ZKP race attacks and allow more miners to receive rewards, thereby encouraging more miners to be online and providing stable and continuous ZKP computing power.

Step 1: For a certain sequence, generate a PoW proof called "proof". First, calculate Hash(proof / address) and submit it to the contract. If proofHash has not been submitted for this sequence before, the submission time window T1 for proofHash will be opened. Within the next T1 blocks, miners are eligible to submit the sequence, and proof can only be submitted after T1 blocks.

Step 2: Submit proof. After T1 block, start submitting proof and limit it to within T2 blocks. If all miners' proof submissions fail to pass verification after T2 blocks, all miners who have submitted proofHash before will be punished. If proofHash can be successfully submitted within the T1 time window but proof cannot be successfully submitted within the T2 time window, and other miners successfully submit proof within the T2 window, the proof can still be submitted. Except for the above scenarios, repeat the two-step submission process.

As shown in the figure below, Proof Sender implements two-phase commit based on three thread-safe and priority-sorted caches. These three caches are sorted based on the starting height of the sequence to ensure that each time an element is obtained from these three caches, the corresponding sequence height is the lowest, and the elements in these three caches are deduplicated. The lower the corresponding sequence height, the higher the priority for processing.

finalProofMsgCahce: Stores the finalProof message sent by the Proof Manager, which is the completion of the ZKP proof.

monitPHTxCache: Stores proofHash transactions to be monitored.

ProofHashCache: Store proof messages for proof on-chain.

As shown in the figure below:

Proof Sender module will start three coroutines after startup, which will consume these three cached data respectively.

The simple process is:

1. Coroutine 1 is responsible for consuming the finalProof messages in finalProofMsgCache, calculating the proofHash. If it meets the conditions for being added to the blockchain (within the T1 condition), then the proofHash will be added to the blockchain and the transaction for the proofHash will be placed in monitPHTxCache.

2. Coroutines 2 consume the proofHash transaction message of monitPHTxCache. If the proof meets the on-chain conditions within the T2 time window, construct the proof message and store it in ProofHashCache.

3. Coroutines 3 consume proof messages and put them on the chain.

Compared to the old module, the structure is clearer and saves resource costs.

Three, Summary

Comparison with Version 1.0

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

The Proof Generator module has added the startBatch parameter compared to the old version, making it easier for new miners to keep up with mining progress.

The Proof Manager module of the encryption industry has been improved compared to the old version: in the event of a miner restarting the service or other reasons causing proof to not be submitted or submitted unsuccessfully, the proof will be resent as soon as possible to ensure the interests of the miner; at the same time, the resend mechanism is not only for proof submission failures, but also for all proof submission failures or non-submissions during the restart time window, ensuring the security of the Rollup Chain.

The Proof Sender module is implemented based on three thread-safe priority caches to achieve two-step transaction submission, reducing the use of global locks compared to previous versions, ensuring that proofs with low heights can be submitted first and ensuring the interests of miners. At the same time, the entire service process is clearer, reducing the number of threads and the consumption of resources during program execution.

Load testing results:

In short, Opside ZK-PoW V2.0 optimizes the process of multiple miners participating in ZKP calculation, improves hardware utilization, enhances service availability, and is more friendly to miners. More importantly, in the scenario of multiple miners, the calculation of ZKP is shortened to less than one minute, greatly accelerating the confirmation time of ZK-Rollup.