探索以太坊原生Rollup - L1与L2的融合

WIP - 进行中的工作

引言：L1 和 L2 的融合

在过去的几年里，以太坊社区接受了 Rollups——将交易捆绑并将数据发布到以太坊的第二层解决方案——将以太坊从单一的“全球计算机”转变为一个专业化执行环境的网络。然而，每个主要的 Rollup 都在重新实现 EVM、桥接逻辑以及与 L1 升级保持同步方面面临困难。

如果我们能够如此彻底地统一 L1 和 L2，使 Rollup 的 EVM 实际上与以太坊的相同，从而消除单独验证的复杂性，那会怎么样呢？原生 Rollups 应运而生——一个新兴的提案，让 L1 “原生” 验证 L2 状态转换，可能提供无信任和无缝升级，而无须每个 Rollup 实现自己的链上验证逻辑。

原生 Rollups 旨在将 Rollup 执行重塑为 L1 自身 EVM 逻辑的一个附加功能，通过一个提议的 EXECUTE 预编译（或操作码）调用。通过利用主网使用的完全相同的 EVM 引擎——而不是在欺诈或有效性证明合约中复制它——这些 Rollups 自动跟踪 L1 变化，消除大量治理负担，并可能实现“瞬时”或“一槽”最终确定。但是，这在实际中是如何工作的，和传统 Rollup 设计相比又如何呢？

本文深入探讨了深层技术细节：从提议的 EXECUTE 预编译到重执行与 zk 证明、桥接逻辑、开销考虑，以及为什么许多开发者认为原生 Rollups 是将 L1 安全性与 L2 可扩展性结合的下一个前沿。

背景与动机

标准 L2 生态系统面临的挑战

当前的 L2 解决方案——Arbitrum、Optimism、zkSync、StarkNet 等——在一个独立的环境中重新实现以太坊虚拟机：

• Optimistic Rollups 依赖于欺诈证明。它们需要一个健全的“二分游戏”或多步骤争议流程，在特定合约中实现 EVM。任何漏洞都可能破坏安全性。
• zk-Rollups 依赖于必须复制整个 EVM 的零知识电路。如果电路滞后于 L1 升级（例如新的操作码），L2 可能会出现问题。通常，还有一个“治理多签”来处理紧急情况。

结果：每个 Rollup 投入成千上万的工程时间重新构建 EVM 逻辑、桥接、升级流程、观察者等。它们还必须快速处理每个更改 EVM 操作码或 gas 规则的以太坊分叉。

原生 Rollup 假设

原生 Rollup 的理念是以太坊自己的 EVM 可以直接验证 L2 交易。L2 并不在合约内部实现 EVM，而是简单地调用 EXECUTE 预编译：

“给定 pre_state_root、post_state_root 和一批交易加无状态见证，运行真实的 EVM 以确认从 pre 到 post 是有效的。”

通过直接连接到 L1 的共识逻辑，原生 Rollup 不再需要重新实现 EVM，消除了整个类别的潜在漏洞。如果 L1 硬分叉添加新的操作码， Rollup 会自动识别该操作码——不需要多签切换或治理负担。

潜在收益：

• 消除单独的 EVM 重新实现——无需自定义验证器或电路以精确镜像 L1 EVM。
• 实时的相当程度——Rollup 始终与以太坊的最新分叉/操作码保持一致。
• 移除安全委员会——无需特殊的桥接逻辑升级或后备委员会。
• 同步结算的可能性——如果重执行或证明验证可以在每个槽中进行，L2 的最终确定性可以接近单槽最终确定性。

EXECUTE 预编译 / 操作码

原生 Rollups 的核心是一种名为 EXECUTE 的新 L1 “操作码” 或 “预编译”，其签名如下：

EXECUTE(
    pre_state_root,
    post_state_root,
    trace,
    gas_used
) -> returns (bool)

• trace：L2 交易的一系列及其相关的“无状态” Merkle 证明，用于每个存储读或写。
• EVM 验证将这些交易应用于 pre_state_root 是否产生 post_state_root，使用的仍然是 L1 自身的 EVM 逻辑。
• 如果正确，返回 true；否则回退或返回 false。

EXECUTE 的 Gas 计算

