同槽L1→L2消息传递 - Layer 2

\ image1792×1024 183 KB

由 Lin Oshitani, Conor McMenamin, Anshu Jalan, 和 Ahmad Bitar 共同撰写，他们都来自 Nethermind。感谢 Brecht Davos, Jeff Walsh, 和 Daniel Wang (来自 Taiko) 的反馈。反馈不一定代表认可。

概要

Rollups 可以将 L1 状态根导入到 L2，以方便两层之间的消息传递，例如用户存款和跨链合约调用。然而，由于 EVM 无法访问当前区块的状态根，rollups 只能拉取过去区块的状态根。这个限制使得 rollups 无法仅使用状态根在同一插槽内处理 L1→L2 消息。

为了克服这个限制，本文介绍了一种协议，该协议使得 L2 提议者可以选择性地将同一插槽中发出的 L1 消息直接注入到 L2 中，从而绕过了等待状态根导入的需求。通过将此协议与我们在之前的帖子中讨论的 L2→L1 提款机制相结合，用户可以执行可组合的 L1<>L2 捆绑操作，例如从 L1 存入 ETH，在 L2 上将其兑换为 USDC，然后提款回 L1——所有这些都在一个插槽内完成。

术语

我们使用 Taiko 协议中的术语，本研究基于该协议。

• 消息 (又名 信号): 在链之间交换的数据单元，以促进互操作性，例如传输代币或执行跨链合约调用。消息在源链上发出，并在_目标_链上消费。
• 同槽消息: 与 L2 区块提议在同一插槽中发出的消息。
• 消息服务合约: 部署在 L1 和 L2 上的合约，以促进两层之间的消息传递。用户在 L1 消息服务合约中发出消息，并在 L2 消息服务合约中消费它们（反之亦然）。
• 锚定区块: 锚定 区块是 L2 区块引用的历史 L1 区块，用于将 L1 状态根导入到 L2 环境中，从而有效地将 L2 执行“锚定”到特定的 L1 状态根。请注意，锚定区块必须是过去的一个或多个插槽，因为 EVM 无法访问当前区块头。

协议

以下是该协议的高级图示：

\ image1001×1122 100 KB

流程如下解释，粗体文本高亮显示了本提案为支持同槽消息传递而新引入的组件。非粗体文本遵循当前 Taiko 协议中的实现。

• (A) 用户调用 L1 消息服务合约来启动 L1→L2 消息传输。
  • 消息被哈希并存储在 L1 消息服务合约中。
• L2 提议者：
  • (B) 选择要导入到 L2 中的同槽消息。
  • (C) 选择锚定区块 ID，即锚定区块的 L1 区块 ID。这决定了哪个历史 L1 区块的状态根将被导入到 L2 中。
  • (D) 将选择的同槽消息哈希提交到批量收件箱合约、 L1 锚定区块 ID 和 L2 批量提交到批量收件箱合约。
• 批量收件箱合约：
  • (E) 通过 L1 消息服务验证消息哈希是否已记录。如果验证失败，则 L2 批量提议将被回滚。这些消息
  • (F) 通过 BLOCKHASH 操作码 获取给定 L1 锚定区块 ID 的 L1 锚定状态根（准确地说，是包含状态根的区块头）。锚定区块必须至少是过去的一个插槽，因为 EVM 无法访问当前区块头。
  • (G) 发出一个事件包含消息哈希、L2 批量和锚定状态根，允许 L2 执行访问和处理它们。
• L2 执行将：
  • (H) 将消息哈希 和 L1 锚定状态根导入到 L2 消息合约中。
  • (I) 执行该批量。批量中的 L2 交易可以：
  • (J-1) 通过调用 L2 消息合约来消费导入的同槽消息。请注意，在这种情况下不需要 Merkle 证明，因为消息哈希可以以更易于检索的方式存储在 L2 消息合约中。
  • (J-2) 消费在锚定区块 ID 或之前的区块中发出的消息。用户（或代表他们行事的 relay）通过将原始消息和 Merkle 证明提交到 L2 消息合约来实现这一点。此证明验证消息是否使用锚定状态根在 L1 上发出。

请注意，消息服务合约不提供原生的重放检测，它将此责任委托给消费消息的应用程序。

接下来，我们将探讨此协议的关键特性，这些特性塑造了其设计决策。

选择性消息导入

该协议的一个重要特性是，L2 提议者可以选择将哪些同槽 L1→L2 消息导入到他们的 L2 区块中。这确保了：

• 状态确定性： 提议者通过避免由于来自 L1 的意外入站消息导致的意外状态更改，来维持对其 L2 批量执行后 L2 状态根的完全控制。这对于即使在 L2 提议者不是 L1 提议者/构建者的情况下，也能实现同槽消息传递尤其重要。
• 成本管理： 提议者可以选择仅导入那些可以补偿处理它们所需的额外 L1 gas 成本的同槽消息。此外，如果没有导入任何同槽消息，区块提议将没有 gas 成本开销。

