通过实时证明实现 Rollup 间的同步组合 - Layer 2

通过实时证明实现 Rollup 之间的同步可组合性

1. Based Rollup 和实时证明

Based Rollup 是一种允许任何人提议新区块的 Rollup，没有特权排序器。任何参与者都可以获取 Rollup 的当前状态，应用一组交易，并生成一个新区块。

当我们要求数据可用性负载和有效性证明作为一个原子单元一起提交时，一个关键的设计优势就显现出来了。在传统的 Rollup 设计中，数据先发布，证明后发布，这引入了一个差距，使激励设计复杂化：谁生成证明？何时？如何确保他们得到公平和及时的补偿？

通过同时发布数据和证明，我们完全消除了这个差距。区块提议者负责执行和证明。如果证明无效或缺失，则该区块根本不存在。这极大地简化了激励机制，区块提议者就是证明者，他们的奖励来自同一来源（例如，交易费用），而无需单独的证明市场或挑战期。

这得益于实时证明，即能够足够快地生成有效性证明，以便可以与区块构建同时生成，而不是作为异步的后续考虑。

实时证明正迅速变得实用。截至今天，证明一个完整的以太坊区块需要大约 12 个 GPU，平均证明时间约为 7 秒。在改进和降低延迟方面仍有很大的空间，包括通过硬件改进和证明系统优化，尽管很难准确预测限制在哪里。Prover 的中心化是一个合理的担忧：硬件要求并非微不足道，并非每个区块构建者都能访问相同的证明基础设施。然而，证明本质上是可并行化和可商品化的，并且趋势显然是更便宜的硬件上更快的证明。

2. 什么是同步可组合性？

同步可组合性意味着在单个交易中，一条链（L1 或 Rollup）上的智能合约可以 CALL 另一条链（L1 或另一个 Rollup）上的智能合约，并在相同的执行上下文中接收结果，就像两个合约都位于同一条链上一样。

如今，跨链交互是异步的：你在链 A 上发送一条消息，等待它被中继到链 B，然后单独处理结果。这打破了使以太坊 DeFi 生态系统如此强大的可组合性模型。协议无法在 Rollup 边界上原子性地组合。

同步可组合性恢复了这一点。从开发者的角度来看，调用另一个 Rollup 上的合约看起来和行为与调用同一条链上的合约完全一样。该交易要么在所有相关链上原子地成功，要么完全回滚。

3. 简单的情况：L2 到 L2 的可组合性

在解决更困难的 L1↔L2 交互问题之前，值得注意的是，仅 L2 Rollup 之间的可组合性相对简单。

如果我们只处理 L2，我们可以将所有受影响的 Rollup 的数据可用性捆绑到一个 blob 中。区块构建者构建一个组合的执行，该执行触及多个 Rollup 状态，将它们全部一起证明，并将结果作为一个原子数据可用性提交。由于所有受影响的状态转换都被一起证明和发布，因此可组合性自然而然地随之而来，这些转换要么全部发生，要么全部不发生。

这个观察是基础。更难的问题是在 L1 智能合约参与交互时如何实现这一点。

4. 代理智能合约

实现跨链调用的核心机制是代理智能合约。代理是部署在一个链上的智能合约，它代表一个位于不同链上的智能合约。

当 L1 上的合约想要调用 Rollup R 上的合约时，它不会以某种方式直接在 R 上执行代码。而是调用 R 合约的代理，该代理存在于 L1 上。代理合约封装了跨链调用：它知道目标合约是什么，它处理调用，在 Rollup 上应用相应的状态更改，并在同一交易执行中返回结果。

从调用者的角度来看，与代理交互与与真实合约交互没有区别。代理是远程合约的本地接口。

5. L1 ↔ L2 交互模型

当一笔交易涉及 L1 和 L2 智能合约时，执行遵循一个结构化的过程：

步骤 1：确保代理合约存在

在执行之前，所有将与 L1 交互的 L2 合约的代理智能合约都必须已部署。如果 Rollup R 上的合约将从 L1 调用，则其代理必须已存在于 L1 上。

步骤 2：构建并提交执行表

执行表被构建并临时存储在 L1 状态中。该表是一个条目序列，其中每个条目描述一个动作及其后果。每个条目包含：

• 动作：主要是 CALL 或 RESULT。
• 一组 L2 状态转换：哪些 Rollup 受到影响，以及它们的状态根从/转换到什么。
• nextAction：接下来会发生什么，要么是 RESULT（带有返回数据），要么是另一个 CALL（到不同的 L1 智能合约）。

该表捕获了跨链交互的完整跟踪。例如，考虑一个嵌套调用场景：

