链抽象下的 Solver 垄断：动态订单分配如何保护跨链交换价格

摘要：链抽象的用户体验，最终会落到 Solver 市场结构

链抽象把“从哪条链付、到哪条链收、经过哪座桥、在哪个 DEX 成交”压缩成一个用户可签名的意图（Intent）。这改善了体验，却也把定价权、执行路径和失败处理交给链下 Solver。问题不在于 Solver 是否存在；没有 Solver，跨链意图很难做到秒级报价和目标链预执行。真正的问题是：当订单流、库存、RPC、MEV 保护和结算信用集中到少数 Solver 时，意图网络会从“竞争执行市场”退化成“黑箱报价市场”。

本文研究第 89 题：基于链抽象架构的 Solver 群体中心化垄断博弈，以及如何用随机占优（Stochastic Dominance）和多属性效用函数设计动态订单分配。核心结论是：只按单次最优报价分配订单，会奖励短期压价和长期垄断；只按白名单准入分配订单，会形成许可化通道。更可行的路径是把报价、成功率、延迟、保证金、可验证结算和失败退款一起纳入评分，并用概率分配保留次优但可靠 Solver 的生存空间。

对 AllSwap 这类无托管跨链交换而言，关键不是声称“路由最优”，而是让用户能验证：报价从哪里来，失败时谁负责，目标链执行是否可证明，Solver 是否有足够竞争压力。相关入口包括 [AllSwap 跨链兑换](/exchange-swap)、[费用说明](/fees)、[USDT TRC20 兑换](/swap/usdt-trc20) 与 [USDT ERC20 兑换](/swap/usdt-erc20)。

1. 系统边界：Intent 不是交易，Solver 不是普通路由器

传统交易描述的是路径：在链 A 调用合约 X，把 token0 换成 token1，再桥接到链 B。Intent 描述的是约束：用户愿意付出什么、最低要收到什么、截止时间是什么、收款地址在哪里、失败时如何退款。Anoma 对意图架构的表述很接近这个边界：用户定义目标状态和约束，系统负责寻找满足约束的完成机制。[1]

在跨链交换里，角色至少有六类：

- 用户：签署意图，不应被迫理解每条链的中间路径。 - 前端或聚合器：收集订单，展示报价、费用、预计时间和失败规则。 - Solver：持有多链库存，计算路径，必要时在目标链先垫付，再从源链清算。 - 结算合约：验证订单、资金托管、执行或释放付款。 - 证明或预言机制：证明目标链执行、桥接完成、超时或退款条件。 - 攻击者：可能是外部 MEV 搜索者，也可能是 Solver、Builder、RPC、桥接方之间的合谋集合。

ERC-7683 试图标准化跨链意图的接口。它的重点不是替某个协议指定具体路由，而是让订单、解析结果和执行约束可以被 Solver、用户或订单分发系统模拟。[2] Across 的实现文档也把用户路径抽象为“声明目标结果，由 relayer 网络完成履约”。[3] 这说明链抽象的最低可用层，不是一个 UI 概念，而是一个可模拟、可清算、可争议的状态机接口。

因此，Solver 不是普通聚合器。聚合器通常只寻找已有流动性路径；Solver 还承担库存风险、Gas 风险、桥接延迟风险、目标链重组风险和失败退款责任。CAKE 框架把链抽象拆成 Permission、Solver、Settlement 等层，原因正在这里：Solver 层估算费用和速度，Settlement 层保证最终执行；跨链异步性会把费用、速度和执行保证拉成三角取舍。[4]

2. 中心化为什么会自然发生：自由竞价并不自动等于充分竞争

很多意图系统的直觉是：只要让多个 Solver 抢单，用户就会拿到更好价格。这个直觉只在三个条件同时成立时才接近真实：订单流足够公开、Solver 成本结构接近、失败惩罚可执行。现实通常相反。

第一，订单流会向历史成功者集中。前端希望成交快，用户希望报价稳定，于是聚合器倾向把更多订单给成功率最高的 Solver。成功率高的 Solver 又因为订单更多而积累更好的库存、路径缓存和做市关系，形成正反馈。

第二，库存规模会造成非线性优势。跨链 Solver 不是只支付一次 Gas。它需要在多条链上预置资产，承受库存波动，并在目标链高峰期仍能垫付。小 Solver 即使算法更好，也可能因为目标链库存不足而无法承接大单。久而久之，市场不是按算法质量排序，而是按资产负债表排序。

