3SF 的 Native Rollup

作者 谈天说币 2025-01-30 10
okex欧易交易所封面图

okex欧易交易所

okex欧易交易所是国内最大的数字货币交易所，现在注册永久免20%手续费！

官网注册
以下是文章的中文翻译:

作者: @adust09, @banr1 来自 Titania Research, @keccak255 来自 Titania Research

1. 简介

在这个提案中,我们介绍了一种新的架构,旨在通过结合Native Rollup和3槽终结(3SF) [1],[2]来进一步改善用户体验(UX)。具体而言,我们展示了将Native Rollup的优势(即Rollup EVM执行可以直接在L1上验证)与3SF(分阶段确认区块)相结合的可能性。我们还提供了一个估计,即可以为zkEL(zk执行层)的开发人员分配多少时间来处理证明。这个估计为开发zkEL的团队提供了有用的信息。

1.1. Native Rollup

Native Rollup是一种通过利用和验证L1 EVM直接实现高安全性的机制[1]。具体来说,它利用了一个新提出的EXECUTE预编译合约,使L1验证者能够直接验证Rollup EVM交易。

这种方法的一个关键特点是,它实现了与以太坊L1完全相同的安全性和升级兼容性,而无需外部安全委员会或复杂的欺诈证明游戏。

由于不再需要严格地在链上验证zkRollup,因此具有灵活的链下验证的优势,同时可以控制gas成本。此外,还可以实现实时结算,大大简化了同步可组合性。

1.2. 3槽终结

3槽终结(3SF)是一种旨在在三个槽内确认提议者提交的区块的协议设计[2]。在之前提出的单槽终结(SSF)中,需要在一个槽内进行大约三轮投票。相比之下,3SF将这些投票轮合并为每个槽一轮[3]。这减少了每次投票所需的签名聚合和P2P网络传播。

3SF假设网络延迟保持在已知的常数Δ内,并且至少三分之二的验证者诚实行为。3SF中每个槽的过程如下:

  • 区块提议(Δ)
  • 头部投票 + FFG投票 (2Δ)
  • 冻结(2Δ)
    • 快速确认(Δ)
    • 视图合并到下一个槽(Δ)

在第1步中,提议者提出一个区块。

在第2步中,头部投票(选择链头)和Casper FFG投票(对源和目标)在同一轮中执行。采用了现有以太坊L1聚合方案。首先广播投票,然后聚合器收集并再次广播,总耗时2Δ。

在第3步中,根据第1步和第2步的结果,如果提议的区块获得超过三分之二的头部投票,则实现快速确认,该区块被视为几乎不可逆。此外,当获得快速确认的区块在下一个槽的开始时被所有验证者共享为链头时,视图将合并。

之后,在第2槽中证明了第1槽提出的区块,在第3槽中最终确认。换句话说,3SF将第1槽的最终确认过程延续到第2槽和第3槽。因此,实际最终确认一个区块最多需要三个槽(最多15Δ)。因此,与在单个槽内(最多6Δ)完成最终确认的SSF相比,3SF需要更长的时间来实现最终确认。

2. 3SF的Native Rollup

2.1. 现有以太坊的Native Rollup

Native Rollup中的zk证明器预计需要比提议者或证明者更长的处理时间。如果我们希望在一个槽内完成证明,我们很可能需要等待ZKP和密码学技术的进一步发展。因此,已经在EIP-7862 [4]中提出了存储前一个区块的stateRoot而不是当前区块的方法。这允许提议者延迟EVM执行。Native Rollup建立在这种方法之上。

下图说明了将Native Rollup应用于现有以太坊时的槽转换。

这里,每个角色名称后的数字表示分配给该槽。例如,attesters2是分配给槽2的证明者。同时,阴影区域表示相应槽中执行以下任务。

  • 绿色阴影: 在EL执行中的提议者
  • 红色阴影: 在提议者的zkEL中生成证明
  • 黄色阴影: 在EL、zkEL执行和验证证明中的证明者

