意图架构与求解器：从交易到意图的范式转移

意图（Intent）正在重塑链上交易的表达方式：用户不再逐笔构造「怎么做」的交易，而是签名一份「想要什么结果」的声明，把路径搜索、gas 竞价、跨链桥接与失败重试全部外包给专业求解器（Solver）网络。这一转向把链上交互从命令式（imperative）推向声明式（declarative），也让订单流（orderflow）本身成为一种可竞价的资产。

本文系统拆解意图架构：从意图的表达与求解空间，到求解器竞价拍卖、ERC-7683 跨链标准、与 ERC-4337 账户抽象的关系，再到激励博弈、失败模式与安全信任假设，最后给出工程接入建议。

前置：/blockchain-account-abstraction-userop/（理解 UserOperation 与 EntryPoint 是读懂意图执行层的前提），/blockchain-mev-pbs/（意图拍卖与区块构建市场共享同一套订单流经济学）。

目录

• 1. 从交易到意图：范式转移
• 2. 意图的表达：声明式约束与求解空间
• 3. 求解器的竞争与拍卖机制
• 4. 订单流、MEV 与意图的关系
• 5. ERC-7683：跨链意图标准
• 6. 与账户抽象（ERC-4337）的关系
• 7. 主流意图基础设施对比
• 8. 求解器激励、结算与失败模式
• 9. 安全与信任假设：托管、抢跑与审查
• 10. 工程实践与接入建议
• 延伸阅读

1. 从交易到意图：范式转移

1.1 命令式交易的三重负担

传统交易（Transaction）是命令式的：用户必须自己回答「走哪条路由、分几笔、gas 出多少、滑点容忍多少」四个问题。这带来三重负担：

• 路径负担：在 Uniswap V3、Curve、Balancer 之间比价，还要考虑多跳拆单与手续费层级。
• 时机负担：决定 gas price，权衡确认延迟与被三明治攻击的风险。
• 失败负担：交易 revert 后 gas 照扣，跨链场景还要处理源链已扣、目标链未到账的中间态。

本质上，用户被迫扮演了一个不合格的做市商与路由算法。

1.2 声明式意图的四个转变

意图把「如何做」换成「要什么」，四个维度发生根本变化。

竞争维度从「谁付更多 gas」变为「谁给出更好的成交结果」，这是意图范式的经济学核心。

2. 意图的表达：声明式约束与求解空间

2.1 约束的三要素

任何可执行的意图都可归结为三要素：输入资产（input）、输出约束（output constraints）、时效与权限（deadline / authority）。用 Solidity 表达大致如下。

// 意图约束的最小表达（非标准，示意用）
struct IntentConstraints {
    address inputToken;        // 用户愿意付出的资产
    uint256 inputAmount;       // 付出的确切数量
    address outputToken;       // 期望获得的资产
    uint256 minOutputAmount;   // 硬约束：低于此值求解器不得成交
    uint32  deadline;          // 硬约束：超时即失效
    address recipient;         // 结果接收方，可与签名者不同
    bool    partialFillAllowed;// 是否允许部分成交
}

硬约束（minOutputAmount、deadline）是求解器不可逾越的红线，软偏好（如「优先走某个池子」）则留给求解器优化。

2.2 求解空间与不可行判定

求解器面对的是一个带约束的组合优化问题：在给定区块状态与预期状态变化下，寻找一组交易使所有意图的约束同时满足且自身利润为正。难点在于：

• 状态耦合：A 的意图成交会改变池子价格，进而影响 B 的意图是否可行。
• 搜索爆炸：n 个意图、m 个流动性池的组合路由空间随规模指数增长。
• 不可行判定：当 minOutputAmount 高于市场最优价时，意图永远无法成交，需要有显式的失效信号而非静默悬挂。

CoW Protocol 的解法是把「多意图合并」变成批量拍卖：把方向相反的两笔意图直接撮合（Coincidence of Wants），省掉 AMM 手续费与滑点。

3. 求解器的竞争与拍卖机制

3.1 批量拍卖与统一清算价

CoW Protocol 采用批量拍卖（batch auction）：每个区块周期内，所有意图收集为一批，求解器提交各自的成交方案（包含每笔意图的执行价格），协议选出总剩余（surplus）最大者执行。

批量拍卖流程：
1. 用户签名 Intent → 进入订单簿（off-chain）
2. 求解器拉取批次 → 本地求解最优路由
3. 求解器提交 solution（含价格向量）→ 链上竞价
4. 协议选出 surplus 最大解 → 结算合约执行
5. 用户获得 >= minOutputAmount，多余部分按规则返还

统一清算价（uniform clearing price）意味着同一批次内相同资产对的所有用户拿到相同价格，这天然消除了批内抢跑。

3.2 荷兰拍与封闭竞价

UniswapX 与 1inch Fusion 走的是**荷兰拍（Dutch auction）**路线：订单以高价起拍，随时间线性降价，做市商（filler）在任意时刻选择接受。

