前言

自 2020 年底以来，以太坊采用以 Rollup 为中心的扩展策略，以实现更快、更低成本的交易。然而，这一模式也带来了生态碎片化的问题，导致用户和流动性分散在多个 Rollup 之间。这种碎片化影响整个以太坊生态，影响了统一的用户体验。

本文将深入剖析碎片化问题的根源，并重点探讨 Rollup 互操作性所面临的关键挑战——双重提交（equivocation）。同时，我们将对不同的互操作性解决方案进行分类，并分析其权衡取舍，以展望更紧密互联的 Rollup 未来。

碎片化问题

Rollup 生态的碎片化会导致用户体验下降、资金效率降低，以及原生可组合性缺失：

• 用户体验：碎片化迫使用户频繁切换网络、管理多份相同代币，并在多个钱包之间切换，增加了交互摩擦和复杂度。例如，Alice 的资金存放在 Rollup A，但她想要购买仅在 Rollup B 上流通的代币。她无法直接点击“购买”，而是需要先切换网络，将资金从 A 转移到 B，等待 L1 确认后，才能完成交易。
• 流动性问题：当流动性分散在多个 Rollup 之间时，交易对的深度和效率都会降低，导致更差的交易价格、借贷协议收益减少，以及次优的交易执行效果。
• 可组合性受限：在单链环境下，借贷协议可以在同一笔交易中调用 DEX 合约，实现即时清算。而在多 Rollup 生态中，这一过程变得异步化。例如，借贷协议可能需要先在一个 Rollup 上触发清算，再等待消息在另一个 Rollup 的 DEX 进行结算。如果过程中出现任何问题，想要撤销操作并不容易。此外，以太坊并未提供原生工具来支持跨 Rollup 的合约调用，也无法保证这些调用能够快速执行。这种原子性（atomicity）的缺失，削弱了以太坊生态的可组合性优势。

互操作性

互操作性的核心目标是让一笔交易可以在一个 Rollup 上发起，并同步更新另一个 Rollup 的状态，例如将代币从 Rollup A 转移到 Rollup B。理想情况下，该过程应该像 L1 交易一样同步进行，即 A 余额减少的同时，B 余额即时增加。然而，在实际操作中，不同 Rollup 之间实现这种无缝的“全有或全无”（all-or-nothing）交互极具挑战性。

理想情况下，不同 Rollup 之间的交互应当像以太坊 L1 那样同步执行。在同步环境中，来自不同 Rollup 的多个合约调用可以被打包进单个交易，要么全部成功，要么全部失败，从而实现即时且原子的执行结果。

相比之下，异步可组合性则涉及跨多个 Rollup、分阶段完成的交互流程。它并非一个原子交易，而是可能先在某个 Rollup 上触发一个事件，等待确认后，再在另一个 Rollup 上完成后续操作。异步可组合性需要处理回滚问题：某个 Rollup 可能会先行执行某个操作，但如果对应的 Rollup 未能完成其部分，则该操作可能需要回滚，以恢复状态一致性。

同步和异步可组合性在许多方面面临相似的挑战，本文将围绕这些问题展开讨论。
此外，本文重点关注原生的 Rollup 互操作性方案，即需要在协议层进行集成的解决方案。我们不涵盖依赖流动性提供者的外部跨链桥方案，因为这类方案通常仅支持同质化代币的转移。

互操作性的挑战

实现真正的 Rollup 互操作性，不仅仅是传递消息，更关键的是确保交易能安全、快速地最终确认。仅依赖以太坊 L1 进行跨 Rollup 结算，意味着高延迟和高成本。例如，当 Alice 想用 Rollup A 上的资金购买 Rollup B 上的代币时，通常有两种方案：

• Rollup B 仅接受通过以太坊 L1 桥接的资金。在这种情况下，Alice 需要先将资金从 Rollup A 提取到 L1，然后再存入 Rollup B，最后才能进行交易。这一过程不仅耗时，还涉及高额 Gas 费用。
• Rollup B 允许 Alice 直接在 Rollup 之间转账，而无需经过 L1 结算。这虽然更快、更便宜，但也带来了新的风险。例如，如果 Rollup A 发生双重提交，未能最终结算，或提交了无效的状态转换，那么 Rollup B 就可能受到影响，面临重组等安全风险。

当两个 L2 以比以太坊更快的延迟进行交互（即在它们提交或结算状态转换到 L1 之前），rollup 需要应对三个核心问题：双重提交、无效性和未结算。

• 双重提交：一个 rollup 向不同的链广播冲突状态，等于多次提交相同的资产。
• 无效性：某个状态转换可能在 L1 上永远无法被证明为有效。
• 未结算：证明生成或结算过程可能会无限期卡住。