由于验证整个 L2 区块可能代价高昂，因此 EXECUTE 调用具有自己的 gas 限制或定价机制，可能是单独的 EIP-1559 风格的“累积 gas 目标”。它防止 L1 由于重执行大量 L2 区块而过载：

• EXECUTE_CUMULATIVE_GAS_LIMIT——单个 L1 区块中所有 EXECUTE 调用可用的总 gas。
• 可能会为这些调用引入基础费用或独立的“Rollup gas”，只有在“无状态以太坊”到来后，才可能与 L1 费用合并。

两种强制执行模式

天真的重执行

L1 节点实际上对每个 EXECUTE 调用重新运行 L2 交易，使用在 calldata 或数据块中发布的无状态 Merkle 见证。

• 优点：
  • 概念上简单——只需使用真实的 EVM。
  • 如果开销较小，则可能实现单块或单槽最终确定。
• 缺点：
  • 如果 L2 区块较大，可能会产生大量开销（你必须发布所有状态证明）。
  • 必须保持严格的 “EXECUTE” gas 限制。
  • 如果没有合理监管可能会“垃圾” calldata，其中包含巨大的 Merkle 证明。

ZK 证明与离线分发

每个 L1 节点获取一个零知识证明，以确认 EXECUTE 调用是正确的，跳过链上的重执行。证明从不在合约中发布，而是在节点之间传播或直接集成到客户端代码中：

• 优点：
  • 如果可靠的 ZK 证明者可以信任或在本地运行，则可以快速验证大型 L2 区块。
  • 非常适合扩展或高吞吐量。
• 缺点：
  • 需要先进的证明生成；如果电路出现故障，整个链可能会接受无效区块。
  • 必须确保客户端能够处理多种证明类型或并发。

桥接、自定义逻辑和“包装 STF”

许多现有的 Rollups 依赖于专门的桥接逻辑——例如，自动将 ETH 从 L1 存入 L2，或“可重试票”。如果 EXECUTE 纯粹是标准的 EVM 逻辑，那么桥接是如何进行的？

• 包装方法

  • 一个 L1 合约调用 EXECUTE，但在主要 EVM 转换之前/之后也处理桥接。例如，它为存款更新某些账户的余额（“state.AddBalance”）。
  • 这将 Rollup 的 STF 分为“depositSTF” + “evmSTF”，每个可能以不同方式进行验证。

• 系统交易

  • L2 可以定义特殊的“系统交易”来进行桥接或存款逻辑。但这在 L1 或升级路径上重新引入了部分自定义逻辑。

结果：如果你希望实现零治理负担并纯粹使用 L1 EVM，你必须将桥接或“depositTx”逻辑保持在极其简单的水平。更先进的桥接将在某种程度上重新引入治理，因为该逻辑与 L1 EVM 不同。

数据和执行开销

无状态追踪的数据开销

天真的重执行要求在 calldata 或数据块中完整的状态访问证明。这可能导致数据使用相对于自定义压缩或专用证明增加 2–5 倍。

缓解措施：

• 单轮欺诈证明：L2 是“乐观的”，但如果存在争议，挑战者在一小部分上调用 EXECUTE。
• 小的 Gas 限制：仅允许适度的 L2 块大小，以保持可控开销。

实时 zk 验证

如果 ZK 电路可以近乎实时更新，则可以跳过大的数据开销。但这将复杂性转移到链外 ZK 硬件或多供应商市场。如果发现电路不健全，确保一个强健的后备方案（如天真的重执行或多证明方法）是有价值的。

治理与升级

自动 EVM 升级

主要好处：因为 L2 使用的是 L1 的实际 EVM 逻辑，所以它自动获得 L1 硬分叉中的新操作码或 gas 规则。无需特殊的多签或安全委员会，与 L1 的变化同步 L2。

L2 创新与锁步

权衡：一些 L2 想要高级功能（例如自定义费用计算、桥接预编译、无签名交易等）。这可能需要部分“包装代码”或扩展环境。

因此，“完全原生”最适合严格等同于 EVM 的设计。一旦你严重偏离 L1 EVM 规则，要么放弃“纯原生性”，要么维持部分治理。

组合性与跨 L2 互操作性

