用于3SF的Native Rollup

该方案提出了一种新的架构,结合了Native Rollup和3SF,旨在提升用户体验。通过在L1上直接验证rollup EVM交易,并分三个阶段完成区块的最终确认,该方案提供了实时结算和灵活的链下验证,同时保持高安全标准。集成的目标是为基于以太坊的应用程序优化可扩展性和安全性。

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

特别感谢:@grandchildrice

1. 介绍

在本提案中,我们介绍了一种新的架构,旨在通过结合 原生 Rollup3-Slot 最终性 (3SF) 来进一步改善用户体验(UX)。具体来说,我们展示了合并原生 Rollup 优势的可能性,即 Rollup EVM 执行可以直接在 L1 上验证,并结合 3SF,后者分阶段完成区块的最终确定。我们还提供了对 zkEL(zk 执行层)开发人员可以分配多少时间用于证明处理的估计。此估计可以为开发 zkEL 的团队提供有用的信息。

1.1. 原生 Rollup

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

スクリーンショット 2025-01-29 18.38.43\ スクリーンショット 2025-01-29 18.38.432160×1350 159 KB

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

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

1.2. 3-Slot 最终性

3-Slot 最终性 (3SF) 是一种协议设计,旨在在三个Slot内完成提议者提交的区块的最终确定。在之前提出的 单Slot最终性 (SSF) 中,有必要在一个Slot内进行大约三轮投票。相比之下,3SF 将这些投票轮次统一为每个Slot一轮。这减少了每次投票所需的签名聚合和 P2P 网络传播的数量。

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

  • 区块提议 (Δ)
  • head-vote + FFG-vote (2Δ)
  • 冻结 (2Δ)

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

在步骤 2 中,head-vote(选择链头)和 FFG-vote(用于源和目标)都在同一轮中执行。当前以太坊 L1 聚合方案被作为基础。首先,广播投票,然后聚合器收集它们并再次广播,使总时间为 2Δ。

在步骤 3 中,基于步骤 1 和步骤 2 的结果,如果提议的区块收到超过三分之二的 head-vote,则实现快速确认,并且该区块被认为是几乎不可逆转的。此外,当实现快速确认的区块在下一个Slot开始时作为链头在所有验证者之间共享时,视图将被合并。

之后,在Slot 1 中提出的区块在Slot 2 中被证明,并在Slot 3 中被最终确定。换句话说,3SF 是一种延长最终性时间,同时缩短确认时间的方法。同时,通过结合 head vote 和 FFG vote,与 SSF 相比,Slot持续时间变得更短。因此,这种平衡被认为对大多数用户来说是足够的。3SF 的Slot结构与当前以太坊 L1 的Slot结构非常相似。

2. 3SF 的原生 Rollup

2.1. 现有以太坊的原生 Rollup

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

以下是将原生 Rollup 应用于现有以太坊时的Slot转换图示。

スクリーンショット 2025-01-29 22.59.59\ スクリーンショット 2025-01-29 22.59.592160×1350 241 KB

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

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

提议者已经空闲了 4 到 12 秒,但 EIP-7862 允许 EL 中的提议者延迟执行。这在图中以绿色显示。

在原生 Rollup 中,提议者不仅必须运行 EL 和 CL,还必须在本地运行 zkEL。 感谢 EIP-7862,证明生成也可以延迟。zkEL 在提议者上的作用是生成 L2 状态转换的证明,以红色显示。与 EL 不同,这可以推迟到下一个Slot中的提议者步骤之前。

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

2.2. 3SF 的原生 Rollup

将 3SF 适配到此架构将导致以下结果。

スクリーンショット 2025-01-29 22.57.28\ スクリーンショット 2025-01-29 22.57.282160×1350 238 KB

为方便起见,attesters1 和 attesters2 分开显示,但规范尚未最终确定,因此它们可能是相同的实体。

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

与之前一样,以下适用:

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

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

在 zkEL 中,当 EL 在Slot开始时请求生成证明时,证明生成任务开始。 然后,直到下一个Slot的投票和聚合阶段之前都有回旋余地。 换句话说,如果可以在 Δ + 2Δ + 2Δ + Δ = 6Δ 内完成证明,则可以实现此方案。 证明者需要证明进行验证,因此只要在验证阶段生成,就来得及。

但是,鉴于 zkVM 目前的性能,zkEL 中的证明生成可能需要几分钟到几十分钟,这不切实际。 依靠高端服务器可能是将其放入 6Δ 内的唯一选择。 如果我们依赖高端服务器,则专业方有可能变得中心化。

3. 讨论与改进

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

3.1 zkEL 证明市场

解决 zkEL 中证明生成计算成本的一种潜在解决方案是将其委托给外部市场。 如果可以建立这样的市场,即使是 solo-staker 也可以通过外包轻松生成证明。 这有点类似于 MEV-Boost。 但是,会出现以下问题:

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

3.2 关于 3SF 的更多研究

3SF 仍然面临安全性和可用性之间的权衡; 从安全角度来看,当像 3SF 那样减少最终性时间时,关于如何支持大量验证者的额外研究可能会有所帮助。

  • 是否有更有效的方法来聚合和传播消息? 首先,当前聚合方案中存在哪些瓶颈?
  • 当讨论减少消息数量(例如 Orbit SSF)时,安全性真的足够吗?
  • 我们如何设置发行奖励以及我们分配给验证者的金额是多少?
  • 我们可以估计 Δ 的长度并提供证明者应满足的更具体的规范吗?
  • 这个提案的方向首先有用吗?

4. 总结

本提案提出了一种新的架构,该架构将 Native Rollup 与 3SF 相集成,以利用两个系统的安全性和效率来增强用户体验。 通过支持在 L1 上直接验证 rollup EVM 交易并在三个阶段中完成区块的最终确定,这种组合方法可在保持高安全标准的同时提供实时结算和灵活的链下验证。 总体而言,此集成旨在优化基于以太坊的应用程序的可扩展性和安全性。

  • 原文链接: ethresear.ch/t/native-ro...
  • 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
以太坊中文
以太坊中文
以太坊中文, 用中文传播以太坊的最新进展