需要强调的是，所有这些问题都可以通过等待 L1 的最终确定性来轻松解决——即状态转换完全在以太坊上结算。然而，我们关注的是如何在比以太坊更快的延迟下实现安全的跨 rollup 交互。因此，我们需要探索在 L1 最终确定性之前的时间窗口内，既能保证安全性，又能提升交互效率的解决方案。

假设 Alice 在 Scroll 主网拥有 10 ETH，并希望将其转移至 Arbitrum。理想情况下，Alice 应该能够以比以太坊更快的延迟，在这两条链之间无缝转移流动性。假设存在某种方案，使得 Arbitrum 可以在 Scroll 向 L1 提交任何数据之前，就先行为 Alice 记账 10 ETH，那么这对 Arbitrum 来说会有哪些潜在风险？

• 双重提交：Scroll 在 L1 提交了一个不同的状态转换，其中并未包含 Alice 的转账交易，这样一来，相当于 Scroll “偷走”了 Arbitrum 先行发放的 10 ETH（Arbitrum 只能通过重组来修正自身状态）。
• 无效性：Scroll 并未进行双重提交，但包含 Alice 交易的状态转换本身是无效的，因此无法在 L1 结算（即无法在 L1 证明其有效性），也就无法将资金交给 Arbitrum。Arbitrum 仍然需要重组以应对这种情况。
• 未结算：Scroll 既未双重提交，且状态转换也是有效的，但负责生成证明的节点下线，导致该状态永远无法在 L1 结算。Arbitrum 再次面临需要重组的问题。

当 Arbitrum 在 Scroll 向 L1 提交之前（在双重提交场景中），或在 Scroll 结算之前（在无效性和未结算场景中）就接受了 Alice 的 10 ETH，意味着它的安全性依赖于 Scroll 的正确性和可用性，从而承担了一定的链间风险。

决定 Rollup 互操作性的一个重要方面是它如何处理双重提交问题。不同的架构对双重提交采取了不同的应对策略。例如，在 OP Superchain 这样的系统中，所有 rollup 被设计为一同进行重组——如果一个 rollup 发生双重提交，所有连接的 rollup 也必须重组其状态，以保持系统的一致性。这种机制被称为跨链联动区块。而其他架构则专注于完全防止双重提交，并采用不同的机制来实现，我们将在下文探讨。

对于未结算和无效性，一旦零知识证明（zk proof） 能够实时生成（即实时证明变得可行），这些问题都可以轻松解决。然而，双重提交则是一个本质上不同的问题。zk 证明可以证明 Alice 在 Arbitrum 上发送了 10 ETH 给 Bob，但 zk 证明 无法保证 Scroll 会在 L1 提交该状态转换。因此，zk 证明本身无法解决双重提交问题，也永远无法解决这一问题。当然，等待 L1 结算可以彻底消除双重提交的风险，但这又牺牲了 rollup 的速度优势。因此，我们的关注点是预结算阶段的双重提交——即在最终提交至以太坊之前，如何提供防双重提交的安全保证。不同的方法涉及不同的权衡，尤其是在信任假设方面，接下来我们将对此展开讨论。

互操作架构

我们探讨了两种不同的互操作性架构，旨在实现比以太坊更快的交互延迟，我们将其称为网状（mesh）和枢纽（hub）模型。

简而言之，网状模型是指 Rollup 之间直接互连，形成一个相互信任的网络，以确保预结算的最终性，同时不发生双重提交。

枢纽模型则引入了一个共享层，所有 Rollup 依赖该层来防止跨链交互中的双重提交，并实现比以太坊更快的交互延迟。接下来，我们探讨这两种模式在实际应用中的区别。

网状模型（Mesh）

网状架构的工作方式符合直觉：各个 Rollup 直接通信，同时仍然负责自身向以太坊 L1 结算。

然而，随着越来越多的 Rollup 相互连接，信任和依赖关系的传递性将成为可扩展性问题。例如，如果 Arbitrum 信任 Scroll，但不信任 zkSync，那么 Scroll 在保持 Arbitrum 信任的同时，也无法信任 zkSync。因此，在网状架构下，只有独立的“信任群体”（即 Rollup 组成的团体）才能相互交互。当 Rollup 数量增加，互操作场景变得更加复杂时，整个系统的安全性最终受制于最薄弱的 Rollup。

尽管网状系统依赖信任来保障预结算安全性，但它们仍然可以在最终结算时检测到双重提交，并触发所有相关 Rollup 的重组。因此，这种互操作模式适用于以下情况：主要参与者是经过验证、安全性较高的 Rollup；这些 Rollup 愿意在系统内部建立信任依赖关系。然而，如果目标是扩展到更多 Rollup、其他 L2，甚至是 L3 和应用链，那么网状模型的扩展性问题将变得不可忽视。

