Opside ZKPoW Introduction
Opside is a decentralized ZKRaaS (ZKRollup as a Service) platform and a leading network for ZKP (ZeroKnowledge Proof) mining. ZKRaaS provides a oneclick service for generating ZKRollups to anyone. Opside offers a universal ZKRollup launchbase, allowing developers to easily deploy different types of ZKRollups on various base chains.

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

ZKRollup types: zkSync, Polygon zkEVM, Scroll, StarkNet, and other variants of ZKRollups.
In Opsideâ€™s design, developers can deploy ZKRollups on these different base chains. As ZKRollup technology matures, there may be hundreds or even thousands of ZKRollups in the future, which will create a significant demand for ZKP computation power. Opside utilizes the ZKPoW mechanism to incentivize miners to provide ZKP computation power, thus providing a complete hardware infrastructure for ZKRollups.
ZKPoW V2.0 Architecture
The overall architecture of ZKPoW V2.0 consists of several key components:

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

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

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

ZKP Computation: The miner nodes receive ZKP computation tasks and perform the necessary computations to generate the required proofs. This involves executing cryptographic algorithms and performing complex calculations.

Proof Submission and Verification: Once the ZKP computations are completed, the miner nodes submit the generated proofs to the ZKPoW Cloud for verification. The cloud infrastructure verifies the correctness of the proofs to ensure their validity and integrity.

Incentive Mechanism: Miners are incentivized to participate in the ZKPoW 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, ZKPoW V2.0 combines the power of minersâ€™ computational resources with cloud infrastructure to provide efficient and scalable ZKP computation for a wide range of ZKRollups.
The Aggregator is an important component of the Prover in the ZKPoW V2.0 system. It is responsible for distributing ZKP proof tasks, receiving task results (ZKP proofs), managing the proofs, and submitting them to the Base Chain to earn rewards. Based on their functions, the new version of the Aggregator is divided into three submodules: Proof Generator, Proof Manager, and Proof Sender.

The Proof Generator module is responsible for assigning proof tasks to the Prover (PoW miner), receiving the task results (ZKP proofs), and storing the ZKP proofs in the DB database.

The Proof Manager is in charge of managing the completed ZKP proofs and packaging the proofs that are ready for onchain submission as tasks for the Proof Sender module.

The Proof Sender module handles the onchain submission of ZKP proofs by submitting them to the zkevm contract deployed on the Base Chain.
Below are the introductions of these three modules:
Proof generator
Rollup Chain aggregates a certain number of transactions into a batch, and then multiple batches (based on factors such as transaction frequency) are combined into a sequence. The sequence is then submitted to the Base Chain, making it the unit of data submission for each onchain operation. Each sequence consists of one or more batches, and the ZKP proof verifies the validity of the submitted sequence. Therefore, the batch is the smallest unit of proof task.
Depending on the number of batches included in a sequence, the required proof tasks vary as follows:

If the number of batches is 1, the proof process involves BatchProofTask followed by FinalProofTask, and the tasks are completed sequentially.

If the sequence contains more than 1 batch, the proof process involves multiple BatchProofTasks, an AggregatorProofTask, and a FinalProofTask, and the tasks are completed sequentially.
To maximize the efficiency of proof generation and increase the mining rewards for PoW miners, we aim to generate proofs concurrently. This is achieved in two aspects:

Proof generation for different sequences can be done concurrently as there is no contextual or state dependency.

Within the same sequence, multiple BatchProofTasks can be executed concurrently.
This approach utilizes the computational resources of Provers more efficiently, resulting in more efficient proof generation.
Proof manager
This module is primarily responsible for managing ZKP proofs and controlling their onchain verification. It consists of three main modules:

submitPendingProof: This module is executed only once when the Aggregator starts. Its purpose is to complete the submission of unfinished ZKP proofs from the previous Aggregator service. This handles the situation where proofHash has been submitted but other miners have already submitted their proofs. For more information about proofHash, please refer to the Proof Sender module.

