1. 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. 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, which developers can use to easily deploy different types of ZK-Rollup to different base chains.
-
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.
- Cryptocurrency narratives worth paying attention to this year: LSD, RWA, Onchain Game…
- Viewpoint: Ethereum validator activation waitlist to disappear in the fall
- Ethereum community members propose the ERC-7265 standard to mitigate DeFi hacks.
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 to the above different base chains. With the gradual maturity of ZK-Rollup technology, hundreds or even thousands of ZK-Rollups may be generated 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, thus providing complete hardware infrastructure for ZK-Rollup.
2. Overall Architecture of ZK-PoW V2.0
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 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 execute ZKP computation. Miners can participate in the ZK-PoW network by running dedicated software on their mining hardware.
-
ZKP task distribution: ZK-PoW Cloud distributes ZKP computation tasks to miner nodes. Distribution is done in a decentralized way to ensure fairness and efficiency. ZKP tasks include generating and verifying zero-knowledge proofs for various ZK-Rollups.
-
ZKP computation: Miner nodes receive ZKP computation 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 computation is complete, miner nodes 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 contributing their computing power. The reward system is designed 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.The Aggregator is an important component of the Prover. It is responsible for distributing ZKP proof tasks, receiving task results, managing ZKP proofs, and submitting ZKP proofs to the Base Chain to obtain rewards. Therefore, based on its functions, the new version of the Aggregator is divided into three sub-modules: Proof Generator, Proof Manager, and Proof Sender.As shown in the diagram, the Proof Generator module in the dotted box above is responsible for publishing proof tasks to the Prover (PoW miner), accepting task results (ZKP proofs), and saving ZKP proofs to the DB database. The Proof Manager is responsible for managing completed ZKP proofs, packaging the proofs to be submitted to the chain into sending tasks, and passing them to the Proof Sender module. The Proof Sender module completes the ZKP proof chain submission, i.e. submitting the proof to the zkevm contract deployed on the Base Chain.The following sections introduce these three modules separately:### Proof GeneratorThe 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 transactions), which is then submitted 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 legitimacy of the submitted sequence, so the batch is the minimum unit of proof task.Depending on the batches included in the sequence, different proof tasks need to be completed, as follows:- If the number of batches is 1, the proof process is BatchProofTask -> FinalProofTask, and the BatchProofTask and FinalProofTask proof tasks need to be completed in order.- If the sequence contains more than one batch, the proof process is multiple BatchProofTasks -> AggregatorProofTask -> FinalProofTask, and multiple BatchProofTasks, AggregatorProofTask, and FinalProofTask proof tasks need to be completed in order.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. This is manifested in the following two aspects:- Proof generation for each sequence has no contextual or state dependencies and can be done in parallel.- Multiple BatchProofTasks in the same sequence can be done in parallel.
In order to better utilize the computational resources of Prover, ZKP proofs can be generated more efficiently.
Proof manager
This module is mainly responsible for managing ZKP proofs and controlling 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 its 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 other miners have submitted proof. For the introduction of proofHash and proof, please refer to Proof Sender.
-
tryFetchProofToSend: executed in a coroutine, adds the latest generated ZKP proof and the corresponding sequence that has not been verified to the cache of Proof Sender, waiting to be put on the chain.
-
processResend: executed in a coroutine, the purpose is to resubmit the sequence that has not been successfully verified beyond the time window.
Proof sender
Opside proposed a two-step ZKP submission algorithm to achieve the decentralization of Prover. This algorithm can prevent ZKP from preemptive 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, produce PoW proof as proof, first calculate Hash (proof / address), and submit it to the contract. If proofHash has not been submitted for this sequence before, start the proofHash submission time window T1, and miners will be eligible to submit this sequence in the next T1 blocks. Proof can only be submitted after T1 blocks.
-
step 2: Submit proof, after T1 blocks, start proof submission, and limit it to T2 blocks. If no miner’s proof submission is verified after T2 blocks, all miners who submitted proofHash before will be penalized. If proofHash can be successfully submitted within T1 time window, but proof cannot be successfully submitted within T2 time window, and other miners have successfully submitted proof within T2 window, then this 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 the lowest each time, and the elements in these three caches are deduplicated. The lower the height of the corresponding sequence, the more priority it needs to be processed.
Load testing results:
-
Version 2.0 uses 10 machines with 64 cores each, completes 566 batch proofs in 7 hours 38 minutes and 40 seconds, with an average of 48.62 seconds to complete one proof. In a multi-miner scenario, compared to V1.0, V2.0’s zk proof generation efficiency is improved by 50% overall.
In summary, Opside ZK-PoW V2.0 optimizes the process of multiple miners participating in ZKP calculations, improves hardware utilization, improves service availability, and is more friendly to miners. More importantly, in a multi-miner scenario, reducing the ZKP calculation to less than a minute greatly speeds up the confirmation time of ZK-Rollup.
Like what you're reading? Subscribe to our top stories.
We will continue to update Gambling Chain; if you have any questions or suggestions, please contact us!