枢纽模型（Hub）

枢纽模型通过引入共享层来弥补网状模型的不足。每个 Rollup 需要信任该层，它作为跨链交互的唯一可信来源，从而使得新增 Rollup 变得更加简单。理所当然，这一共享层必须尽可能安全，以在提供比以太坊更快的交互延迟的同时，确保最大程度的防双重提交能力。

这种方案的优势在于：新增 Rollup 不会带来额外的信任依赖问题，因为互操作层在 Rollup 之间充当“防护盾”。无论是 L2、L3 还是应用 Rollup，只需集成到枢纽，即可享受互操作带来的好处。

然而，该方案的主要权衡点在于：所有 Rollup 共同依赖同一个枢纽层，这使得该层在系统中的权力大幅提升。

特别是在预结算阶段的防双重提交问题上，我们必须确保枢纽不会与恶意 Rollup 串通作恶。因此，与网状模型需要 Rollup 之间的相互信任不同，枢纽模型将这种信任集中到一个共享层，要求其保持独立性，不得与其他 Rollup 共谋进行双重提交。

因此，构建 Hub 时必须以安全性和去中心化为核心考虑因素。关于 Hub 的实现，有几种不同的方案：

• 使用现有的 Rollup：这是最简单的方案，直接基于一个已有、经过实战考验的 Rollup 进行扩展，仅需在其上部署智能合约即可。
• 创建专门的枢纽组件：而非让 Rollup 依赖某个现有 Rollup 的完整安全体系，可以开发一个专门用于互操作的轻量级组件作为枢纽。这种方式的优势在于，组件可以针对跨链需求进行优化，最小化漏洞和攻击面，甚至可以进行形式化验证以提高安全性。
• 直接使用以太坊 L1：该方案直接在 L1 上使用基于 L1 的预确认，利用极致的去中心化和安全性，同时提供近乎即时的交易确认、最小化提款时间等优势。

如果使用 zk 证明，上述三种方式都可以利用证明聚合来降低成本。L1 只需验证一个聚合证明，该证明批量涵盖多个 Rollup 的验证数据，从而显著提升系统效率。

现有系统

多个项目已提出不同的互操作性（interop）解决方案，主要可分为以下几类：

网状系统（Mesh Systems）：OP Superchain 和 Arbitrum 的 Chain-clusters 属于网状系统，其中链与链之间必须共同结算——如果其中一条链发生双重提交，所有连接的链都必须进行重组。这些系统依赖链间信任来实现预结算确认。

然而，由于信任团体难以扩展到多个大型 Rollup，最终可能需要引入某种枢纽机制来实现更高效的预结算终局性。

枢纽系统（Hub Systems）：Espresso 和 zkSync 的 Elastic Chain 采用枢纽系统。Scroll 也在探索基于枢纽的设计，以实现更具可扩展性、去信任化的互操作方案。我们在 2024 年哥伦比亚加密经济学研讨会（Columbia CryptoEconomics Workshop 2024）上分享了该设计的初步概念，并将在后续文章中提供更多细节。

其它系统：L1 的 Rollup（Based Rollups）具备同步可组合性，不仅能与其他 Rollup 无缝交互，还能直接与以太坊 L1 交互，并利用 L1 进行双重提交防护。

Polygon 的 AggLayer 也是一种枢纽系统，它提供一个共享层，使所有 Rollup 通过该层进行通信。然而，它的不同之处在于避免在共享层引入额外的信任假设。AggLayer 依赖最终结算来保障安全性，并采用悲观证明来防止双重提交，意味着其防护机制仅在结算时生效。该系统可以选择性地使用预确认来提供更快的终局性保证。近期，AggLayer 宣布与 Espresso Systems 达成合作，共同提供共享排序机制。

结语

在以太坊之上的跨链互操作设计，需要权衡安全性、去中心化与可信中立性，其中双重提交防护是核心挑战之一。但这并非唯一难点，其他关键问题仍待解决，包括：数据可用性、结算层设计（例如跨 Rollup 共享桥接）、Rollup 智能合约的实现、消息传递协议和经济激励机制，以确保系统的可持续运行。正如 Vitalik 在最近的推文中所说，我们比大多数人想象的更接近解决这些跨链问题。在互操作性的最终形态中，用户将不再感觉自己是在使用各个独立的 Rollup，而是“体验到一个完整的以太坊”。

声明：

1. 本文转载自[Scroll Research]。所有版权归原作者所有[Alejandro Ranchal-Pedrosa]。若对本次转载有异议，请联系 Gate Learn 团队，他们会及时处理。
2. 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
3. Gate Learn 团队将文章翻译成其他语言。除非另有说明，否则禁止复制、分发或抄袭翻译文章。