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 involvesBatchProofTask
followed byFinalProofTask
, and the tasks are completed sequentially.If the
sequence
contains more than 1batch
, the proof process involves multipleBatchProofTasks
, anAggregatorProofTask
, and aFinalProofTask
, 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
, multipleBatchProofTasks
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 theAggregator
starts. Its purpose is to complete the submission of unfinished ZKP proofs from the previousAggregator
service. This handles the situation whereproofHash
has been submitted but other miners have already submitted theirproofs
. 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 unverifiedsequence
, to theProof Sender
's cache, waiting for on-chain submission.processResend
: This module runs as a coroutine and aims to resubmitsequences
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 thefinalProof
messages sent by theProof Manager
, indicating the completion of ZKP proofs.monitPHTxCache
: Stores theproofHash
transactions to be monitored.ProofHashCache
: Stores theproof
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 thefinalProofMsgCache
, calculates theproofHash
, and if it meets the conditions for on-chain submission (within the T1 window), it submits theproofHash
to the chain and adds theproofHash
transaction to themonitPHTxCache
.Coroutine 2 consumes the
proofHash
transaction messages from themonitPHTxCache
. If theproofHash
meets the conditions for on-chain submission within the T2 window, it constructs the proof message and stores it in theProofHashCache
.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