提议者已经空闲4到12秒,但EIP-7862使提议者在EL中可以延迟执行。这在图中用绿色表示。

在Native Rollup中,提议者必须在本地运行不仅EL和CL,还有zkEL。由于EIP-7862,证明生成也可以推迟。提议者在zkEL上的角色是为L2状态转换生成证明,如红色所示。与EL不同,这可以推迟到下一个槽的提议者步骤之前。

请注意,attesters2验证的stateRoot来自槽1。由于EIP-7862,会出现这种偏移,但它提供了延迟执行的好处。每个stateRoot都有L1和L2版本。L1端通过实际执行计算来确认正确性,而L2端通过验证零知识证明来确认正确性。

2.2. 3SF的Native Rollup

将3SF适应于此架构将产生以下结果。

为了方便起见,attesters1和attesters2分开显示,但具体规格尚未确定,因此它们可能是同一个实体。

而现有以太坊的槽处理包括提议、投票和聚合,3SF增加了一个冻结步骤。这是所有验证者的共同处理,提供快速确认和视图合并。

如前所述,以下情况适用:

  • 绿色阴影: 在提议者的EL中执行
  • 红色阴影: 在提议者的zkEL中生成证明
  • 黄色阴影: 在证明者的EL和zkEL中验证执行和证明

即使在3SF下,情况与现有以太坊的Native Rollup大致相同。通过分别延迟提议者和证明者的执行和验证,执行时间有一些灵活性,这与3SF步骤并不冲突。我们相信Native Rollup也可以应用于3SF。

在zkEL中,证明生成任务在EL请求证明生成时开始。在下一个槽的投票和聚合阶段之前,有一些余地。换句话说,如果证明可以在Δ + 2Δ + 2Δ + Δ = 6Δ内完成,就可以实现这种方案。证明者需要证明进行验证,所以只要在他们的验证阶段之前生成,就会及时到位。

然而,考虑到当前zkVM的性能,在zkEL中生成证明需要几分钟到几十分钟,这是不现实的。依赖高性能服务器可能是唯一的选择来适应6Δ。如果依赖高性能服务器,专门的参与方可能会变得集中。

3. 讨论和改进

可以进行以下讨论和改进。

3.1 zkEL证明市场

解决zkEL中证明生成计算成本的一个潜在解决方案是将其委托给外部市场。如果建立了这样的市场,即使是单独质押者也可以通过外包来轻松生成证明。这在某种程度上类似于MEV-Boost。但是,会出现以下担忧:

  • 集中化风险
    • 冗余和抗审查能力降低
    • zkVM证明方法的多样性丧失
  • 激励设计失衡

3.2 对3SF的进一步研究

3SF仍然面临着安全性和可用性之间的权衡;从安全性角度来看,当减少最终确认时间(如3SF所做的那样)时,支持大量验证者的额外研究可能会很有益。

  • 是否存在更有效的方式来聚合和传播消息?目前聚合方案中存在哪些瓶颈?
  • 在讨论减少消息数量(如Orbit SSF[5])时,安全性是否真的足够?
  • 我们如何设置发行奖励,以及分配给验证者的数量?
  • 我们是否可以估算Δ的长度,并为证明器提供更具体的规范?
  • 这个提议的方向是否有用?

4. 总结

该提议提出了一种创新的架构,将Native Rollup与3SF相结合,通过利用两个系统的安全性和效率来提升用户体验。通过在L1上直接验证rollup EVM交易并分三个阶段完成区块确认,这种综合方法提供了实时结算和灵活的链下验证,同时保持了高安全标准。此外,该提议还解决了zkEL证明生成时间的挑战,并提出了潜在的解决方案,如zkEL证明市场。总的来说,这种集成旨在优化基于以太坊的应用程序的可扩展性和安全性。

5. 参考文献

The End

文章声明：以上内容(如有图片或视频亦包括在内)除非注明，否则均为谈天说币原创文章，转载或复制请以超链接形式并注明出处。

上一篇 下一篇

相关阅读