设计跨L2互操作性标准：共享资源的影响

L2 生态系统的快速扩张与碎片化

正如在 L2Beat 上观察到的，Layer 2（L2）解决方案正在迅速增长。目前，已经有 126 个 L2 上线或即将上线，而一个月前只有 90 个。L2 的叙事得到了验证，因为越来越多的用户将其活动转移到 L2s 上，以逃避以太坊 L1 上高昂的交易费用，后者很容易超过两位数美元。这种转变导致 L2 生态系统蓬勃发展，一切都似乎在朝着正确的方向发展。

然而，这段“蜜月期”并未持续太久。随着各种 L2 开始竞争 TVL，用户的资产在不同 L2 之间的分布越来越分散，暴露出用户体验（UX）方面的诸多挑战，特别是在跨 L2 交互中。两个核心挑战——资产碎片化 和 状态碎片化 ——已经成为阻止用户充分利用多层网络潜力的重大障碍。这些问题也是过去一年中对以太坊进行 FUD 的主要来源。

资产碎片化相对容易理解。每个 L2 都希望吸引尽可能多的流动性。在 L2 出现之前，所有资产都集中在以太坊 L1 上。随着 L2 的崛起，更多的资产通过 Canonical Bridges 存入或通过第三方流动性桥进行转移。然而，当用户想要通过 Canonical Bridges 将资产从 L2 撤回到 L1 时，体验远非无缝。例如，从 Optimistic Rollups 提款需要等待挑战期，而 ZK Rollups 可能需要延迟提交。这为用户创造了一个“易进难出”的困境。

状态碎片化是一个更为微妙但影响深远的问题。每个 L2 网络都维护着独立的状态，意味着它们的区块链数据（例如账户余额、智能合约状态）无法自然同步或相互交互。这种互操作性的缺乏极大地限制了跨 L2 智能合约的交互。例如，想象一个用户在 Arbitrum 上完成抵押操作，随后想要在 Mantle 上参与一个协议。这两个 L2 无法直接通信其状态。相反，用户需要从 Arbitrum 提取资产到以太坊 L1，然后将其桥接到 Mantle。这个过程不仅成本高昂，还涉及多个步骤。更重要的是，它缺乏实时效率——用户必须等待桥接交易完成，这可能需要几分钟甚至几小时。那么，我们如何解决这种糟糕的用户体验，让整个 L2 生态系统像以太坊 L1 上的智能合约一样无缝通信？

探索 L2 之间的资源共享

从上述设计中可以看出，资源共享 在多链和跨链区块链生态系统中变得越来越重要。我们坚信，任何级别的互操作性从根本上都依赖于共享资源。这些资源由互联链共同维护，作为一座无形的桥梁，成为打破链间隔离的关键。例如，就像当前的桥接器一样，用户需要使用桥接器中的共享流动性来完成链资产的交换，这就是桥接器的共享资源。这种共享机制不仅增强了生态系统的协作，还为跨 L2 系统的增长奠定了坚实的基础。

模块化设计的演进：从分离到协作

模块化区块链近年来已成为区块链设计的重要趋势。其核心思想是 分离结算、数据可用性和执行功能 ，让不同模块专注于特定任务。通过分解和优化单体区块链的功能，模块化设计旨在通过灵活组合创建一个优化的系统。

传统互联网技术的演变为我们提供了许多类似的例子。例如，早期的计算机网络将所有计算、存储和网络功能集中在一台主机上（例如大型机）。随着时间的推移，这演变为分布式系统，将这些功能拆分到独立的节点上。后来，云计算平台的崛起通过共享存储、计算能力和网络带宽等资源，将这些分布式系统重新整合到统一的框架中。这种模块化和协作的演进显著提高了系统效率和灵活性。

同样，模块化区块链的最终目标是通过更高效的模块集成实现最佳解决方案。我们现在正处于这一历史性转变的关键时刻。随着模块化设计的不断成熟，区块链生态系统有望实现更大的可扩展性和协作潜力。

共享资源：跨 L2 协作的无形桥梁

对于所有 L2 而言，当前的碎片化问题可以被视为模块化分离带来的阵痛。所有解决这一问题的尝试本质上都依赖于利用 共享资源。这正是为什么共享资源仍然是实现链间协作的无形桥梁，作为多链生态系统中实现互操作性的关键环节。

现在让我们采用自上而下的系统分析方法，来说明以太坊生态系统中共享资源的各种利用方式及其对链间互操作性的影响。为了让这一点更加具体，我们考虑一个特定的交易场景：用户希望在 Arbitrum 上 销毁 10 USDT，然后在 Mantle 上 铸造 10 USDT。

