EIL：信任最小化的跨L2互操作标准

执行摘要

以太坊的 Rollups 带来了扩容，但也让用户体验变得碎片化。如今，每个 L2 都像一个孤岛，有自己的 Gas、桥，有时甚至有自己的钱包。在它们之间切换，打破了以太坊本应提供的无缝、无需信任的用户体验。

过去有许多统一 L2 用户体验的尝试，但通常都以牺牲以太坊的核心价值为代价：

• 更弱的抗审查性 —— 通过中间人进行交易。
• 更弱的安全性 —— 将资金或状态证明托付给第三方。
• 更弱的隐私性 —— 向第三方暴露用户的 IP 地址和/或意图。
• 更弱的开源性 —— 大多数逻辑运行在第三方服务器上，对用户而言往往不透明。

我们想要单一链的用户体验、以太坊的安全性和抗审查性，同时拥有 L2 生态的可扩展性、低廉价格和快速体验。本文将讨论 以太坊互操作层（EIL），这是一个旨在实现上述目标的互操作标准。

以太坊互操作层（EIL）通过让用户为跨链交易进行一次签名且不引入新的信任假设，使以太坊的 Rollups 感觉像一条统一的链。基于 ERC-4337 账户抽象和《无需信任宣言》的原则，用户直接从自己的钱包发起并结算跨 L2 操作，而不是通过中继器或求解器。EIL 保留了以太坊关于自我托管、抗审查、去中介化和可验证链上执行的核心保证。这个基于账户的新型互操作层将以太坊碎片化的 L2 生态统一在其自身的安全模型之下。

愿景

用户体验：多链犹如单链

Arbitrum 上的 Alice 想发送 0.1 ETH 给 Base 上的 Bob。Alice 将 Bob 的地址粘贴到钱包中，发送 0.1 ETH，她的钱包搞定一切，Bob 在几秒内收到资金。

我们想要的这种简洁用户体验，不仅适用于转移 ETH 和 ERC20 代币，也适用于更复杂的操作（例如多链调用、跨链交换）。Alice 应该能够在一个地方使用任意资产支付手续费，并且每项操作只需签名一次，而不是每条链签名一次。延迟应尽可能低。

安全与隐私：抗审查，无信任的中间人

Alice 和 Bob 不应为了 活性、安全性 或 隐私性 而信任任何第三方。即：

• 协议不应依赖任何 “既定”角色 来运行。
• 流动性提供者或其他角色不应能够盗取 Alice 的资金。安全假设应与底层链相同。
• 流动性提供者或其他角色甚至不能冻结 Alice 的资金，即使是短暂冻结。如果一个流动性提供者在交易中途消失，其他提供者应能介入并完成交易。
• 不应有 任何服务器 需要 Alice 或 Bob（甚至流动性提供者）去 ping，从而泄露他们的 IP 地址。他们唯一需要通信的是 L1/L2 的 RPC 节点，可能还有一个 p2p 交易内存池。
• 流动性提供者不应提前获知细节，这些细节可能使他们能进行三明治攻击或以其他方式利用 Alice。

背景

为什么通用、抗审查的意图很难实现

乍一看，意图求解器似乎是实现跨链用户体验的捷径。但无需许可且去中心化的求解器面临着结构性的拒绝服务攻击和制造麻烦风险。

例如：

• Sybil 攻击者可以在目标链上部署恶意合约，并发送许多使用这些合约的意图，导致求解器在链上意外回滚而无法获得报酬。求解器将不得不通过白名单合约来缓解。例如，只支持已知代币的封闭列表。这曾在 MEV 搜索者身上发生过：最初他们自动使用所有 ERC-20 代币，然后遇到了 salmonella，几小时内他们就都切换到了白名单。
• 通用意图可能任意复杂，且难以验证其结果。Oscar 可以运行恶意的求解器，以非预期的方式完成意图，导致 Alice 支付了费用却没有得到想要的结果。例如，求解器可以用不足（但边缘）的 Gas 调用所请求的合约，导致内部调用帧回滚，而意图的其余部分却成功。缓解每一次此类攻击很容易，但为所有可能的意图缓解所有可能的攻击却很难。协议可能通过白名单已知安全的意图类型来缓解。
• Oscar 的求解器可以分解一个多链意图，在一条链上执行操作，但在另一条链上不执行。求解器不会获得报酬，但用户会陷入一种进退两难的中间状态，Oscar 可能从中受益。意图协议可能通过白名单求解器来缓解。

