Opside ZK-PoW V2.0: ZKP Mining Supporting Multiple Chains and Rollups

Opside ZK-PoW V2.0: ZKP mining for multiple chains and rollups.

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) can provide one-click ZK-Rollup generation services for anyone. Opside provides a universal ZK-Rollup launchbase, and developers can easily deploy different types of ZK-Rollups 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 zkEVMs, as well as other types of ZK-Rollups.

  • FTX sues its former chief compliance officer Dan Friedberg: what does it mean for FTX creditors?
  • RWA Discussion: Underlying Assets, Business Structure, and Development Path
  • Understanding ERC-6551: Has the composability of NFTs finally been achieved?

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 above different base chains. With the gradual maturity of ZK-Rollup technology, 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 complete hardware infrastructure for ZK-Rollup.

2. ZK-PoW V2.0 Architecture Overview

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

• ZK-PoW 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. ZK-PoW 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 ZK-PoW network by running dedicated software on their mining hardware.

• ZKP Task Distribution: ZK-PoW 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 zero-knowledge proofs for various ZK-Rollups.

• 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 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 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, 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, 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 sub-modules, 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 on-chain 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 on-chain 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 two-step 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 two-step submission process is repeated.

As shown in the figure below, Proof Sender implements the two-step submission based on three thread-safe and priority-ordered 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 on-chain.

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:

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

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

3. Coroutine 3 consumes proof messages and puts them on-chain.

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 sub-modules, each responsible for proof generation, proof management, and proof on-chain, 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 re-send proof at the first time to ensure the miner’s interests. At the same time, the re-send mechanism is not only for proof submission failure, but also for all proof submission failures or non-submissions, and restarts the time window to ensure the security of Rollup Chain.

• The proof sending module Proof Sender uses three thread-safe priority caches to implement two-step 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 64-core machines in 7 hours, 38 minutes, and 40 seconds, with an average of 48.62 seconds per proof. In the multi-miner scenario, V2.0 increased the efficiency of zk proof generation by 50% compared to V1.0.

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

We will continue to update Blocking; if you have any questions or suggestions, please contact us!