跨链意图：ERC-8211为何是最佳编码方案

第一部分：什么是意图，以及它为什么是正确的原语

在以太坊的大部分历史中，用户一直用交易的语言与链对话。一条交易表述为：调用这个合约，使用这些调用数据，消耗这么多 Gas，在这条链上，立即执行。这是机器的语言，而不是坐在钱包前的人的语言。

用户真正想要的几乎从来都不是那样的表达。他们想要的是：

• “将 Arbitrum 上的 1,000 USDC 转换成 Base 上的 ETH。”
• “用我持有的任意一种稳定币支付这张发票。”
• “当利率反转时，把我的 Morpho 头寸转移到 Aave。”
• “将发送到这个地址的任何资产转发到我的金库。”

这些就是意图：关于期望最终状态的声明性陈述。用户表达的是应该是什么，而不是如何做——不是桥接、不是 DEX 路由、不是 Gas 代币、不是操作顺序。路径是别人的问题。

为什么意图是好的

意图不仅仅是为了用户体验的便利。从交易到意图的转变具有结构性的优势，这些优势会相互叠加：

将表达与执行解耦。 用户永远不必成为底层机制的专家。意图描述目标；求解器找出路径。就像 SQL 不需要你编写查询计划一样，意图也不需要你编写路由。

一次签名，N 个操作。 一次交易是一个调用。一个意图可以是对整个程序的一次签名——多个步骤、多条链、多个协议，从用户角度看都是原子的。

开放的求解器市场。 因为用户只承诺结果，多个求解器可以竞争来填充同一个意图。用户默认获得最佳执行；求解器在价格、速度和可靠性上竞争，而不是通过锁定专有的订单格式来竞争。

跨链变得可处理。 意图从“我想要链 A 上的 X”过渡到“我想要链 B 上的 X”时，无需强迫用户在三个不同的链钱包中手动配置桥接、批准和 Gas。表达存在于比链标识更高的层次。

条件执行和延时执行。 “仅当……时才执行”和“当……时执行”可以清晰地映射到意图上——它们是对状态的谓词。它们很难映射到交易上，因为交易本质上要么现在执行要么永远不执行。

程序的可组合性。 意图成为独立的对象：可以组装、模拟、签名并作为工件存储。它们是用户签名的程序，而不是用户逐个签名的交易。

目前意图出了什么问题

尽管有这些优点，当前部署的意图模型有三个尖锐的问题：

不透明性。 大多数意图系统交给用户一个需要签名的哈希和一个模糊的“你至少会收到 X”。实际执行什么由求解器以用户无法读取的格式决定。用户信任的是一个黑盒。当黑盒行为异常时，事后分析很困难。

格式锁定。 每个协议都发明了自己的意图格式。为一个求解器网络签名的订单无法被另一个求解器填充。流动性沿着意图格式的线碎片化，切换提供商意味着重新实现集成。

无备用方案。 如果没有求解器愿意填充意图——网络宕机、限速、审查，或者只是对这个交易规模不感兴趣——用户无法单方面采取任何行动。他们向市场签了一个订单，而不是一个他们可以自己运行的程序。

这些都不是意图概念的根本问题。它们是意图被编码方式的结果。这就是 ERC-8211 发挥作用的地方。

第二部分：为什么 ERC-8211 是意图的良好编码

ERC-8211（“智能批处理”）是一个提议的以太坊标准，定义了一种批量执行格式，具有两个不同寻常的特性：参数可以在执行时从链上状态解析，并且单个步骤可以通过链上状态的谓词进行门控。接口很小——只有一个 executeComposable(...) 入口点——并且有意停留在编码层，而不是规定意图如何路由、结算或求解。

这种中立性使其成为意图的干净基础。以下属性源于选择 ERC-8211 作为意图表达的格式。

标准化

