嵌入式 Rollup 第二部分：共享桥接 - Layer 2

\ image1792×1024 143 KB

一个 rollup 嵌入另一个 rollup 的罕见图像

由 Lin Oshitani 和 Conor McMenamin 共同撰写，他们都来自 Nethermind。感谢 Patrick McCorry, Chris Buckland, Swapnil Raj, Ahmad Bitar, 和 Denisa Diaconescu 提供的反馈。反馈不一定代表认可。这是关于嵌入式 rollup 的两部分系列文章的第一部分。

Vitalik Buterin 曾经说过:

假想一个世界，所有的 L2 都是有效性证明 rollup，并在每个 slot 都提交到以太坊。即使在这个世界里，从一个 L2 “原生”地移动资产到另一个 L2 也需要提款和存款，这需要支付大量的 L1 gas。解决这个问题的一种方法是创建一个共享的最小 rollup，其唯一功能是维护哪些类型的 token 由哪个 L2 拥有多少余额，并允许通过任何 L2 发起的一系列跨 L2 发送操作批量更新这些余额。这将允许跨 L2 的转移发生，而无需为每次转移支付 L1 gas，也无需像 ERC-7683 这样的基于流动性提供者的技术。

在本文中，我们将描述嵌入式 rollup 如何实现最小共享 rollup 的概念，而无需在每个 slot 都将证明提交到以太坊。

别担心，我们理解你的想法 Vitalik。

介绍

在 本系列的第一部分 中，我们介绍了嵌入式 rollup (ERs) 的概念——嵌入在其他 rollup 中并由它们共享的 rollup。当嵌入一个 ER 时，一个 rollup 将 ER 的状态与其自身的状态一起存储和更新，这使得该 rollup 在执行期间可以本地只读地查看 ER 的状态。如果多个 rollup 嵌入了相同的 ER，它们可以共享这个只读状态，而无需依赖 L1 状态或执行。

在本文中，我们将描述如何使用嵌入式 rollup 在嵌入相同 rollup 的 L2 之间创建一个共享桥。这种嵌入式 rollup 实现了 L2 之间快速且廉价的互操作性，无需在 L1 上执行交易即可将 token 从一个 L2 的状态发送到另一个。这种简单的功能有可能解决以太坊长期路线图中的主要问题之一；用户及其流动性在 L2 之间的碎片化 (请参阅参考)。

现有互操作性解决方案的问题

如今，要在 L2 之间移动资产，你有以下选择，通常通过以下方式描述：

• 通过 L1 结算的慢路径：通过从源 L2 提款并存入目标 L2 来通过 L1。这需要为每次转移支付昂贵的 L1 gas 费，这非常昂贵。
• 通过求解器网络的快路径：使用在 L2 之间维护流动性池的第三方求解器。随着 L2 数量的增长，这种方法变得越来越低效，因为求解器必须将其资本分散到所有 L2 中，导致流动性不足，并且在不太受欢迎的路径上的定价较差。
• 全有或全无的依赖性：这类解决方案以 AggLayer 和 Superchain 方法为例，其中 rollup 通过共享桥连接，并且一个 rollup 的执行取决于桥中所有其他 rollup 的执行（有一些注意事项）。为了在 rollup 之间发送 token，rollup 节点实际上需要运行所有其他 rollup 的完整节点（或 信任第三方来验证其他 rollup 的执行）。

我们可以通过创建一个通过嵌入式 rollup 的共享桥来解决所有这些问题。嵌入式 rollup 维护着每个 L2 拥有的每种类型的 token 数量的单一统一账本。共享桥生态系统中的每个 rollup 只需要维护嵌入式 rollup 状态的本地视图，而无需验证有关嵌入嵌入式 rollup 的其他 rollup 的执行的任何信息。

回顾：嵌入式 Rollup

本节描述了 rollup 嵌入嵌入式 rollup 必须遵循的核心协议，如 本系列的前一篇文章 中介绍的。

预备知识：传统 Rollup

为了考虑 rollup 如何嵌入 rollup，让我们首先考虑 rollup 当前如何推进其状态。对于一些没有嵌入式 rollup 的传统 rollup A，A 根据以下协议推进其状态：

1. 更新 A 的 L1 本地视图。
2. 从 L1 上的 rollup A inbox 中读取 rollup A 交易。Rollup A 可能 还会读取 rollup A 排序器提供的 L1 上 rollup A inbox 中预确认的交易**。
3. 通过执行 rollup A 交易来更新 A rollup。