第三，私有订单流会削弱竞价。Flashbots MEV-Share 的动机之一就是降低排他性订单流对 Ethereum MEV 供应链的中心化影响。[5] 同样的问题会出现在意图市场：如果某些钱包、前端或做市商把订单流排他给少数 Solver，公开竞价只是表层，真实价格发现已经发生在私有通道里。

第四，声誉本身会变成准入壁垒。1inch Fusion 的 resolver 文档包含注册、业务信息、合规和访问流程；Fusion 的用户体验依赖第三方 resolver 支付 Gas 并完成 Dutch auction 订单。[6][7] 这类设计有现实必要性，因为系统需要排除恶意执行者。但如果准入、订单流和信用评分长期不透明，声誉会从安全工具变成市场护城河。

所以 Solver 中心化不是“协议设计失败”才会出现，而是 Solver 市场的默认吸引子。只要订单分配规则只看短期成交价，最终就会奖励有能力短期压低报价、长期垄断订单流的参与者。

3. 单次最优报价的缺陷：它忽略了分布、尾部风险和退出成本

令订单集合为 O，Solver 集合为 S。对某个订单 o，Solver i 给出报价 q_i(o)，预估完成时间 t_i(o)，失败概率 p_i(o)，保证金 c_i，历史退款延迟 r_i。最朴素的分配规则是：

```text winner(o) = argmax_i q_i(o) ```

这条规则容易解释，也容易被滥用。它只比较单点报价，不比较报价背后的分布。一个 Solver 可以在竞争期对高价值订单报出极窄价差，等竞争者退出后再扩大 spread；也可以对普通订单稳定履约，对复杂跨链路径选择性失败。用户看到的是当下最优，系统承担的是长期尾部风险。

随机占优提供了更合适的比较语言。若把每个 Solver 对某类订单的结果看成随机变量 X_i，包括净到手金额、成交时间、失败损失和退款时间，则一阶随机占优要求一个分布在所有阈值上都不差于另一个分布；二阶随机占优进一步偏好更低风险的分布。[8] 对订单分配来说，这意味着“平均报价更高”不足以证明某个 Solver 更好。一个平均值更高但尾部失败极差的 Solver，可能不应拿到更多流量。

可执行的评分可以写成多属性效用：

```text U_i(o) = w_quote * norm(q_i) - w_time * norm(t_i) - w_fail * norm(p_i * loss_o) - w_refund * norm(r_i) + w_bond * norm(c_i / exposure_i) + w_proof * proof_score_i ```

这里 `proof_score_i` 衡量 Solver 能否提供目标链 receipt、桥接状态、执行路径摘要或可复验的结算证据。`c_i / exposure_i` 衡量保证金相对于当前未结算敞口是否足够。关键不是公式里的权重一次定死，而是每个权重都必须可解释、可审计、可回测。

多属性随机占优的用途，是在 `U_i` 的结果分布上比较 Solver，而不是只比较最新报价。若 Solver A 的结果分布在大多数用户效用函数下都优于 Solver B，A 可以获得更高订单权重；若 A 只是均值略高但失败尾部显著更差，系统应保留对 B 或 C 的分配。

4. 动态订单分配：概率化，不等于随机乱派

如果永远把订单给最高分 Solver，市场仍会坍缩。更稳健的方式是把分配做成概率函数：

```text score_i = U_i(o) - penalty_i + exploration_bonus_i P(i | o) = exp(score_i / tau) / sum_j exp(score_j / tau) ```

`tau` 是温度参数。温度低时，订单更集中给高分 Solver；温度高时，系统给更多 Solver 探索流量。`exploration_bonus_i` 不是奖励弱者，而是为系统购买信息：没有新订单样本，就无法知道中小 Solver 是否已经改善库存、延迟或执行质量。

这类分配有三个工程好处。

第一，它能防止赢家通吃。只要低排名 Solver 仍满足最低安全门槛，系统就保留少量真实订单流给它们，避免市场只剩一个或两个资产负债表最大的执行者。

第二，它能把失败成本内生化。Solver 如果为了抢流量报出不可持续价格，后续失败、超时、退款延迟会进入分布，降低未来分配概率。

第三，它能支持按订单类型分层。大额稳定币跨链、小额长尾资产、同链 swap、跨 L2 资产迁移的风险分布不同。订单分配不应有一个全局排行榜，而应有按资产、链、金额、时间窗口和历史失败模式分桶的评分。

