跨链互操作性报告

本文是对跨链互操作性解决方案的全面概述，重点关注其在Optimism Superchain中的适用性。报告深入探讨了桥接机制的安全性、活跃性、延迟、激励成本和实现复杂性，并提出了改进跨链互操作性的建议，特别是强调了零知识证明在实现安全且高效的跨链通信中的潜力。此外，还分析了原子性的不同模型，包括原子包含和原子执行，并评估了各种实现方案。

跨链互操作性报告

作者：Norswap，
感谢 Frederik Lührs、Heechang Kang (xpara)、Naman Garg 的帮助，
以及众多其他人的建议和见解！

<!-- TOC -->

<!-- TOC -->

背景

本报告由 Optimism 治理部门委托，旨在提供跨链互操作性解决方案的现状概述，及其在 Optimism 超级链中的适用性，并就未来发展方向提出建议。

当我们谈论跨链互操作性时，我们指的是在区块链之间传输信息的能力，因此也允许一个区块链中的操作触发另一个区块链上的操作。 我们将经常使用术语“消息”来指代通用信息。

在大多数情况下，跨链互操作性关注的是桥接消息和资产。 我们不局限于应用层，因此我们与“桥接”的一些含义有所不同，因为我们还考虑链级架构的可能性 - 例如，rollup 排序。

虽然我们谈论的是“跨链互操作性”，但本报告的真正目标是揭示跨rollup互操作性的可能性。 在此过程中，我们将讨论许多适用于任何类型链的内容。 同样，我们将使用 EVM 链的经典架构作为对话和命名的基础，尽管很多讨论具有普遍性。

我们认为你已经了解了跨链互操作性的重要性，因此跳过相应的原因说明部分。 稍后我们将定义跨链互操作性的一些理想属性。

本报告的读者应具有区块链架构的扎实基础，并能轻松理解“rollup”、“L1/L2”、“最终性”、“桥接”和“排序”等术语。

最后，我们注意到本报告并非旨在比较现有解决方案，尽管提到了某些解决方案。 相反，我们尝试从特定实现中抽象出来，专注于通用解决方案及其属性。

如果你热衷于阅读特定桥接提供商的比较，请参阅以下一些采用此方法的文章和报告：

目录

为了能够将任意消息从源链桥接到目标链，唯一真正重要的硬性要求是建立一种机制来验证从源链发送到目标链的消息。 这个问题可以推广到验证来自源链的区块哈希或状态根的问题。

我们将在（大量的）桥接分类部分中讨论这些机制，我们将桥接分为以下几类：

  • 嵌入式桥
  • 轻客户端桥
  • 验证者桥
  • 罚没桥
  • 乐观桥
  • 反向桥
  • Rollup 桥
    • 执行证明桥
    • 故障证明桥

在桥接属性部分，我们将定义桥接的几个关键属性（安全性、活跃性、延迟、激励和成本以及实现复杂性），并根据这些属性评估分类中的所有桥接。

此外，还可以在身份验证机制中添加两个重要的内容。

首先，一种消除桥接最终性风险的机制。 只要源链没有最终确定，桥接就不可能是安全的。 当前使用以太坊作为数据可用性 (DA) 层的 rollup 的最短最终确定时间为 15 分钟：以太坊在最佳情况下最终确定需要 14 分钟，而 rollup 发布到以太坊的交易平均需要 1 分钟。 这个问题可以通过确保如果发送消息的源链区块回滚，那么接收消息的目标链区块也必须回滚来解决。 我们将在最终性部分中详细讨论这个问题。

其次，一种确保跨链交易的原子包含或交易及其发送的消息的原子执行的机制。 原子包含可以通过共享排序轻松实现，但提供的有意义的硬性保证很少（但是，它对于 MEV 提取非常有趣）。 原子执行是一个强大得多的属性，但实际上也更难实现。 这是原子性和同步性部分的主题。

消息格式和接口部分将讨论跨链交易如何在源链和目标链上表示，并重点介绍这些接口的一些设计折衷方案。

最后，结论与建议部分将总结报告的发现，并为未来提供一些观点和建议。

超级链模型

在考虑两个 rollup 系统的互操作性时，重要的是要考虑它们之间的关系。 例如，互操作性是无需许可即可实现，还是需要一方或双方的协作（甚至软件更改）？

Optimism 超级链是“一个水平可扩展的链网络，它们共享安全性、通信层和一个开源开发堆栈。” OP Labs 已经公布了其跨 rollup 互操作性的一些计划，但未来仍有很多途径可供选择。

在我们的报告中，我们将考虑三个模型：

  • 小型模型，其中将链包含到超级链中的过程是经过许可的，需要候选链提供许多保证。 这似乎是当前由链的法则体现的“社交”模型。

  • 大型模型，其中任何链都可以在最小的监督和开销的情况下加入超级链。

  • 图模型，其中每个链独立决定它可以接受来自哪个链的消息。 对于一条新链，接受来自其他链的消息是无需许可的，而在另一个方向，其他链需要选择加入接受来自新链的消息。 这是当前在Optimism 互操作规范中反映的“技术”模型。

重要的是要注意，没有哪个模型是优越的，它们只是有不同的折衷方案。 小型模型可以启用一些解决方案，其中系统的某些组件（如排序器）由于存在权力下放或财务保证，因此更“可信”。 大型模型的优势在于允许任何人以自己想要的方式运行其 rollup，但它排除了 rollup 的不当行为会对超级链中的其他 rollup 产生负面影响的解决方案。 图模型是一种混合模型，它允许每个链定义自己的信任集。

这些解决方案也不是排他的。 事实上，在超级链的上下文中，图模型可以被视为统一了小型模型和大型模型：一组核心链将完全可互操作（彼此信任），而更广泛的一组卫星链将信任其他核心链或卫星链，但不被核心链信任。 新技术也有可能使大型模型更实用。

桥接分类

我们提出了一个桥接分类，将其分为七个类别：

  • 嵌入式桥
  • 轻客户端桥
  • 验证者桥
  • 罚没桥
  • 乐观桥
  • 反向桥
  • Rollup 桥
    • 执行证明桥
    • 故障证明桥

让我们定义每一个。 我们在这里保持描述简短，因为我们将在后面讨论它们各自的属性。

嵌入式桥是这样一种系统，其中目标链嵌入了源链的完整节点——因此，所有验证者都应该遵循并验证源链（或信任其他人这样做）。 这是rollup桥在L1到L2方向上使用的模型。

轻客户端桥是这样一种系统，其中目标链运行或验证源链的轻客户端的执行。 所谓的轻客户端，我们指的是验证源链共识但不验证交易执行的系统 (1)。 从某种角度来看，这在某种程度上并不安全，因为链的共识通常也具有升级链的权限（因此可以“允许”任何执行结果）。 此类别还包括使用共识零知识证明的桥。

(1) 让我们注意到，以太坊轻客户端协议（在 Altair 硬分叉中引入）不属于此定义，因为它依赖于一个证明委员会，该委员会的安全假设远弱于以太坊共识。 在此处阅读了解更多详细信息。

(2) 轻客户端和完整客户端之间的关键区别在于，完整客户端还会验证执行，因此能够参与“社会共识”：它可以选择遵循它认为合法的规则集（状态转换函数）。

验证者桥是这样一种系统，其中一组验证者被委托验证源链，并且必须证明被桥接的信息（无论是状态根、交易还是其他任何内容）的真实性，并且目标链验证这些证明。 这与轻客户端桥非常相似——验证者桥验证验证者的共识——区别在于验证者不需要参与源链的实际共识，因此他们的证明不具有相同的保证。

罚没桥是这样一种系统，其中一组许可的 relayer 可以将消息从源链中继到目标链。 如果 relayer 在目标链上发布了并非源自源链的消息，则任何人都可以将此（已签名！）消息的副本发布到源链，从而导致 relayer 被罚没。

该系统仅具有经济上的安全性，并且必须以一种可以在伪造消息的情况下运行的方式使用，并确保伪造消息造成的损失低于 relayer 的保证金。 实际上，这可能意味着在经济价值方面限制 relayer 的速率。

还有一个问题是如何确保 relayer 实际传递消息。 至少，我们可以允许用户挑战 relayer，迫使他们在源链上发布已签名的中继消息，这样用户（或善意的第三方）至少能够在需要时手动中继消息。

我们不知道有任何纯粹的罚没桥部署，但它在其约束范围内是一种合理的设计，并且通常会向其他类型的桥添加罚没机制。

乐观桥的工作方式与罚没桥类似，但另外增加了一段时间，在此期间可以在目标链上挑战消息，然后才将其视为有效。 一组经过许可的行为者（这可能是 relayer 集本身）负责挑战，并且挑战会立即使中继的消息无效。 无效的挑战本身可以在源链上以与无效消息相同的方式进行挑战。 只要有一个诚实的行为者能够在挑战期内挑战伪造的消息，该系统就是安全的。 需要罚没 relayer 和挑战者，以避免恶意攻击。

反向桥是依赖于另一个桥（我们将其称为“正向桥”）在反向方向（目标到源）上存在的桥。 用户在源链上发布消息，relayer 将其转发到目标链。 然后，使用正向桥，relayer 证明他确实中继了该消息，并可以从用户那里解锁付款。

反向桥与其他桥的不同之处在于它们不声明中继消息的真实性。 因此，这些消息仅限于那些无论是否从源链发起都可以发送的消息。 这些消息可以包含最终用户 (EOA) 签名以进行验证，但无法确定源链上的智能合约是否发出了消息。 用例包括跨链资产转移、在另一个链上触发无需许可的操作以及操作由来自另一个链的 EOA 控制的智能钱包。

反向桥从其正向桥继承安全假设，尽管用户和 relayer 的风险会发生改变。

Rollup 桥是使 rollup 系统在 L2 到 L1 方向上进行桥接的桥（在 L1 到 L2 方向上，rollup 使用嵌入式桥），以及在共享相同架构和桥接机制的 rollup 之间进行桥接。