共享结算

众所周知，所有以太坊 L1 智能合约本质上共享以太坊的全局状态，实现了单体链生态系统内的最高互操作性。然而，由于 gas 和性能限制，我们仍然依赖 L2 来处理以太坊 L1 的执行溢出。为了保持其独立性，L2 仅通过独立的桥接合约共享结算层，这显著降低了 L2 之间的互操作性水平。

链抽象 作为解决碎片化问题最有前途的解决方案之一受到了广泛关注。我们已经看到诸如 Mantle 和 Nomial 的尝试，通过共享链上流动性来消除流动性碎片化。同样，Across 整合了链下流动性以提供平滑的跨链转移用户体验，而 Particle 提出了统一的结算层以实现无缝的互操作。这些设计扩展了共享结算层，为所有连接的 L2 提供共同的安全保障和经济效益。然而，这些解决方案并没有从根本上解决过程的异步性——无论是基于流动性聚合还是桥接机制，链间的互操作仍然是一个 异步 的进程。

但如果将独立的桥接合约替换为通用化的共享资源，让所有 L2 共享流动性，这将为我们带来一个共享的桥梁。例如，当用户在 Arbitrum 上执行销毁交易时，一旦交易提交到以太坊 L1，就不需要等待最终状态。Mantle 可以立即检索到状态转换的 Merkle 证明并执行铸造操作。虽然这个过程仍然是异步的，但它显著减少了等待交易最终化的时间，极大地提高了跨 L2 操作的效率和整体用户体验。

共享排序

如果我们共享更多资源，情况会改变吗？假设我们将 L2 提交的交易进行通用化，并在统一组件中执行跨 L2 交易排序。这种方法可以实现多链交易打包成 tx bundle，并保证被包含在下一个区块中。然而，一个关键问题出现了：原子包含并不保证交易的成功执行。

这意味着即使 Arbitrum 上的销毁交易失败，Mantle 上的铸造交易仍然可以继续。在这种情况下，系统可能会遇到状态不一致的风险，这是极其危险的结果。如果没有确保跨链交易的原子性，这种机制可能会严重损害区块链系统的完整性和可信度。

因此，这种方法并没有从根本上提高互操作性水平。我们仍然需要等待 Arbitrum 上的交易最终化，然后才能执行 Mantle 上的相应交易。这种对交易结果同步的依赖是当前跨链互操作性设计中无法避免的要求，特别是在需要保持状态转换的完整性和一致性的情况下。

共享数据可用性

如果我们进一步扩大共享资源的范围，引入 共享数据可用性（Shared DA），会发生什么？Shared DA 为多个 L2 提供了统一的数据存储和验证基础设施，使所有参与的链共享相同的数据可用性层。这种设计在提高数据可靠性和降低成本方面具有显著优势，特别是在模块化区块链架构中，Shared DA 可以有效减少每条链独立维护数据可用性所需的资源开销。

然而，Shared DA 本身对提高互操作性并没有直接影响。它的主要作用是为其他共享资源（如共享结算层或共享排序）提供更高效的基础设施支持。通过与其他共享资源的协作，Shared DA 可以间接影响互操作性水平。例如，当多个 L2 共享相同的 DA 层时，跨链交易的状态转移（如 Merkle 证明的生成和验证）可以变得更加快速和一致，显著减少跨链交易的延迟。然而，这些改进并没有从根本上改变互操作性的异步性质。

额外的互操作性考虑

在当今的区块链生态系统中，跨多个 L2 网络实现原子执行仍然是互操作性中最紧迫的挑战之一。原子执行 要求跨链操作中的所有交易要么全部成功，要么完全回滚——这是确保去中心化生态系统信任和一致性的关键功能。然而，由于现有的智能合约无法直接触发跨链操作，实现这种级别的协调并非易事。

多链区块构建

社区正在探索各种解决方案。一个很有前景的方向是协作构建，例如 Optimism Superchain 框架。在这个模型中，Superchain 中的每个 L2 排序器独立运行，但通过实时 gossip 与“核心依赖集”中的其他链共享关键交易日志（例如跨链消息）。此外，还有一个共享的时间戳不变性，确保跨链交易可以在区块间传播——这意味着在 Chain A 上发起的交易可以在同一 L2 区块高度内触发 Chain B 上的操作，即使 Chain A 的执行尚未最终化。这种设计消除了目标链等待源链最终化的需求，实现了近乎即时的跨链交互，同时保持了原子性。

