Prover Architecture

Overall Architecture

The Aggregator , acting as a proxy between the ZKP-calculator and the verifier contract on the base chain, is an important component of the Prover in the ZK-PoW V2.0 system. It is responsible for

  • distributing ZKP proof tasks and receiving task results (ZKP proofs)

  • managing the proofs submitting them to the Base Chain to earn rewards.

Based on the jobs, the new design of Lumoz's Aggregator is divided into three sub-modules: Proof Generator, Proof Manager, and Proof Sender.

  • The Proof Generator 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 on-chain submission as tasks for the Proof Sender module.

  • The Proof Sender module handles the on-chain 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 on-chain operation.

During the process, 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 on-chain 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 on-chain 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 on-chain processing.

Proof sender

Lumoz has proposed to achieve decentralization of the prover. This algorithm prevents ZKP front-running attacks and enables more miners to receive rewards, thereby encouraging more miners' participation and provide stable and continuous ZKP computation power.

The following diagram illustrates how Proof Sender implements the two-step submission using three thread-safe and priority-sorted 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 on-chain 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:

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

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

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