这里有一个边界：概率化分配不能牺牲用户显式约束。用户设置了最低收到金额、截止时间、目标地址和退款规则，任何 Solver 都必须先满足这些硬约束，再进入概率分配。换句话说，分配算法优化的是“合格 Solver 之间的长期市场健康”，不是替用户降低成交条件。

5. 防合谋：价格竞争之外，还要约束订单流和 Builder 通道

Solver 垄断最危险的形式不是一个 Solver 报价最高，而是 Solver、订单分发方、RPC、Builder 或跨链中继之间形成隐性联盟。它们可以不直接作恶，只要延迟某些订单、优先处理自有库存路径、或把竞争者报价排除在用户视野之外，就能扩大 spread。

CoW Protocol 的 Fair Combinatorial Auction 说明了另一种方向：收集 off-chain intents，再由 Solver 对单个订单或订单组合出价，协议按目标函数和公平约束选择结果。[9] 它的 solver competition rules 还明确把规则分成智能合约强制、链下基础设施强制和治理社会共识三类，并使用 score、UDCP 和 winner selection 来约束执行。[10] 这很重要，因为 Solver 市场的许多问题无法只靠链上合约解决；链下拍卖、治理、观察者和争议流程都要参与。

UniswapX 采用 signed order、Dutch auction 和 filler 竞争。订单不直接上链，filler 在经济可行时提交结算，价格取决于第一个成功 filler 在拍卖时间线中的执行点。[11] 1inch Fusion 也使用 Dutch auction，resolver 通过支付 Gas 和批量执行获取利润机会。[7] 这些机制共同说明：现代 DEX 执行正在从“用户发交易”转向“用户签约束，执行者竞争履约”。

但 Dutch auction 不是万能药。若参与者足够少，或订单流只对少数人开放，拍卖会变成形式化降价曲线。若 Solver 可以观察用户底线滑点，却无需暴露真实成本，它可能把价格推到用户可接受边界附近。更强的方案需要至少三层约束：

- 订单可见性约束：谁能看到订单、何时看到、是否有排他窗口，必须可审计。 - 成本与履约约束：Solver 不必公开全部策略，但必须证明执行满足订单约束和退款条件。 - 订单分配约束：订单流不能长期无解释地集中到同一组 Solver。

零知识证明可用于隐藏用户底线滑点或 Solver 成本细节，同时证明某次分配满足“所有合格 Solver 都被同一规则评估”。这不等于把完整拍卖放进 ZK 电路；更实际的路径是先证明输入集合、评分承诺、随机种子和 winner selection 没被篡改。

6. 失败模式：跨链 Solver 市场的风险不止是报价差

第一个失败模式是选择性违约。Solver 在报价时低估目标链 Gas 或库存波动，成交后发现履约会亏损，于是等待超时或走退款。若惩罚低于履约亏损，理性 Solver 会违约。防御需要动态保证金：保证金不按固定金额收，而按订单金额、目标链波动、桥接时间和 Solver 当前敞口阶梯上升。

第二个失败模式是库存诱导报价。大 Solver 在某条链上库存过剩时，会用低价吸引订单，把用户流量导向对自己库存最有利的路径，而不是全局最优路径。这不一定违反单笔订单约束，却会造成长期价格偏移。检测信号是：某 Solver 在特定链对的胜率异常高，但相同订单在公开流动性模拟下并没有持续优势。

第三个失败模式是订单流排他。前端把高质量订单先给少数 Solver，其他 Solver 只能看到剩余订单。长期看，后者无法训练报价模型，也无法证明自己能处理高价值路径。防御不是强迫全部订单完全公开，而是要求排他窗口、样本比例和分配结果可观测。

第四个失败模式是目标链 MEV 合谋。Solver 可以和 Builder 或私有 RPC 合作，延迟竞争者交易或优先打包自己的结算。Flashbots 文档强调 MEV-Share 不 enshrine 单一 builder，并试图降低 exclusive orderflow 的中心化影响。[5] 意图市场也需要类似原则：执行通道越私有，越需要可验证的结果和替代通道。

第五个失败模式是退款不可归因。用户只看到“跨链失败”，却不知道是源链锁定失败、目标链执行失败、桥接消息延迟、Solver 库存不足，还是目标链重组。无托管跨链交换必须把失败状态拆成可归因状态机，否则 Solver 惩罚和用户退款都无法公平执行。

7. AllSwap 相关性：无托管跨链交换需要的是可验证竞争，而不是口号式最优

对 AllSwap 来说，Solver 机制的价值不在于把用户界面变得更炫，而在于降低跨链操作的认知成本，同时不把用户资产交给不可审计的中间人。用户在 [AllSwap 跨链兑换](/exchange-swap) 中关心的是目标资产、到账链、预计费用、到账时间和失败退款；系统内部可以很复杂，但复杂性不能变成黑箱。

一个更稳健的 AllSwap Solver 市场可以按四层设计。

第一层是硬约束过滤：目标链、资产、地址、金额、截止时间、最低到账、可退款路径必须全部满足。不满足者不进入竞价。

第二层是报价竞争：比较净到账、费用、滑点、Gas 和路径质量。这里可以接入多源流动性，但必须把费用结构和 [费用说明](/fees) 对齐。

第三层是风险评分：按链对、资产、金额区间统计成功率、失败原因、退款时间和争议记录。比如 USDT 在 [TRC20](/swap/usdt-trc20) 和 [ERC20](/swap/usdt-erc20) 路径上的执行风险完全不同，评分也不应混在一起。

第四层是概率分配和审计：对合格 Solver 进行动态订单分配，公开或半公开地记录分配原因、执行结果和惩罚。这样可以在不泄露用户隐私和 Solver 全部策略的前提下，维持市场竞争。

这不是说 AllSwap 必须立刻实现复杂 ZK 拍卖。更现实的工程路线是：先收集可验证执行数据；再引入保证金和失败归因；最后把订单分配从固定白名单升级为概率化、可回测的机制。跨链交换的长期壁垒不是“支持多少链”，而是异常路径下能否把责任算清楚。

8. 开放问题：Solver 市场还没有最终答案

第一，如何在隐私和可审计之间取平衡。完全公开订单会暴露用户意图和滑点，完全私有订单又会放大排他订单流。ZK 承诺、TEE、延迟揭示和部分信息拍卖都可用，但各自有成本和信任假设。

第二，如何给 Solver 保证金定价。固定保证金会排斥小 Solver，却未必覆盖大额订单风险；动态保证金需要实时估计波动、库存和跨链延迟，又容易被极端行情击穿。

第三，如何证明订单分配没有偏袒。公开全部评分可能泄露策略，隐藏评分又让治理无法判断是否存在垄断。可行方向是公开规则承诺和聚合统计，隐藏订单级敏感参数。

第四，如何处理跨链最终性错配。源链确认、目标链执行、桥接消息和退款窗口并不共享同一个时钟。Solver 的 SLA 必须按链对定义，不能用一个全局“预计到账时间”覆盖全部路径。

第五，如何避免“去中心化名义下的许可化”。如果只有通过复杂合规、KYC、白名单和私有 API 的机构才能成为 Solver，系统可能安全一些，但会牺牲开放竞争。真正的设计难点是让安全门槛和市场开放性同时成立。

References

[1] An Introduction to Intents and Intent-centric Architectures, Anoma, 2023, https://anoma.net/blog/an-introduction-to-intents-and-intent-centric-architectures

[2] ERC-7683: Cross Chain Intents, Ethereum Improvement Proposals, https://eips.ethereum.org/EIPS/eip-7683

[3] ERC-7683 in Production, Across Docs, https://docs.across.to/guides/concepts/erc-7683

[4] Introducing the CAKE framework, Frontier Research, 2024, https://frontier.tech/the-cake-framework

[5] MEV-Share Introduction, Flashbots Docs, https://docs.flashbots.net/flashbots-mev-share/introduction

[6] Resolver Introduction, 1inch Business Docs, https://business.1inch.com/portal/documentation/resolvers/introduction

[7] 1inch Intent Swap API Introduction, 1inch Business Docs, https://business.1inch.com/portal/documentation/apis/swap/intent-swap/introduction

[8] Stochastic Dominance lecture notes, Avinash Dixit, Princeton University, https://www.princeton.edu/~dixitak/Teaching/EconomicsOfUncertainty/Slides%26Notes/Notes04.pdf

[9] Fair Combinatorial Batch Auction, CoW Protocol Docs, https://docs.cow.fi/cow-protocol/concepts/introduction/fair-combinatorial-auction

[10] Solver competition rules, CoW Protocol Docs, https://docs.cow.fi/cow-protocol/reference/core/auctions/competition-rules

[11] UniswapX Overview, Uniswap Developers, https://developers.uniswap.org/docs/liquidity/uniswapx/overview

[12] UniswapX repository, Uniswap Labs, https://github.com/Uniswap/UniswapX

[13] Fair Combinatorial Auction for Blockchain Trade Intents, arXiv, 2024, https://arxiv.org/html/2408.12225v2