备注：

*大多数 rollup 都有 两个 inbox，一个延迟 inbox 和一个排序器 inbox：

• 一个延迟 inbox，可以无需许可地添加到其中。在延迟 inbox 窗口之后，延迟 inbox 中的交易必须应用于 rollup 的状态。

• 一个排序器 inbox，只能由排序器更新。排序器 inbox 交易会立即按照它们出现的顺序应用于 rollup 的状态。排序器 inbox 可以随时在延迟 inbox 窗口之前从延迟 inbox 中弹出交易。

\\ rollup A、ER 和 L1 的排序器可以是不同的、共享的或部分共享的。不同的、共享的或部分共享的排序器都会改变从一个排序器到另一个排序器的预确认强度。

回顾：嵌入式 Rollup 协议描述

假设 rollup A 想要嵌入一个 rollup ER。在这种情况下，rollup A 通过以下方式推进其状态：

1. 同步其本地 L1 节点。

2. 从 L1 上的 rollup A 和 rollup ER inbox 中检索 rollup A 和 rollup ER 交易，以及它们随附的 calldata 或 blobs。

   • Rollup A 可能 还会读取来自 rollup A 排序器和/或 rollup ER 排序器的预确认交易。
3. 通过执行 ER 交易来更新它们对 ER 的本地视图。

4. 通过执行 A 交易来更新 rollup A 的状态。

   • 这些交易可以从 A 的 ER 本地视图中读取。

使用嵌入式 Rollup 实现共享桥

嵌入式 rollup 可用于在 L2 之间提供快速（几乎即时）且廉价（无需 L1 交易）的互操作性，而不会 将流动性分散在 L2 之间。实现为嵌入式 rollup 的共享桥描述如下：

从 L1 存款到 L2

当用户想要在存在嵌入式共享桥 rollup 的情况下将其 token 转移到 L2 时，他们有两种选择：

1. 通过原生桥存款（与正常情况一样）：

a. 用户将其 token 发送到 L1 上的 L2 inbox 合约 .

b. L2 从 L1 inbox 中读取

c. L2 在 L2 上为用户铸造相应的 token。

2. 通过共享桥存款：

a. 用户将其 token 发送到 L1 上的共享桥 rollup inbox 合约。

b. 共享桥 rollup 读取 L1 上的 inbox，然后在共享桥 rollup 上铸造相应的 token，将其记入共享桥 rollup 上的 L2 inbox。

c. L2 读取它们在共享桥 rollup 上的 inbox，然后在 L2 上铸造相应的 token，将其记入 L2 上的用户。

\ image745×458 86.5 KB

通过结算的慢路径

通过结算将共享桥 token 从 A 转移到 B 具有以下流程。为简单起见，我们将 L2 表示为 A 和 B。重要的是，考虑到 A 和 B 都嵌入了相同的共享桥 SB，从 A 到 B 的流程与从 B 到 A 的流程相同。

1. A 向其本地 SB 合约提交 A → SB 转移请求。此转移请求中的 token 实际上在 A 中被烧毁。
2. A 的状态根（包含 A → SB 转移请求）结算到 L1。
3. A 的状态根通过被推送到 L1 上的 SB inbox 合约来导入到 SB 中，然后由 SB 读取。
4. A 的状态根被推送到 SB → A 桥合约，解锁与 A → SB 转移请求相对应的 token。
5. 转移消息由（或代表）用户发送到 SB rollup 上的 A 合约，其中存储了 A 的 token。此消息证明用户确实向 A 上的 SB 合约发送了有效的转移请求。请注意，此转移消息可以作为步骤 4 中的消息的一部分进行捆绑或执行。
6. SB 更新其账本，将 token 从 A 的 inbox 发送到 B 的 inbox。
7. B：

a. 读取它在 SB 上的 inbox，并在 B 上铸造相应的 token。

b. 这些 token 会记入 B 上的用户。

与传统的通过结算的慢路径不同，这不需要在 L1 上进行单独的提款或存款交易。

请注意，即使 B 没有将 SB 嵌入到其状态转换函数中，B 仍然可以读取 L1 上的 SB 状态根，并合并 SB → B 转移，而无需任何 L1 交易。对于此功能，B 需要等待共享桥在 L1 上结算包含 SB → B 转移的状态根。