rollup 的特殊性在于，它们不会通过验证者的大多数投票来达成关于区块链状态的共识。 相反，他们在 L1 链上证明，给定状态转换函数的承诺和包含的交易，状态（由状态根表示）是有效的。 如果 L2 链交易数据的真实来源（即数据可用性层）不是 L1 链，则还需要桥接这些承诺，以及由此带来的额外信任假设。

一旦确定了 L2 链区块状态根的有效性，就可以在 L1 链上中继在该区块中发送的消息（通过针对状态根证明消息）。 因此，L2 到 L1 的桥几乎可以免费与状态共识机制一起使用。

Rollup 桥也可以用于在 rollup 之间进行桥接，此处的机制特定于 rollup 桥的类型。

Rollup 桥有两种类型，分别特定于 validity/ZK rollup（执行证明桥）或乐观 rollup（故障证明桥）。

执行证明桥是 L1 链验证 L2 链上转换正确执行的零知识 (ZK) 证明的系统。 这也称为有效性证明，因为密码证明机制主要用于其简洁性属性（验证证明比执行计算便宜得多），而不是其隐私属性。

使用执行证明进行跨 rollup 桥接非常简单：目标 rollup 链可以简单地验证有效性证明。 为此，它需要访问 L1 和可能的 DA 区块哈希，它已经跟踪这些哈希，因为它本身就是一个 rollup。 这些哈希提交给构成区块的所有输入（主要是交易），因此除了已证明的源链哈希或状态根之外，它们是有效性证明的唯一公共输入。 输入（交易）本身可以是证明的私有输入，这些输入由证明针对公共输入哈希进行证明。

故障证明桥是一种系统，其中 L1 链在接受提议的 L2 链区块的状态根作为有效之前，会等待一个挑战期。 如果提出挑战，则会在 L1 链上进行挑战游戏以确定挑战的有效性。

解释挑战游戏超出了本文档的范围，但如果感兴趣，请参阅此介绍性帖子和此视频以了解一般思路，以及本文和此视频以了解更精细的细节。

使用故障证明桥接跨 rollup 需要排序器来传递来自其他 rollup 的消息。 一种共享的故障证明系统确保传递了未在源 rollup 上发送的消息的区块被视为无效。

我们相信这种分类法恰当地捕捉了所有已使用或提议的桥设计。 当然，可能存在变体，但我们认为它们通常不会从根本上改变桥的属性。

有时可以使用混合桥。 例如，可以将罚没添加到大多数其他类型的桥中，尽管它通常不会从根本上改变其属性。 一个有趣的例子是将验证者集添加到零知识桥（无论是轻客户端还是 rollup）中，以防止可能的证明系统漏洞。

桥接属性

我们确定了 5 个关键的桥接属性：

  • 安全性
  • 活跃性
  • 延迟
  • 激励和成本
  • 实现复杂性

安全性描述了桥接可能发生故障的条件，无论是通过传递未发送的消息，还是通过 从不 传递已发送的消息。 也可以根据桥接故障可能造成的经济损失来描述。

活跃性描述了桥接可能停止运行的条件，无论是停止接受新消息，还是暂时不传递已发送的消息。

延迟描述了消息包含在源链的区块中后，在目标链上传递消息所需的时间。

激励和成本 涉及桥接系统中各种参与者产生的成本和获得的利润，并着眼于这些如何激励他们的行为，尤其是与前三个属性（安全性、活跃性和延迟）相关。

实现复杂性涉及桥接系统实现的复杂性。 复杂性包括代码库的大小、独立软件组件和参与者的数量、高级技术和算法的使用（特别是密码学）或其他专业知识不太广泛的利基技术。 大多数桥接攻击都是由实现问题而不是根本性的设计缺陷造成的。

让我们对分类中各种桥接类型的属性进行一些观察。

“摘要”部分将概括每种桥接类型的属性。

安全性

我们将安全性定义为“安全性违规”，即违反主要桥接不变性的情况，即必须传递每条已发送的消息，并且只能传递已发送的消息：

  1. 消息丢失：消息已在源链上发送，但从未在目标链上传递。
  2. 消息伪造：消息已在目标链上传递，但从未在源链上发送。

大多数桥不会完全允许这两种情况（除了罚没桥，它允许伪造消息，尽管会对其进行惩罚）。 但是，始终存在一些条件，在这些条件下可能发生这些安全性违规。

因此，安全性是一种范围，必须通过桥接安全所需的额外假设（除了源链和目标链的安全性（即正确执行））来描述。

一种流行的区分是将信任最小化的桥分开，除了实现的正确性之外，这些桥不会增加安全假设。 它们包括嵌入式桥、执行证明桥和轻客户端桥。

故障证明桥（在乐观 rollup 中使用）确实增加了一个诚实挑战者的假设：只要有一个（无需许可的）行为者在挑战窗口内挑战不正确的状态根，rollup 就可以安全。

嵌入式桥是最安全的桥类型，但也是可扩展性和现实性最差的桥类型，因为它们需要一个区块链系统来嵌入另一个区块链系统。 它们仅适用于 rollup。

Rollup 桥和轻客户端桥都需要可更新，因为源链可能会被更新。 因此，在更新机制中存在信任假设，无论是多重签名还是治理投票。 可以添加更新延迟来减轻恶意更新带来的风险，尽管这可能会妨碍快速响应 rollup 漏洞的能力。

轻客户端桥可以通过使链的共识能够更新桥来解决此问题。 如果链了解轻客户端（并且升级包括验证者签名的通用“更新轻客户端”交易），或者验证者控制桥部署（尽管这排除了无需许可的轻客户端桥），则此方法有效。

罚没桥很奇怪。 从某种意义上说，它们是完全不安全的，因为无法阻止伪造消息，但其想法是，伪造消息所造成的损失以及伪造者所获得的利润将低于从伪造者那里罚没的金额。 必须正确校准这种等价性，理想情况下使用硬协议内会计。

罚没桥的另一个风险来自源链的活跃性。 如果源链在足够长的时间内不可用，则恶意 relayer 可能会在招致罚没处罚之前提取其保证金。 可以通过使提取延迟足够长来减轻这种情况，以使其不太可能发生。

乐观桥依赖于单个诚实挑战者的存在，该挑战者能够在挑战期内提出挑战。 与故障证明桥相比，窗口通常小得多（例如，故障证明桥为 30 分钟，而故障证明桥为 7 天），这使系统更容易受到对目标链的活跃性和抗审查性的潜在攻击。 这里的安全性可以通过使链在挑战期内不可用的成本或审查该期间的挑战的成本来描述。

验证者桥的安全性源于验证者集的权力下放，可以使用与分析区块链权力下放相同的方式来分析。

罚没桥和乐观桥要求 relayer 缴纳保证金，而验证者桥要求 relayer 成为许可集的一部分。 除非新的参与者由现有参与者投票选出，否则选择许可参与者（例如，治理投票）的机制会将假设添加到桥的安全性中。

反向桥的安全性源于底层正向桥，尽管它会改变某些属性。 对于其他桥，安全风险在于消息在目标链上被伪造。 因为反向桥只能在目标链上执行无需许可的操作，所以这里不存在这种风险。

但是，无需许可的操作对于 relayer 来说可能代价高昂（例如，转移资产），因此，如果正向桥发生故障，阻止 relayer 在源链上解锁付款（或执行感兴趣的操作）是一种安全风险。

同样，如果正向桥中伪造了消息，则源链中的用户可能会被迫支付（或执行某些操作），而目标链上没有发生所需的操作。

源链中的活跃性失败也可能会延迟 relayer 的付款（或逻辑执行）。 从理论上讲，这不是一个安全问题，但是由于反向桥通常用于资产转移，因此 relayer 可能会因超过预期的价格风险而蒙受损失。

最后，我们注意到，某些桥可能希望比源链的最终性期间更快地传递消息，这样做会带来额外的风险，我们将在延迟部分中讨论。

有关本报告之外的更多安全性信息，请参阅跨链风险框架，它更侧重于运营安全性，以及L2Bridge 风险框架，它也涉及流动性网络。

活跃性

活跃性是根据“活跃性违规”来定义的，在这些违规期间，要么：

  1. 延迟消息：已发送的消息在很长一段时间内没有传递。 这是一种主观的评价，但我们通常认为这是一个特别不受欢迎的问题，特别是当可以进行传递时（例如，目标链是活动的且未拥塞），但没有进行传递。
  2. 桥接停止工作：无法发送新消息。

桥的活跃性可能取决于以下因素：

  • 源链和目标链的活跃性
  • 源链和目标链的抗审查性
  • 内置机制（例如，紧急暂停功能）
  • 中继器的存在、激励和活跃性
  • 验证者的活跃性（对于验证者桥）

一般来说，活跃性和抗审查性具有相同的效果：审查可以被视为某些类型的交易的有针对性的活跃性失败，因此我们将在本次讨论中将活跃性失败视为包含审查。

目标链或源链中的活跃性失败会自动分别导致桥中的 1 类（延迟消息）或 2 类（桥停止工作）的活跃性失败，但这与桥的设计无关。

此外，在乐观桥中，源链的长时间活跃性失败可能使恶意 relayer 能够在不招致罚没的情况下挑战目标链上的消息，从而导致活跃性问题，而不是安全问题。 这类似于罚没桥的安全问题，并且适用相同的缓解措施：使 relayer 保证金的提取延迟足够长，以使其不太可能发生。

桥可能包括用于暂停桥的内置机制。 这通常是可取的，以帮助打击黑客攻击和其他运营失败。 但是，必须注意确保不会滥用此机制。 理想情况下，消息发送者不应被此机制劫持，并且应该能够取消尚未传递的消息。

最后，relayer 的存在是桥活跃性的关键因素。 需要考虑两种情况：无需许可的情况，在这种情况下，用户最多可以成为他们自己的 relayer；以及许可的情况，在这种情况下，relayer 必须属于许可集。 需要 relayer 提供保证金但以其他方式无需许可的桥位于中间位置，因为大多数用户可能没有足够的资金成为 relayer，但善意的第三方可能会介入。

嵌入式桥的独特之处在于不需要 relayer，因为 relayer 实际上是链的验证者和/或排序器。

