同步可组合性的新方向

Vitalik 最近关于同步组合性的 ethresearch 帖子 意义重大，原因有二：它标志着他在这个话题上的立场发生了重大转变，并且为一个有些停滞的研究领域注入了新的视角。

在本文中，我们将深入探讨这篇文章，与现有设计进行比较和对比，并尝试勾勒出该想法成为现实所需的条件。但首先，让我们先明确一些定义：

什么是同步组合性？

在单个领域（例如 L1 EVM）中的同步组合性是我们都熟悉的概念。它是指将多个较小的操作或合约调用拼接成单个较大交易的能力。执行是同步且原子的：每个调用都能看到前一个调用的效果，要么整个交易成功，要么整个交易回滚。无需考虑中间状态或部分失败。

这是以太坊的核心优势之一。它允许通过组合 无需许可 的货币乐高积木来涌现出复杂的应用，其中独立部署的合约可以在无需事先协调的情况下安全且可预测地组合。

同步组合性发生了什么？

以 Rollup 为中心的路线图 扩展了以太坊的总吞吐量，但代价是将状态分散到多个执行环境中。默认情况下，位于不同链上的合约无法同步交互。跨域调用会带来延迟，并且必须异步处理，通常跨多个区块。在这种世界中，在每个 Rollup 上重新部署相同的 DEX 或借贷协议并在本地构建流动性，通常比利用 L1 上现有的流动性更容易。

为了应对这种碎片化，意图（Intents）作为部分互操作性解决方案出现。它们允许用户表达期望的结果，并依赖第三方跨链执行这些结果。然而，在实践中，意图主要用于跨链代币转账，并且常常引入额外的信任假设。虽然有用，但它们无法提供与同步组合性相同的用户体验和开发者体验——在同步组合性中，交互是原子的，状态是共享的，并且执行可以像单个交易一样进行推理。

L1<>L2 同步组合性的要求

在本文的其余部分，我们将专门关注 L1 和 Rollup 之间的同步组合性，这比 Rollup 到 Rollup 更难实现。

1. 实时证明

L1 操作只有在相应的 L2 操作成功时才应成功。同步强制实现这一点的唯一方法是让 L1 验证 L2 执行的有效性证明。因此，乐观 Rollup 与此模型不兼容。为了保持同步性，Rollup 状态转换必须在单个 L1 Slot 内得到证明，这需要实时证明者。

在上图中，证明封装了 L2 交换。如果证明无效，则对 borrow() 的调用会回滚，原子性得以保留。反之，如果 borrow() 在 L1 上失败，则 swap_l2() 调用永远不会发生，因此 L2 交换不得存在于 Rollup 的历史中。如果排序器尝试包含它，证明将失败，整个交易回滚。 2. 随 L1 重组

如果由于 L1 重组而删除了 L1 发起的操作，则相应的 L2 操作也必须删除，否则原子性将被破坏。例如，L1 存款不应在重组后被移除，而 L2 上仍记入用户余额。这就是为什么 Rollup 通常会延迟处理 L1 发起的操作，直到 L1 区块得到充分确认或最终确定。同步组合性要求 Rollup 改为与 L1 同步重组。 3. 协调排序

为了使合约成功组合，所有执行都必须针对商定好的前状态进行。如果 borrow() 在 L1 上失败或交换在 L2 上失败，则所有后续操作都必须失败以保持原子性。虽然这种行为是安全的，但除非能够可靠地实现成功，否则对用户没有用处。

因此，实用的同步组合性需要 L1 提议者和 L2 排序器之间的协调。双方必须提供关于它们所执行的前状态的保证，以便交易的每个部分都能预期成功。 4. 单个 L1 交易

原子性不能跨越多个 L1 交易。一旦 L1 交易成功，协议就无法撤销它。因此，同步可组合操作必须完全包含在单个 L1 交易内。

如果 Rollup 在后续交易中结算，则原子性丧失。例如，如果 borrow() 在一个 L1 交易中成功，而 Rollup 后来结算时没有包含相应的 L2 交换，那么 Rollup 状态转换在孤立情况下可能是有效的，但整个操作违反了原子性。无法回滚已经成功的 L1 操作。

因此，一个同步可组合的交易必须包含所有 L1 发起的操作、Rollup 的数据提交、相应的有效性证明以及该证明的验证，所有这些都在同一个 L1 交易内。

Based Rollup（Based Rollups）呢？

Based Rollup 和同步组合性经常被一起讨论，因为 Based Rollup 天然满足所需属性中的两个。特别是，它们轻松地解决了协调要求：为 Rollup 排序的实体定义上就是 L1 提议者。没有单独的排序器需要协调，Rollup 的执行天然与 L1 前状态对齐。

此外，由于 Based Rollup 直接由 L1 排序，它们自然随 L1 重组。如果一个 L1 区块被重组掉，相应的 Rollup 区块也会被重组，从而无需特殊处理即可保持原子性。