一个 8211 意图只是一个 ComposableExecution[]——一个由步骤组成的类型化数组，带有已发布的结构体定义。任何支持该标准的账户、钱包、执行器、中继器都可以读取它、模拟它并运行它。编码没有任何专有性。基于 8211 的意图在求解器网络之间是可移植的，就像 ERC-20 转账在钱包之间可移植一样。

这意味着：

• 求解器竞争是结构性的，而不是合约性的。 新的中继器无需定制集成工作即可进入市场。对于用户和应用程序来说，切换求解器网络的成本大幅降低。
• 工具化会产生复合效应。 为 8211 构建的索引器、模拟器、钱包和浏览器可以用于以它表达的任何意图。花费在工具上的工作不会局限在一个协议中。
• 跨链一致性。 一个跨两条链的 8211 编码意图可以在两端被同一段代码解析。跨链栈中最碎片化的表面（订单格式本身）变得统一。

可见性——每一步都是透明的调用数据

这是与传统意图系统最显著的区别。

在典型的意图流程中，用户签署一个哈希。这个哈希的含义由求解器解释，求解器在填充时组装实际的交换、桥接和批准序列。用户签署了一个结果承诺；执行在发生之前是不透明的。

在 ERC-8211 中，意图就是执行。包中的每一步都是一个类型化的 ComposableExecution，包含函数选择器、输入参数声明和输出捕获。没有隐藏的步骤，没有中继器在填充时添加的内容，没有求解器可以选择的内容。用户签署的是将要运行的文字调用数据。

struct ComposableExecution {
    bytes4 functionSig;
    InputParam[] inputParams;
    OutputParam[] outputParams;
}

这种透明性带来的好处：

• 有意义的签名前模拟。 钱包可以在签名前模拟整个意图，并向用户展示实际的调用序列、余额和结果——而不是一个营销字符串。
• 可审计的事后分析。 如果出现问题，已签名的包就是规范。不需要调查“求解器到底决定做什么”这样的问题。
• 更小的信任面。 用户不信任求解器会遵守订单的精神。订单就是规范，逐字节如此。

运行时获取器不会破坏这个属性——获取器是一个关于如何在执行时读取值的声明（例如，“这个地址的 WETH 余额”），而这个声明本身是普通的、可检查的调用数据。用户精确地看到哪些状态将被查询；只有值是延迟的，而不是问题本身。

自执行——用户永远不会被锁在自己的意图之外

一个 8211 意图是一个 ComposableExecution[]，任何拥有签名的人都可以通过调用 executeComposable(...) 提交它。包括用户自己。

在大多数意图系统中，签名的订单只对特定的求解器网络有意义。如果那个网络拒绝、不可用或正在审查，用户就会被卡住——他们无法单方面执行自己的订单，因为订单不是执行，而是对市场的指令。

在 8211 系统中，同一个包可以以两种模式工作：

• 自执行。 用户自己提交每条链的批次。他们支付 Gas，但保留全部输出（没有中继器费用），并且不依赖任何第三方。
• 中继执行。 用户将签名的包交给中继器，中继器垫付 Gas（通常还有目标链的流动性），提交每条链的批次，并通过意图输入和输出之间的差额获得补偿。

用户在签名时不需要承诺一种模式。两种模式运行完全相同的编码。自执行是内置在格式中的抗审查能力：无论中继器市场变得多么不可靠，意图永远不会停止被直接执行。

这也是为什么 8211 上的中继器市场在结构上更健康。因为包是完全标准化且自包含的，用户的备用选项——“我自己运行它”——是真实的。中继器是在这个底线之上竞争，而不是在空无一物的替代方案之上竞争。

机制中立性

ERC-8211 的谓词观察状态，而不是机制。一个等待桥接资产的目标链步骤不关心是哪个桥接器带来的它；它只是通过余额超过某个阈值来门控：

“约束观察状态，而不是机制。桥接器可以是任何提供者——目标链批次只是等待余额出现。”

对于意图来说，这很重要，因为意图的正确性不依赖于特定的桥接器或求解器管道。同一个意图今天可以通过 Across 填充，明天通过 CCTP 填充，而无需重新签名。用户承诺的是结果；编码忠于用户，而不是场所。