在轻客户端桥、反向桥、验证者桥和 rollup 桥中，relayer 可以完全无需许可（尽管并非当今所有 rollup 都是这种情况，在某些 rollup 上，发布状态根是排序器的权限，而用户通过针对最终状态根发布证明来“中继”消息）。

在许可的情况下，活跃性要求 relayer 启动并运行。 对于验证者桥（无论是许可的还是无需许可的），必须有达到法定人数的验证者处于活动状态。

与具有许可 relayer 的设计相比，使用无需许可但有担保的 relayer 的设计可以被认为更具活跃性，尽管一般来说，relayer 在需要时未能出现仍然可以被认为是活跃性失败。

通过允许用户取消消息请求，可以改进某些设计。

通常，通过权力下放 relayer 和验证者集来提高活跃性，这与权力下放链的验证者集的方式相同：地理多样性、司法管辖区多样性、消除共享的有效控制、客户端多样性...

最后，从技术上讲，运营 relayer 仍然必须“出现”才能中继消息，如果没有适当的激励，他们可能不会这样做。 这将在激励和成本部分中讨论。

延迟

我们将延迟定义为消息包含在源链的区块中后，在目标链上传递消息所需的时间。

从理论上讲，延迟可以是 0，在原子可组合性的情况下（请参阅后面的讨论）或每当单个实体能够在两个链上构建区块并且愿意承担可能存在的任何最终性风险时。 由于这样的系统也可以用于确保原子可组合性，因此我们也会在该部分中介绍它。

更常见的是，延迟至少是 relayer 需要观察源链上的区块并进行交易以将其传递到目标链所需的时间，这是目标链的区块时间。

一般来说，鉴于目标链上的拥塞以及网络问题，无法保证消息将在下一个区块中传递。 实际上，从理论上讲，无法保证有界传递时间，尽管在实践中这很少成为问题。

乐观桥和故障证明桥具有固有的延迟，这是由于它们的挑战期造成的。

执行证明桥必须允许证明时间，在撰写本文时，这无法与区块生产时间相提并论。 现在，Prover 能够 在几十分钟内证明一个以太坊区块（如果将以太坊的 Keccak 哈希函数替换为 prover 友好的哈希函数（如 Poseidon），则最快只需几分钟）。

我忍不住想要快速进入零知识证明生成的世界。

zkEVM 运行电路以证明 EVM 的执行，而通用 zkVM 证明通用指令集（如 RISC）的执行。 为了证明 EVM 链的状态转换函数的执行，zkVM 必须证明更大的计算量，因为它们证明的是 EVM 解释器的执行，而 zkEVM 证明的是 EVM 的直接执行。

过去几年，两种类型的Prover（它们共享底层技术）都得到了迅速改进。 2022 年 12 月，Polygon zkEVM 可以在 2.5 分钟内以约 0.30 美元的价格证明 1000 万 gas（使用 Poseidon，并请注意，完整的以太坊区块是 3000 万 gas，这不是可重现的基准）。 在过去一年中，zkVM 一直在追赶。 2024 年 8 月，Succinct SP1（一个 zkVM）能够在约 11 分钟内以约 0.14 美元的价格证明 1000 万 gas（仍然使用 Poseidon）。 最近，Polygon zkEVM 宣布了 type 1 proving，它能够证明使用 Keccak 哈希函数的真实 Ethereum 区块。他们的自述基准报告称，证明一个 10M gas 的区块需要 44 分钟，成本约为 0.23 美元，而证明一个 12M gas 的区块需要 78 分钟，成本约为 0.41 美元。我听说 Keccak 的新的“预编译（precompiles）”可能会显著缩短这些时间（这并非 Polygon 特有的，但底层技术可以加速两种类型的证明器）。

请注意，证明的成本和延迟是同一枚Coin的两面，因为许多用于生成证明的计算都是高度可并行化的，这意味着可以通过投入更多的硬件来权衡成本以换取延迟。

这项技术正在迅速改进，并且期望在未来一两年内性能提高一到两个数量级似乎并非遥不可及。

回到关于延迟的讨论，桥必须应对源链的重组（re-orgs）的可能性。如果桥在发送消息的源链区块达到最终性（此时不再可能发生重组）之前传递消息，则桥是不安全的。否则，消息可能会被传递，但发起消息的交易可能会被重组掉，这将导致安全违规。

解决这个问题的方法，如果不是只使用具有即时最终性的链，就是确保目标链在源链回滚时也回滚（重组），从而确保没有传递未发送的消息。

我们将在 最终性 部分处理这个问题。这是 rollup 互操作性的主要问题之一，因为它们最多有 15 分钟的最终确认时间（Optimism 平均需要 1 分钟才能将区块发布到 Ethereum，尽管有时可能长达半小时，并且 Ethereum 区块在最佳（但通常）情况下需要 14 分钟才能最终确认）。

激励与成本

各种类型的桥有不同类型的参与者，可能需要他们在场才能使桥工作，因此需要激励他们这样做。这些参与者包括中继者（relayers）、验证者（validators）、挑战者（challengers）和证明者（provers）。

我们将首先讨论中继者，因为它们是最常见的参与者，并且一些讨论将推广到其他参与者。然后，我们将讨论动态目标链 gas 费用的问题，这可能导致用户指定的费用不足以支付中继者的成本。然后，我们将讨论其余的参与者。

中继者

中继者是最常见的参与者，几乎每种类型的桥都需要他们，嵌入式桥除外。在某些设计中，可以选择让用户自己中继消息。特别是，对于任何可以实现无需许可中继的桥来说，这是可行的，即验证者桥、轻客户端桥以及 rollup 桥。

在验证者桥中，只需获得验证者的签名即可进行中继。或者，验证者可能只决定中继状态根，在这种情况下，中继的消息必须包含针对状态根的包含证明（任何人都可以生成）。同样的原则适用于 rollup 桥：需要有人中继链的状态根。对于某些像基于 OP-stack 的 rollup，这是无需许可的，而在其他一些 rollup 中，必须是排序器（sequencer）。状态根需要经过验证（通过提交 zk 证明或等待挑战窗口），然后任何人都可以通过针对状态根进行证明来中继消息。

对于执行证明桥，证明者必须发布状态根的证明。这可以是无需许可的，尽管预计用户不会承担这个负担。

对于轻客户端桥，需要有人将所有与共识相关的信息（通常是聚合签名）中继到目标链。这也可以是无需许可的，尽管预计情况并非如此。

然而，通常希望有中继者来减轻用户的中继负担。对于罚没桥和乐观桥，中继者必须绑定，因此用户无法无需许可地承担此角色。

如果中继是许可的，则应注意确保最终传递每条已发送的消息（避免安全违规）。这可能采取挑战的形式，即消息发送者请求中继者在源链上发布一条签名消息，用户然后可以手动中继该消息，否则中继者将被罚没（可能逐渐地，直到发布请求的消息）。

反向桥有点特殊，因为虽然理论上用户可以自己中继消息，但它们的用处通常在于保证消息会自动中继，或者中继者执行一项成本高昂的操作（例如，在目标链上转移代币，以换取在源链上收到代币）。

只要需要中继者，就需要向他们付费，因为他们承担了成本。这些成本的重要部分包括目标链上的交易费用。此外，中继者希望获得一些利润。在下一节中，我们将描述由目标链上交易费用的可变性引起的问题。

处理可变的目标链费用

必须向中继者支付费用。由于目标链上的交易费用波动，因此有必要确保费用足够高，既能支付中继者的费用，又能激励他继续运营（利润）。

起初，似乎更容易在源链上支付中继者的费用。这当然是从用户那里收取费用的最简单（通常也是唯一）方法。但是，这并不能解决将费用支付给实际中继消息并因此产生相关成本的特定中继者的问题。（反向桥是例外，在这种情况下，这种确定很容易。）

实际上，在目标链上支付中继者的费用更容易。这是因为付款可以作为传递消息的交易的一部分被解锁。因此，桥必须确保目标链具有支付中继者的流动性。如果桥专注于代币桥接，则中继交易可能会从桥接的代币中扣除目标链费用。

如果在源链上收取费用并在目标链上支付费用，则需要进行费用估算。这不能在源链上完成，因此必须在链下进行，并包含在任何可能触发发送消息的源链交易中。

如果中继者付款设置得太低，因为目标链费用上涨了，则应该可以在源链上增加费用。应注意避免重放攻击（两次传递同一消息）。

顺便说一句：这种机制也可以兼作重放已传递但失败的消息的方式。如果消息触发的执行只是暂时失败（例如，由于合约状态），或者如果用户设置的 gas 限制太低，则可能会发生这种情况。

实际上，桥运营商有时会收取他们知道在可预见的未来有利可图的固定费用，或者有时甚至在没有明确付款的情况下运营中继者，如果目标链费用较低并且预计会保持如此——收入是在应用层产生的，例如，代币转账的费用。桥协议也可以用他们的协议代币或任何其他类型的链下交易来激励中继者。

也可以使用第三方中继服务，这些服务可以在链上（例如，Chainlink、Gelato、Keep3r）或链下（例如，Gelato）支付。同样，存在可变目标费用的问题，如果费用在源链上支付，第三方中继者通常可以调整费用。

如果中继者集合是无需许可的，那么通常可以安全地运营一个相当中心化的中继者，或者依靠第三方。这还可以协调链下的中继者，以平衡他们之间的竞争环境并确保最低限度的冗余。

但是，如果中继者集合是许可的，那么中继者不应依赖任何中心化实体来执行他们的任务并获得报酬，否则他们可能会停止运营并导致安全违规。

最后，让我们考虑嵌入式桥（即 L1 到 L2 rollup 桥）的特殊情况。不需要中继者，因为 L2 节点会监视 L1 链的更新，并且必须中继在那里发送的 L1 到 L2 消息。但是，这些消息仍然需要产生某种成本，否则 L2 链将使自己受到来自 L1 链的用户的垃圾邮件攻击，他们可以编写一个 L1 合约来免费向 L2 链发送消息。

Optimism 选择燃烧 L1 gas 来支付这些消息的费用，并为 L1 到 L2 消息实施单独的费用市场。因为它这样做，所以它能够确保总是有足够的 gas 至少在 L2 上注册交易，如果其执行失败，用户可以在 L2 上重放它。

