鏈抽象下的 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