# 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 ZKP Two-Step Submission 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:

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`

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

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

Last updated