Arbitrum 使用“可重试票证（retryable ticket）”系统，用户向 L1 链支付费用，并且如果交易失败，用户可以在一段时间内重试该交易。

这两种方法之间存在一些差异：Optimism 的系统不收取费用，但这使其能够被 Solidity 中不是 payable 的合约函数调用。因为它将失败的消息存储在 L2 存储中，所以节点不需要在 L2 节点中保留可重放交易的索引，并且交易可以永远重放，而 Arbitrum 仅允许重放一周（可能是出于安全考虑）。

验证者、证明者和挑战者

验证者（在验证者桥中）通过运行区块链节点来验证源链的状态而产生费用。可以像激励中继者一样激励他们，尽管情况更容易，因为他们不会产生像交易费用这样高度可变的成本。

证明者（在执行证明桥中）通过生成证明而产生费用——这些证明很昂贵，因为与原始计算相比，它们产生了大约 10,000 倍的开销。

由于成本的原因，最好有一种选择证明者（或者如果需要一些冗余，则选择多个证明者）的方法。这可以通过“首选”证明者之间的链上循环赛来实现。这不需要排除无需许可的证明，以防首选证明者以某种方式未能交付证明。

乐观桥、罚没桥和执行证明桥需要挑战者。挑战者是看门人，他们挑战不正确的消息、状态根或其他挑战。对于罚没桥和故障证明桥，挑战是无需许可的，因为它不会导致活跃性或延迟问题。

我们还没有看到关于 rollup 中挑战激励的太多讨论，但预计许多“自然”节点运营商（交易所、RPC 提供商、区块浏览器）可以承担这个角色。

如前所述，我们不知道任何纯粹的罚没桥部署。

在乐观桥中，需要挑战者来避免在目标链上传递伪造的消息。因此，必须对该角色进行许可，以便挑战者可以在源链上绑定，并且如果他提出无效挑战，则会被罚没。由于有效的挑战会导致中继者被罚没，因此可以从中继者的债券中向挑战者付款。

中继者作弊的可能性仍然很小，这意味着挑战者可能期望永远无法获得利润。通过使中继者和挑战者集合相同，可以巧妙地解决这个问题，这使中继者能够以很少的额外成本验证其他人的中继者行为。此外，桥的安全性符合中继者的利益，因为桥是他们的收入来源。

实施复杂性

我们将很少谈论实施复杂性，因为这非常主观。

让我们重申在查看实施复杂性时需要注意的一些关键领域：

  • 代码库的大小和质量
  • 独立软件组件和参与者的数量
  • 先进技术和算法的使用（特别是密码学）
  • 技术堆栈的成熟度（例如，编译器、库等）

总的来说，简单是关键。更简单的系统更容易推理，并且允许更少的棘手情况。

一个相关的因素是系统是否存在高质量的文档和规范。通常，当这些文档和规范不公开可用时，这不是一个好兆头。

总结

本节简要总结了各种桥类型的属性，尽管重要的是阅读前面的问题以了解细微差别。

关于延迟，这些指示假设没有人愿意承担最终性（重组）风险。否则，延迟可能低至承担风险的一方希望的水平，并且可以根据当前的费用水平负担得起。

我们没有包括对激励讨论的总结，因为我们认为这通常不是桥设计的关键因素，难以总结，并且与活跃性和安全性部分（其中确定了确实需要激励的参与者）重复。

  • 嵌入式桥
    • 安全性：信任最小化 (1)
    • 活跃性：没有额外的假设
    • 延迟：> 源链最终性
    • 复杂性：简单
  • 轻客户端桥
    • 安全性：信任最小化 (1)
    • 活跃性：中继者
    • 延迟：> 源链最终性
    • 复杂性：取决于源链共识
  • 验证者桥
    • 安全性：验证者仲裁是诚实的
    • 活跃性：验证者和中继者
    • 延迟：> 源链最终性
    • 复杂性：简单
  • 罚没桥
    • 安全性：仅在经济上通过单一诚实挑战者假设保证安全，源链活跃性风险
    • 活跃性：中继者（绑定或许可）
    • 延迟：> 源链最终性
    • 复杂性：中等（双向）
  • 乐观桥
    • 安全性：单一诚实挑战者假设
    • 活跃性：中继者（绑定或许可）
    • 延迟：> 源链最终性 + 挑战期
    • 复杂性：中等（双向）
  • 反向桥
    • 安全性：只有无需许可的操作，前向桥必须安全或中继者面临风险
    • 活跃性：中继者
    • 延迟：> 源链最终性
    • 复杂性：中等（双向）
  • Rollup 桥
    • 执行证明桥
      • 安全性：单一诚实挑战者假设
      • 活跃性：中继者
      • 延迟：> 源 rollup 最终性 (2) + 挑战期
      • 复杂性：复杂（故障证明）
    • 故障证明桥
      • 安全性：信任最小化 (1)
      • 活跃性：中继者
      • 延迟：> 源 rollup 最终性 (2)
      • 复杂性：复杂（零知识密码学）

(1) 信任最小化意味着没有比源链和目标链的假设以及实施正确性更安全的其他假设。

(2) Rollup 最终确认时间为：DA 提交延迟 + DA 最终确认 + DA 桥最终确认（当 DA != L1 时）。

最终性

如 延迟 部分末尾所述，桥必须应对源链的重组（re-orgs）的可能性。如果桥在发送消息的源链区块达到最终性之前传递消息，则消息可能会被传递，但发起消息的交易可能会被重组掉，这将导致安全违规。

定义与问题

区块最终性是指链中可以确信是规范链的一部分的区块：重组可能无法在同一高度替换另一个区块。最终确认时间是指区块在生成后达到最终确认所需的时间。

有些链具有即时（也称为“单槽”）最终性。Cosmos 链就是这种情况，它使用 Tendermint 共识算法。工作量证明链没有最终性，或者毋宁说是概率性最终性：在区块之上构建的区块越多，重组该区块的可能性就越小（即成本越高）。

rollup 的最终确认时间是区块发布到其数据可用性 (DA) 层所需的时间 + DA 层达到最终确认所需的时间的总和。

在领先的数据可用性解决方案中，Celestia 具有即时最终确认，区块时间约为 12 秒 (1)，EigenDA 依赖于 Ethereum 最终确认 ([1])，Avail 通常在两个 Avail 区块内最终确认（约 1 分钟 - 1, 2）。

Ethereum 的最终确认时间至少（通常）是生成 2 个 epoch（64 个区块）所需的时间，约为 14 分钟。更准确地说，要求是 epoch 中的第一个区块在两个单独的投票轮次中获得 2/3 的多数票，使其（以及之前 epoch 中的所有区块）最终确认 (1)。在最终确认失败时，可能会继续生成区块！

(1) 请参见 此处 以了解为什么需要两轮投票。

将区块发布到 DA 层的时间因 rollup 堆栈和配置而异。对于乐观 rollup，这纯粹是成本问题：一次提交多个区块可以分摊固定交易成本，以及将多个区块压缩在一起，从而提高压缩率，从而降低数据成本。这也适用于 ZK rollup，尽管它们可能还想等待生成证明，因为这避免了将区块发布到 DA 但由于证明系统中的问题而无法证明的情况。

你可以查阅 L2Beat 活跃性仪表板 以查看各种 rollup 的 30 天平均区块（交易数据）提交时间。

我们关心最终确认，因为中继在非最终确认的区块上提交的消息可能会导致安全违规：如果区块被重组掉，则消息可能会被传递，尽管它从未在规范源链上发送。

等待源链最终确认始终是安全的，但速度可能很慢。使用 Ethereum 作为其 DA 层的 rollup 之间的消息大约需要 15 分钟才能安全中继。

但是，在延迟小于最终确认时间的情况下，有人会承担最终确认风险。在资产桥接协议中，这通常是桥接协议，特别是其流动性提供者。同样，在反向桥中，中继者充当即时流动性提供者，他们承担风险。

这种行为不一定鲁莽 - Ethereum 从未经历过大于 7 个区块的重组（约 1 分 24 秒）。而且，万一发生重组，可以通过重新提交在源链上提交消息的交易来收回一些损失。

但是，对于希望用于任何类型消息的通用消息传递桥来说，这不是一个合理的风险。

除了使用具有快速最终确认的 DA 之外，解决此问题只有另一种方法：如果保证源链和目标链一起重组，那么问题就消失了。

跨链 Contingent 区块 (Cross-Chain Contingent Blocks)

实现此目的的直接方法是在目标链上包含源链区块的区块哈希，并强制如果源链区块未能最终确认，则目标链区块也不得最终确认（回滚）。 我们可以称之为 跨链 Contingent 区块 (2)。

(2) James Prestwich 实际上将其命名为“跨 ORU 区块”（ORU = Optimistic RollUp），但是没有理由不能将相同的原则应用于其他类型的链。

但是，对于共享相同 DA 层的 rollup，我们可以使该机制更通用。与其提交到源链中的区块，不如提交到 DA 层区块。 这样，如果 DA 层重组并使消息从源链中消失，则消息也不会在目标链上传递（因为我们提交到不再存在的 DA 层区块）。

此外，这使得该机制更加通用：目标 rollup 现在可以接受来自使用相同 DA 层的任何源 rollup 的消息，只要桥运营商可以独立验证源 rollup 区块的执行。

这种通用机制今天已经适用 - 例如，OP 堆栈 rollup 在每个 L2 区块中都携带一个 Ethereum 区块哈希。 排序器可以灵活地更新此区块哈希，保证不超过 30 分钟。 但是，在最近抽样的 Optimism 区块上，L1 区块哈希大约有 2 分钟的历史记录，远小于 15 分钟的 Ethereum 最终确认时间。

共享有效性排序（依赖机制）

共享有效性排序 设计中提出了另一种类似的设计，其中不是将源链的整个状态根携带到目标链，而是仅携带已发送消息的 Merkle 根，并且如果此根与源链上最终确认的根不同，则目标链将回滚 (3)。 这种设计的优点是，通过不复制整个区块哈希，它可以与共享排序结合使用，从而实现两个链之间的双向桥接，在相同高度的区块上（参见 原子包含 部分）。 想法是，消息根可以包含在目标链的 区块中，该区块与源链上更新的消息根处于相同高度。

