1.Opside ZK-PoW简介Opside是一个分散的ZK-RaaS(ZK-汇总即服务)平台，也是业内领先的ZKP(零知识证明)采矿网络。ZK-RaaS (ZK汇总即服务)可以为任何人提供一键生成ZK汇总的服务。Opside提供了一个通用的ZK-Rollup launchbase，开发人员可以通过它轻松地将不同类型的ZK-Rollup部署到不同的basechains。
基链，包括以太坊/opside chain/bnb chain/polygon pos等公链。
ZK卷的类型包括zkSync、Polygon zkEVM、Scroll、StarkNet和其他ZK卷。
Opside ZK-PoW云将部署在多个链上，包括但不限于以太坊、BNB链、多边形PoS和Opside链本身。在Opside的设计中，开发者可以在上述不同的基链上部署ZK卷。随着ZK卷技术的逐渐成熟，未来可能会诞生数百个ZK卷，这将为ZKP计算能力带来巨大需求。Opside使用ZK-PoW机制来鼓励Miner提供ZKP计算能力，从而为ZK-Rollup提供完整的硬件设施。
二、ZK-PoW V2.0的整体架构ZK-PoW V2.0的整体架构包括几个关键部分:
ZK-战俘云:这是Opside为ZKP计算提供的云基础设施。它部署在多个链上，包括以太坊、BNB链、多边形PoS和Opside链。ZK战俘云负责协调和管理ZKP计算任务。
矿工节点:这些是由矿工操作的节点，他们贡献自己的计算能力来执行ZKP计算。矿工可以通过在他们的采矿硬件上运行特殊的软件来加入ZK电力网。
ZKP任务分配:ZK战俘云将ZKP计算任务分配给矿工的节点。分配是分散的，以确保公平和效率。ZKP的任务包括生成和验证各种ZK汇总的零知识证明。
ZKP计算:矿工节点接收ZKP计算任务，并进行必要的计算，以生成所需的证明。这包括执行加密算法和执行复杂的计算。
证据提交和验证:一旦ZKP计算完成，miner节点将生成的证据提交给ZK-战俘云进行验证。云基础设施验证证书的正确性，以确保其有效性和完整性。
激励机制:矿工们被鼓励加入ZK战俘网络，因为他们对计算的贡献得到奖励。奖励制度旨在激励矿工，维护网络的安全和稳定。
总的来说，ZK-PoW V2.0将矿工的计算资源与云基础设施相结合，为各种ZK卷提供高效、可扩展的ZKP计算能力。
聚合器是证明者的重要模块，负责分发ZKP认证任务和接收任务结果，管理ZKP认证，向基链提交ZKP认证进行奖励。因此，基于功能，新的聚合器分为三个子模块，即证明生成器、证明管理器和证明发送器。
如上图，虚线框中的证明生成器模块将负责向证明者(PoW矿机)发出证明任务并接受任务结果:ZKP证明，然后将ZKP证明保存在DB数据库中。证明管理器负责管理ZKP证明的完成，把要缠绕的ZKP证明封装成发送任务，传递给模块证明发送器。模块证明发送者完成ZKP证明卷绕，即将证明提交给部署在基链上的zkevm契约。
下面分别介绍三个模块:
Proof generatorRollup链将一定数量的事务打包成一批，再将几批(根据事务发生的频率等因素)打包成一个序列，然后提交给基链，所以我们可以说每个上行的数据单元就是一个序列。每个序列包含多个批次，ZKP证明是为了证明提交序列的合法性，因此批次是证明任务的最小单位。
根据序列中包含的批次，要完成的认证任务有所不同，如下所示:
批次号等于1，证明流程BatchProofTask & # 8212-& gt；FinalProofTask，需要依次完成BatchProofTask和FinalProofTask证明任务。
序列包含大于1的批号，证明有多个BatchProofTask & # 8212-& gt；AggregatorproofTask & # 8212& gtFinalProofTask，需要依次完成多个BatchProofTask、AggregatorproofTask和FinalProofTask认证任务。
为了尽可能的提高证书生成的效率，也为了提高战俘矿工的收入，我们尽可能的并发生成证书。具体表现在以下两个方面:
每个序列证明生成没有上下文或状态依赖性，并且可以并发执行。
同一序列中的多个BatchProofTask可以同时执行。
这样可以更好地利用证明者的计算能力资源，从而更高效地生成证明。
校样管理器该模块主要负责管理ZKP校样和控制ZKP校样的上行验证。主要分为三个模块。
SubmitPendingProof:该模块仅在聚合器每次启动时执行一次，以便提交在聚合器服务最后一次停止之前未完成的ZKP证书。这里是proofHash提交，其他矿工提交证明的情况。关于凭证散列和凭证的介绍，请参考凭证发送者。
TryFetchProofToSend:流程执行时，新生成的ZKP证明和相应的证明序列不进行验证，并添加到证明发送方的缓存中进行卷绕。
ProcessResend:在流程中执行，目的是重新提交时间窗口内没有验证成功的序列。
证明者提出了一种ZKP两步提交算法来实现证明者的去中心化。该算法不仅可以防止ZKP抢先攻击，还可以奖励更多的矿工，从而鼓励更多的矿工上线，提供稳定持续的ZKP计算能力。
步骤1:某一序列的功率产生的证据被记录为证据。首先计算Hash(proof/address)，记录为proofHash，提交给契约。如果之前没有提交过proofHash，则打开proofHash提交时间窗口T1，下一个T1区块的所有矿工都有资格提交序列，并且只能在T1区块之后提交证明。
第二步:提交证明。在T1块之后，打开证明提交并将其限制在T2块。如果所有矿工提交的证明在T2封锁后都没有通过验证，所有之前提交证明的矿工都将受到处罚。如果在T1时间窗口中可以成功提交证明，但是在T2时间窗口中不能成功提交证明，并且在T2窗口中的其他矿工已经成功提交证明，则仍然可以提交证明。除了上面的场景，再次经历两步提交过程。
如下图所示，Proof Sender基于三个线程安全的优先级缓存实现两步提交，按照序列的起始高度排序，保证每次从这三个缓存中获取的元素对应的序列高度最低，并对这三个缓存中的元素进行去重。相应序列的高度越低，需要的优先级越高。
FinalProofMsgCahce:存储证明管理器发送的finalProof消息，即ZKP证明完成。
MonitPHTxCache:要监视的Store proofHash事务。
ProofHashCache:存储证明上行的证明消息。
如下图所示:
证明发送方模块启动后，将启动三个会话，分别消费三个缓存的数据。
简单的过程是:
协诚1负责消费finalProofMsgCahce中的finalProof消息，计算proofHash，如果满足winding条件(T1条件内)，则将proofHash进行winding，并将proofHash事务放入monitPHTxCache。
协成2消费monitPHTxCache的proofHash交易报文。如果在T2时间窗口内满足证明上行链路条件，这将构造一个证明消息并将其存储在ProofHashCache中。
谢城3消耗证明消息，证明是伤口。
与旧模块相比，结构更清晰，节省资源成本。
第三，总结与1.0版本的对比
V2.0将原有服务拆分为三个子模块，分别负责凭证生成、凭证管理和凭证卷绕，结构更加清晰，耦合度低，健壮性强。
证明与旧版本相比，证明生成器增加了startBatch参数，方便新矿工更快跟上挖掘进度。
证明证明管理器管理模块优于旧版:矿工重启服务或因其他原因无法提交证明，将尽快补办证明，确保矿工利益；同时，重传机制不仅针对提交证明失败，还对所有失败或未提交的证明重新启动时间窗口，以保证Rollup Chain的安全性。
证明发送方模块实现了基于三线程安全优先级缓存的两步事务提交，相比上一版本减少了全局锁的使用，保证了低级证明可以第一时间提交，保证了矿工的利益。同时，整个服务流程更加清晰，线程数量减少，程序执行的资源消耗减少。
压力测试结果:
2.0版本使用10台64核机器完成566个批量证明，耗时7小时38分40秒，平均完成一个证明需要48.62秒。在多矿工场景下，与V1.0相比，V2.0的zk证明生成效率整体提升50%。
总之，Opside ZK-PoW V2.0优化了多矿工参与ZKP计算的流程，提高了硬件利用率，提高了服务可用性，对矿工更友好。更重要的是，在多名矿工的场景下，ZKP的计算缩短到不到一分钟，大大加快了ZK-罗博的确认时间。
温馨提示：注：内容来源均采集于互联网，不要轻信任何，后果自负，本站不承担任何责任。若本站收录的信息无意侵犯了贵司版权，请给我们来信，我们会及时处理和回复。
原文地址"Opside ZK-PoW V2 版本：多矿工场景下 ZKP计算可缩短至不到一分钟"：http://www.ljycsb.cn/qukuailian/210283.html。
微信扫描二维码投放广告
▲长按图片识别二维码