另一种创新解决方案通过分离排序器和构建者的角色来提高灵活性。例如，独立排序器可以保留对区块生产的控制权，但将“区块顶部”空间拍卖给专门的超级构建者（如 Nodekit 的 Javelin）。这些超级构建者专注于组装跨链交易包并将其注入到购买的区块中。如果用户想要在 Arbitrum 和 Mantle 之间交换代币，他们只需向超级构建者提交交易意图。超级构建者随后在两条链上购买区块空间，预先模拟交易以确保满足依赖关系，并原子地执行操作。这种设计不仅减少了对单一中心化实体的依赖，还允许超级构建者在异构 L2 生态系统中运行，而无需完全控制排序过程。

多链 STF 组合

除此之外，我们知道单条 Rollups 的状态转换函数（STF）有效性验证相对成熟——无论是通过零知识证明（ZK Proofs）确保状态正确性还是通过欺诈证明挑战潜在错误，每条 Rollup 生态系统都建立了自己的信任机制。然而，当用户需要在多条异构 Rollups 上同时执行交易时（例如在 Mantle 上存入资产并触发 ZKSync 上的借贷），将不同 Rollups 的 STF 逻辑耦合以实现跨链原子性仍然是一个尚未完全解决的挑战。两者之间的结算时间差异可能导致跨链操作陷入死锁。

来源：https://l2beat.com/scaling/finality

对于纯粹在 ZK rollups 之间的交互，由于它们的最终性近乎即时，可以通过额外引入如 Proof Aggregation Layer 来实现 STF 级别的组合。在这个附加层中，可以根据不同 Rollups 使用的证明系统进行分类和后续验证。

对于 Optimistic Rollups 之间的交互，由于它们都需要经过挑战期才能被视为最终化，而不同的 L2 可能具有不同的挑战期——例如 Arbitrum 和 Optimism 各自使用自己的挑战机制——当它们在以太坊 L1 上结算时，它们的 STF 是分别验证的，并且受较长的挑战期的链的约束。如果我们想要优化这一用户体验方面，可能需要引入额外的信任假设（如重新质押）来承担挑战期带来的风险，然后通过回滚或结算费收入等方式对冲这些风险。

最后，最复杂的情况是 ZK 和 Optimistic rollups 之间的 STF 组合，这也将受限于结算较慢的链。此外，由于证明系统的差异，STF 需要被抽象化，引入可以同时容纳两种状态验证的组件，显然以太坊本身是实现这一目标的最佳选择。

多链交易排序最终时间

跨 L2 中的另一个 UX 问题是多链之间交易排序的时间保证。一个常见的方法是让多个 Rollups 共享一个 Sequencer，sequencer 在同一时间窗口内执行跨 L2 交易的“全局打包”。Shared Sequencer 可以让每条链在执行级别感知到跨链交易的排序，但是，要安全地最终确认仍然需要回到以太坊 L1 的数据可用性和最终性（大约 15 分钟），因为多个 L2 仍然需要依赖 L1 进行安全背书。因此，即使引入了 Shared Sequencer，进展仍然要受“最慢链”的结算速度拖累。

为了减少对单一或少数 Sequencer 的信任，可以通过引入绑定机制来增强安全和仲裁能力。为了进一步加速跨 L2 交易的“软确认”，也可以在协议中建立一个 Fast Finality Committee。委员会成员在短时间内对交易提供签名背书，使得交易在几秒到几分钟内就能得到“软确认”。

Vitalik 对跨 L2 标准的看法

来源：https://x.com/VitalikButerin/status/1820412635244081471

针对当前生态系统面临的问题，社区提出了许多 EIPs。幸运的是，Vitalik 分享了他对此的看法，挑选了几个最关键的 EIPs，并建议将它们组合起来以更有效地应对这些挑战。

第一阶段 - 结合现有 EIPs 开发互操作性标准

开发跨 L2 通信标准

所有交易的起点是我们如何识别和区分我们的钱包？众所周知，所有 EVM 网络共享相同的地址格式，这经常导致用户选择错误链时资产丢失。

Vitalik 因网络选择错误在 Polygon 上的资产损失

