作者:手机用户2502861125 | 来源:互联网 | 2023-08-19 12:40
如何提高 ZK Proof 的生成速度将是决定 ZK Rollup 未来发展的重大问题。
撰文:SA (Sybil Attack)
1. ZK Rollup 中的两大核心角色
主流的 ZK Rollup 如 StarkWare 等,其架构包含两大角色:
- Sequencer(执行交易)
- Prover(生成 ZK 证明)
Sequencer(排序器)负责执行 Layer2 网络内的交易,将这些交易事件排序,打包成交易批次(Batch)。我们可以将 Batch 理解为压缩版的 Layer2 区块数据。
Sequencer 会定期将生成的 Batch 发布出去,Prover(证明者)会自动读取 Batch,为其生成一个 ZK Proof,交由 Layer1 上的指定智能合约进行验证。
2. 在现在的 ZK Rollup 方案中,Sequencer 与 Prover 的工作速度相差甚远。在目前的家用电脑上,每秒可执行约 4000 笔交易,但为每笔交易生成 Proof 却需要约 1.5 秒~2.5 秒,相当于每秒仅能为 0.6 笔交易生成 Proof。这样算来,Sequencer 和 Prover 的工作效率相差至少 5000 倍,两者之间始终存在延迟。
如果无法解决 ZK Proof 生成时间过长的问题,就会对 Layer2 的可用性产生负面影响。最直接的影响就是跨链转账。
通常情况下,用户在 Layer2 发起一笔向 Layer1 的转账,会先被 Sequencer 节点处理,随后包含跨链转账的 Tx Batch 会发布到 Layer1 上。
但此时,这个 Batch 尚未生成对应的 Proof,无法通过验证。
在这种情况下,跨链桥不会为这笔跨链转账放行。只有对应的 ZK Proof 提交到了 Layer1 的指定合约,并经过验证,跨链转账才会得到跨链桥的确认并通过。
此外,ZK Proof 生成过程太慢,也不利于实现 Sequencer 的去中心化。
3. 所以,如何提高 ZK Proof 的生成速度将是决定 ZK Rollup 未来发展的重大问题。目前看来,定制高性能的 ZK 加速芯片、推出激励机制促使 Prover 节点间展开竞争,将是缩短 ZK Proof 生成时间的最有效方式。
我初步阅读了 Scroll、Hermez、Taiko 等 ZK Rollup 的文档,了解到 POE(Proof Of Efficiency)机制。
我认为 Scroll 和 Hermez 可能是最值得关注的 ZK Rollup。如果项目方能够将其设想充分实现,那么这两者将是最适合 ZK 挖矿的理想乡。在下面的陈述中,我将针对我的论点展开一些论述。
4. ZK 加速方案的必要性:由于 ZK Rollup 需要先将传统编程语言转换为对 ZK 证明友好的形式。同时,常用的 SHA256 或 Keccak 函数对 ZK 也很不友好,要生成对应的 ZK Proof 会产生很长的耗时。这些复杂操作会大幅延长证明生成时间。
Scroll 的联创 Zhang Ye 的一篇论文曾提及,目前的 ZK-SNARK 证明虽然验证速度快,但其生成过程仍然十分困难。通常情况下,为一段程序生成对应的 ZK Proof,首先要将程序转化为一个约束系统,其尺寸大小通常可以达到原始程序的几倍,最高可达几百万倍。随后,证明程序要在一个大的有限域上执行一系列数学运算
其中产生的操作量与对应的程序相关,但与约束系统中的约束数量相比,其操作量总是超线性的。大多数情况下,生成 zk-SNARK 的时间要比验证它的时间长得多,有时两者的差距可达到几百倍,比如仅仅是为一次支付事务生成 Proof 就可能长达几分钟,其执行过程却仅需要几十毫秒而已。
5. 对此,Scroll 提出了名为 PipeZK 的 ZK 加速解决方案,该方案可以在普通消费级硬件上将 ZK Proof 的生成过程提高至少 10 倍以上。如果未来再结合 FPGA 和 ASIC 等专用硬件,加速效果或将进一步提升。
同时,Scroll 表示将于未来实现 Layer2 节点的去中心化,允许用户运行 Prover 节点参与到 ZK Rollup 网络运行。按照其愿景,如果普通用户可以自由的运行 Prover 节点,通过生成和提交 Proof 来获得奖励,其实质就构成了「挖矿」行为;
此外,可以让多个 Prover 节点同时参与 Proof 生成。由于 Sequencer 可以在短时间内执行大量交易,将其打包为多个 Batch,这 N 个 Batch 就可以交给至少 N 个 Prover 节点来生成 Proof。
同时,N 个 Proof 还可以被聚合到一起,这样就可以让聚合版 Proof 覆盖的交易数量更多,进而节约在 Layer1 上发布 Proof 产生的 Gas 成本。
6. 这相当于采用并行计算的方式完成 Proof 生成。由于多个 Proof 可以被聚合为单个 Proof,最后的聚合版 Proof 可以一次性覆盖 N 个交易 Batch,如果将每个交易批次包含的交易数量适当缩减,调动更多 Prover 参与到并行生成 Proof 的工作中,相当于在同一时刻运行更多的 Prover 线程,理论上可以进一步缩短 Proof 生成时间。
这将有助于提高 ZK Rollup 的可用性,也可以扩大 Prover 节点的规模,进而为 ZK 加速芯片打开市场需求空间。
7. 同为 ZK EVM 解决方案的 Taiko 则在并行化的基础上提出了窗口期的设定。对此,Taiko 在其文档中有明确的解释:当一个待证明的 Layer2 区块被生成时,会发布到 Layer1 上,等待 Prover 节点为其生成对应的 Proof 证明。但 Taiko 设置了窗口期,如果一个待证明的交易批次在规定时间内没有被证明,就可以被抛弃或被替换。
这就会敦促 Layer2 区块生产者 Sequencer 自行寻找具有更高性能的 Prover 节点,与其合作在更短的时间内生成 Proof。这种方法可以在一定程度上排除掉「不作为」的 Prover 节点运行者,但如果窗口期设置的过长,仍然无法高效刺激 Prover 节点提高其效率。
8. 为此,Polygon 的 Hermez 项目组提出了一个很有意思的构想,名为 Proof Of Efficiency(POE),它允许多个 Prover 无需许可的参与到 ZK Proof 生成过程,并让这些 Prover 节点展开竞争,最终的 Proof 奖励只会分配给第一个成功的节点。
在 POE 机制下,Prover(Aggregator)以无许可的方式参与到 Proof 的生成过程中,虽然 Hermez 并未对此处的「无许可」做出明确解释,但我个人分析认为,「无许可」可能意味着 Prover 节点无需质押代币也无需事先注册,可以直接读取 Sequencer 发布到 Layer1 上的交易批次(Layer2 区块),并为其生成对应的 Proof。
Hermez 在其 POE 方案中称,允许多个 Prover 节点以竞赛的方式提交 Proof 并获得奖励,如果某个 Prover 是第一个生成正确 Proof 的节点,它将获得全部的 Proof 生成奖励,该笔奖励由 Sequencer 以悬赏的形式进行支付。
结合上文中提到,Taiko 曾提出「窗口期」概念,如果 Sequencer 提交到 Layer1 的交易批次长时间未生成对应的 Proof,就会被废弃,Sequencer 一般会有很强的动力去提高 Proof 悬赏金额,刺激 Prover 群体高效工作。
这样一来,Sequencer 或 ZK rollup 项目方相当于把 ZK Proof 加速策略委托给 Prover 节点运行者去研发,通过悬赏市的竞赛机制,可以很大程度上调动广大矿工的积极性,不失为一种共赢策略。
9. 对于 POE 方案存在的问题,提出者本人也曾指出,仅将全部的 Proof 生成奖励分配给一个 Prover 可能不太公平,因为网络延迟或者交易审查会影响 Proof 的提交时间,所以更好的优化方法是将奖励分配给 Proof 提交时间相近的几个 Prover 节点,这样可以更好的激励 Prover 群体,也能保留住更大规模的 Prover 节点群。
10. 如果 Prover 节点顺利去中心化,并且全部的 Proof 奖励分配给性能最优越的几个 Prover 运营方,类似比特币矿池的组织形式极有可能出现,这些 Prover 矿池由许多散户矿工贡献的设备连接而成,按照每个人贡献的算力分配奖励。
同时,由于 ZK Proof 生成任务可以并行化,可切分,拥有的加速芯片越多、使用的生成策略越优秀,获得的奖励就会越多。照此看来,ZK 挖矿很有可能复制比特币挖矿的老路,挖矿设备会不断的更新迭代,组织形式将以矿池为主,而 ZK Rollup 本身也将大幅受益于这种变迁。
但需要明确的是,以上讨论仅在 ZK Rollup 得到大规模采用后才有落地的可能,而现在的讨论仍然是超早期话题。 这是因为,ZK Prover 矿工的激励来自于 Layer2 的用户手续费,不同于以太坊会不断增发代币激励矿工,如果单纯靠手续费激励矿工群体,可能无法维持庞大的 prover 群体。
所以单个 ZK rollup 的 Prover 群体注定不会特别大,但 danksharding 后会搭载多个 zk rollup,如果把他们当做一个整体来看的话,zk miner 的空间还是不小,虽然比不上比特币和以太坊挖矿,但与莱特币或 ETC 或许还是可以相提并论的。
毕竟在这个「币圈一天,人间一年」的领域里,一切皆有可能。