A (在 L1 上) 调用 B (在 Rollup 2 上)
  → B (在 Rollup 2 上) 调用 C (在 L1 上)
    → C (在 L1 上) 返回
  → B (在 Rollup 2 上) 返回
A (在 L1 上) 继续执行

在这种情况下，执行表将包含两个条目：

| # | Action                | L2 State Transitions          | nextAction          |
|---|-----------------------|-------------------------------|---------------------|
| 1 | CALL B (在 Rollup 2 上) -| Rup2: stateRoot₀ → stateRoot₁ | CALL C (在 L1 上)      |
| 2 | RETURN from C (在 L1 上) | Rup2: stateRoot₁ → stateRoot₂ | RETURN to A (在 L1 上) |

第一个条目说：“当 A 调用 Rollup 2 上的 B 时，Rollup 从 stateRoot₀ 转换为 stateRoot₁，接下来需要发生的是调用 L1 上的 C。”第二个条目说：“一旦 C 返回，Rollup 2 从 stateRoot₁ 转换为 stateRoot₂，最终结果返回给 L1 上的 A。”

执行表编码了整个调用/返回序列，以及每个步骤发生的所有 Rollup 状态转换。至关重要的是，该表附带一个单一的有效性证明，保证了表中每个执行步骤的正确性。该证明在提交表格时验证一次。

步骤 3：使用代理解析的 L1 执行

现在 L1 交易正常执行。当执行到达 L1 合约调用代理合约的点时，代理执行以下操作：

1. 在执行表中查找相应的 CALL 动作。
2. 验证并应用受影响的 Rollup 的状态根更改。
3. 如果序列中存在嵌套的 L1 调用，则执行它们。
4. 从执行表中删除已消耗的条目（以避免浪费 L1 存储）。
5. 将 RESULT 返回给调用的 L1 合约。

从 L1 执行环境的角度来看，该调用正常发生并返回了结果。跨链交互的复杂性完全由代理和执行表抽象出来。

步骤 4：L2 发起的交易

从与 L1 交互的 L2 发起的交易遵循相同的模型，但执行表中的第一个动作是 L2TX 而不是 CALL。L2 交易启动执行，对 L1 合约的任何调用都成为表中的嵌套条目，以相同的方式解析。

步骤 5：处理回滚

两个特殊动作：REVERT 和 REVERT_CONTINUE 以一种反映回滚在单个链中如何工作的方式处理跨链边界的回滚。

当 L2 上的执行期间发生回滚时，REVERT 动作被发送到 L1。然后 L1 通过撤消作为回滚执行路径一部分的任何嵌套 L1 调用并相应地更新受影响的 Rollup 状态根来处理回滚。一旦 L1 完成展开回滚的调用，REVERT_CONTINUE 动作将被发送回 L2，允许执行恢复。最终结果是回滚的工作方式与目前在单个链中的工作方式相同。

6. 补充说明

账户抽象和激励对齐

确保部署代理合约以及用户和区块构建者之间的激励正确对齐可以使用现有的以太坊标准来处理——特别是 EIP-7702 （设置 EOA 账户代码）和 EIP-4337 （账户抽象）。这些标准提供了协调设置阶段所需的灵活性，而无需更改核心协议。

Rollup 不限于 EVM

参与此系统的 Rollup 不需要是 EVM 原生的。任何可以接受和生成对其他 Rollup 的 `CALL` 的 Rollup 都可以参与。每个 Rollup 通过 zkVerification key 定义自己的状态转换函数。 Rollup 甚至可以拥有对其状态根具有完全控制权限的所有者。

主系统施加的唯一约束是以太币责任：系统必须跟踪每个 Rollup 持有多少以太币，并且不得允许 Rollup 发出超过其以太币总余额的 `CALL`。

原生 Token 和价值转移

Rollup 可以定义自己的原生 token。唯一的限制是，如果 Rollup 使用不同的原生 token，则状态转换函数不应接受或发出从或向外部 Rollup 发出具有非零以太币值的 `CALL`。这可以防止 Rollup 内部 token 与 L1 系统跟踪的以太币之间的会计错配。

无需 L1 分叉

整个机制可以在不分叉 L1 的情况下实现。一切都通过部署在现有以太坊网络上的智能合约进行操作。

与预确认正交

该提案与预确认机制完全正交。它既不依赖于预确认，也不与预确认冲突。事实上，一旦 L1 预确认可用，它可以从中受益，因为更快的 L1 最终性将减少跨链交互的延迟。

参考实现

这些智能合约如何工作的第一稿可在以下网址获得：https://github.com/jbaylina/sync-rollups

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