EIP-3770 通过提出一种标准化的格式来解决这个问题，即向区块链地址添加链标识符。例如，通过在地址前添加前缀 chainID:address，可以清楚地表明地址属于哪条链。例如，ethereum:0x123...456 和 mantle:0x123...456 表示相同私钥在两个不同网络上的地址。这对于多链生态系统至关重要，我们知道 Polkadot 和 Cosmos 也使用相同的私钥，但它们在自己的不同网络中生成不同的地址，其中 Polkadot 将网络前缀作为地址编码的一部分，为不同网络生成唯一的地址，而 Cosmos 采用与 EIP-3770 更类似的方法，直接在地址开头添加网络前缀，例如 cosmos1...。这种方法提高了可读性，并允许直观的链识别。

接下来是 ERC-7683，它是 Ethereum 生态系统中跨链交互的一个重要提议。其目标是标准化跨链意图的创建、传播和执行，提高多链交互的效率，优化流动性的使用，并促进生态系统的互操作性。简而言之，ERC-7683 引入了链间“对话”标准。例如，它允许我声明：“我将从当前 L2 提供资产给任何在另一个 L2 上为我提供足够资金的人。”

ERC-7683 真正迷人的地方不仅在于其对话标准本身，还在于它的灵活性，这为未来解锁了无限的可能性。我们可以从这一概念中提出几个问题：

- 谁为我提供资金？

来源：https://x.com/knwang/status/1818644641312366608

这可能是参与 DeFi 协议的链上流动性提供者，也可能是拥有大量长尾资产的链下做市商和风险投资家（VCs）。这一想法引出了 SolverFi 的概念，甚至有可能演变为 Solver 即服务 的叙事。

- 我们如何验证对方已经提供了我所需的资产？

这个问题引出了通用验证服务的模块化设计叙事。此类服务通常与消息协议结合，为跨链 dApps 提供可定制的验证。例如 LayerZero 的分散式验证器网络（DVNs）和 Hyperlane 的链间安全模块（ISMs）。

我们甚至看到了互操作性的新模块化设计！来源：模块化互操作性协议（0xjim）

通过进一步抽象这些验证服务，我们可以设计一个验证器市场。在这样的抽象市场中，我们可以实现更高程度的互操作性，例如组合多重验证交易并原子地执行它们。这种基于市场的设计不仅增强了验证的灵活性，还为未来复杂的跨链交互提供了关键基础设施。

一种新的轻客户端形式：ERC-3668 的应用

另一个重要的 EIP 是 ERC-3668（也称为 CCIP Read），由 ENS 提出，旨在通过允许智能合约安全访问链下数据来扩展以太坊的功能。该 EIP 引入了一种“中继链下数据”的机制，使智能合约可以从链下获取数据，同时提供链上验证机制以确保数据的可信度。

为什么这被视为一种新的轻客户端形式？

我们都知道传统轻客户端有两个核心特性：访问链下状态 和 验证状态的可信性。轻客户端不需要存储整个区块链的数据，而是通过区块头或证明来验证链下状态。

ERC-3668 与这些功能高度契合。ERC-3668 允许链下服务使用 Merkle 证明或 zkSNARKs 将数据安全地提交到链上合约，合约使用这些证明来验证链下数据的真实性，这与轻客户端的逻辑一致。

来源：https://eips.ethereum.org/EIPS/ERC-3668

因此，ERC-3668 可以被视为轻客户端功能的扩展，使智能合约能够安全地访问链下状态。其架构包括客户端和链上验证合约，以及链下 CCIP Read 网关。在实践中，用户通过客户端发起链下数据请求，合约返回一个包含网关 URL 的 OffchainLookup 错误，以及一个回调函数和参数（extraData）以备将来使用。客户端随后向 URL 发送 HTTP 请求，将链下信息与 extraData 结合，并在回调函数中完成验证。

目前，Linea 和 ENS 已经实现了 ERC-3668，将 ENS 数据存储在 L2 上，同时允许用户在以太坊 L1 上无缝解析这些数据。这种方法在保持数据检索最低信任假设的同时显著降低了成本。Linea 的实现严格遵循 ERC-3668 的原始设计。例如，如果用户拥有域名 abc.linea.eth，L1 dApps 看不到其绑定的地址，但可以通过 ERC-3668 检索。工作流程如下：

来源：https://docs.linea.build/get-started/tooling/cross-chain/ccip-read

1. 用户在以太坊 L1 上发起 ENS 域名解析请求。L1 上的 Resolver 合约调用 Fetcher 合约构建查询。用户随后收到一个包含查询网关 URL 的 OffchainLookup 错误的回退。

2. 客户端向指定网关 URL 发送 HTTP 请求，获取 L2 上 ENS 域的存储槽信息和最新的已一旦这两个 Gadgets 优化到生产就绪水平，通用的 L2 轻客户端将不再是问题。这不仅会增强 L2 的验证能力，还将为更广泛的多链生态系统带来去中心化和改进的用户体验。