一方面，这不需要更改 B 的状态转换函数，而另一方面，从 SB 的转移现在受到 SB 状态更新的证明和结算时间的限制。（感谢 Paddy Mc）

\ image815×434 95.6 KB

通过求解器的快路径（带有条件）

为了实现更快的转移，求解器可以在共享桥 SB 中维护其流动性，并代表用户将 token 发送到目标 rollup，以换取通过慢路径接收这些 token 以及费用。这是对传统基于求解器的协议的关键改进，这些协议需要在各个 L2 中分散流动性。使用此 SB 流动性，求解器可以实现快速的跨 L2 token 转移。

快速转移请求

为了描述快速路径协议，首先介绍一下快速（和慢速）转移请求，最初在此处介绍。快速 A → B 转移请求实际上是通过慢路径将 token 发送到 B。但是，提取这些 token 的条件与通过结算进行的传统提取不同。快速请求将最终在 SB 上解锁的 token 的专有权授予代表请求者在 SB 上提交有效解决方案的第一个求解器。有效的解决方案代表请求者在 SB 上向另一个地址发送特定数量的 token，如请求中所指定的那样。要在 SB 上提取与 A 上的快速请求相对应的 token，必须证明该请求存在于 A 的已结算状态根中，并且：

1. 提交了一个解决方案，允许求解器提取，或者
2. 没有提交解决方案，允许用户提取。

接下来，让我们更详细地逐步了解此协议。

协议描述

与之前一样，我们假设我们正在将 token 从 rollup A 转移到 rollup B，两者都嵌入了相同的 SB。

1. 用户在 A 上提交快速（和慢速）A → B 转移请求，将 token 发送到 A 上的 SB 桥合约以进行销毁。
2. 在观察到 A 批次中的快速 A → B 转移请求后，求解器执行有条件解决方案，如下所示：

a. 包含快速转移请求的批次被推送到 L1 上的 A 的 inbox 合约。

b. 包含快速请求的 A 批次的哈希值被推送到 L1 上的 SB inbox 合约。

c. 此哈希值从 L1 上的 SB 的 inbox 中读取并导入到 SB。

d. 解决方案由求解器创建，将其执行与包含特定承诺（例如，包含有效快速转移请求的 A 批次的哈希值）的 A 批次的包含相关联。

e. 该解决方案将与快速转移请求相对应的 token 转移到 $Bs inbox。

f. 该解决方案将 A 的有效转移记录推送到 SB 上的 A 的 inbox。

3. 然后 B：

a. 读取其在 SB 上的 inbox，并在 B 上铸造相应的 token。

b. 这些 token 会记入 B 上的用户。

4. A 的状态根（包含快速转移请求）结算到 L1。
5. A 的状态根导入到 SB 中：

a. 通过被推送到 L1 上的 SB inbox 合约，

b. 由 SB 从 L1 上的 inbox 合约读取。

6. A 的状态根被推送到 SB 上的 A 的 inbox。
7. 求解器从 A 的 inbox 中提取与快速转移请求相对应的 token，证明该请求存在于已证明的状态根中。
8. 如果没有求解器在 SB 上提交解决方案，则当包含请求的 A 状态根在 L1 上结算时，用户可以从 SB → A 合约中提取资金。

\ image843×507 80.3 KB

如协议中所述，解决方案的执行可以取决于某些 SB 或 L1 交易的存在。对于无风险解决方案（求解器获得 token 或不发生任何事情），由于 SB 从 L1 读取，因此求解器可以将 SB 解决方案的执行与 L1 上 A 批次的包含相关联。通过这种方式，如果求解器知道包含的 A 批次执行并导致在 A 上执行快速转移请求，则求解器也知道当 A 状态根在 L1 上得到证明时，与请求相对应的 token 将在 SB 合约上可用。如果 A 批次被 rollup 排序器分叉并且未推送到 L1 inbox，则 SB 转移的条件将不满足，并且 SB 转移将不会执行。

通过预确认增强快路径

此协议要求包含快速转移请求的批次在求解器可以在桥 rollup 上执行解决方案之前出现在 L1 上。由于 L1 和 rollup 排序器之间没有协调，因此在 L1 上的 rollup 批次中观察到快速转移之前，无法生成解决方案。从理论上讲，用户至少需要 12 秒才能在 rollup B 上收到资金，这是观察包含批次的 L1 区块和生成包含解决方案的共享 rollup 批次之间的时间。这不太好。