对求解器或用户进行白名单的协议不具备抗审查性。

对合约或意图类型进行白名单的协议不是通用的，并且需要为每个新的用例付出额外工作来支持。支持新用例所带来的额外摩擦可能成为事实上的守门行为。

由于求解器必须在不受信任的合约上执行任意逻辑，完全的抗审查性和通用性之间存在着根本性的矛盾。

为什么跨链隐私很难：隐私/安全/用户体验 三难困境

提交意图会提前泄漏用户期望的结果——用户将在每条链上做什么。它还通常需要与链下服务交互，从而将用户的 IP 地址与意图关联起来。这带来了隐私问题。

示例 1：

Arbitrum 上的 Alice 想向 Scroll 上一个有争议的事业捐款。她联系求解器，求解器拒绝了她，或者说同意但实际不执行。他们记录了她的 IP 地址，并将她的真实世界身份与该事业关联起来。

她可以选择将捐款拆分为两笔交易：1. 将资金发送到她自己的 Scroll 地址；2. 在 Scroll 上发送捐款。在这种情况下她不会被审查，但她的 IP 仍然因为步骤 1 而与捐款关联，而且她的用户体验下降——她需要为一个操作签署两笔交易。

示例 2：

Base 上的 Bob 想在 Arbitrum 的一个拍卖中出价。他不想将他的 IP 地址与出价关联，但由于抢跑安全风险，他也不想透露他的出价意图。

• 如果他使用链下意图协议和一个信誉良好的求解器，他相对安全地免受抢跑攻击，但求解器现在知道他的 IP。
• 如果他使用链上意图协议以避免连接到求解器，他的 IP 保持隐藏，但牺牲了安全性——他的操作对抢跑者可见。
• 如果他将该操作拆分为两笔交易——先将资金发送到 Arbitrum，然后再签署另一笔交易进行实际出价——他则可以免受这两种风险，但用户体验下降。

这构成了一个三难困境：{隐私, 安全, 用户体验} —— 三选二

要点： 如果不引入一些信任假设或降低用户体验，目前不可能实现完全抗审查、保护隐私、安全且无缝的意图执行。

一个设计良好的跨链协议应旨在解决这个三难困境：

• 不需要与链下服务器交互。
• 不需要提前透露整个意图。
• 良好的用户体验：可靠性、低延迟、每次操作一次签名。

这可以通过让用户始终处于完全控制之下来解决

如果 Alice 在每条链上发起每一笔交易，而没有中间人代表她进行交易，那么没有人可以审查她、骚扰她、限制她只能使用特定用例，或损害她的隐私。目标达成。

但这需要解决一些问题：

1. Alice 如何透明地使用一条未知链，而不必信任 dApp 已将其添加到她的钱包中，也不必信任未知的 RPC 服务器？
2. Alice 如何为她以前从未使用过的链支付 Gas？
3. Alice 如何在不信任桥运营商或使用昂贵且缓慢的规范 L1 桥的情况下在链之间转移资产？
4. 她如何仅用一次签名完成所有这些操作？

EIL 如何工作

使用 ERC-4337 进行多链调用

假设 Alice 想在 N 条不同的链上执行 N 个操作。到目前为止，最常见的情况是：在链 A 上将资产转移给流动性提供者，然后在链 B 上执行一个操作。但也有其他更复杂的情况。

在 EIL 中，用户使用一个针对多链用例优化了逻辑的 ERC-4337 账户。钱包生成多个不同的 UserOp，然后签署一个基于所有这些 UserOp 的 Merkle 树的单一授权。每条链上账户的验证部分期望：(i) 一个 UserOp，(ii) 一个 Merkle 分支，证明其在某个树中的成员资格，以及 (iii) 一个对树根部的签名。