• UniswapX：filler 需通过 UniswapX 的 fill 接口执行，源链签名、目标链（或同链）填充，填充者获得衰减中的溢价。
• 1inch Fusion：引入「拍卖解析器（resolver）」角色，用户可设置拍卖时长与起始价，解析器承担 gas 成本并获取价差。
• 封闭竞价：部分协议采用 sealed-bid，提交期看不到他人报价，降低竞价战中的 gas 军备竞赛。

两种机制的共同点：用时间换价格发现，让专业做市方为订单流定价。

4. 订单流、MEV 与意图的关系

4.1 意图如何抑制三明治

三明治攻击依赖攻击者能在内存池中看见受害者的具体交易并预测其价格影响。意图模式下：

• 用户交易不直接进入公共内存池，而是签名后交给求解器。
• 成交价格由批量清算决定，攻击者无法通过前后夹单改变批内价格。
• 求解器若作恶夹单，会在竞价中输给诚实求解器（因为夹单降低 surplus）。

因此意图被广泛宣传为「抗 MEV 的用户体验层」。

4.2 意图拍卖中的新型 MEV

但 MEV 并未消失，只是转移了形态：

• 求解器间 MEV：求解器可观察他人已提交的方案做延迟套利（类似 PBS 中的 builder 竞争）。
• 跨域 MEV：跨链意图在源链锁仓、目标链填充之间存在时间窗，套利者可利用两条链的价格差。
• 优先级操纵：若求解器同时是区块构建者，可优先打包自己的解。

结论：意图把 MEV 从「用户被夹」转化为「求解器与构建者之间的利润分配」。

5. ERC-7683：跨链意图标准

5.1 CrossChainOrder 与 ResolvedCrossChainOrder

ERC-7683 定义了跨链意图的通用接口，让不同协议的订单可被同一批求解器识别。

// ERC-7683 核心数据结构
struct CrossChainOrder {
    address settlementContract;
    address swapper;
    uint256 nonce;
    uint32  originChainId;
    uint32  initiateDeadline;   // 源链发起截止
    uint32  fillDeadline;       // 目标链完成截止
    bytes   orderData;          // 各实现自定义负载
}

struct Output {
    bytes32 token;
    uint256 amount;
    bytes32 recipient;
    uint32  chainId;
}

struct ResolvedCrossChainOrder {
    address settlementContract;
    address swapper;
    uint256 nonce;
    uint32  originChainId;
    uint32  fillDeadline;
    uint32[] fillDeadlines;     // 每个 output 独立截止
    bytes   orderData;
    Output[] minReceived;       // 最少应得，硬约束
    FillInstruction[] fillInstructions;
}

struct FillInstruction {
    uint64  destinationChainId;
    bytes32 destinationSettler;
    bytes   originData;
}

5.2 IOriginSettler 与 IDestinationSettler

标准把执行拆成源链与目标链两个接口，源链「打开订单」，目标链「填充订单」。

interface IOriginSettler {
    event Open(bytes32 indexed orderId, ResolvedCrossChainOrder resolvedOrder);

    function open(CrossChainOrder calldata order) external returns (bytes32 orderId);

    function openFor(
        CrossChainOrder calldata order,
        bytes calldata signature,
        uint32 filler
    ) external returns (bytes32 orderId);

    function resolve(CrossChainOrder calldata order)
        external view returns (ResolvedCrossChainOrder memory);
}

interface IDestinationSettler {
    function fill(
        bytes32 orderId,
        bytes calldata originData,
        bytes calldata fillerData
    ) external;
}

resolve 把用户签名时无法确定的信息（如目标链 token 地址、独立截止时间）在源链上确定下来，open 发出事件供求解器索引；求解器在目标链调用 fill 完成交付。Across 的 SpokePool 与 UniswapX 的跨链扩展都在向这一接口收敛。

6. 与账户抽象（ERC-4337）的关系

6.1 分层：4337 是执行层，意图是意图层

ERC-4337 解决的是「谁可以发起交易、如何支付 gas」——通过 UserOperation、EntryPoint、Paymaster 把账户变成可编程对象。意图解决的是「交易应当达成什么结果」。两者是不同抽象层：

• 4337 层：把「签名 + 发起」从 EOA 中解耦，支持社交恢复、代付 gas、批量执行。
• 意图层：把「路径 + 时机 + 执行」从用户中解耦，交给求解器。

一个意图最终仍需要一个链上账户去执行，4337 恰好提供了这个可编程执行器。

6.2 组合模式：Intent + UserOperation

最常见的组合是把求解器的结算动作包装成 UserOperation：