Optimism 采用了一种通用化这种机制的方法，用于其实验性的 互操作性规范。 在那里，不需要转发消息的 Merkle 根，而是由一个故障证明程序负责验证所有与其跨 rollup 消息形成封闭依赖图的区块。

(3) 该机制与跨链 Contingent 区块中的机制相同，但在此处被赋予了一个名称：“共享故障证明”。

局限性和攻击向量

这两种解决方案要求目标链了解源链，因此它们必然是受信的并且范围有限。

请注意，这些解决方案不是完整的桥接机制：它们没有说明源链区块的有效性。 它们仅确保桥不会因最终确认风险而遭受损失，方法是确保如果消息实际上未在源链上发送，则目标链会回滚。

不幸的是，每当目标 rollup 无法验证源区块哈希或状态根时，都会存在一些可能的攻击向量（因此，依赖 DA 区块哈希是可以的！）。 让我们在以下讨论中以验证者桥为例。

最简单的攻击向量是，如果链有任何承担最终确认风险的“快速桥”，则恶意验证者集可能会使用这些桥来双重花费：他们会创建一个无效区块，授权一个不正确的状态根，通过快速桥退出，等待通过共享故障证明发生重组，然后再次花费他们的余额。

一种更复杂的攻击是利用链回滚造成的混乱来重放感兴趣的交易，并从链中提取最大的 MEV。由于除了攻击者之外，没有人真正为这种情况做好准备，他们将在捕获此 MEV 方面具有很大的优势。

这些情景需要大量的技巧，并且在我们的估计中并不是特别有可能发生，但它们表明重组机制不能被视为几乎无关紧要，因为其中存在激励措施。

当然，任何回滚都会对用户造成很大的破坏，用户通常希望预先确认的交易无论如何都要包含在内。

原子性与同步性

一组操作的原子性意味着要么所有操作都发生，要么都不发生。

在跨链消息传递的上下文中，原子性可以应用于交易包含或交易成功执行。

原子交易包含是指多个链的交易同时包含在其各自的链中。 有必要仔细定义“同时”，因为链可能没有相同的区块时间，或者区块生成可能会延迟（区块时间可能与实际区块生成的挂钟时间不对应）。

原子交易执行是指不同链的交易在其各自的链上成功执行。 实际上，这通常也需要同时发生，否则可能会导致不必要的回滚，尽管某些设计建议锁定部分状态以避免这种情况发生，这可以使此要求有些宽松。

我们使用同步性的方式与许多编程语言中使用的方式相同：异步操作被触发，其结果不会立即可用，而同步操作是等待其结果的操作。

基于这些定义，我们可以区分五种原子性模型：

  • 非原子 (异步) 执行 (asynchronous message passing)
  • 原子包含 (Atomic inclusion)
  • 非原子即时异步执行 (非原子同步执行 + 原子包含)
  • 原子异步执行 (Atomic asynchronous execution)
  • 原子同步执行 (又名“通用同步可组合性（universal synchronous composability）”)

请注意，根据定义，非原子同步执行是不可能的，因此我们将其简称为“非原子执行”。

到目前为止，本报告已采用非原子执行，与原子执行模型相比，它受到的约束较少。适用于非原子执行的每个约束也适用于原子执行。

原子包含有点不同，因为它不保证任何交易的成功，而只是保证它们都将被包含在内。 因此，它根本不是一种消息传递模型。

如果将原子包含与非原子执行结合使用，则会得到非原子即时异步执行。 此模型与原子执行模型不同，因为消息传递触发的操作的成功是不保证的。 实际上，消息通常是在目标链上执行操作的指令（例如，购买 NFT），并且不能保证该操作会成功（例如，如果 NFT 已经卖给其他人）。

另一方面，原子执行保证如果目标链上的操作不成功，则源链上的交易也不会被执行。

这种情况的典型例子是，一个交易在源链上交换同质化代币（例如，将 USDC 兑换为 ETH），将交换后的代币桥接到目标链，然后使用桥接的代币在目标链上购买 NFT。 在此示例中，发送到目标链的消息是一个交易，该交易在目标链上转移/铸造第二个代币，并使用它来购买 NFT。 如果无法购买 NFT，我们不希望发生代币交换和桥接。

在原子异步执行中，我们只是发送消息，但无法从另一个链获取数据。 另一方面，在原子同步执行中，我们等待目标链上的消息结果，然后可以使用该结果恢复源链上的执行。 我们实际上是在进行一种函数调用，而不是仅仅触发一条消息。

两种类型的原子执行都可以根据其深度和广度特征进一步区分。 对于深度，消息传递是否会触发发送更多消息？ 这种递归可以进行多远？ 对于广度，单个交易是否可以触发发送多个消息？ 到多个不同的目标链？

对于原子执行，我们的讨论将集中在最简单的情况上 - 原子异步执行，即向单个链发送一条消息且没有递归。 正如我们将看到的那样，这已经足够困难了。 然后，我们将为其他情况添加一些限定条件。

有关原子性如何与区块链工程中的其他主题相关的良好讨论（我们确实没有时间在本报告中进行介绍），我建议阅读 Jon Charbonneau 的 “我们都在构建相同的东西”。

消息传递与捆版 (Bundling)

到目前为止，我们已经从消息传递的角度讨论了桥接：在源链上发送一个交易，该交易向目标链发送一条消息，通常是通过写入源链上的某种收件箱，然后将消息中继到目标链

实现桥接的另一种方法是创建一个原子包，其中包含源链的一个交易和目标链的一个交易，其中所有交易都必须包含或在其各自的链上成功执行。

原子包含需要使用捆版。

原子执行可以使用消息传递或捆版。 消息传递模型功能更强大，因为它可以根据源链的状态动态调整正在发送的消息——执行源链之前不需要知道该消息。

尽管如此，在讨论执行时，我们将使用捆版的概念来简化我们的解释，并在必要时添加限定条件。

原子包含

如上文所述，原子交易包含是指多个链的交易“同时”包含在其各自的链中。

由于原子包含不保证交易的成功执行，因此它不足以实现安全桥接，但可以通过将延迟降低到 0 来加快桥接速度（我们之前称之为“非原子即时执行”）。 它们还可以通过降低 MEV 搜索者的风险来更好地提取跨链 MEV，从而实现例如原子跨链套利。

值得注意的是，就像原子包含不能确保安全桥接一样，它本身也不能消除最终确认风险。 仍然需要专用机制或快速最终确认的 DA 层。

共享排序 (Shared Sequencing)

实现原子包含的主要方法是使用共享排序。 在共享排序中，多个链（通常是 rollup）共享一个公共排序器，该排序器负责对这些链上的交易进行排序。 因为传播和排序交易比区块生成便宜得多（它不需要执行或保持链的状态），所以共享排序可以扩展到大量的链。

现有的共享排序解决方案包括 Astria（使用 Celestia 作为 DA 层）、Espresso（使用其自己的 Tiramisu DA 层）、NodeKit（使用他们自己的自定义 DA 层）和 Radius。

构建者-提议者分离 (PBS)

实现原子包含的另一种可以想到的方法是依赖于 rollup 的提议者-构建者分离 (PBS) 系统。 在这样的系统中，有一组被选为提议区块的提议者，以及一组提议者将构建任务委托给的区块构建者（这通常是为了优化 MEV 提取而完成的）。

有了这样的系统，如果一个提议者被选为在多个 rollup 中构建区块，他可以委托给一个能够执行跨区块原子包含的构建者。

PBS 系统的主要限制是，只有在提议者获得提议多个 rollup 的区块时，或者在构建者被多个提议者为不同链选择时，才可能进行原子包含。 因此，原子包含的可用性无法得到保证。

共享排序也可以采用 PBS 系统 - 虽然这不会为原子包含带来额外的好处，但这样的系统可以用于原子执行。 这不是一个灵丹妙药，正如我们稍后将讨论的那样。 如果选择单个构建者来构建所有区块，请参见 运行多个节点 部分，如果不是，请参见 共享有效性排序 (SVS) + PBS 部分。

声明安全性 (Reclaiming Safety)

在任何一种情况下，原子包含保证都将取决于协议的属性（共享排序或 PBS）。这些通常与链本身的安全属性不同，因此增加了新的安全假设。这些通常是定制的共识（类似于验证者桥或完全成熟的区块链）或经济保证（类似于罚没桥）。

然而，有一种方法可以恢复安全属性，即实现共享有效性排序，如关于最终性的章节所讨论的。这确保了原子包含保证得到尊重，因为不同链中包含原子捆绑交易的区块引用了相同的消息 Merkle 根。如果其中一个区块没有最终确定，那么其他的区块也不会（共享故障证明）。这还为你提供了非原子即时异步执行。

请注意，共享有效性排序不是用交易捆绑来表达的，而是用源链中的交易将消息添加到被 Merkelized 的收件箱来表达的。然而，该设计也可以与捆绑一起使用，它只需要Merkle化捆绑，并确保 Merkle 根包含在源链和目标链上，并且捆绑的交易会针对它进行检查。

然而，共享有效性排序依赖于共享排序系统来真实地传播链之间的消息 Merkle 根，从而使共享排序系统成为一个内嵌的验证器桥 (1)。共享排序器不能破坏安全性（因为有共享故障证明），但它可以暂时使链产生无效区块，这可能会导致我们在限制和攻击向量部分中描述的问题。

(1) 通常，共享排序器只对交易进行排序，因此不会导致任何安全问题，也不会导致区块回滚。通过要求它证明消息（或捆绑）的 Merkle 根，它可能会导致在无效区块被共享故障证明回滚之前执行。

应用于 Superchain (原子包含)

共享排序可以与大型 Superchain 模型一起使用：新的链可以无需许可地选择加入共享排序器基础设施，并且由于不需要执行，共享排序器的可扩展性仅受底层 DA 层的速度限制。

没有共享排序的 PBS 模型也适用，但构建者成为原子包含的看门人。在原子执行部分中，我们将对此进行更多讨论，在该部分中，共享有效性排序与 PBS 的模型耦合甚至更加相关。

原子执行

如上所述，我们考虑原子执行（同步和异步），其中单个消息发送到单个目标链，并且没有递归。

原子执行的主要缺点是，即使在原子异步执行模型中，也需要同步跨链节点通信。

让我们以前面的 swap-bridge-buy-NFT 示例为例（在链 A 上交换代币，桥接它们，使用它们在链 B 上购买 NFT）。你必须确保 NFT 仍然在链 B 上出售，才能在链 A 上提交交换，这需要锁定链 B 上的相关状态。

运行多个节点

最简单的方法是要求链 A 的所有节点也运行链 B 的节点。这不能很好地扩展，因为你没有在多个链之间分配资源。实际上，你的链集与单个链一样受到资源限制。这仍然有一些优点：每个链都可以有意义地进行定制（例如，不同的 gas 代币、执行 VM，...）。

你可以支持分配此系统，即让来自不同 rollup 的节点相互通信。我们认为这不切实际：大量的同步网络通信会给区块生产带来非常大的延迟。然而，这似乎是 Radius 团队在这个演示中实现的内容。

状态锁定

如果我们想要可扩展性，事情会变得更加困难。一种幼稚的解决方案包括锁定两个链上的状态。给定一个要在链上原子执行的交易捆绑，确定它们需要访问的状态 (1)，让两个链锁定该状态（在捆绑解决之前，没有其他交易可以写入它），然后执行交易，如果它们都成功，则提交它们，否则中止并解锁状态。

(1) 这本身不是一个简单的问题，实际上可能需要一种严格的状态访问列表形式。

这不是一个很好的解决方案：它需要在链之间进行多次网络往返（并且可能需要位于中间的某种协调系统）。虽然其他交易可以继续处理，但当状态非常热时，锁定状态仍然可能是一个重要的瓶颈：例如锁定 AMM 池的余额，或 NFT 铸造合约。

有趣的是，这正是 Polygon AggLayer 提出的解决方案。该文档过去提到了提交已知会失败的捆绑的参与者的罚没。但如果这是一个问题，我们还需要考虑大多数交易失败的常见情况，例如 NFT 铸造事件，或者只是高价格波动时期。如果系统仅限于始终有效的交易，则它并不比原子包含更强大。他们还提到了通过锁定大量状态进行恶意攻击，但未能触及锁定有价值状态的问题。

更正： 本文档中对 AggLayer 的讨论基于先前发布的文档。此后，我被告知该设计已更改，AggLayer 将不具有状态锁定功能。在发布时，没有任何文档可以对 AggLayer 进行有意义的讨论。然而，关于 AggLayer 的所有说法都完全适用于状态锁定系统，因此仍然相关。

Chimera chain也是一种使用状态锁定的替代方案。在这种情况下，状态被划分为一个“基本状态分区”和一组“奇美拉状态分区”，这些分区旨在与其他链的奇美拉状态分区组合以创建一个新的“奇美拉链”，在该链上可以对各种奇美拉分区进行跨链交易。

Chimera chain为手头的问题提供了一个更实际的解决方案：智能合约不会假装锁定任何状态是实际的，而是会刻意划分出可以被锁定并且只能由特定的奇美拉链写入的状态（它仍然可以被基本链读取）。虽然这有有趣的用例，但它不允许接触任意状态的完整原子执行——我们桥接代币以购买 NFT 的典型示例不太可能有效，除非某些 NFT 专门保留为仅在特定的奇美拉链上出售。

另一个问题是谁应该负责奇美拉链上的执行。在 Anoma 生态系统的背景下（奇美拉链是在这里提出的），答案是使用参与奇美拉链的各种链的验证者的交集。这可以通过让所有 rollup（即它们的排序器）为它们参与的所有奇美拉链“运行一个节点”并让它们轮换该链的区块提议者来扩展到 rollup。

这必然是一个许可系统，因为排序器不太可能想要与一个未知的 rollup 运行一个奇美拉链，该 rollup 可能会通过向他们的奇美拉链提交大量虚假状态或交易来恶意攻击他们。

Crossbar 系统

另一种选择是在“crossbar 系统”中协同定位原子捆绑的执行，如此处提出的。这可能是 L1 链的一部分，或者是所有参与链都应该遵循的不同链（或 rollup）（即实现嵌入式桥）。该 crossbar 系统将执行原子跨链捆绑的无状态执行。

crossbar 系统接收原子交易捆绑，以及每个交易的状态访问列表，以及针对状态根制作的每个访问状态的状态证明。然后，它输出一组交易，每个参与链必须在其下一个区块的开头包含这些交易。

这里同样没有灵丹妙药，并且需要一个桥接机制供 crossbar 系统接收状态根。一个好的选择是使用在最终性部分中讨论的跨链或有区块系统。请注意，对于 rollup，只有在 DA 层的速度至少与 rollup 区块一样快时，该系统的 DA 介导版本才能在此处应用。或者，我们可以限制跨链交易仅发生在速度较慢的 DA 层的 X 个区块中的一个区块中。

该系统在 rollup 中尤其出色，因为跨链交易可以发布到 DA 并被视为规范链的一部分。这意味着，如果排序器忽略它们，则它从执行进一步交易中获得的状态根将被视为无效并且将无法证明。这类似于 rollup 使用的“强制包含”机制来强制排序器定期包含直接发布到 DA 层的交易（这可以防止排序器集进行总的交易审查）。

该系统仍然具有跨链或有区块的属性，即如果一个已发布的区块哈希无效，则其他链中依赖于该区块哈希的所有区块也必须回滚。由于 crossbar 系统在链之间创建了传递依赖关系，因此这可能意味着使用 crossbar 系统的大部分或所有链都需要回滚。

crossbar 系统的主要缺点是它位于使用它的所有链的执行路径中：要生成一个区块，它们必须等待 crossbar rollup 完成处理，这会降低链吞吐量。

多节点解决方案和 PBS 解决方案（我们将在稍后介绍）具有此问题的较弱版本：每当处理跨链交易时，交易触及的所有链的区块构建都会暂时中断。crossbar rollup 解决方案更糟糕，因为它在处理所有跨链交易时会阻止所有 rollup。

crossbar 系统有助于扩展跨链系统，但并没有从根本上解决这个问题：通过将所有跨链交易的执行委托给单个系统（crossbar 链或 rollup），跨链生态系统能够与其产生的常规交易相比，按跨链交易的相对量成比例地扩展。

例如，在一个具有 10 个 rollup 的系统中，幼稚的解决方案是让每个链的节点运营商运行所有 10 个链的节点。如果每个链上不超过 10% 的交易是跨链的，那么向组合添加一个 crossbar rollup 可以实现相同的结果，但只需要运行感兴趣的 rollup 的节点和 crossbar rollup 的节点。

我们注意到一些状态锁定解决方案也存在这个问题。

共享有效性排序 (SVS) + PBS

最后，我们可以使用共享有效性排序 (SVS)来确保原子执行保证得到尊重。

SVS 将共享排序（在前面的共享排序部分中介绍）与一种绕过最终性延迟的机制（在前面的共享有效性排序（依赖机制）部分中介绍）相结合：通过在源链上 Merkelize 发送的消息，我们可以保证如果目标链包含此 Merkle 根，则会创建对源链的依赖关系，如果源链通过共享故障证明回滚，则会导致目标链回滚。

我们还在原子包含部分中看到，SVS 可以容纳原子包含，因此可以容纳非原子即时异步执行。

我们还可以修改 SVS 以获得原子执行，方法是修改目标链上的合约，以便仅当它们触发的操作成功时，才将消息添加到那里的 Merkle 树中。如果是这种情况，那么只有在跨链交易的双方都成功时，消息 Merkle 根在源链和目标链上才能相似。

然而，创建保证此属性的区块需要实际执行区块。这就是提议者-构建者分离 (PBS) 发挥作用的地方：区块创建拍卖给运行各种链节点的复杂区块构建者。这些构建者只有在可以验证消息传递引起的操作在目标链上成功时，才会发布要在源链上发送的消息。

构建者有动力保持诚实，因为不诚实会导致区块通过分片故障证明回滚，并且他们的利润会损失。添加保证金和罚没条件也可能是可取的，因为构建者可以从限制和攻击向量部分中描述的那种攻击中获利。

SVS + PBS 解决方案的缺点是它不保证原子执行的可用性：构建者需要为他们希望构建跨链原子交易的每个链设置节点。强迫他们这样做意味着确保跨链交易的抗审查性。普通的抗审查性已经是一个难题 (2)，但事物的跨链性质使这更加困难，因为必须证明跨链交易已经成功才能建立审查。

SVS + PBS 创建了中心化，对审查抗性产生影响。在以太坊上，三个构建者生成了以太坊上的大部分区块（因为它们更擅长提取 MEV）。如果在跨链系统中出现类似的情况，那么维护审查抗性（这次不仅针对跨链交易）就成了一个问题，就像在以太坊上一样。

SVS + PBS 的另一个问题是很难验证构建者的工作。特定 rollup 的节点无法轻松验证原子捆绑中的消息是否实际上与在其他链上成功执行的交易相关联。他们必须信任这些远程链的其他节点，或者为 rollup 可以与之交互的所有链运行节点。使用执行的零知识证明是避免此问题的唯一可扩展且无需信任的方式。

(2) 例如，请参阅以太坊包含列表的工作（一、二、三）以了解该任务的一些复杂性。

让我们在这里提到 NodeKit Javelin（文档），它提供了一个跨链构建者实现。目前，NodeKit 没有共享的重组机制，而是选择让构建者发布一个可以在行为不端时被罚没的股份。虽然这种形式的经济安全性不是非常可扩展的，但该项目具有实际实现的优点。有一个想法是将有效性证明添加到系统中，这可以构成共享重组机制的基础。

应用于 Superchain (原子执行)

这些解决方案在大规模 Superchain 模型中都不能很好地工作。

  • 运行所有节点显然是非常许可的，并且仅适用于相对少量的链。
  • 由于参与链存在恶意攻击系统的可能性，因此锁定状态也需要许可。
  • 如果单个链发布无效区块哈希，则 crossbar 系统容易回滚。
  • 在 SVS + PBS 中，构建者充当看门人，并且不保证原子执行的可用性。