这样做（而不是让钱包用一个点击为用户签署 N 次）的主要优势是为了支持硬件钱包，硬件钱包通常不支持同时生成 N 个签名的功能。

钱包如何使用它：

ZeroDev 和 Biconomy 实现了类似工作的验证模块。

代币转账

从链 A 到链 B 的代币转账出于两个原因。首先，Alice 通常想在链之间转移代币。其次，如果 Alice 想在链 B 上做某事，但她在链 B 上没有代币，她需要以某种方式支付 Gas 费，这需要从链 A 转移代币过来。

与调用不同，代币转账确实需要 L2 之间的信息流动。目前，我们无法信任地实现快速消息传递，所以次优方案是原子交换。

最广为人知的方法是 HTLC。双方在一条链上的时间锁合约中锁定资金，另一方可以使用合约中哈希的秘密来提取。两个合约使用相同的哈希，因此一旦生成秘密的一方执行了提取，另一方就可以看到秘密并在另一条链上执行提取。如果秘密未在规定时间内揭示，双方均可取回原始存款。资金不会丢失或被盗，但协议效率低下。它需要 1:1 的关系，两条链上的多笔交易，并且可能在一段时间内锁定资金。

我们能做得更好吗？是的！我们拥有典型的 HTLC 实现所没有的工具：我们没有快速、廉价的无需信任消息传递，但我们有通过 L1 的缓慢、昂贵的消息传递。

这使得乐观设计成为可能，消除了对秘密的需求，并将交易次数减少到源链上的 2 次（双方各一次）和目标链上的 0 次。提取不需要专门的交易，而是在用户使用资金的调用中发生。转账可以快至 1 个源链区块 + 1 个目标链区块，在许多当前 Rollup 上只需 2 秒。

它是如何工作的

我们引入了一个 CrossChainPaymaster，它既是一个用于跨链 Gas 支付的 ERC-4337 Paymaster，也是一个用于 ETH 和 ERC-20 代币的无需许可流动性中心。

XLP（跨链流动性提供者） 在多个链上的 CrossChainPaymaster 中注册并存入资金。此外，他们在 L1 上的 L1CrossChainStakeManager 中锁定一笔质押。解除质押的延迟为 8 天——长于最大 L2 最终性时间。如果 XLP 开始 8 天的解除质押过程，它会立即被取消注册。

注册与质押：

取消注册与解除质押：

质押的结构和用途在 EIL：内部原理 中讨论。

交易过程：

• Alice 想从 Chain_A 交易到 Chain_B。她找到同时在两条链上运行的已注册 XLP。
• Alice 签署一个多链 UserOp。在 Chain_A 上，她将资金锁定在 CrossChainPaymaster 中，并请求一个匹配的 Chain_B 凭证（voucher），指定她愿意使用的 XLP 列表和费率表（详见 下文）。该请求是短期的。如果未及时提供凭证，Alice 的资金将被解锁。
• XLP 通过提供签名凭证——对 Chain_B 的签名承诺——来认领 Alice 在 Chain_A 上的资金。同一个签名凭证在 Chain_A 上认领资金，同时在链 B 上向 Alice 释放 XLP 的资金——形成原子交换。Chain_A 上的资金会锁定一小时（以减轻 Rug Pull 尝试——详见下一节），之后记入 XLP 的存款。
• Alice 将 XLP 的凭证附加到她的 Chain_B UserOp 签名中，并提交到 Chain_B。
• Chain_B 上的 CrossChainPaymaster 验证凭证，检查 XLP 是否有足够的存款，支付 Gas 费，并将资金交给 Alice。
• Alice 在 Chain_B 上的调用被执行，她的账户在此调用期间使用这些资金。Gas 从 XLP 在 Chain_B 的余额中支付。

• 这个流程可以继续，并使用相同的签名遍历任意数量的 L2。
• 每次迭代都会转移价值并执行一个或多个调用。
• 如果需要，也可以在 Chain_A 上执行完成调用。
• 调用在所有链上通过一次签名执行。Gas 已在源链上支付。

可能出什么问题？我们如何处理？EIL 定义了一个基于 L1 的无需信任争议机制，确保资金无法丢失或被盗，惩罚违反规则的 XLP，并激励其他 XLP 向 L1 证明任何此类违规行为。参见 EIL：内部原理 中的攻击与缓解部分。

凭证费用结构

凭证请求提供费用以补偿 XLP。每个请求可能包含一种或多种资产，例如用于 Gas 的 ETH、ERC-20 代币。费用以第一种资产计价，无论是 ETH 还是代币。

请求指定多个可以认领它们的 XLP。第一个提供凭证的 XLP 获得费用。这会在 XLP 之间产生竞争。

费用发现使用反向荷兰式拍卖。请求指定一个费用范围和一个每秒增加的费率。

• 时间 T+0：UserOp 仍在内存池中。任何列出的 XLP 可以在请求和凭证都上链后立即提供凭证并获得初始费用。
• 时间 T+1：如果 T+0 时没有 XLP 提供凭证，请求可能未完成就上链。提供凭证的 XLP 将获得更高的费用。
• 费用以用户指定的速率每秒增加，直到提供凭证或达到最大费用。
• 如果请求始终未被认领，则过期，资金返回给用户。

Alice 可以从一个非常低的费用开始，让它增加，直到 XLP 认为足够。然而，为了最小化延迟，她应该从接近当前市场费用开始。如果她提供当前市场费用或更高，她可以期望零延迟完成。当前市场费用可以在链上观察到，因为 Paymaster 会为每个凭证发出事件。

这种机制是对 Gas 费用工作原理的优化。起始费用相当于当前 Gas 价格，可以从链上数据获取。为了避免在价格上涨时签署新交易，指定了一个范围。反向荷兰式拍卖利用 XLP 之间的竞争，确保用户以可能的最低费用进行交易。

内存池动态

同时运行打包器（bundler）并参与内存池的 XLP 可以将 UserOp 与其自己的认领资金的 UserOp 打包在一起，从而在其他 XLP 有机会行动之前赚取费用。凭证请求成为 MEV 的一部分。

在竞争环境中，不这样做的 XLP 通常会晚 1 个区块，很少能赚取费用。

因此，预计大多数 XLP 会加入内存池，并在用户提交请求的同一区块中竞争完成请求。用户受益于 1 区块的跨链交换。

当我们获得无需信任的跨链消息传递时，可以改进什么

未来，我们预计随着 Rollups 从乐观模型转向 ZK 有效性证明，L2 最终性会更快。这可以实现快速的无需信任跨 L2 消息传递和 L2 状态的高效证明。

当快速 L2 最终性可用时，我们将构建另一个 Paymaster——CrosschainMessagingPaymaster——它不使用原子交换，并做出不同的权衡。它移除 XLP，代之以被动流动性提供者，很像 Uniswap 的流动性池。

多链账户将能够在源链上发送资金，并在两条链上的 Paymaster 之间传递消息后，立即使用这些资金在目标链上完成交易。

流动性提供者将在每条链上赚取费用，并被激励在链之间重新平衡池子。

与 CrossChainPaymaster 相比，它提供了更好的活性保证，因为没有一条链上可能没有 XLP 运行的风险，但由于 L1 上的 L2 最终性时间，延迟更高，并且由于跨链消息传递开销，成本略高。

CrosschainMessagingPaymaster 和 CrossChainPaymaster 可以共享相同的接口，因此钱包无需额外工作即可同时支持两者。默认情况下，它们可能更倾向于使用更快、更便宜的 CrossChainPaymaster，但如果某个链上出现协议活性问题，可以回退到 CrosschainMessagingPaymaster。

当我们获得原生账户抽象（EIP-7701）时，可以改进什么