// 求解器通过 EntryPoint 代用户提交执行
struct PackedUserOperation {
    address sender;          // 用户的 Smart Account
    uint256 nonce;
    bytes   initCode;
    bytes   callData;        // 指向意图结算合约的调用
    bytes32 accountGasLimits;
    uint256 preVerificationGas;
    bytes32 gasFees;
    bytes   paymasterAndData;// 可由求解器或 Paymaster 承担 gas
    bytes   signature;
}

Paymaster 可以由求解器出资，用户以「输出资产中扣除」的方式偿还，实现真正的「零 gas 体验」。这也是「意图 + AA + Paymaster」被称为下一代交易栈的原因。

7. 主流意图基础设施对比

7.1 单链意图协议

7.2 跨链意图协议

Anoma 走得更远：它把意图作为一等公民，链本身只负责「求解器提交的解是否满足意图约束」的验证，而不是执行固定交易序列。

8. 求解器激励、结算与失败模式

8.1 激励结构与盈亏模型

求解器利润可写成：

利润 = 用户支付上限 - 实际执行成本 - gas 成本 - 桥接/滑点成本 - 失败罚没

• 收入侧：荷兰拍溢价、批量拍卖的 surplus 分成、跨链价差。
• 成本侧：源链与目标链 gas、资金占用（跨链填充需先垫付）、重组风险敞口。
• 罚没侧：未在 fillDeadline 前完成填充会触发惩罚或声誉扣分。

当竞争充分时，求解器利润被压缩至接近边际成本，用户获得接近「无 MEV 理想价」的成交——这正是意图范式的理论收益。

8.2 失败模式清单

• 截止时间竞速：目标链拥堵导致填充超时，用户资金在源链已锁定。
• 价格脱锚：荷兰拍期间市场剧烈波动，起始价过高导致长时间无人填充。
• 部分填充悬空：允许部分成交但未成交部分长期悬挂，占用用户授权额度。
• 求解器离线：单一求解器垄断某资产对时，其宕机导致订单无法成交。
• 结算竞态：多个求解器同时填充同一订单，链上只能有一个成功，其余承担 gas 损失。

工程上必须为每类失败模式设计显式的超时与退款路径。

9. 安全与信任假设：托管、抢跑与审查

9.1 托管与授权风险

意图签名通常包含对结算合约的授权（approve 或 Permit2 签名）。若用户签的是无限额度授权，一旦结算合约被攻破，资产可被全部划走。最佳实践是：

• 使用 Permit2 或 EIP-2612 的有限额度、有限时效授权。
• 校验 settlementContract 地址与 originChainId，防止跨链重放。
• 对 orderData 做结构化校验，避免求解器塞入额外调用。

9.2 抢跑、审查与求解器串谋

• 抢跑：同链意图的填充交易本身可被抢跑，需要 fillDeadline 与竞态保护配合。
• 审查：若求解器与构建者合谋，可选择性忽略某些订单，形成事实上的审查。
• 串谋：少量求解器可通过默契压价，损害用户 surplus；需要开放准入与声誉机制制衡。

信任假设的差异决定了协议的安全边界：批量拍卖信任「至少一个诚实求解器」，而中心化 RFQ 则信任做市商不滥用订单流信息。

10. 工程实践与接入建议

10.1 接入清单

• 签名层：用 EIP-712 结构化签名表达意图，domain 中绑定 chainId 与结算合约地址。
• 索引层：订阅 Open 事件，构建订单簿；为跨链订单同时监听源链与目标链。
• 求解层：先实现单链 AMM 路由（可复用 Uniswap V3 Quoter），再扩展跨链填充。
• 结算层：优先接入已支持 ERC-7683 的结算合约，避免自建跨链消息层。
• 监控层：对 fillDeadline 剩余时间、成功率、surplus 分布建立告警。

10.2 生产注意事项

• 非确定性防范：求解必须基于同一区块状态的快照，避免模拟与执行状态漂移。
• 资金效率：跨链填充需预置目标链流动性，用 LP + 中继返还降低资金占用。
• 回退路径：当意图长期未成交时，应允许用户一键取消并退回授权。
• 渐进式去中心化：初期可用白名单求解器保证可用性，随后开放准入并引入声誉。

意图架构不是「更快的交易」，而是「把复杂度从用户转移到专业市场」，接入时应优先保证约束的严谨性与失败路径的完备性。

10.3 速查表与一句话记忆

一句话记忆：意图把「怎么做」外包给求解器竞价市场，用户只保留「至少要什么」的硬约束。

延伸阅读

• /blockchain-account-abstraction-userop/ — ERC-4337 与 Paymaster，理解意图的执行底座
• /blockchain-mev-pbs/ — 订单流、区块构建市场与意图拍卖的经济学同源
• /cross-chain-bridges/ — 跨链消息与桥接，跨链意图填充的底层依赖
• /defi-protocols/ — AMM 与聚合器路由，求解器搜索空间的构成要素
• /web3js-ethersjs-interaction/ — 前端签名与事件索引，意图接入的工程起点
• Web3 区块链专题 — 区块链 Web3 专题