反对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的整体架构由几个关键组件组成：   这是Opside为ZKP计算提供的云基础设施。它部署在多个链上，包括以太坊、BNB Chain、Polygon PoS 和 Opside Chain。 ZK-PoW Cloud 负责协调和管理 ZKP 计算任务。 ZK-PoW Cloud： 这些是由矿工运营的节点，他们贡献自己的计算能力来执行 ZKP 计算。矿工可以通过在其挖矿硬件上运行专门的软件来参与 ZK-PoW 网络。 矿工节点：    ZK-PoW云将ZKP计算任务分配给矿工节点。分配以去中心化的方式进行，保证公平和效率。 ZKP 任务包括生成和验证各种 ZK-Rollups 的零知识证明。 ZKP任务分配：   矿工节点接收ZKP计算任务并执行必要的计算以生成所需的证明。这涉及执行加密算法和执行复杂的计算。 ZKP计算：  ZKP 计算完成后，矿工节点将生成的证明提交给 ZK-PoW 云进行验证。云基础设施验证证明的正确性，以确保其有效性和完整性。 证明提交和验证： 矿工通过计算贡献获得奖励来激励他们参与 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 证明并控制其链上验证。它由三个主要模块组成：    ：该模块仅在聚合器启动时执行一次。其目的是完成之前聚合器服务未完成的 ZKP 证明的提交。这处理了 ProofHash 已提交但其他矿工已经提交了证明的情况。有关proofHash的更多信息，请参阅Proof Sender模块。 commitPendingProof    ：该模块作为协程运行，并将最新生成的 ZKP 证明及其相应的未验证序列添加到 Proof Sender 的缓存中，等待链上提交。 tryFetchProofToSend    ：该模块作为协程运行，旨在重新提交在给定时间窗口内尚未成功验证的序列。其目的是确保超过验证时间的序列重新提交进行链上处理。 processResend 证明发送者 提出了两步ZKP提交算法来实现证明者的去中心化。该算法可以防止ZKP抢先交易攻击，让更多的矿工获得奖励，从而鼓励更多的矿工参与并提供稳定、持续的ZKP算力。 Opside  ：在为特定序列生成PoW证明（简称证明）时，证明者首先计算“证明/地址”的哈希值并将其提交给合约。如果之前没有为该序列提交 ProofHash，则打开 ProofHash 提交时间窗口 T1。矿工有资格在T1区块内提交序列，并且只能在T1区块之后提交证明。 步骤1  ：T1区块后，T2区块的证明提交窗口打开。如果T2区块内提交的证明均未通过验证，则所有先前提交proofHash的矿工都将受到惩罚。如果proofHash在T1时间窗口内成功提交，但在T2时间窗口内无法成功提交证明，并且其他矿工在T2时间窗口内成功提交证明，证明者仍然可以继续提交该证明。其他场景则重新开始两步提交流程。 步骤2 下图说明了 Proof Sender 如何使用三个线程安全且按优先级排序的缓存来实现两步提交。这些缓存根据序列的起始高度进行排序，确保每次从这些缓存中检索元素时，它都对应于最低的序列高度。此外，这些缓存中的元素都经过重复数据删除。对应序列的高度越低，处理的优先级越高。  FinalProofMsgCache：存储Proof Manager发送的finalProof消息，表示ZKP证明完成。  monitPHTxCache：存储要监控的proofHash交易。  ProofHashCache：存储链上提交的证明消息。   Proof Sender模块启动后，会启动三个协程来消费三个缓存中的数据。简化流程如下： 协程1从finalProofMsgCache中消费finalProof消息，计算proofHash，如果满足链上提交条件（T1窗口内），则将proofHash提交到链上，并将proofHash交易添加到monitPHTxCache中。 协程 2 使用来自 monitPHTxCache 的proofHash 交易消息。如果proofHash满足T2窗口内链上提交的条件，则构造证明消息并将其存储在ProofHashCache中。 协程 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 交易的确认时间。

This writer has a vested interest be it monetary, business, or otherwise, with 1 or more of the products or companies mentioned within.

該音頻是用故事的原始語言製作的！

太長; 讀書

Get Free Unlimited IP Geo Data With IPinfo Lite

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

About Author

註釋

標籤

这篇文章刊登在

Related Stories

点击赚钱：Telegram 可能会在 Solana 之前吸引下一个 100 亿加密用户

架构师指南：构建 AI/ML 数据湖参考架构

扬帆起航：利用数据湖开发生产级 RAG 应用程序

点击赚钱：Telegram 可能会在 Solana 之前吸引下一个 100 亿加密用户

架构师指南：构建 AI/ML 数据湖参考架构

扬帆起航：利用数据湖开发生产级 RAG 应用程序

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps