Opside ZK-PoW V2.0：多链、多汇总去中心化证明者网络

反对ZK-PoW介绍

Opside 是一个去中心化的 ZK-RaaS（ZK-Rollup as a Service）平台和领先的 ZKP（零知识证明）挖矿网络。 ZK-RaaS 为任何人提供生成 ZK-Rollups 的一键式服务。 Opside 提供了通用的 ZK-Rollup 启动基地，允许开发者轻松在各种基础链上部署不同类型的 ZK-Rollup。

• 基础链：以太坊/Opside链/BNB链/Polygon PoS等公链。
• ZK-Rollup 类型：zkSync、Polygon zkEVM、Scroll、StarkNet 以及 ZK-Rollup 的其他变体。

在Opside的设计中，开发者可以在这些不同的基础链上部署ZK-Rollups。随着ZK-Rollup技术的成熟，未来可能会有数百甚至数千个ZK-Rollup，这将对ZKP算力产生巨大的需求。 Opside利用ZK-PoW机制激励矿工提供ZKP算力，从而为ZK-Rollups提供完整的硬件基础设施。

ZK-PoW V2.0架构

ZK-PoW V2.0的整体架构由几个关键组件组成：

1. ZK-PoW Cloud：这是Opside为ZKP计算提供的云基础设施。它部署在多个链上，包括以太坊、BNB Chain、Polygon PoS 和 Opside Chain。 ZK-PoW Cloud 负责协调和管理 ZKP 计算任务。

   
   

2. 矿工节点：这些是由矿工运营的节点，他们贡献自己的计算能力来执行 ZKP 计算。矿工可以通过在其挖矿硬件上运行专门的软件来参与 ZK-PoW 网络。

   
   

3. ZKP任务分配： ZK-PoW云将ZKP计算任务分配给矿工节点。分配以去中心化的方式进行，保证公平和效率。 ZKP 任务包括生成和验证各种 ZK-Rollups 的零知识证明。

   
   

4. ZKP计算：矿工节点接收ZKP计算任务并执行必要的计算以生成所需的证明。这涉及执行加密算法和执行复杂的计算。

   
   

5. 证明提交和验证： ZKP 计算完成后，矿工节点将生成的证明提交给 ZK-PoW 云进行验证。云基础设施验证证明的正确性，以确保其有效性和完整性。

   
   

6. 激励机制：矿工通过计算贡献获得奖励来激励他们参与 ZK-PoW 网络。奖励制度旨在激励矿工，维护网络的安全稳定。

总体而言，ZK-PoW V2.0 将矿工计算资源的力量与云基础设施相结合，为各种 ZK-Rollups 提供高效且可扩展的 ZKP 计算。

Aggregator是ZK-PoW V2.0系统中Prover的重要组成部分。它负责分发ZKP证明任务，接收任务结果（ZKP证明），管理证明，并将其提交到基础链以获得奖励。根据功能，新版本的聚合器分为三个子模块：证明生成器、证明管理器和证明发送器。

• Proof Generator模块负责向Prover（PoW矿工）分配证明任务，接收任务结果（ZKP证明），并将ZKP证明存储在DB数据库中。

• Proof Manager 负责管理已完成的 ZKP 证明，并将准备上链提交的证明打包为 Proof Sender 模块的任务。

• Proof Sender 模块通过将 ZKP 证明提交到部署在基础链上的 zkEVM 合约来处理 ZKP 证明的链上提交。

  
  

下面分别对这三个模块进行介绍：

证明生成器

Rollup Chain 将一定数量的交易聚合成一个批次，然后将多个批次（基于交易频率等因素）组合成一个序列。然后将序列提交到基础链，使其成为每次链上操作的数据提交单位。每个序列由一个或多个批次组成，ZKP 证明验证所提交序列的有效性。因此，batch是证明任务的最小单位。根据序列中包含的批次数量，所需的证明任务会有所不同，如下所示：

• 如果批次数为1，则证明过程先是BatchProofTask，然后是FinalProofTask，并且任务依次完成。

• 如果序列包含多于1个batch，则证明过程涉及多个BatchProofTask、一个AggregatorProofTask和一个FinalProofTask，并且任务按顺序完成。

  
  

为了最大限度地提高证明生成的效率并增加 PoW 矿工的挖矿奖励，我们的目标是同时生成证明。这是通过两个方面实现的：

• 不同序列的证明生成可以同时完成，因为不存在上下文或状态依赖性。

• 在同一序列内，可以同时执行多个 BatchProofTask。

  
  

这种方法更有效地利用证明者的计算资源，从而更有效地生成证明。

