执行摘要
以太坊的Rollup带来了可扩展性，却割裂了用户体验。如今，每个L2都像一座孤岛，拥有自己的Gas代币、桥接方式，有时甚至需要专属钱包。在它们之间切换破坏了以太坊本应提供的无缝、无需信任的用户体验。
尽管已有许多尝试统一L2用户体验的方案，但往往牺牲了以太坊的核心价值：
抗审查性降低——交易需通过中介完成；
安全性降低——需信任第三方托管资金或验证状态；
隐私性降低——向第三方暴露用户的IP地址和/或交易意图；
开源透明度降低——大部分逻辑运行在第三方服务器上，对用户不透明。
我们希望实现单一链的用户体验、以太坊级别的安全与抗审查性，同时保留L2生态系统的可扩展性、低廉费用和高速性能。本文将介绍“以太坊互操作层”（Ethereum Interop Layer, EIL）——一个旨在实现上述目标的互操作标准。
以太坊互操作层（EIL）通过让用户仅需一次签名即可完成跨链交易，且不引入任何新的信任假设，使以太坊的多个Rollup感觉如同一条统一的链。EIL基于ERC-4337账户抽象和《无需信任宣言》（Trustless Manifesto）的原则构建，用户直接从自己的钱包发起并结算跨L2操作，而非依赖中继器（relayers）或求解器（solvers）。EIL完整保留了以太坊关于自我托管、抗审查、去中介化以及链上可验证执行等核心保障。这一新型基于账户的互操作层，在以太坊自身的安全模型下，统一了碎片化的L2生态系统。
愿景
用户体验：多链如单链
Arbitrum上的Alice想向Base上的Bob发送0.1 ETH。她只需将Bob的地址粘贴到钱包中，发送0.1 ETH，钱包会自动处理一切细节，Bob几秒内就能收到资金。
我们希望这种简洁的用户体验不仅适用于ETH和ERC20资产的转移，也适用于更复杂的操作（例如跨链调用、跨链兑换）。Alice应能在一个地方使用任意资产支付所有费用，并且每次操作只需签署一次，而不是每条链各签一次。延迟应尽可能低。
安全与隐私：抗审查、无信任中介
Alice和Bob不应依赖任何第三方来保障活性（liveness）、安全性或隐私性。具体而言：
协议运行不应依赖任何“官方指定”的角色；
流动性提供者或其他参与者不得窃取Alice的资金，其安全假设应与底层链一致；
甚至不能冻结Alice的资金（即使短暂也不行）。若某流动性提供者在交易中途退出，其他提供者应能立即接手并完成交易；
Alice或Bob（甚至流动性提供者）不应需要连接任何中心化服务器，以免泄露IP地址。他们唯一需要交互的是L1/L2的RPC节点，可能还包括一个P2P内存池；
流动性提供者不应提前获知足以使其抢先交易（sandwich）或以其他方式剥削Alice的细节信息。
背景
为何通用、抗审查的意图（intents）难以实现？
乍看之下，意图求解器（intent solvers）似乎是实现跨链UX的捷径。然而，开放且去中心化的求解器面临结构性的DoS攻击和恶意干扰（griefing）风险。
例如：
攻击者Sybil可在目标链部署恶意合约，并发送大量使用该合约的意图，导致求解器在链上意外回滚且无法获得报酬。为缓解此问题，求解器不得不采用白名单机制，例如只支持已知代币列表。MEV搜索者就曾遭遇类似情况：最初自动支持所有ERC-20代币，后因“沙门氏菌攻击”（salmonella attack）在数小时内全部转向白名单。
通用意图可能极其复杂，其结果难以验证。攻击者Oscar可运行恶意求解器，以非预期方式履行意图，导致Alice付款却未获得预期结果。例如，求解器可调用目标合约但故意提供不足（但接近足够）的Gas，致使内部调用失败而外部意图仍被标记为成功。虽然每种攻击单独来看容易防御，但要防御所有可能意图的所有潜在攻击却极为困难。协议可能因此限制只支持已知安全的意图类型。
Oscar的求解器还可将一个多链意图拆解，仅在部分链上执行操作。虽然求解器无法获得报酬，但用户却被困在中间状态，而Oscar可能从中获利。为缓解此问题，意图协议可能转而采用求解器白名单。
但凡对求解器或用户进行白名单管理的协议，都不具备抗审查性；
但凡对合约或意图类型进行白名单管理的协议，则不具备通用性，且每新增一种用例都需要额外开发工作。这种摩擦可能演变为事实上的准入门槛。
由于求解器必须在不可信合约上执行任意逻辑，完全的抗审查性与通用性本质上存在冲突。
为何跨链隐私难以实现？——隐私/安全/用户体验三难困境
提交意图通常会提前暴露用户在各链上的预期行为，且往往需要与链下服务交互，从而将用户IP地址与其意图关联，带来隐私风险。
示例1：
Arbitrum上的Alice想向Scroll上一个具争议性的事业捐款。她联系求解器，对方要么拒绝，要么口头答应却不实际执行，同时记录她的IP地址，将其现实身份与该事业关联。
她也可将捐款拆分为两笔交易：(1) 先将资金转至自己在Scroll的地址；(2) 再从Scroll发起捐款。这样虽可避免审查，但步骤(1)仍会暴露IP，且用户体验下降——一次操作需两次签名。
示例2：
Base上的Bob想参与Arbitrum上的一场拍卖。他既不想让IP地址与出价关联，也不想提前暴露出价意图（以防被抢跑）。
若使用链下意图协议和信誉良好的求解器，他相对安全免于抢跑，但求解器会知晓其IP；
若使用链上意图协议以避免连接求解器，则IP保持隐藏，但操作意图公开，易遭抢跑；
若将操作拆分为两笔交易（先转账再出价），则可规避上述两类风险，但用户体验受损。
一个设计良好的跨链协议应致力于解决这一三难困境：
无需与链下服务器交互；
无需提前完整披露意图；
良好用户体验：可靠、低延迟、每次操作仅需一次签名。
这可通过始终将控制权完全交予用户来实现：
只要Alice在每条链上的交易均由她本人直接发起，没有任何中介代其执行，就无人能审查她、干扰她、限制她的使用场景，或侵犯她的隐私。目标达成。
但这引出了若干关键问题：
Alice如何在不信任DApp为其钱包添加未知链、也不信任陌生RPC服务器的前提下，透明地使用一条从未接触过的链？
Alice如何为从未使用过的链支付Gas费用？
Alice如何在不依赖桥接运营商、也不使用昂贵缓慢的官方L1桥接的前提下，在链间转移资产？
她如何仅凭一次签名完成上述所有操作？
原文：https://ethresear.ch/t/eil-trust-minimized-cross-l2-interop/23437
免责声明：本文为c2e Labs的第三方内容，仅供信息分享与传播之目的，不代表我们的立场或观点且不构成任何投资及应用建议。版权归原作者或来源方所有，如内容或素材有所争议请和我们取得联系。