通过预确认，包含快速请求的 rollup 批次可以在将请求提交到 rollup 排序器后立即在 L2 上进行预确认。不仅如此，通过 rollup 和 L1 排序器之间的某种协调，此 rollup 批次可以在 L1 上进行预确认。更好的是，如果 rollup 是基于的，则这些 rollup 和 L1 排序器将是同一实体。在此类系统中，求解器可以根据 L1 上预确认的 rollup 批次生成其共享桥解决方案。最后，此解决方案可以包含在共享桥 rollup 批次中，并在 L1 上以任意快的速度（在 rollup 批次之后立即）进行预确认。总而言之，这意味着用户可以在生成和预确认 L1 上的 2 笔交易所需的时间内收到目标 rollup 上的 token。

尽管这听起来很棒，但这种增强型解决方案依赖于尚未完全部署到此点的一些技术进步；Based Rollup 和 基于预确认。这些是积极的研究和开发领域，希望预确认在不久的将来出现在主网上。尽管在许多Based Rollup 中，跨多个Based Rollup 的亚秒级依赖预确认对于低资源基于提议者来说是不可行的，但高资源预确认者（通过网关或 彩虹质押）可能会出现，以满足此处提出的嵌入式共享桥等解决方案的需求。

也可以进行无条件求解。尽管我们描述了如何有条件地提供解决方案，但求解器也可以提交无条件解决方案。这些无条件解决方案将取决于求解器和参与转移请求的 rollup 排序器之间的信任；也就是说，至少是转移发起地的 rollup 和共享桥 rollup。当单个排序器对转移发起地的 rollup 和桥 rollup 进行排序时，这种信任在某种意义上得到了简化，但这并不是必需的。

嵌入式共享桥的实践

通过嵌入式 rollup 进行共享桥接可以被视为原生桥的附加组件或替代品。本节介绍了对于现有 rollup 来说，这可能会如何发生，以及一些嵌入 rollup 的其他注意事项。

无嵌入到嵌入

在本节中，我们考虑了有和没有将 rollup 嵌入到 rollup 状态转换函数中时，跨 rollup 可组合性的含义：

• 无嵌入：rollup 的状态转换函数不维护嵌入式 rollup 状态的本地视图。相反，rollup 仅通过 L1 上嵌入式 rollup 合约中已证明的状态根读取嵌入式 rollup 状态更新。这些状态根可以指定到嵌入式 rollup 上的 rollup 桥合约的存款。
• 嵌入：rollup 的状态转换函数维护嵌入式 rollup 状态的本地视图。为了推进嵌入嵌入式 rollup 的 rollup 的状态，嵌入式 rollup 的本地视图必须与之前的状态更新保持一致，可能需要推进嵌入式 rollup 的本地视图的 head 以实现活跃性。

原生桥到共享桥

现在我们考虑 token 将如何在共享桥和原生桥之间分配。

• 无可组合性：所有 rollup 将其 token 保存在自己的原生桥中。rollup 用户的正常 UX。必须通过 L1 交易才能将 token 从 rollup A 转移到 B。
• 具有一些可组合性需求：一些 token 锁定在原生桥中，一些锁定在共享桥合约中。在共享桥 rollup 中，token 要么是解锁的，要么是锁定在共享桥 rollup 上存在的 rollup 合约之一中。为了从 rollup A 转移到 rollup B，用户需要在 rollup A 上获取共享桥 token（与原生桥 token 不同），然后通过共享桥上的快速或慢速路径将这些 token 转移到 rollup B。然后，当这些共享桥 token 通过共享桥合约发送到 rollup B 时，用户可以选择将 token 保留在其共享桥形式中，或者将 token 出售以换取 rollup B 上的原生 token。
• 最大可组合性：没有 token 存储在原生桥中，而是所有 token 都存储在共享桥中。与之前一样，在共享桥 rollup 中，这些 token 要么可以解锁，要么可以锁定在共享桥 rollup 中存在的 rollup 桥合约之一中。

其他注意事项

为了桥的安全性，来自 rollup 原生桥的 token 可能需要与来自共享桥的 token 具有不同的表示形式。否则，如果共享桥 token 持有者能够通过原生桥提取 token，反之亦然，原生桥用户可能被迫承担共享桥用户风险才能提取其 token。