tryFetchProofToSend: This module runs as a coroutine and adds the latest generated ZKP proof, along with its corresponding unverified sequence, to the Proof Senderâ€™s cache, waiting for onchain submission.

processResend: This module runs as a coroutine and aims to resubmit sequences that have not been successfully verified within a given time window. Its purpose is to ensure that sequences that exceed the verification time are resubmitted for onchain processing.
Proof sender
Opside has proposed a twostep ZKP submission algorithm to achieve decentralization of the prover. This algorithm prevents ZKP frontrunning attacks and enables more miners to receive rewards, thereby encouraging more miners to participate and provide stable and continuous ZKP computation power.

Step 1: When producing a PoW proof for a specific sequence (referred to as proof), the prover first calculates the hash of â€śproof / addressâ€ť and submits it to the contract. If no proofHash has been submitted for that sequence before, a proofHash submission time window, T1, is opened. Miners are eligible to submit the sequence within T1 blocks, and proof can only be submitted after T1 blocks.

Step 2: After T1 blocks, the proof submission window is opened for T2 blocks. If none of the submitted proofs pass the verification within T2 blocks, all miners who previously submitted proofHash will be penalized. If proofHash is successfully submitted within the T1 time window but proof cannot be successfully submitted within the T2 time window, and other miners successfully submit their proofs within T2 window, the prover can still continue to submit that proof. In other scenarios, the twostep submission process is restarted.
The following diagram illustrates how Proof Sender implements the twostep submission using three threadsafe and prioritysorted caches. These caches are sorted based on the starting height of the sequences, ensuring that each time an element is retrieved from these caches, it corresponds to the lowest sequence height. Additionally, the elements in these caches are deduplicated. The lower the height of the corresponding sequence, the higher the priority for processing.

finalProofMsgCache: Stores the finalProof messages sent by the Proof Manager, indicating the completion of ZKP proofs.

monitPHTxCache: Stores the proofHash transactions to be monitored.

ProofHashCache: Stores the proof messages for onchain submission.
After the Proof Sender module is launched, three coroutines are started to consume data from the three caches. The simplified process is as follows:

Coroutine 1 consumes the finalProof messages from the finalProofMsgCache, calculates the proofHash, and if it meets the conditions for onchain submission (within the T1 window), it submits the proofHash to the chain and adds the proofHash transaction to the monitPHTxCache.

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

Coroutine 3 consumes the proof messages from the ProofHashCache and submits the proofs to the chain.
Compared to the previous module, this structure is clearer and saves on resource overhead.
Summary
Comparison with Version 1.0

Version 2.0 splits the original service into three submodules, each responsible for proof generation, proof management, and proof submission, resulting in a clearer structure, lower coupling, and stronger robustness.

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

The proof management module, Proof Manager, has been improved compared to the old version. It promptly resends proofs in case of miner service restart or other reasons for proof submission failure, ensuring miner interests. The resend mechanism not only addresses proof submission failure cases but also handles all cases of proof submission failure or nonsubmission, ensuring the security of the Rollup Chain.

The proof submission module, Proof Sender, implements a twostep transaction submission using three threadsafe priority caches. It reduces the use of global locks compared to previous versions, ensuring that proofs with lower heights are submitted promptly and protecting miner interests. Additionally, the overall service flow is clearer, with reduced thread count and reduced resource consumption during program execution.
Stress testing results:
 In Version 2.0, using 10 machines with 64 cores each, 566 batch proofs were completed in 7 hours, 38 minutes, and 40 seconds, with an average time of 48.62 seconds per proof. In a multiminer scenario, compared to Version 1.0, the efficiency of zk proof generation in Version 2.0 improved by 50% overall.
In conclusion, Opside ZKPoW V2.0 has optimized the process of multiple miners participating in ZKP computations, improving hardware utilization, enhancing service availability, and being more minerfriendly. Importantly, in a multiminer scenario, the computation time for ZKP has been reduced to less than a minute, significantly accelerating the confirmation time of ZKRollup transactions.