Opside ZKPoW V2.0: ZKP Mining Supporting Multiple Chains and Rollups
Opside ZKPoW V2.0: ZKP mining for multiple chains and rollups.
1. Introduction to Opside ZKPoW
Opside is a decentralized ZKRaaS (ZKRollup as a Service) platform and a leading ZKP (ZeroKnowledge Proof) mining network in the industry. ZKRaaS (ZKRollup as a Service) can provide oneclick ZKRollup generation services for anyone. Opside provides a universal ZKRollup launchbase, and developers can easily deploy different types of ZKRollups to different base chains through the launchbase.

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

ZKRollup types, including zkSync, Polygon zkEVM, Scroll, StarkNet and other zkEVMs, as well as other types of ZKRollups.
Opside ZKPoW 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 ZKRollups on the above different base chains. With the gradual maturity of ZKRollup technology, hundreds or even thousands of ZKRollups may be born in the future, which will bring great demand for ZKP computing power. Opside uses the ZKPoW mechanism to incentivize miners to provide ZKP computing power, thereby providing complete hardware infrastructure for ZKRollup.
2. ZKPoW V2.0 Architecture Overview
The overall architecture of ZKPoW V2.0 includes several key components:

ZKPoW Cloud: This is the cloud infrastructure provided by Opside for ZKP computing. It is deployed on multiple chains, including Ethereum, BNB Chain, Polygon PoS, and Opside Chain. ZKPoW Cloud is responsible for coordinating and managing ZKP computing tasks.

Miner Nodes: These are nodes operated by miners who contribute their computing power to perform ZKP computations. Miners can participate in the ZKPoW network by running dedicated software on their mining hardware.

ZKP Task Distribution: ZKPoW Cloud distributes ZKP computing tasks to miner nodes. Distribution is done in a decentralized manner to ensure fairness and efficiency. ZKP tasks include generating and verifying zeroknowledge proofs for various ZKRollups.

ZKP Computation: Miner nodes receive ZKP computing tasks and perform the necessary computations to generate the required proofs. This involves performing cryptographic algorithms and complex computations.

Proof Submission and Verification: Once ZKP computation is completed, miner nodes submit the generated proofs to ZKPoW 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 ZKPoW network by receiving rewards for contributing their computing power to ZKP computations. The reward system aims to incentivize miners and maintain the security and stability of the network.
Overall, ZKPoW V2.0 combines the computing resources of miners with cloud infrastructure to provide efficient and scalable ZKP computing power for various ZKRollups.
Aggregator is an important component module of Prover, which is responsible for distributing ZKP proof tasks and receiving task results, managing ZKP proofs, and submitting ZKP proofs to the Base Chain for rewards. Therefore, based on functionality, the new version of Aggregator is divided into three submodules, namely: Proof Generator, Proof Manager, Proof Sender.
As shown in the dotted box in the figure above, the Proof Generator module is responsible for giving the prover (PoW miner) proof tasks and receiving 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 encapsulating the ZKP proofs to be submitted to the Proof Sender module for sending. The Proof Sender module completes the ZKP proof submission to the zkevm contract deployed on the Base Chain.
Below is a description of these three modules:
Proof generator
Rollup Chain packs a certain number of transactions into a batch, then packs several batches into a sequence according to multiple factors such as the frequency of transactions, and then submits it to the Base Chain. Therefore, we can say that the unit of data submitted to the chain each time is a sequence. Each sequence includes one or more batches, and the ZKP proof proves the legality of the submitted sequence, so the batch is the minimum unit of the proof task.
Depending on the batches included in the sequence, the proof task to be completed is also different, as follows:

When the number of batches is equal to 1, the proof process is BatchProofTask —> FinalProofTask, and the BatchProofTask and FinalProofTask proof tasks need to be completed in sequence.

When the sequence contains more than one batch, the proof process is multiple BatchProofTask —> AggregatorproofTask —> FinalProofTask, and multiple BatchProofTask, AggregatorproofTask, and FinalProofTask proof tasks need to be completed in sequence.
In order to maximize the efficiency of proof generation and increase the income of PoW miners, we generate proofs in parallel as much as possible, which is manifested in the following two aspects:

The proof generation of each sequence has no context or state dependence and can be performed in parallel.

Multiple BatchProofTasks within the same sequence can be performed in parallel.
In order to better utilize the computing power resources of Prover, and thus generate proofs more efficiently.
Proof Manager
This module is mainly responsible for managing ZKP proofs and controlling the onchain verification of ZKP proofs. It is mainly divided into three modules:

submitPendingProof: This module is executed only once when the Aggregator is started each time, and the purpose is to complete the submission of ZKP proofs that were not completed before the last Aggregator service was stopped. This is aimed at the situation where proofHash has been submitted and proof has been submitted by other miners. For the introduction of proofHash and proof, please refer to Proof Sender.

tryFetchProofToSend: Executed in a coroutine, the latest generated ZKP proof and the corresponding sequence that have not been verified are added to the Proof Sender cache to wait for onchain verification.

processResend: Executed in a coroutine, the purpose is to resubmit sequences that have not been successfully verified beyond the time window for submission.
Proof Sender
Opside proposed a twostep submission algorithm for ZKP to achieve decentralization of Prover. This algorithm can not only prevent ZKP rushing attacks, but also 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, produce a PoW proof called proof. First calculate Hash(proof/address), called proofHash, and submit it to the contract. If proofHash has not been submitted for this sequence before, the submission time window T1 of proofHash is opened. Within the next T1 blocks, miners are qualified to submit this sequence, and proof can only be submitted after T1 blocks.

Step 2: Submit proof. After T1 blocks, the proof submission is opened and limited to T2 blocks. If all miners fail to verify the proof submitted within 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, the twostep submission process is repeated.
As shown in the figure below, Proof Sender implements the twostep submission based on three threadsafe and priorityordered caches. These three caches are sorted based on the starting height of the sequence to ensure that the height of the sequence corresponding to the element obtained from these three caches is always the lowest, and the elements in these three caches are unique. The lower the height corresponding to the sequence, the higher the priority of processing.

finalProofMsgCahce: Stores finalProof messages sent by the Proof Manager, which represents the completed ZKP proof.

monitPHTxCache: Stores proofHash transactions to be monitored.

ProofHashCache: Stores proof messages for proof onchain.
As shown in the figure below:
The Proof Sender module starts three coroutines that consume data from these three cache objects.
The basic flow is as follows:

Coroutine 1 is responsible for consuming finalProof messages from finalProofMsgCahce, calculating proofHash, and if it meets the onchain conditions (within the T1 condition), then it puts the proofHash onchain and puts the proofHash transaction into monitPHTxCache.

Coroutine 2 consumes proofHash transaction messages from monitPHTxCache. If it meets the proof onchain condition within the T2 time window, it constructs a proof message and stores it in ProofHashCache.

Coroutine 3 consumes proof messages and puts them onchain.
Compared to the old module, the structure is clearer and resources are saved.
Three, summary
Compared with Version 1.0:

V2.0 splits the original service into three submodules, each responsible for proof generation, proof management, and proof onchain, respectively. The structure is clearer, the coupling between the three modules is lower, and the robustness is stronger.

The proof generation module Proof Generator in V2.0 adds the startBatch parameter to facilitate new miners to catch up with the mining progress more quickly.

The proof management module Proof Manager is better improved than the old version: if proof is not submitted or submission fails due to miner service restart or other reasons, it will resend proof at the first time to ensure the miner’s interests. At the same time, the resend mechanism is not only for proof submission failure, but also for all proof submission failures or nonsubmissions, and restarts the time window to ensure the security of Rollup Chain.

The proof sending module Proof Sender uses three threadsafe priority caches to implement twostep submission of transactions. Compared to the previous version, it reduces the use of global locks, ensures that proofs at low heights can be submitted first, and ensures the interests of miners. At the same time, the entire service flow is clearer, the number of threads is reduced, and the consumption of resources during program execution is reduced.
Load test result:

Version 2.0 completed 566 batch proofs using 10 64core machines in 7 hours, 38 minutes, and 40 seconds, with an average of 48.62 seconds per proof. In the multiminer scenario, V2.0 increased the efficiency of zk proof generation by 50% compared to V1.0.
In short, Opside ZKPoW V2.0 optimizes the process of multiminer participation in ZKP calculation, improves hardware utilization and service availability, and is more friendly to miners. More importantly, in the multiminer scenario, the calculation of ZKP is reduced to less than one minute, greatly accelerating the confirmation time of ZKRollup.
We will continue to update Blocking; if you have any questions or suggestions, please contact us!
Was this article helpful?
93 out of 132 found this helpful
Related articles
 How will the Pendle War unfold?
 OPNX bond trading is being questioned as a “false transaction” gimmick. Can Su Zhu fulfill his wish to open an exchange to pay off debts?
 Founder’s Complaint: What Has Moonbirds Done This Year to Make People Disheartened?
 Global Coin Research: How to create a sustainable Web3 game economy model
 Canadian woman creates a metaverse law firm and plans to profit from renting out metaverse properties.
 Gemini cofounder angrily accuses DCG founder: “Scammer, return the money quickly, or we will officially sue DCG and individual.”
 DWeb Camp Experience and Impressions