也就是说，Based Rollup 本身并不足够。为了实现与 L1 的同步组合性，Based Rollup 仍然需要能够实时生成并验证其有效性证明。这个要求直到最近才变得可行。

没有 Based Rollup 的同步组合性？

这是 SCOPE 概述的方法。它不将 Rollup 完全基于，而是让 L1 提议者将其部分区块空间出售给 Rollup 排序器。这允许排序器获得关于 L1 前状态的强有力保证，这足以成功执行同步可组合交易。

这种设计的一个关键优势是，Rollup 不需要向 L1 提议者放弃排序自主权。Rollup 无需改变其执行模型，只需在需要同步组合性时选择加入 L1 提供的附加服务。这有助于减轻 MEV 问题，并显著减少现有 Rollup 接近基于行为所需的工作量。

主要缺点是这种方法依赖于 L1 供应链内部更深入的协调。特别是，需要 L1 预确认来出售区块空间，而这会带来其自身的采用和运营挑战。

Vitalik 的方法则反转了这种模式。不是 Rollup 排序器从 L1 购买区块空间，而是 Rollup 将自己部分区块空间提供给 L1 提议者。然后 L1 提议者可以像往常一样保证 L1 前状态，并且通过获得对部分 L2 区块空间的控制权，也能保证 L2 前状态。在两个前状态对齐的情况下，跨 L1 和 L2 的同步可组合执行就变得可能，而无需 L1 预确认。

逐步解析 Vitalik 的设计

* 来源：将预确认与 Based Rollup 结合以实现同步组合性

证书和常规区块

我们对 Rollup 排序器的拓扑结构或领导者选举机制不做任何假设。相反，我们将 常规 区块（浅绿色显示）定义为附有有效证书的区块。

Rollup 的状态转换函数只处理带有有效证书的常规区块。这种抽象可以清晰地概括不同的排序模型，包括中心化排序器、去中心化委员会和共享排序器，其中证书可以包含单个签名、签名法定人数，或签名加上证明签名者是当前领导者的证据。

Slot 结束区块

像今天一样，排序器的主要角色是频繁地在链下发布常规区块。然而，在这种设计中，一个区块也可能作为特殊的 Slot 结束 区块（深绿色显示）。

Slot 结束区块在内容上与常规区块没有区别。相反，它只是表示在给定的 L1 Slot 内需要排序器证书的最后一个区块。在此之后，Rollup 允许在其之上构建基于区块。

在原始帖子中，当排序器附加一个特殊证书时，区块被指定为 Slot 结束。然而，这种指定不需要是显式的。只要 Rollup 的状态转换函数能够验证，任何规则都是可以接受的。例如，如果排序器的证书包含 L1 Slot 编号，那么一个 Slot 内每第 N 个常规区块可以被隐式地视为 Slot 结束区块。

基于区块

出现在 Slot 结束区块之后以及相应 L1 Slot 结束之前的区块被称为 基于区块（红色显示）。它们被称为“基于”，是因为与 Based Rollup 设计一样，任何人都可以尝试发布它们，并且有效性不需要排序器证书。

然而，与 普通的 Based Rollup 设计 一样，无需许可的发布并不意味着保证包含。L1 提议者最终决定哪些区块被上链。因此，我们将 L1 提议者以及周围的 PBS 管道视为基于区块的有效排序器。

同步组合性窗口

一旦 Slot 结束区块被广播，一个滑动窗口就会打开，持续到当前 L1 Slot 结束。在这个窗口期间，L2 前状态是固定的：L1 提议者确切地知道他们正在哪个 Rollup 状态之上构建，并且至关重要的是，知道该状态不会在他们之下发生变化。同时，作为当前提议者，他们也控制着 L1 前状态。

在两个前状态都固定的情况下，L1 提议者可以安全地在此窗口期间构建同步可组合交易，确信跨 L1 和 L2 的执行将原子性地成功。

Rollup 结算

L1 提议者负责将常规区块、Slot 结束区块和基于区块捆绑并发布到 L1。如果没有基于区块产生（无论是由于没有人尝试构建，还是由于提议者选择不包含它），Rollup 排序器只需在下一个 Slot 中在上一个 Slot 结束区块之上继续构建常规区块。

值得注意的是，提交有效性证明并非严格要求用于结算 Rollup。有效性证明仅对于实现同步组合性是必要的。Rollup 仍然可以使用没有实时证明的基于区块，作为部分去中心化排序的一种机制。这种方法甚至与乐观 Rollup 兼容，尽管它不提供原子性的 L1–L2 组合性。

时机博弈

排序器必须仔细选择发布 Slot 结束区块的时机。如果发布得太早，Rollup 用户可能会在 L1 提议者构建基于区块时经历短暂的停机期，因为我们假设 L1 提议者不会预确认 L2 交易。