打样经理

该模块主要负责管理 ZKP 证明并控制其链上验证。它由三个主要模块组成：

• commitPendingProof ：该模块仅在聚合器启动时执行一次。其目的是完成之前聚合器服务未完成的 ZKP 证明的提交。这处理了 ProofHash 已提交但其他矿工已经提交了证明的情况。有关proofHash的更多信息，请参阅Proof Sender模块。
• tryFetchProofToSend ：该模块作为协程运行，并将最新生成的 ZKP 证明及其相应的未验证序列添加到 Proof Sender 的缓存中，等待链上提交。
• processResend ：该模块作为协程运行，旨在重新提交在给定时间窗口内尚未成功验证的序列。其目的是确保超过验证时间的序列重新提交进行链上处理。

证明发送者

Opside提出了两步ZKP提交算法来实现证明者的去中心化。该算法可以防止ZKP抢先交易攻击，让更多的矿工获得奖励，从而鼓励更多的矿工参与并提供稳定、持续的ZKP算力。

• 步骤1 ：在为特定序列生成PoW证明（简称证明）时，证明者首先计算“证明/地址”的哈希值并将其提交给合约。如果之前没有为该序列提交 ProofHash，则打开 ProofHash 提交时间窗口 T1。矿工有资格在T1区块内提交序列，并且只能在T1区块之后提交证明。

  
  

• 步骤2 ：T1区块后，T2区块的证明提交窗口打开。如果T2区块内提交的证明均未通过验证，则所有先前提交proofHash的矿工都将受到惩罚。如果proofHash在T1时间窗口内成功提交，但在T2时间窗口内无法成功提交证明，并且其他矿工在T2时间窗口内成功提交证明，证明者仍然可以继续提交该证明。其他场景则重新开始两步提交流程。

下图说明了 Proof Sender 如何使用三个线程安全且按优先级排序的缓存来实现两步提交。这些缓存根据序列的起始高度进行排序，确保每次从这些缓存中检索元素时，它都对应于最低的序列高度。此外，这些缓存中的元素都经过重复数据删除。对应序列的高度越低，处理的优先级越高。

• FinalProofMsgCache：存储Proof Manager发送的finalProof消息，表示ZKP证明完成。
• monitPHTxCache：存储要监控的proofHash交易。
• ProofHashCache：存储链上提交的证明消息。

Proof Sender模块启动后，会启动三个协程来消费三个缓存中的数据。简化流程如下：

1. 协程1从finalProofMsgCache中消费finalProof消息，计算proofHash，如果满足链上提交条件（T1窗口内），则将proofHash提交到链上，并将proofHash交易添加到monitPHTxCache中。

2. 协程 2 使用来自 monitPHTxCache 的proofHash 交易消息。如果proofHash满足T2窗口内链上提交的条件，则构造证明消息并将其存储在ProofHashCache中。

3. 协程 3 使用来自 ProofHashCache 的证明消息并将证明提交到链上。

   
   

与之前的模块相比，这个结构更加清晰，并且节省了资源开销。

概括

与1.0版本对比

• 2.0版本将原来的服务拆分为三个子模块，分别负责证明生成、证明管理和证明提交，结构更清晰、耦合性更低、鲁棒性更强。
• 证明生成模块Proof Generator相比老版本增加了startBatch参数，让新矿工更容易跟上挖矿进度。
• 校样管理模块Proof Manager与旧版本相比有所改进。当矿机服务重启或其他原因导致证明提交失败时，及时重新发送证明，保障矿工利益。重发机制不仅可以解决证明提交失败的情况，还可以处理所有证明提交失败或不提交的情况，保证Rollup Chain的安全。
• 证明提交模块 Proof Sender 使用三个线程安全优先级缓存实现两步交易提交。与之前的版本相比，减少了全局锁的使用，保证了较低高度的证明能够及时提交，保护了矿工的利益。此外，整体服务流程更加清晰，减少了线程数量，减少了程序执行过程中的资源消耗。

压力测试结果：

• 在2.0版本中，使用10台64核机器，在7小时38分40秒内完成了566批批量打样，平均每次打样时间为48.62秒。在多矿工场景下，相比1.0版本，2.0版本的zk证明生成效率整体提升了50%。

  
  

综上所述，Opside ZK-PoW V2.0优化了多个矿工参与ZKP计算的流程，提高了硬件利用率，增强了服务可用性，对矿工更加友好。重要的是，在多矿工场景下，ZKP 的计算时间已缩短至不到一分钟，显着加快了 ZK-Rollup 交易的确认时间。