• 基于（Based） vs 原生

  • “基于“意味着 Rollup 从以太坊的区块构建者那里继承 L1 排序。
  • “原生”的意义在于 L1 执行引擎强制执行 L2 转换。
  • 它们是正交的。一个 Rollup 可以是两者、任一或都不是。

• 与非原生的桥接

  • 一个原生 Rollup 可以轻松地与其他共享相同 EVM 环境和桥接合约的原生 Rollup 进行互操作。
  • 但是，与“正常”的 Rollup 的桥接仍然需要典型的跨 L2 桥接或消息传递。像 Espresso 或通用桥接这样的项目可以将这些统一。

时间线和下一步

以太坊社区中的许多人认为 2026 年及以后是实施 EXECUTE 预编译的合理时间表。路径可能如下所示：

• 提议“原生执行桥接”的 EIP。
• 首先为天真的重执行设定较小的 gas 限制（如 proto-danksharding 对数据所做的）。
• 随时间推移，利用可选的链外 ZK 证明来超越这个小限制。

主要 L2 是否会采用“纯原生”还有待观察：完全无信任的 EVM 等价性的机会巨大，但许多 L2 更喜欢或需要自定义桥接和高级功能。无论如何，原生 Rollups 是一种强大的新途径，以可能大幅简化整个 L2 生态系统的方式将 L1 和 L2 融合在一起。

待探讨的开放性问题

最后，我想留给你一些待探讨的开放性问题：

• “纯” 等价性应有多严格？
  原生 Rollup 可以在多大程度上引入桥接逻辑、无签名交易或预编译，而不破坏“纯”无信任性或重新引入部分治理？

• 天真的重执行能否支持高吞吐量？
  如果 L2 增长到每秒数千笔交易，L1 节点能否合理处理用于重执行的无状态追踪？或者这是否不可避免地将我们推向链外 ZK 证明？

• 如果在 ZK 虚拟机客户端中出现安全性漏洞会发生什么？
  如果多个 L1 节点依赖链外电路跳过重执行，我们如何处理该电路的灾难性漏洞？“多种证明多样性”可行或必要吗？

• 我们能否在实践中实现单槽最终确定性？
  理论上，天真的重执行或单槽证明生成可以在同一区块中最终确定 L2。但这需要一个专门的证明流水线，还是只需一个小的重执行限制就足够？

• L1 排序复杂性如何与 EXECUTE 调用交互？
  如果“Based Rollup”统一 L1 和 L2 区块构建，我们如何整合验证每个 L2 区块的开销？部分并发或并行化是否可以缓解资源争用？

• 非原生 Rollup 的桥接安全性
  即使原生 Rollup 无缝分享 EVM 逻辑，与正常或部分信任 Rollup 的桥接仍然存在。是否有办法在没有新治理的情况下，通过单一协议统一所有 L2 的桥接？

• 包装逻辑与链上可升级性
  如果一个 Rollup 使用“包装 STF”进行桥接或存款逻辑，该包装是否需要可升级性？这是否可能成为单点故障或重新引入安全委员会？

• 如果 L1 EVM 创新速度低于 L2 会怎样？
  如果 L2 开发者希望超出标准 EVM 能力的不同比交易类型、新操作码或先进桥接预编译，是否会失去原生 Rollups 的优势，或者我们是否会推动更频繁的 L1 升级？

• 完全 L1 验证的执行开销是特性还是缺陷？
  我们是否会将其视为故意“限流” L2 以保持系统更简单和更无信任，还是这是一种不可避免的瓶颈？部分协议内数据压缩是否可以减轻这种情况，而无需特殊电路？

• 以太坊是否应采取甚至更通用的“执行分片”方法？
  如果社区重新考虑旧的 Eth2 “第2阶段”风格的执行分片，这是否自然会取代或纳入原生 Rollups？这些愿景在实践中如何重叠或不同？

这些问题突显了原生 Rollups 背后的复杂性和开放设计空间。它们邀请围绕信任桥接、治理影响、潜在性能陷阱，以及如何在纯 EVM 等价性与对更大 L2 创新的渴望之间导航进行深入讨论。

参考文献

1. 原生 Rollups——来自 L1 执行的超能力。
2. 原生 Rollups - 会议
3. 以太坊排序和预确认通话 - 会议

• 原文链接： github.com/thogiti/thogi...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～