Opside ZK-PoW V2.0：支持多链多Rollup的ZKP挖矿
一、Opside ZK-PoW 介绍
Opside 是一个去中心化的 ZK-RaaS (ZK-Rollup as a Service)平台，也是业内领先的 ZKP（零知识证明）挖矿网络。ZK-RaaS (ZK-Rollup as a Service) 可以为任何人提供一键生成 ZK-Rollup 的服务。Opside 提供通用的 ZK-Rollup launchbase，开发者可以通过 launchbase 轻松地部署不同类型的 ZK-Rollup 到不同的 base chain 上。
-
Base chain，包括 Ethereum/Opside chain/BNB chain/Polygon PoS 等公链。
-
ZK-Rollup 类型，包括 zkSync、Polygon zkEVM、Scroll、StarkNet 等 zkEVMs，以及其他种类的 ZK-Rollups。
Opside ZK-PoW Cloud 会部署到多链上，包括但不限于 Ethereum、BNB Chain、Polygon PoS 以及 Opside Chain 本身。在 Opside 的设计中，开发者可以在上述不同的 base chain 上部署 ZK-Rollups。随着 ZK-Rollup 技术的逐渐成熟，未来可能会诞生成百上千个 ZK-Rollups，这将带来极大的 ZKP 算力需求。Opside 使用 ZK-PoW 机制来激励 Miner 提供 ZKP 算力，从而为 ZK-Rollup 提供完整的硬件设施。
二、ZK-PoW V2.0 整体架构
ZK-PoW V2.0 的整体架构包括几个关键组件：
-
ZK-PoW Cloud：这是 Opside 提供的用于 ZKP 计算的云基础设施。它部署在多个链上，包括 Ethereum、BNB Chain、Polygon PoS 和 Opside Chain。ZK-PoW Cloud 负责协调和管理 ZKP 计算任务。
-
矿工节点：这些是由矿工操作的节点，他们贡献自己的计算能力来执行 ZKP 计算。矿工可以通过在他们的挖矿硬件上运行专用软件来参与 ZK-PoW 网络。
-
ZKP 任务分发：ZK-PoW Cloud 将 ZKP 计算任务分发给矿工节点。分发是以去中心化方式进行的，以确保公平性和效率性。ZKP 任务包括为各种 ZK-Rollup 生成和验证零知识证明。
-
ZKP 计算：矿工节点接收 ZKP 计算任务，并进行必要的计算来生成所需的证明。这涉及执行密码学算法和进行复杂的计算。
-
证明提交和验证：一旦 ZKP 计算完成，矿工节点将生成的证明提交给 ZK-PoW Cloud 进行验证。云基础设施验证证明的正确性，以确保其有效性和完整性。
-
激励机制：矿工通过为他们的计算贡献获得奖励来激励他们参与 ZK-PoW 网络。奖励系统旨在激励矿工并维护网络的安全性和稳定性。
总的来说，ZK-PoW V2.0 将矿工的计算资源与云基础设施相结合，为各种 ZK-Rollup 提供高效且可扩展的 ZKP 计算能力。
Aggregator 是 Prover 的重要组成模块， 它负责分发 ZKP 证明任务并接收任务结果即 ZKP 证明，管理 ZKP 证明以及将 ZKP 证明提交到 Base Chain 以此获取奖励 。因此基于功能将新版 Aggregator 分为三个子模块，分别为：Proof Generator, Proof Manager, Proof Sender。
如上图虚线框内 Proof Generator 模块将负责给 prover（PoW 矿机） 发布证明任务并接受任务结果：ZKP 证明，然后将 ZKP 证明保存到 DB 数据库中。Proof Manager 负责管理完成是 ZKP 证明，将要上链的 ZKP 证明封装成发送任务转交给模块 Proof Sender。模块 Proof Sender 完成 ZKP 证明上链，即提交证明给部署在 Base Chain 上的 zkevm contract。
下面分别介绍这三个模块：
Proof generator
Rollup Chain 将一定数量交易，打包成一个 batch，然后将若干个（依据交易的频繁性等多个因数）batch 打包成一个 sequence，然后将其提交到 Base Chain，因此我们可以说每次上链数据单位是 sequence。 每个 sequence 包括 1 个以上 batch，而 ZKP 证明是证明已提交的 sequence 的合法性，所以 batch 是证明任务最小单位。
依据 sequence 包含的 batch 不同，需要完成的证明任务也不同，具体如下：
-
batch 数目等于 1 ， 证明流程 BatchProofTask —-> FinalProofTask，需要依次完成 BatchProofTask，FinalProofTask 证明任务。
-
sequence 包含 batch 数目大于 1 ， 证明流程多个 BatchProofTask —->AggregatorproofTask —> FinalProofTask，需要依次完成多个 BatchProofTask ，AggregatorproofTask，FinalProofTask 证明任务。
为了尽可能提高证明产生的效率，也为了提高 PoW 矿工收益，我们尽可能并发生成证明。具体表现在以下两方面：
-
各个 sequence 证明生成没有上下文或者状态上依赖，可以并发进行。
-
同一个 sequence 里多个 BatchProofTask 可以并发进行。
以此更好的发挥 prover 的算力资源，从而能更高效的生成证明。
Proof manager
该模块主要负责管理 ZKP 证明，控制 ZKP 证明上链验证。主要分为三个模块
-
submitPendingProof: 该模块只在 Aggregator 每次启动时执行一次，目的是将上一次 Aggregator 服务停止前未完成的 ZKP 证明提交完成。这里是针对 proofHash 提交了且其他矿工提交了 proof 的情况。关于 proofHash， proof 的介绍参考 Proof Sender。
-
tryFetchProofToSend: 在协程执行，将最新生成的 ZKP 证明且该证明对应的 sequence 未被验证加入到 Proof Sender 的缓存中等待上链。
-
processResend: 在协程执行，目的让超过时间窗口没验证成功的 sequence 重新提交上链。
Proof sender
Opside 提出了一个 ZKP 两步提交算法，来实现了 prover 的去中心化。这种算法既能够防止 ZKP 抢跑攻击，又可以让更多的矿工获得奖励，从而鼓励更多的矿工在线，并提供稳定、持续的 ZKP 算力。
-
第 1 步：对于某个 sequence 生产 PoW 证明记为 proof，首先计算 Hash(proof / address), 记为 proofHash，并向合约提交，若该 sequence 之前没有提交过 proofHash，则开启 proofHash 的提交时间窗口 T 1 ， 在之后 T 1 个区块内矿工都有资格提交该 sequence，且 T 1 区块后才能提交 proof。
-
第 2 步：提交 proof， T 1 后区块后，开启 proof 提交，且限定在 T 2 个区块内提交。如果 T 2 区块后，所有矿工提交 proof 都没验证通过，则之前所有提交过 proofHash 的矿工都被被惩罚。如果在 T 1 时间窗口能成功提交了 proofHash，但是在 T 2 时间窗口内未能成功提交 proof，且 T 2 窗口内其他矿工成功提交了 proof，则仍然可以继续提交该 proof。除了以上场景外，重新走两步提交流程。
如下图，Proof Sender 基于三个线程安全且优先级排序缓存来实现两步提交，这三个缓存基于 sequence 的起始高度进行排序，保证每次从这个三个缓存获取元素对应的 sequence 高度都是最低的，同时这三个缓存中元素是去重的。对应 sequence 的高度越低越需要优先处理。
-
finalProofMsgCahce: 存放的是 Proof Manager 发送来 finalProof 消息，也就是完成 ZKP 证明。
-
monitPHTxCache： 存储要监控 proofHash 交易。
-
ProofHashCache: 存储 proof 消息，用于 proof 上链。
如下图：
Proof Sender 模块启动后会启动 3 个协程，分别消费这三个缓存数据。
简单流程是：
-
协程 1 负责消费 finalProofMsgCahce 中的 finalProof 消息，计算 proofHash ，如果符合上链条件（在 T 1 条件内），则将 proofHash 上链，同时将 proofHash 交易放入到 monitPHTxCache 中。
-
协程 2 消费 monitPHTxCache 的 proofHash 交易消息，如果在 T 2 时间窗口内，满足 proof 上链条件，这构造 proof 消息，存放到 ProofHashCache。
-
协程 3 消费 proof 消息，proof 上链。
相对旧模块，结构更加清晰，节省资源开销。
三、总结
与 Version 1.0 对比
-
V2.0 拆分了原有服务为三个子模块，三个模块分别负责证明产生，证明管理，证明上链，结构更加清晰，三个模块耦合性低，鲁棒性强。
-
证明产生模块 Proof Generator 相对旧版添加了 startBatch 参数方便新加入矿工能更快跟上挖矿进度。
-
证明管理模块 Proof Manager 相对旧版更好改进：对于矿工重启服务或者其他原因导致 proof 未提交或者提交失败会第一时间重发 proof，保证矿工利益；同时重发机制不仅针对 proof 提交失败情况，也针对所有 proof 提交失败或者未提交，重启时间窗口，保证 Rollup Chain 安全性。
-
证明发送模块 Proof Sender 基于三个线程安全优先级缓存来实现交易两步式提交，相对之前版本减少全局锁使用，保证了低高度的 proof 能第一时间提交，保证了矿工的利益。同时，整个服务流程更清晰，减少了线程数量，减少了程序执行中资源的消耗。
压测结果：
- Version 2.0 使用 10 台 64 核机器，完成 batch 证明 566 个，耗时 7 小时 38 分 40 秒，平均 48.62 秒完成一个证明。在多矿工场景下，相较于V1.0 ，V2.0 的 zk proof 生成效率整体提高了 50%
总之，Opside ZK-PoW V2.0 优化了多矿工参与 ZKP 计算的流程，提升了硬件利用率，提高了服务可用性，对矿工更加友好。更重要的是，在多矿工的场景下，将 ZKP 的计算缩短到不到一分钟，极大地加快了 ZK-Rollup 的确认时间。