目前，协议使用 ERC-4337 账户进行多链操作。作为 ERC 而非以太坊协议的一部分，4337 不可避免地会在交易之上增加一层。这带来了一些缺点：

• AA 协议被实现为单例合约（EntryPoint），增加了一些 Gas 开销。
• 4337 内存池是一个打包器网络，而非区块构建者网络。打包器随后与区块构建者交互，增加了复杂性。

EIP-7701 引入了协议内灵活的账户抽象。它启用了不同的 AA 模型，包括一个更高效的 ERC-4337 变体，其中 EntryPoint 合约被协议取代，打包器逻辑可以由希望参与 AA 内存池的区块构建者直接实现。

EIL 在设计时考虑了 EIP-7701。实现 EIP-7701 的链将受益于一个效率更高、抗审查性更强的 EIL 实现。

回顾：该机制的一些关键用户体验、安全和隐私属性是什么？

无缝的用户体验

• 多链智能账户和 EIP-7702 委托使得多链交易只需每项操作签名一次，而不是在每条链上分别签名。
• 你可以在任何链上购买任何代币的凭证，并在任何地方使用它们。
• 你可以在一条链上购买 Gas 凭证，并在另一条链上用于支付费用。
• 最小延迟——与底层链一样快。
• 将互操作集成到钱包中。凭证在同一个区块中请求和接收，钱包直接在所有链上交易，无需等待跨链消息。

抗审查、安全、隐私

• EIL 使用无需许可且具有激励的内存池。一个诚实的节点就足够了。
• 无信任的中间人，调用由用户直接发出，资金原子交换，任何争议直接通过 L1 解决。
• 注重隐私的用户可以直接发送到 p2p 内存池。可否认性。
• 交易提交前步骤：揭示代币数量和 Gas 限额。实际调用在用户执行之前不向任何人透露。注重隐私的用户可以选择发送到保护免受三明治攻击的构建者市场，或使用任何未来的解决方案来解决同样的问题。
• 在用户本地机器上运行，开源。跨链流动性提供者仅提供 Gas 和流动性，执行最小功能（原子交换），且完全可在链上验证。

这种架构如何支持最常见的用例？

无缝的跨链转账

Arbitrum 上的 Alice 想发送 100 USDC 给 Base 上的 Bob。Alice 将 Bob 的地址粘贴到钱包中，发送 100 USDC，她的钱包搞定一切，Bob 在几秒内收到资金。

无缝的多链调用

Alice 想在 Linea 上铸造一个 NFT。它花费 1 ETH。她从未使用过 Linea，但在 Arbitrum 上有 0.8 ETH，在 Scroll 上有 0.5 ETH。她点击“铸造”按钮并签署一笔单一交易。她的钱包搞定一切，透明地从 Arbitrum 和 Scroll 转移足够的 ETH，在 Linea 上铸造 NFT，并验证她收到了它。

无缝的跨链交换

Arbitrum 上的 Alice 想将 USDC 换成 RUT（罕见代币）。它在 Arbitrum 上流动性很少，但她在 Taiko 的一个 DEX 中找到了好价格。她签署了一笔单一交易，她的钱包搞定一切，在 Taiko 上进行交换，并在几秒内回到 Arbitrum 收到 RUT。

EIL 与其他设计的区别

EIL 不是意图或桥

EIL 是基于账户的互操作：用户自己的账户直接在每个链上执行每个调用。流动性提供者仅提供 Gas 和资产——他们从不提交交易，也从不看到调用目标。这消除了意图和桥中存在的“中间状态”信任依赖，即第三方求解器/中继器代表用户进行交易。

类比：为你的车买汽油 vs. 购买公交车票：

• 如果购买公交车票，你被绑定在那辆公交车上。
  • 隐私：公交公司知道你去了哪里。
  • 抗审查：如果公交车司机决定开往别处，或在半路停车把你赶下去，你无法到达目的地。存在一个不能换乘的中间状态。