尽管“碎片化不好”是现有求解器网络的主要问题，但我们省略了对这种问题有多糟糕与嵌入共享桥相比的定性分析。我们鼓励任何有兴趣的人模拟此类分析。无论在竞争激烈的求解器市场中碎片化的成本如何，共享桥方法都可以实现求解的访问民主化，因为求解器没有结算风险，这使其可以被非专业人士访问。

在增强部分中，我们提到一个 rollup 交易批次中的解决方案可以取决于 L1 上在其之前的任何批次。从技术上讲，可以通过允许来自不同 rollup 的 rollup 交易在同一批次中交织来实现改进。通过这种（次要的）改进，将启用依赖的跨 rollup 交易链。

相关工作

嵌入式 rollup 与几种不同的协议具有相似之处，我们将在本节中概述这些协议。随着我们接近实时证明，嵌入式 rollup 将与我们概述的许多解决方案越来越紧密地融合在一起。但是，就目前而言，嵌入式 rollup 与现有解决方案之间存在关键差异。

假设 rollup A 想要将资金转移到 rollup B。在本节中，我们将比较现有互操作解决方案如何处理此类转移，并与 ER 进行比较。

ERC-7755

Rollup A 结算到 L1，rollup B 导入已结算的 A 状态根并读取消息。此方法最大限度地减少了 rollup A 和 rollup B 执行之间的依赖性，因为 rollup B 仅在 rollup A 的状态已得到证明和结算后才采取行动。但是，此过程很慢，因为 rollup B 必须等待 L1 上 rollup A 状态的证明和结算，这可能需要大量时间，相当于使用嵌入式共享桥的慢路径。

聚合结算

聚合结算 通过将一个 rollup 的结算与其他 rollup 的结算相关联，从而实现 L2 之间的同步可组合性。这允许 rollup 从另一个 rollup 导入消息，根据这些消息执行 L2 区块，如果在共享结算时间验证其他 rollup 的状态根发现消息无效，则稍后恢复执行。该协议有效地通过利用 L2 共享结算层这一事实来实现 L2 之间的同步可组合性。

但是，此方法需要 rollup A 和 rollup B 之间紧密的执行耦合，因为排序器必须执行两个链。此外，如果在结算时检测到 inbox-outbox 不匹配，则可能导致 rollup 的“级联”恢复。相比之下，在我们的嵌入式 rollup 解决方案中，尽管 rollup A 和 B 都嵌入了 ER（它们与 ER 耦合），但不会引入 A 和 B 之间的耦合。

AggLayer 的快速路径和 Optimism 的 Superchain 采用了这种方法。

现有基于求解器的解决方案

我们的共享桥解决方案利用共享桥 rollup 上的求解器来促进可组合性，类似于 Across 等协议。但是，传统的基于求解器的方法面临流动性碎片化的问题，因为求解器需要为其支持的每个链对维护单独的流动性池。对于流动性需求较低的小链来说，这尤其具有挑战性。相比之下，我们的桥 ER 解决方案将所有求解器流动性集中在嵌入式共享桥中。此设置允许求解器在共享桥中的任何 rollup 组合之间促进交易，而无需将其流动性移出共享桥。此外，求解器无需同时执行 A 和 B。为了促进 A 到 B 的转移，求解器只需要维护 A 的状态和共享桥，即可通过共享桥上的 $Bs inbox 将 token 转移到 B。

L3

使用 L2 作为基础层的 L3 可以利用 L2 比 L1 更快的区块时间，从而以更快的方式促进 L3 的状态根传递。但是，L3 的活跃性现在将取决于 L2 的活跃性。相比之下，通过嵌入式 rollup 互操作的 L2 从 L1 继承活跃性。

ZKSync 的弹性链 和 Arbitrum Orbit L3 采用了这种解决方案。

增强型 Rollup

嵌入式 rollup 与 增强型 rollup 非常相似。在增强型 rollup 中，每个 rollup 都维护整个 L1 状态的本地视图，rollup 中的任何合约都可以轻松访问该视图。类似地，嵌入式 rollup 的功能类似于增强型 rollup，但它们不是在 L1 之上“增强”，而是在另一个 rollup 之上增强。增强型 rollup 的实现可能会被修改以实现嵌入式 rollup。

如果你对类似这样的主题感兴趣，并且想站在以太坊协议研究的最前沿，我们正在招聘。通过网站申请，或通过 Twitter 联系其中一位共同作者（Conor 或 Lin）。让我们一起保持以太坊的伟大。

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