运行时参数吸收现实世界的波动

意图在实践中失败，因为世界在签名和执行之间发生变化。滑点波动，桥接费用浮动，份额价格更新，灰尘累积。静态编码要么过高报价（浪费资金），要么过低报价（导致回滚）。

8211 的运行时获取器（BALANCE、STATIC_CALL）完全绕过了这个问题。一个步骤说“供应我这里所有的 WETH”，无论实际到达了多少 WETH 都能工作。以前批处理标准根本无法表示的模式——发送我的全部余额，转发任何到达的资产，供应交换返回的全部金额——成为了一等公民。

用户以他们实际想要的方式表达意图。编码不会强迫他们对未来撒谎。

谓词门控使条件意图成为原生能力

“仅当 Y 为真时才做 X” 是一个一等构造函数：一个目标为 address(0) 且约束编码了条件的批次条目。没有自定义合约，没有链下条件逻辑，没有单独的流程。

跨链意图很依赖这个。目标链的批次以一个谓词开始，该谓词门控桥接资产的到达。中继器可以通过 eth_call 模拟该门控，并且只在通过时才提交；如果门控从未通过（桥接失败，截止时间到期），则什么都不会运行，链上也不会留下任何残留。条件意图不再是单独的产品类别，而成为了参数选择。

无需为每个意图形状部署新合约

在较旧的意图系统中，每个新的流程形状通常都需要一个自定义的结算器或执行器合约——审计周期、部署、治理，以及一长串几乎相同的合约，每个都持有少量流动性。

一个 8211 意图是数据，而不是代码。新的形状是 SDK 级别的更改：获取器、谓词和调用的新组合。执行器端已经部署并已经过审计。从“我们想支持一种新的意图形状”到“我们正在发布它”的时间压缩了一个数量级。

与任何账户类型兼容

ERC-8211 完全与账户无关。如今，它可以与任何智能账户一起使用，并且完全兼容诸如 ERC-7579、EIP-7702、ERC-6900 等账户标准。作为一个纯粹的编码接口，8211 也已准备好迎接以太坊向原生智能账户的迁移（通过 EIP-8141 帧交易）以及任何未来可能出现的执行标准。

整合起来

一个基于 ERC-8211 的跨链意图在实践中看起来像这样。作者声明式地编写：

const intent = smartBatch([
  // — 源链（Base） —
  swap({ from: WETH, to: USDC, amount: fullBalance() }),
  predicate({ balance: gte(USDC, account, 2500e6) }),
  bridge({ from: base, to: ethereum, token: USDC, amount: fullBalance() }),

  // — 目标链（Ethereum） —
  predicate({ balance: gte(USDC, account, 2490e6) }),
  supply({ protocol: "aave", token: USDC, amount: fullBalance() }),
]);

这会编译成每个链的类型化 ComposableExecution[]，经过 Merkle 根化，并一次性签名。每一步都是透明的调用数据。用户可以自执行，交给单个中继器，或广播到开放的中继器市场——在所有三种情况下包都是相同的。

意图说明了是什么。编码使得如何做变得可读、可执行和标准化。这就是一直缺失的组合。

结语

意图是下一代链上用户体验的正确原语，但编码一直是瓶颈。现有的意图系统往往要么放弃可见性（所以用户信任求解器），要么放弃自执行能力（所以用户被锁定在一个市场），要么放弃可移植性（所以流动性碎片化）——而较大的系统则放弃了所有这三者。

ERC-8211 很小，范围明确，并且并非要成为一个意图标准。这正是它成为一个好标准的原因。它给了意图一直需要的编码：跨执行器标准化、透明到调用数据级、用户需要时可自执行、跨桥接器和场所机制中立、对运行时变化鲁棒、并且与账户抽象栈的其余部分可组合。在上面构建意图，你就可以获得意图模型的好处，而没有迄今为止伴随它而来的结构性妥协。

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