实际上，crossbar 系统和 SVS+PBS 系统具有相同的问题，这阻止了它们完全无需许可，因此可以在大型 Superchain 模型中工作：一个新的未知 rollup 可以包含恶意代码，使其能够在某些条件下回滚链，这将导致所有其他 rollup 也回滚。

我们已经在应用于 Superchain（原子包含）部分中讨论了一种可能的解决方案：如果我们能够保证 rollup 不包含任何自定义代码，并且仅在经过审核的一组选项中做出定制选择（以可以在 L1 上验证的方式），那么这些可以更容易地被信任。虽然这是充满希望的，但也很可悲，因为实验是启动新 rollup 的最佳理由之一。

最后，所有高级解决方案理论上都可以通过让一些参与者发布保证金（状态锁定的捆绑提交者，crossbar 系统和 SVS+PBS 的排序器）来实现无需许可，但该保证金必须与潜在的损害相称（状态锁定的活跃度失败，crossbar 系统的回滚）。鉴于所有链都受到影响，保证金必然是巨大的，而较小的链将被排除在外。

所有模型都易于适应小型和图 Superchain 模型。

领域特定解决方案

上面提出的所有解决方案并非没有权衡取舍。但可以想象，通过将自己限制于某些用例（而不是通用消息传递），我们可以实现原子交易而无需付出过高的代价。这些领域特定的解决方案可以带有自己的架构，或者建立在通用原子执行解决方案之上，从而减轻其缺点。

特别是，跨链交易的主要用例是代币（包括同质化代币和 NFT）的桥接和交换。想想我们这里运行的 swap-bridge-buy-NFT 示例。我相信这些交易可以实现原子性，而不会带来太大的不利影响。

我们可以为此概述一个利用同步状态锁定的解决方案，只要只需要锁定目标链。

状态锁定的主要问题是当多个链尝试写入相同的状态时，会出现锁定争用。我们可以通过使用托管合约来缓解此问题，该合约在链 X 上持有我们希望交换链 Y 上某些其他代币的代币。

托管合约的设置方式是，买方的代币在固定的时间内被锁定，并且在此期间，提取代币的唯一方式是托管合约收到来自链 Y 的消息，表明已在那里收到请求的代币。可以在每个链上设置一个标准合约，以使代币余额能够发送到其他链。

当使用这种状态锁定设置（仅需要在一条链上锁定）时，流动性提供者可以使用链 Y 上的有争议状态（例如 AMM 池、NFT 市场）来获取代币，而不会引起锁争用。在链 X 侧，托管合约根本没有争用，因为唯一试图写入它的人是试图满足请求的解算者——无论如何，只有其中一个可能成功。

单方面锁定属性很重要：它使解算者能够使用链 Y 上的有争议状态（例如 AMM 池、NFT 市场）来获取代币，而不会引起锁定争用。在链 X 侧，托管合约根本没有争用，因为唯一试图写入它的人是试图满足请求的解算者——无论如何，只有其中一个可能成功。

有趣的是，原子性在这里保护了解算者。如果我们在没有原子性的情况下使用相同的设置（仅异步消息传递），那么两个解算者都可以满足买方的订单（向他发送链 Y 上的代币），但只有第一个到达链 X 的消息的始发者才会从托管合约中获取代币。

我们的解决方案仍然容易受到通过提交跨链交易来攻击的攻击，这些交易会锁定托管合约但失败，这是一个需要单独解决的问题（例如，通过让用户拥有锁，并通过签名授予使用它们的权限）。

如果 Polygon 的 AggLayer 允许单方面锁定并且可以解决恶意攻击问题，则可以在其上实现此解决方案。

一个似乎实现了与此建议的解决方案非常相似的领域特定项目是 OneBalance，它通过在每个感兴趣的链上为用户部署智能合约钱包来实现跨链转移和交换。它不是使用托管合约，而是使用“资源锁”来锁定用于订单的代币。但是，它没有利用原子性，因此必须依赖额外的安全假设，或者至少依赖经济安全来避免恶意攻击 (1)，这取决于他们所谓的“可信承诺机器”的实现（这尚未完全确定）。

(1) 例如，如果 OneBalance 让解算者通过宣布他们将完成订单来“锁定资源锁”，这可能会在没有经济激励的情况下导致恶意攻击。

更强大的模型

如前所述，我们可以比普通的异步原子执行更进一步。

在原子同步执行中，我们等待目标链上的消息结果，然后在源链上恢复执行。在状态锁定解决方案中，这需要在链之间进行更多往返，从而导致状态锁定时间更长。在 crossbar 解决方案中，这意味着必须提前准备好交易的更多“分支”，这没什么大不了的，但必须小心源链上的单个交易可能开始产生的成本（对源链和目标链都是如此）。SVS+PBS 也可以做到这一点，尽管它再次受到经济激励的保护。

扩展深度（使消息传递能够触发进一步消息的发送，无论是同步还是异步）具有相同的效果。

扩展广度（使单个交易能够触发向相同或不同链发送的多个消息）再次相同，除了如果这些消息并行发送，那么延迟不会为状态锁定解决方案增加，并且为 PBS 构建者启用更多并行化。

消息传递格式和接口

到目前为止，我们的讨论主要停留在高层次上，但现在让我们深入了解链之间消息传递的本质。

格局

必须指出的是，任意消息传递需要在源链和目标链上都有智能合约，有时分别指定为“发件箱”和“收件箱”。为此目的，已经提出了一些标准，按时间顺序列出如下：

除了提议的标准之外，大多数桥、rollup 和其他互操作性项目都有自己的消息传递界面。数量太多无法列出，但让我们提几个有复数化意愿的（即不与任何特定提供商绑定）。此列表不旨在详尽无遗。

让我们还提一下 Optimism 的桥接规范和互操作规范，作为 L1 和 L2 之间以及跨 L2（分别）的消息传递标准示例

最后，一些标准或提议的解决方案专门侧重于桥接代币，例如：

尽管标准和解决方案激增，但没有一个接近成为事实上的标准，甚至没有获得显着的吸引力，也许 xERC20 除外（尽管其成功仍然适中）。我们稍后会更多地谈论它。

设计注意事项

我们可以深入了解每个提案的细节以及它们的比较方式，但我认为这不会明智地利用我们的时间。让我们来看看消息传递接口的一般注意事项、权衡取舍。

如前所述，任意消息传递的接口通常具有与源链上的发件箱和目标链上的收件箱类似的东西。

发布到发件箱的消息需要具有三个通常的交易属性：发送者（自动填充）、目标地址和一些数据（“calldata”）。有多种方式可以存储甚至表示数据：

  1. 它可以简单地按原样发布（或可能压缩）并存储在发件箱中。
  2. 或者，只有数据的哈希可以存储在发件箱中。然后，实际数据可以：
    1. 在事件中发出。
    2. 位于源链 calldata 中。
    3. 根本不发布在链上，而只是与中继者进行链下通信，或由提交者自己中继。它也可以临时存储在替代数据可用性 (DA) 层上。

第一种替代方案消耗了宝贵的区块链存储空间，通常是永久占用的（至少在区块链采用数据过期之前）。

第二种替代方案对智能合约发起的消息传递产生影响，因为只有第一个选项（在事件中发出）可以轻松地通过仅跟踪源链来检索消息。将数据存储在 calldata 中仅适用于由用户直接发起而不是由中间智能合约中介的消息传递（并且检索 calldata 确实需要一些高级节点数据查询——而不是简单的 JSON-RPC 调用）。第三个选项需要存在额外的协调机制。

除了发送者、目标地址和数据之外，还需要指定目标链。有两种主要方法可以做到这一点：要么明确指定链，要么为每个可能的目的地部署单独的发件箱。

在消息中找到的另一个常见字段是 nonce（一个序列号，要么对发送者是唯一的，要么是全局唯一的），这可以防止重放攻击（多次中继同一消息）。

虽然防止重放攻击是可取的，但请注意，这样做的机制不一定需要存在于消息传递接口中：可以通过确保任何重放的消息都会失败来在没有重放保护的通用消息传递标准之上实现它（例如，通过直接在数据中提供 nonce）。这是 Optimism 桥采用的方法，它提供了两个接口层：一个没有 nonce 的低级接口，以及一个构建在其之上的具有重放保护的高级接口。

顺便提一下，从技术上讲，还可以从低级层中省略目标链，这允许将广播消息发送到任何链。辅助层可以启用指定 (a) 特定目的地。必须对这一层进行标准化，否则中继者必须了解特定于应用程序的数据才能知道在哪里中继非广播消息。

一旦消息位于源链的发件箱中，它必须到达目标链的收件箱。许多标准都对消息应如何中继以及应如何证明其真实性有所说明。

我们已经详细讨论了这些主题，包括如何确定消息的真实性、安全性和活跃度特征，以及比源链的最终性更快桥接的风险，以及中继者的角色及其激励。

更有趣的是，一些标准明确地决定避开这些考虑因素，并将消息验证留给实现或外部合约。这尤其适用于 EIP-5164、EIP-6170、Hyperlane 和 xERC20。

虽然这使得事情不那么“标准”（消息将根据源、目的地和收件箱/发件箱部署以不同的方式中继和验证），但它提供了更大的灵活性，这可能有利于它们的采用。

特别是，它似乎对 xERC20 和 Hyperlane 产生了良好的效果。对于 xERC20，对于代币的管理机构来说，能够在不执行代币迁移或复杂的合约升级的情况下使用多个桥接提供商（或更改提供商）是有吸引力的。xERC20 的另一个好处是，它在存在来自多个链的代币桥的情况下，可以实现单一的代币表示，而不是大量的不可替代的包装器。对于新的区块链来说，Hyperlane 具有吸引力，原因大致相同：它允许接收来自许多链的消息，而无需内嵌桥接提供商。

请注意，这些标准并不总是互不兼容的：例如，完全可以拥有一个 xERC20 代币，它授权从 Hyperlane 收件箱或 MMA 接收器进行铸造，而该接收器本身又委托给一个或多个特定于桥的接口。

