EIL:信任最小化的跨L2互操作 — Layer 2

以太坊中文 发布于 2025-11-14 阅读 5

EIL(以太坊互操作层)是一种信任最小化的跨L2互操作标准,旨在解决以太坊Rollup带来的用户体验碎片化问题。它基于ERC-4337账户抽象,让用户一次签名即可完成多链交易,无需依赖中继器或求解器。通过引入跨链流动性提供者(XLP)和原子交换机制,实现快速、安全的资产转移,同时利用L1争议解决机制保障资金安全。EIL强调用户完全控制,没有中间状态,在隐私、抗审查和用户体验之间取得了平衡。文章详细介绍了其工作原理、与intents和bridges的区别,以及常见用例。

执行摘要

以太坊的 Rollup 带来了扩展性,但也碎片化了用户体验。如今,每个 L2 都像一个独立的孤岛,有自己的 Gas、桥接,有时甚至有自己的钱包。在这些 L2 之间移动,破坏了以太坊本应提供的无缝、无需信任的用户体验。

为了统一 L2 的用户体验,人们进行了许多尝试,但这些尝试往往妥协了以太坊的核心价值:

  • 抗审查性降低 – 通过中介进行交易。
  • 安全性降低 – 将资金或状态证明委托给第三方。
  • 隐私性降低 – 将用户的 IP 地址和/或意图暴露给第三方。
  • 开源程度降低 – 绝大多数逻辑运行在第三方服务器上,通常对用户不透明。

我们希望拥有单链的体验、以太坊的安全性和抗审查性,同时具备 L2 生态系统的可扩展性、低价格和高速度。本文将介绍 以太坊互操作层 (EIL),这是一个旨在实现上述目标的互操作标准。

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

愿景

用户体验:多链感觉像单链

Arbitrum 的 Alice 想向 Base 的 Bob 发送 0.1 ETH。Alice 将 Bob 的地址粘贴到她的钱包中,发送 0.1 ETH,她的钱包会处理所有事情,Bob 在几秒钟内收到资金。

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

安全与隐私:抗审查,无信任中介

Alice 和 Bob 不应为了 活跃性安全性隐私性 而信任任何第三方。也就是说:

  • 不应存在协议运行所依赖的 “固定”角色
  • 流动性提供者或其他参与者不应能够窃取 Alice 的资金。安全假设应与底层链相同。
  • 流动性提供者或其他参与者甚至不应能够冻结 Alice 的资金,即使是短暂的时间。如果一个流动性提供者在交易中途消失,其他提供者应该能够介入并完成交易。
  • 不应存在 Alice 或 Bob(甚至流动性提供者)需要连接的服务器,以免泄露他们的 IP 地址。他们唯一需要通信的是 L1/L2 的 RPC 节点,以及可能的 p2p mempool
  • 流动性提供者不应提前获知交易细节,以免能够对 Alice 进行三明治攻击或其他利用。

背景

为什么通用的抗审查意图(Intents)很难实现

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

例如:

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

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

对合约或意图类型进行白名单化的协议不是通用的,并且需要为每个新用例付出支持工作。支持新用例所增加的费用可能实际上成为把关。

由于求解器必须在不受信任的合约上执行任意逻辑,完全的抗审查性和通用性在根本上是相互冲突的。

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

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

示例 1:

Arbitrum 的 Alice 想向 Scroll 上的一个有争议的事业捐款。她联系求解器,他们要么拒绝她,要么说好但实际上不执行。他们会记录她的 IP 地址,并将她的真实身份与该事业联系起来。

她可以改为将捐款分为两笔交易:1. 将资金发送到她在 Scroll 的地址;2. 在 Scroll 上进行捐款。在这种情况下,她不会被审查,但她的 IP 仍然与捐款相关联(由于第一步),并且她的用户体验下降——她必须为一次操作签署两笔交易。

示例 2:

Base 的 Bob 想在 Arbitrum 上竞拍一个拍卖品。他不想将自己的 IP 地址与出价关联起来,但也不想因为抢跑安全问题而透露自己的出价意图。

  • 如果他使用链下意图协议和一个信誉良好的求解器,他相对安全,不受抢跑影响,但求解器现在知道了他的 IP。
  • 如果他使用链上意图协议以避免连接求解器,他的 IP 保持隐藏,但牺牲了安全性——他的行为对抢跑者来说是公开的。
  • 如果他将操作拆分为两笔交易,先将资金发送到 Arbitrum,然后签署另一笔实际竞价的交易,他对这两种风险都是安全的,但用户体验下降。

这就呈现出了一个三方困境:{隐私, 安全, 用户体验} —— 三选二

选择(你优化的目标) 示例方法 你失去的
隐私 + 用户体验 链上意图协议(完全公开的 mempool 执行) 失去抢跑安全性——交易在包含前可被观察和利用。
安全 + 用户体验 信誉良好的链下求解器网络(私有匹配和执行) 失去隐私——用户透露意图细节和元数据,如 IP 地址,这些可能将他们的区块链地址和真实身份与中心化或半可信的求解器关联起来。
安全 + 隐私 拆分流程:链上意图仅用于转账,单独发送调用 失去用户体验——高延迟、多次签名和碎片化的用户流程。

结论: 在不引入某些信任假设或用户体验下降的情况下,目前不可能实现完全抗审查、保护隐私、安全且无缝的意图执行。

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

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

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

如果 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 个签名的功能。

钱包如何使用它:

Untitled

ZeroDevBiconomy 实现了类似的验证模块。

代币转账

将代币从链 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 代币的无需许可流动性中心。

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

注册与质押:

Untitled (1)

取消注册与解除质押:

Untitled (2)

质押金的结构和使用在 EIL:内部机制 中讨论。

交易:

  • Alice 想从 Chain_A 交易到 Chain_B。她找到在两条链上都运行的已注册 XLP。
  • Alice 签署一个多链 UserOp。在 Chain_A 上,她在 CrossChainPaymaster 中锁定资金,并请求一个匹配的 Chain_B 凭证,指定一个她愿意使用的 XLP 列表和费用表(详见下文)。该请求是短期的。如果没有及时提供凭证,Alice 的资金将被解锁。
  • XLP 通过提供签名凭证(一个对 Chain_B 的签名承诺)来索取 Alice 在 Chain_A 上的资金。同样的签名凭证在 Chain_A 上索取资金,并在 Chain_B 上释放 XLP 的资金给 Alice——形成一个原子交换。在 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 余额中支付。

Untitled (3)

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

可能出现什么问题,我们如何应对?EIL 定义了一个基于 L1 的无需信任的争议解决机制,确保资金不会丢失或被盗,惩罚违反规则的 XLP,并激励其他 XLP 将任何此类违规行为证明给 L1。请参见 EIL:内部机制 中的攻击与缓解措施部分。

凭证费用结构

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

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

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

  • 时间 T+0:UserOp 仍在 mempool 中。任何列出的 XLP 可以在请求和凭证都被包含到链上后立即提供凭证并获得起始费用。
  • 时间 T+1:如果没有 XLP 在 T+0 提供凭证,请求可能未被满足就进入链上。向提供凭证的 XLP 支付更高的费用。
  • 费用每秒按用户指定的速率增加,直到提供凭证或达到最高费用。
  • 如果请求一直无人认领,它就会过期,资金将退还给用户。

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

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

Mempool 动态

一个同时运行打包器并参与 mempool 的 XLP 可以将 UserOp 与其自己的索取资金的 UserOp 打包在一起,从而在其他 XLP 有机会行动之前赚取费用。凭证请求成为 MEV 的一部分。

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

因此,预计大多数 XLP 将加入 mempool,并在用户提交请求的同一个区块中竞争履行请求。用户受益于单区块跨链交换。

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

在未来,随着 Rollup 从乐观模型转向 ZK 有效性证明,我们预计 L2 最终确认会更快。这将启用快速、无需信任的跨 L2 消息传递以及 L2 状态的高效证明。

当快速的 L2 最终确认可用时,我们将构建另一个 Paymaster,即 CrosschainMessagingPaymaster,它不使用原子交换,并做出不同的权衡。它移除 XLP,并用被动流动性提供者取代它们,类似于 Uniswap 流动性池。

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

流动性提供者将在每条链上赚取费用,并有动力在链间重新平衡资金池。

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

CrosschainMessagingPaymaster 和 CrossChainPaymaster 可能共享相同的接口,因此钱包无需额外工作就能支持两者。默认情况下,它们可能更愿意使用更快、更便宜的 CrossChainPaymaster,但如果某个链存在协议活跃性问题,则可以回退到 CrosschainMessagingPaymaster。

当我们获得原生账户抽象(EIP-7701)时,我们可以改进什么?

目前,该协议对多链操作使用 ERC-4337 账户。作为一个 ERC 而不是以太坊协议的一部分,4337 不可避免地给交易增加了一层。这带来了一些缺点:

  • AA 协议被实现为一个单例合约(EntryPoint),增加了一些 Gas 开销。
  • 4337 mempool 是一个打包器网络,而不是区块构建者网络。打包器随后与区块构建者交互,增加了一层复杂性。

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

EIL 的设计考虑到了 EIP-7701。实现 EIP-7701 的链将受益于具有更高效率和更强抗审查性的 EIL 实现。

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

无缝用户体验

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

抗审查性、安全性、隐私性

  • :white_check_mark: EIL 使用无需许可且具有激励机制的 mempool。一个诚实的节点就足够了。
  • :white_check_mark: 没有信任的中介,由用户直接进行调用,资金原子交换,任何争议都直接通过 L1 解决。
  • :white_check_mark: 注重隐私的用户可以直接发送到 p2p mempool。具有合理否认可信度。
  • :white_check_mark: 提交前的步骤会透露代币数量和 Gas 限制。实际的调用在用户执行之前不会向任何人透露。注重隐私的用户可以选择发送到防止三明治攻击的构建者市场,或使用未来解决相同问题的任何方案。
  • :white_check_mark: 在用户自己的机器上本地运行,开源。跨链流动性提供者只提供 Gas 和流动性,执行最小功能(原子交换),并且完全可在链上验证。

该架构如何支持最常见的用例?

无缝跨链转账

Arbitrum 的 Alice 想向 Base 的 Bob 发送 100 USDC。Alice 将 Bob 的地址粘贴到她的钱包中,发送 100 USDC,她的钱包会处理所有事情,Bob 在几秒钟内收到资金。

Untitled (4)

无缝多链调用

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

Untitled (5)

无缝跨链交换

Arbitrum 的 Alice 想将 USDC 换成 RUT(稀有使用代币)。它在 Arbitrum 上流动性很小,但她在 Taiko 的一个 DEX 中找到了一个好价格。她签署一笔交易,她的钱包会处理所有事情,在 Taiko 上交换,她在几秒钟内收到回到 Arbitrum 的 RUT。

Untitled (6)

EIL 与其他设计的不同之处

EIL 不是意图或桥接

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

类比是给你的车买汽油与买公交车票:

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

对于意图或桥接,存在一个中间状态,第三方本应“带你到那里”,此时你依赖于他们。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 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~

相关文章

0 条评论