证明者架构
总体架构
在ZK-PoW V2.0系统中，作为ZKP计算器和基础链上验证器合约之间的代理的Aggregator是Prover的一个重要组件。它负责以下任务：
分发ZKP证明任务并接收任务结果（ZKP证明）
管理证明并将其提交到基础链以获得奖励。
基于这些任务，Lumoz的Aggregator的新设计被划分为三个子模块：Proof Generator、Proof Manager和Proof Sender。
Proof Generator负责将证明任务分配给Prover（PoW矿工），接收任务结果（ZKP证明）并将ZKP证明存储在DB数据库中。Proof Manager负责管理已完成的ZKP证明，并将准备好进行链上提交的证明打包为Proof Sender模块的任务。Proof Sender模块负责将ZKP证明提交到部署在基础链上的zkevm合约中进行链上提交。
以下是这三个模块的介绍
证明生成器
Rollup Chain将一定数量的交易聚合成一个批次，然后将多个批次（基于交易频率等因素）组合成一个序列。然后，该序列被提交到基础链，成为每个链上操作的数据提交单位。
在该过程中，每个序列由一个或多个批次组成，而ZKP证明验证了所提交序列的有效性。因此，批次是证明任务的最小单位。
根据包含在一个sequence中的batches数量，所需的证明任务如下所示：
如果
batches数量为1，证明过程包括BatchProofTask，然后是FinalProofTask，任务按顺序完成。如果
sequence包含多个batch，证明过程涉及多个BatchProofTasks，一个AggregatorProofTask和一个FinalProofTask，任务按顺序完成。
为了最大化证明生成的效率并增加PoW矿工的挖矿奖励，我们的目标是同时生成证明。这通过以下两个方面实现：
不同
sequences的证明生成可以同时进行，因为它们之间没有上下文或状态依赖。在同一个
sequence内，可以同时执行多个BatchProofTasks。
这种方法更有效地利用了Prover的计算资源，从而实现了更高效的证明生成。
证明管理器
该模块主要负责管理ZKP证明并控制它们的链上验证。它由三个主要模块组成：
submitPendingProof: 该模块在Aggregator启动时仅执行一次。其目的是完成来自先前Aggregator服务的未完成ZKP证明的提交。它处理了proofHash已经被提交，但其他矿工已经提交了他们的proofs的情况。有关proofHash的更多信息，请参考证明发送器模块。tryFetchProofToSend: 该模块作为一个协程运行，并将最新生成的ZKP证明及其对应的未验证sequence添加到Proof Sender的缓存中，等待进行链上提交。processResend: 该模块作为一个协程运行，旨在重新提交在给定时间窗口内未能成功验证的sequences。其目的是确保超过验证时间的序列重新提交进行链上处理。
证明发送器
Lumoz提出了 ZKP两步提交 来实现Prover的去中心化。这种算法可以防止ZKP前置攻击，并使更多的矿工获得奖励，从而鼓励更多的矿工参与并提供稳定连续的ZKP计算能力。
下图展示了Proof Sender如何使用三个线程安全且按优先级排序的缓存来实现两步提交。这些缓存根据sequences的起始高度进行排序，确保每次从这些缓存中检索的元素对应于最低的sequences高度。此外，这些缓存中的元素是去重的。对应序列的高度越低，处理的优先级越高。
finalProofMsgCache: 存储由Proof Manager发送的表示ZKP证明完成的finalProof消息。monitPHTxCache: 存储待监视的proofHash交易。ProofHashCache: 存储用于链上提交的proof消息。
启动Proof Sender模块后，会启动三个协程来从三个缓存中消费数据。简化的过程如下所示：
协程1从
finalProofMsgCache中获取finalProof消息，计算proofHash。如果满足链上提交的条件（在T1窗口内），则将proofHash提交到链上，并将proofHash交易添加到monitPHTxCache中。协程2从
monitPHTxCache中消费proofHash交易消息。如果proofHash满足在T2窗口内进行链上提交的条件，它将构建证明消息并将其存储在ProofHashCache中。协程3从
ProofHashCache中消费证明消息，并将证明提交到链上。
与先前的模块相比，这种结构更清晰，并节省了资源开销。
Last updated