条件化

此外，请注意，如果指定的同槽消息未在 L1 中发出，则批量提议交易将回滚（请参阅协议描述中的 (C)）。这使 L2 提议者可以无信任地将其 L2 批量条件化于相关的同槽消息。

绑定循环：L1→L2→L1

假设 L1 用户想要从 L1 存入 ETH，在 L2 上将其兑换为 USDC，然后提款回 L1——所有这些都在同一插槽内完成。通过将此提案与我们在 快速（和慢速）L2→L1 提款 中引入的同槽 L2→L1 提款机制相结合，可以实现此目的。具体来说，L2 提议者可以提交一个包含以下三个交易的 L1 捆绑包：

• 用户发出消息以将 ETH 存入 L2 的 L1 交易。
• L2 提议者导入上述存款消息并包含以下内容的 L2 批量提议交易：
  • 用户将 ETH 兑换为 USDC 的 DEX 交易。
  • 用户将 USDC 发送回 L1 的提款交易。
• 求解者执行提款的 L1 解决方案交易。

这里需要共享的排序器/构建器吗？

重要的是要注意，在上述 L1→L2→L1 场景中，L2 提议者_不必_是 L1 构建者。也就是说，不需要共享的排序器/构建器。重要的是捆绑包以原子方式执行——捆绑包中的所有交易都成功，或者根本不包含捆绑包。这种原子性可以通过诸如 eth_sendBundle 之类的构建者 RPC 或通过 EIP-7702（一旦实施）来实现，确保 L1→L2→L1 捆绑包将在同一插槽内以原子方式执行。换句话说，L2 提议者不需要准确知道 L2 批量执行的 L1 状态。相反，L2 提议者只需要知道“足够”的 L1 状态——具体来说，是导入的同槽消息——来执行 L2 批量。

这意味着不一定需要 rollup 在 L1 和 L2 之间具有共享排序器的意义上是“基于”的，这是Based Rollup 的 价值主张之一。但是，依靠同槽 L1 消息进行 L2 执行会在 L1 和 L2 之间建立紧密的耦合。因此，L2 需要在重组事件期间与 L1 “一起重组”。实际上，只有Based Rollup 才会接受这种重组。

未来方向

激励

当前协议没有引入激励 L2 提议者包含和使用同槽消息的机制。这些激励可以在 L2 执行端实现。我们可以引入诸如条件化于特定 L2 区块中包含的 L2 交易或具有“衰减”优先费的 L2 交易等功能。请注意，这样的功能对于解决预确认的 公平交换问题 也很重要，因为预确认和同槽消息传递都旨在激励提议者尽早包含交易。

迈向任意读取：Taiko Gwyneth

该协议的一个限制是 L2 只能读取同一插槽中消息传递服务合约的 L1 状态。我们能否获得任意 L1 状态的读取权限，而不仅仅是消息传递服务合约状态，以实现 L1 和 L2 之间更无缝的可组合性吗？

Gwyneth 是 Taiko 团队正在开发的一个令人兴奋的新协议，旨在实现从 L2 读取此类任意的同槽 L1 状态。正在考虑的一种有趣的方法是引入一个新的“内省预编译”(EIP-7814)，该预编译将当前交易 trie 和操作码计数器暴露给 EVM。有了这些信息，批量收件箱合约可以获取交易 trie 和操作码计数器，并将它们传递给 L2 执行。这将使 L2 能够模拟整个 L1 执行，直到批量提议，并计算批量提议的精确操作码计数器的插槽中间的 L1 状态根。

在此处阅读有关 Gwyneth 设计的更多信息 here。

附录：Gas 成本

每个同槽消息导入的 L1 gas 的粗略估计如下：

• 32 字节 * 16 gas/字节 = 512 gas，用于调用数据中的消息哈希。
• 2600 gas，用于从收件箱到 L1 消息服务的函数调用。我们可以批量调用消息服务以分摊此成本。
• 1 SLOAD = 2100 gas，用于读取消息服务中的消息哈希

因此，512 + 2100 = 2612 gas，加上在消息之间共享的调用消息服务的 2600 gas 成本。此外，如果我们允许 L2 提议者释放他们为同槽包含而消费的消息的 EVM 插槽，他们可以收到 gas 退款，以补偿额外的 gas 成本。

• Signal-Boost: Rollups 的 L1 互操作插件
• 规范的跨链交换：使用规范/原生 L1->L2 消息传递实现跨链交换的快速和去中心化结算
• 先发制人的可证明断言

• 原文链接： ethresear.ch/t/same-slot...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～