在对消息验证有所说明的标准中，我们通常可以区分那些想要根据源链的状态根证明消息的真实性，以及那些期望直接中继消息的标准。

有时，根本身不是链的状态根，而是特定于收件箱的“消息根”。还可以批量传递消息，甚至可以将来自多个源链的消息包含在同一批次中。请参阅 EIP-7533，其中规定了这两件事。

代币层

让我们多谈谈代币桥接的特殊性。

除了我们到目前为止谈到的所有内容之外，代币还面临着“路径依赖”形式的额外挑战：每当代币从源链桥接到目标链时，代币通常会被锁定或销毁在源链上，并在目标链上解锁或铸造，这通常被称为“包装代币”合约。

当源链恰好是规范代币表示所在的链时，这种方式效果很好。但是，尝试在其他两个链之间进行桥接会导致相互不可替代的代币包装器激增，其中一些是“包装器的包装器”。

可以通过在每个链上采用单个代币合约，销毁源链上的代币并在目标链上铸造来解决此问题，但是这种方法（大多数桥接提供商不支持）并非没有权衡取舍：现在每个链上的代币合约都容易受到所有允许铸造到其中的桥的安全风险的影响。

xERC20 通过使代币治理能够设置来自任何给定桥的代币流的速率限制来解决此风险。当然，解决“包装器的包装器”问题的经典解决方案是将每个代币通过其规范链路由，尽管此“解决方案”的 UX 非常糟糕。另一个非解决方案是在所有包装器之间引入流动性池。在流动性提供商承担在各个链上重新平衡代币流动性任务的情况下，这可以凑合着工作。

铸造和销毁到单个合约的方法也不支持无需许可的桥部署。这几乎是一个根本性的权衡取舍，但在非常同质的链和桥接环境中，例如我们的小型 Superchain 模型中，可以减轻这种情况：如果已知所有链都具有相似的执行环境，并且任何这些链之间的桥都保证具有相同的安全属性，则可以允许在所有这些链上无需许可地或自动部署镜像代币合约。请注意，这通常在图 Superchain 模型中是不可能的。

结论和建议

本报告涵盖了很多方面：我们建立了一个专注于消息认证机制的桥分类法，并分析了它们的属性（安全性、活跃度、延迟、激励和成本以及实施复杂性）。

我们讨论了链最终性是如何快速且安全的桥接体验的主要障碍，并强调了一个关键属性：要比链最终性更快地桥接，目标链必须在源链重组时进行重组。然后，我们讨论了使这种情况发生的机制（共享有效性排序、跨链或有区块）。

我们已经了解了如何在源链和目标链上紧密耦合执行，其主要目标是原子同步执行（又名通用同步可组合性）。我们回顾了解决该问题的最新解决方案（状态锁定、crossbar 系统、SVS + PBS），并探讨了不太通用的领域特定解决方案的可能性（例如原子代币交换）。 最后，我们讨论了各种消息传递格式及其权衡。

现在，我们为未来提供一些意见、建议和愿望。

桥接机制

毫无疑问，对于跨rollup桥接，执行证明桥接（又名 ZK桥接 或 有效性桥接）是最安全的解决方案 —— 它是唯一适用于rollup的无需信任的解决方案，并且比其他近乎无需信任的解决方案（如故障证明桥接）具有更好的延迟特性。

然而，到目前为止，它们的采用一直受到以下事实的阻碍：与安全性较低的桥相比，生成证明仍然相对昂贵且缓慢。

正如我们在 延迟 部分（其中分解了证明时间和成本）中讨论的那样，该技术一直在快速改进，并且有理由期望它在未来几年内与 DA 层的速度相匹配。

随着证明时间降至几秒而不是几分钟，我们可以期待零知识桥开始蓬勃发展。 在这一点上，专注于其他机制对于雄心勃勃的互操作项目来说似乎是一个错误。 令我们非常懊恼的是，我们的桥接分类注定会成为一部历史纪事。

话虽如此，零知识证明并不能解决互操作性中的所有问题。

延迟

首先，对于使用 Poseidon hash 进行 Merkle 化的链，它们今天的证明时间已经低于大多数 rollup 的最终确定时间。 正如我们所指出的，桥接速度快于源链的最终确定是不安全的。

除了等待以太坊转移到单槽最终确定性（可能需要数年时间）之外，另一种选择是形成一个一起重新组织的 rollup 网络。

我们看到了两种方法：跨链条件区块 (CCCB) 和共享有效性排序 (SVS)。 这些本质上是相同的，唯一的区别是 CCCB 承诺状态根，而 SVS 处理消息根。 沿着相同的方向继续，Optimism 互操作协议甚至不需要超出交易本身包含范围的承诺。

这些解决方案中的任何一个都可以，尽管 CCCB 不允许原子性。 Optimism 的解决方案是唯一一个正在实际实施的解决方案，并且其设计非常周到，特别是对跨链依赖关系图模型的认识以及通过共享故障证明实现共享重新组织的实际机制。 下一步是将共享重新组织机制扩展为也支持 zk/有效性证明。

还有另一种选择，即采用像 Celestia 这样的快速最终确定 DA 层。 这些完全避免了重新组织。 然而，这也不是万能的：DA 层不会给使用它们的链增加安全性风险，但——矛盾的是——当一条链接收来自另一条使用不同 DA 层的链的消息时，它们会增加安全性风险。 如果源链的 DA 层受到威胁并且未实施共享重新组织机制，则目标链将面临桥接安全违规。

快速执行证明也可以在这里提供帮助：如果证明生成时间可以与 DA 区块时间相匹配，那么快速的无需信任的桥接将成为可能。

实施复杂性

执行证明的另一个问题是它们具有所有机制中最高的实施复杂性。 有些人会不同意，并说故障证明也很复杂。 这很公平，但能够审计零知识协议所需的专业知识是一个特别繁重的障碍。

因此，将零知识桥与验证器桥耦合起来可能是一个好主意，既需要有效的证明，也需要法定数量的签名。 这两种类型的桥都很快，并且拥有验证器桥可确保在桥中创建安全违规需要同时危及大多数验证器并利用故障证明中的错误——这是一种不太可能发生的情况。

原子性

当涉及到原子性时，情况就更加不明朗了。

我们甚至需要原子性吗？ 这本身尚不清楚。 大多数被提及的用例本质上都是金融性质的，并且涉及在不将资本置于风险之中的情况下进行复杂的交易（就像在我们正在运行的交换-桥接-购买 NFT 示例中一样）。 “流动性碎片化”通常被认为是原子性是必要的原因，但在我看来，通过快速的非原子消息传递来令人满意地解决这个问题（即使不那么优雅）似乎并非疯狂。 当资本可以安全地以区块生产的速度在链之间移动时，原子性仅仅是锦上添花。

但是，好吧，原子性确实很酷，它可以实现以太坊最初的承诺之一：它为我们提供了世界计算机，一个统一的计算层。 这是一个值得努力实现的目标。 那么，如何实现呢？

我们研究了三种解决方案：状态锁定、交叉杆系统、SVS + PBS。 这些都有权衡。

状态锁定与锁定争用作斗争：如果多个链想要访问相同的状态，则需要大量的同步网络通信，从而增加延迟。 锁定被租借更长的时间会导致希望操纵此状态的操作的活跃度降低。 它们也容易受到恶意攻击者的攻击，这些攻击者会不断请求锁定以获取失败的交易。

交叉杆系统有助于扩展（通过不要求参与者运行每个节点），但由于需要等待交叉杆 rollup 完成其工作，因此降低了所有 rollup 的吞吐量。

SVS + PBS（共享有效性排序 + 提议者构建者分离）(1) 依赖于经济激励的区块构建者的存在来实现原子执行。 这可能效果很好，但使区块构建者成为互操作性的强大看门人，并可能增加一种集中力量，从而对审查抵抗产生影响。

在这个阶段，似乎没有针对通用原子执行的灵丹妙药，我们认为特定领域的解决方案更有可能在不久的将来被采用。 那些可能有他们自己的架构或缓解一般架构中的问题。 特别是，对于跨链代币交换，某种形式的状态锁定可以很好地工作，这一点似乎很清楚。

但是，如果我必须为完全通用的原子执行发布建议，我会选择：

  • 小型超级链模型中的交叉杆系统，以牺牲比 SVS + PBS 略低的吞吐量为代价来避免中心化参与者。
  • 图形或大型超级链模型中的 SVS + PBS，但请注意区块构建者成为链参与的看门人。 交叉杆系统不支持这些模型。

（在另行证明之前，状态锁定作为一种通用方法从根本上存在缺陷，因为存在锁定争用和恶意攻击向量。）

(1) Optimism 的互操作协议可以在这里替代 SVS，因为它能够实现共享重新组织并允许在相同的高度/时间同时执行跨链交易。

总结

在就该主题展开如此多的讨论之后，本报告的结论出乎意料地简单：

  1. 零知识证明实现了无需信任的桥接，并有望在中期成为卓越的桥接形式，因为证明时间和成本进一步降低。

  2. 在任何情况下，最终确定时间仍然是实现快速桥接的一个问题。 采用具有快速最终确定性的通用 DA 层可以缓解此问题。 由于以太坊是大多数 rollup 的事实上的 DA，因此这表明单槽最终确定性是一个优先事项。 在没有快速最终确定 DA 层的情况下，必须使用共享重新组织的机制。 共享有效性排序 和 Optimism 互操作协议 都是解决该问题的良好解决方案。

  3. 每一种已知的原子交易执行解决方案都具有显着的权衡。 然而，特定领域的解决方案，特别是针对代币交换的解决方案，似乎可以在最大限度地减少缺点的同时实现。 我们表明，这可以建立在通用的状态锁定机制之上。 特定领域的架构也可能可行。

至此，我们结束本报告。

如果你读到了这里，非常感谢你的关注！ 你是一个真正的研究高手。

  • 原文链接： github.com/0xFableOrg/xc...
  • 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ，好文好收益，欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
0xFableOrg
0xFableOrg
江湖只有他的大名，没有他的介绍。

0xFableOrg

如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！