• 如果你为车买汽油然后自己开到目的地，要么这个加油站卖给你汽油，要么另一个加油站卖给你，但无论如何，一旦你拿到汽油，你对加油站的依赖就结束了。
  • 隐私：加油站不知道你要去哪里。
  • 抗审查：一旦他们卖给你汽油，就无法阻止你。没有中间状态，交易是原子的——你付钱，拿到汽油，交易完成。

对于意图或桥，存在一个中间状态，其中第三方应该“把你带到那里”，此时你依赖他们。EIL 没有这个中间状态，因为调用是由用户而不是第三方进行的。

EIL 不是跨链消息传递协议

目前，无需信任的跨链消息传递速度很慢。它依赖于 L1 区块时间以及 L2 最终性速度。为了提高速度，消息传递协议引入了信任假设。第三方需要证明消息的有效性，直到通过 L1 证明/反驳为止。

与 EIL 相比，消息传递协议有不同的优点和缺点：

• 优点：它们可以实现 EIL 无法实现的功能——多个链上的合约之间的可组合性。EIL 是基于账户的，允许账户组合对不同合约的调用，但不尝试实现从一条链上的合约到另一条链的调用。对于这种用例，项目应该在慢速无需信任的消息传递（规范桥）和更快的消息传递协议之间进行选择。存在做出不同权衡的好选择。
• 缺点：消息传递会引入延迟。需要的信任越少，延迟就越高。EIL 不会产生这种延迟，因为调用是从用户到每条链，而不是从一条链到另一条链。

EIL 确实在需要欺诈证明时使用规范桥进行消息传递。正常的用户流程不涉及消息传递。因此，它不能被看作是一个基于消息传递的协议。

未来，当我们拥有 L1 和 L2 的更快最终性，从而支持无需信任的消息传递时，将有可能将 EIL 实现为基于消息传递的协议，并简化协议。然而，目前它并非基于消息传递。

何时使用 / 不使用 EIL？

EIL 支持在多个链上无需信任地执行调用，并为这些调用提供流动性和 Gas。

EIL 适合何时使用？

• 你需要在多个链上无缝执行调用。
• 用户不一定在每个链上都有 Gas 资金。
• 资产分散在多个链上，你希望使用它们而不必承受桥接的摩擦。
• 你宁愿只信任你的钱包，而不增加中间人和信任假设。

何时应该使用其他方案？

• 你的 dApp 只知道高层次上想要实现什么，不知道如何将其转换为合约调用。EIL 不会委托给第三方服务，因此 dApp 必须指定要执行的调用。
  • 意图让你委托给求解器，让它找出调用。缺点是交易逻辑由第三方控制，抗审查性降低。
• 你的操作涉及链下的交易对手，而不仅仅是智能合约。例如，基于链下订单簿的交换。EIL 是一个链上协议。它可以跨链转移资产，但依赖 DEX 来将一个代币交换为另一个。
  • 如果交易需要协调链下各方，意图更合适。它带来上述缺点，加上信息不对称风险。
• 一条链上的合约需要调用另一条链上的合约，而不信任用户。
  • EIL 允许用户在多个链上交易，但如果合约需要直接相互调用，那么你需要一个跨链消息传递协议。缺点是延迟高（规范桥——乐观 Rollup 需要 7 天），或者信任链下预言机来证明跨链消息。

如果我是一个……，如何使用 EIL？

钱包开发者

• 支持带有扩展的 ERC-5792（wallet_sendCalls）以支持多链操作，或使用 EIL SDK。
  • 智能账户：使用我们提供的多链账户模块，或基于 ERC（工作进行中）自行构建。
  • EOA 钱包：使用我们提供的多链 7702 实现，或实现 ERC（工作进行中）。
  • 使用 CrossChainPaymaster 进行跨链 Gas 支付和代币转账。

dApp 开发者

• 默认情况下，使用 ERC-5792（wallet_sendCalls）进行多链操作，或使用 EIL SDK。
  • 仅当钱包不支持时才回退到桥。

用户

• 选择支持 EIL 的钱包。
• 像在单个链上一样进行交易，无需切换网络或桥接资金。

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