如果 Slot 结束区块发布得太晚，L1 提议者可能没有足够的时间来构建基于区块、将区块打包成 blob、生成并验证状态转换证明、包含交易以及在 Slot 结束前发布 L1 区块。

因此，排序器被迫参与时机博弈，在 Rollup 的活跃度和用户体验与同步组合性所需的狭窄窗口之间进行权衡。

分步示例

1. 排序器观察 L1 确认

排序器等待前一个 L1 区块被证明并获得充分知晓，确保在其之上构建是安全的。

2. 排序器生成常规区块

在 L1 Slot 期间，排序器持续在链下发布常规 L2 区块，每个区块都附有有效证书。

3. 排序器发布 Slot 结束区块

接近 L1 Slot 结束时，排序器发布一个 Slot 结束区块。此时，当前 Slot 的 L2 前状态被固定。

4. L1 提议者构建基于区块

在观察到 Slot 结束区块后，L1 提议者开始构建基于区块：

a. 提议者更新其对 L2 状态的本地视图，以反映 Slot 结束区块。

b. 提议者模拟 depositAndSwap() 的 L1 部分，使用模拟输入插入相应的 L2 交易，接收 L2 执行结果，并继续在 L1 上执行。

c. 提议者对额外的调用（如 withdrawAndLend()）重复此过程，同步交错执行 L1 和 L2。

5. L1 提议者证明 Rollup 状态转换

a. 所有常规区块、Slot 结束区块和基于区块被打包成一个或多个 blob。

b. 一个实时证明者生成一个覆盖证书链、Rollup 状态转换函数以及任何 Rollup 特定有效性规则的有效性证明。

6. L1 提议者构建单个 L1 交易

a. 交易包含所有 L1 用户操作，例如 depositAndSwap()。

b. 它包含 Rollup blob 和相应的有效性证明。

c. 它调用 Rollup 的收件箱合约以提交 blob。

d. 它调用 Rollup 的桥接或结算合约以最终确定状态转换。

7. L1 交易被排序

提议者或构建者确保在将其排序到 L1 区块之前，L1 前状态对于同步可组合交易是正确的。

8. L1 区块被广播

包含可组合交易和 Rollup 结算的 L1 区块被发布到网络。

9. 为下一个 Slot 重复

弱点 / 开放问题

证明时间

在单个 12 秒的 L1 Slot 内生成并验证有效性证明是极其苛刻的要求，直到最近才变得可行。在这种设计中，L1 提议者的时间通常更短，因为证明生成只能在 Slot 结束区块已知后才能开始。

减少证明延迟的一种方法是让 Rollup 降低其 Gas 限制，但这会直接降低吞吐量，并可能损害 Rollup 的竞争力。一种更具吸引力的方法是让 L1 提议者或预确认者通过随着可用区块逐步证明已排序的区块来流水线化证明生成。在这种情况下，关键路径是在剩余的 Slot 时间内证明提议者自己的基于区块。

L1 时机博弈

L1 的时机博弈已将区块发布越来越推向证明截止期限。这通过延长 Rollup 排序器在安全生成下一个 Slot 的第一个常规区块之前必须等待的时间，对用户体验产生了负面影响。

幸运的是，一些提案（例如将 L1 Slot 时间减少到 6 秒）也将按比例减少这种排序器停机时间，有助于在不改变底层设计的情况下减轻最差的 UX 影响。

无需许可性

这种设计在狭义上是无需许可的：任何人都可以尝试提交基于区块，并且有效性不需要排序器证书。然而，基于区块的存在仍然取决于首先产生一个 Slot 结束区块。因此，排序器可以通过拒绝发布 Slot 结束区块来完全阻止同步组合性。

虽然这种行为可以通过激励机制来阻止，但它提出了一个开放问题：是否存在一种定义 Slot 结束区块的规则是排序器无法博弈的？

对 Rollup 堆栈的修改

幸运的是，这种设计对现有 Rollup 堆栈的修改相对较少。在高层面上，实现可能包括以下组件：

1. 无需许可的收件箱合约

收件箱合约不白名单排序器。相反，任何人都可以提交 Rollup 数据，前提是他们能提供有效的证书链。未通过验证的提交只会回滚，从而使无效或垃圾出版物无害。 2. 即时结算

收件箱合约只应在同一 L1 交易内验证有效性证明后才接受 blob。 3. 基于邮箱的账户

为了简化跨链记账和执行，邮箱抽象（例如 SCOPE 中使用的）很有用。它们提供了用于跨域同步传递输入和输出的清晰接口。 4. 状态转换函数更新

Rollup 的状态转换函数必须扩展以验证证书链、强制执行区块有效性规则，并确保 L1 和 L2 执行之间的邮箱等价性。

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