证明聚合层的引入

众所周知，如果每个 L2 独立生成并提交自己的 ZKP，那么在 L1 上验证这些证明的成本可能会非常高昂。当需要同时验证多个 L2 状态时，这个问题变得更加显著，因为计算和存储成本会迅速上升。一个自然的优化是使用聚合证明，它将多个 ZKP 压缩为一个单一证明，显著减少了计算和存储方面的验证成本。

来源：https://learnblockchain.cn/article/12167#proof-aggregation-layers

对于像 Optimism Superchain 或 zkSync Elastic Chain 这样的原生 Rollup 集群，为同构链生成聚合证明相对简单。例如，Superchain 可以实现一个共享桥，因为这些框架内的兼容性挑战很少。这些设置不仅简化了链间的互操作性，还通过标准化工具和协议减少了跨 Rollup 操作的复杂性。

对于异构的 L2（使用不同技术栈和证明系统的 L2），聚合过程更具挑战性。一个有效的解决方案是在证明系统层面开始，根据 Rollup 使用的证明系统（例如 Groth16、PLONK 等）对它们进行分类，然后在其上构建进一步的适应和标准化层。通过这样做，即使不同的 L2 采用不同的证明技术，我们也可以在更高层次上实现跨 Rollup 的聚合证明，最终提高整个多链生态系统的效率和互操作性。

L1 主导的铸造和销毁桥

ERC-7683 的初始目的是简化多链之间的“原生资产”跨链交换。然而，对于“桥接/封装资产”，通常需要在一侧执行铸造操作，在另一侧执行销毁（或锁定-解锁）操作。当存在一个独立的多签委员会控制桥接中的资产时，这些铸造/销毁操作的安全性本质上依赖于这个多签设置。因此，为了让“跨 Rollup 资产”真正与 L1 安全绑定，跨链事件的可验证记录和结算需要在 L1 层进行。这就是设计 L1 主导的铸造和销毁桥的动机。

如 ERC-7868 中所述，我们需要引入可验证的跨 Rollup 输入标识符来识别跨 Rollup 交易来源和数据。这些标识符可以通过源 Rollup 提交给 L1 的执行结果（如区块头、状态根）进行加密验证。在此基础上，进行“结算时间验证”，这意味着在结算时同步验证“跨 Rollup 消息或跨 Rollup 链接”。在这里我们可以使用两种不同的结算方法：

来源：https://github.com/polymerdao/ERCs/blob/bo/xrollup-links/assets/erc-XXX/shared_or_chained_settlement.png

• 共享结算： 所有通信的 Rollup 共享同一个 L1 桥，进行同步提交。• 链式结算： 每个 Rollup 提交自己的状态和“待验证的跨链链接”，要求结果在整个 Rollup 系列中相互依赖，以完成整个结算。

这确保了所有跨 L2 操作在“最终结算时间”受到 L1 安全的完全保护。这也避免了传统多签桥的中心化问题。

代号 ETH，北极星也是 ETH

以太坊的 Rollup 中心化策略初步实现了多链生态系统的扩展，将大量用户活动从高成本的 L1 转移到低成本、高吞吐量的 L2。然而，随着 Rollup 数量的持续增长和 L2 生态系统的日益成熟，如何实现 L1 和 L2 之间的合理功能划分已成为下一阶段的核心问题。

我们都希望让以太坊 L1 成为所有 L2 的共享资源，那么以太坊应该承担哪些责任，L2 应该在多大程度上共享它？如上所述，不同程度的依赖共享资源允许 L2 实现不同层次的互操作能力。与此同时，作为共享资源，我们需要保持其简洁性和高度抽象性。目前，以太坊的共识机制和数据可用性服务将为所有 L2 提供统一的信任源。无论是跨链资产转移还是状态同步，以太坊都可以作为最终仲裁者被依赖。此外，以太坊可以充当 L2 Rollup 之间的通信枢纽，通过证明聚合、统一消息协议和跨链桥接技术减少 L2 间的通信延迟和验证成本。这就是以太坊为 L2 生态系统带来的意义——代号是 ETH，北极星也是 ETH。

我们衷心感谢 Bo Du、Tim Robinson 和 Andreas Freund 审阅了本文。

免责声明：2077 研究提供的内容仅供参考，不构成财务、法律或税务建议。所表达的观点是作者的观点，并不一定反映 2077 研究或其附属机构的意见。读者在解释所提供的信息时应自行进行研究并独立判断。

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