多池聯合夾擊與清算線操縱：DeFi 路由如何識別短時錯誤價格

摘要：多池夾擊的核心不是單個池子的滑點

現代 DeFi 價格操縱風險已經很少停留在“一個池子裏前後夾一筆交易”的簡單模型。更危險的路徑是多池聯合夾擊（Multi-Pool Sandwich）和閃電貸驅動的多維清算線扭曲：攻擊者不需要長期持倉，只要在一個原子交易窗口內同時影響 AMM 池、預言機採樣、抵押率計算和清算觸發條件，就可能讓一個本應安全的倉位短暫落入可清算區域。本文從 Uniswap V2/V3、Curve 穩定交換、TWAP、預言機緩存和借貸協議清算模型出發，建立一個防禦性數學框架：把每個池子的局部滑點導數擴展成跨協議價格向量的雅可比矩陣，再用風險值（VaR）和熔斷狀態機約束異常路徑。對 AllSwap 這類跨鏈交換而言，關鍵不是預測每一次 MEV，而是避免把被操縱的短時價格當作可執行報價和退款依據。

問題邊界：防禦性建模，不提供攻擊流程

本文討論的是協議防禦、路由風控和清算風險建模，不提供可複用夾擊腳本、交易排序模板、目標池篩選方法或真實系統攻擊步驟。系統角色包括：AMM 池、借貸協議、預言機、清算者、MEV Builder、搜索者、跨鏈路由器、用戶和風控合約。攻擊者能力假設爲：可以獲得閃電貸或短期流動性，可以在同一執行窗口內提交多筆交易，可以觀察公開 mempool 或 Builder 訂單流，可以利用協議間價格引用滯後；不假設攻擊者能僞造預言機簽名、繞過共識規則或修改合約代碼。

邊界要先劃清。單池夾擊主要影響用戶成交價格；多池聯合夾擊影響的是“其他協議如何讀取價格”。如果一個借貸協議用某個 AMM 派生價格計算健康因子，而另一個衍生品池又用該價格更新保證金，價格向量就不再是獨立變量。一個池子的瞬時偏移會通過預言機、TWAP、抵押率、合成資產指數和清算閾值傳播，形成跨協議狀態衝擊。防禦目標不是讓價格永不波動，而是讓異常的、短時的、不可持續的價格不觸發不可逆清算或跨鏈釋放。

對跨鏈交換還要增加一個維度：時間。源鏈報價、目標鏈執行、橋確認、退款窗口和預言機更新時間並不同步。某條路線在報價時安全，不代表目標鏈執行時仍安全；某個 TWAP 在本鏈足夠穩健，不代表跨鏈等待期間沒有過期。AllSwap 的路由風險模型必須把價格衝擊、最終性延遲和退款可歸因性放在同一個狀態機裏處理。

多池價格衝擊模型

以 Uniswap V2 常數乘積池爲例，忽略費用時有：

```text x * y = k p = y / x dp / dx = -y / x^2 - k / x^2 adjusted by reserve path ```

實際實現會加入手續費、輸入輸出方向和整數取整。重點不是公式細節，而是局部價格對交易量的導數。Uniswap V3 又把流動性集中到 tick 區間，局部價格衝擊取決於當前 tick 附近的有效流動性 `L`，而不是全池名義 TVL。Curve 的穩定交換在錨定區間內提供更低滑點，但當池子偏離平衡或放大係數失效時，價格曲線會變得更陡。也就是說，“池子很大”不是充分安全條件，必須看目標價格區間裏的實際深度。

把多個池子放在一起，價格狀態可以寫成向量：

```text P = (p_amm1, p_amm2, p_curve, p_lending_oracle, p_perp_index) Q = (q_1, q_2, ..., q_n) J = dP / dQ ```

`Q` 是在不同池子和協議中的交易或狀態變更向量，`J` 是價格敏感度矩陣。單池防禦只看某個 `dp/dq`；多池防禦要看 `J` 的方向性。如果一個小交易向量能讓多個價格分量同向偏移，清算條件就可能被放大。若偏移方向剛好影響抵押品價格下跌、債務資產價格上漲、保證金指數上升，健康因子會出現非線性惡化。

清算條件可以抽象爲：

```text H = collateral_value(P) * liquidation_threshold - debt_value(P) liquidatable if H is not positive ```

防禦者關心的是 `dH / dQ`。如果某組交易讓 `H` 在一個區塊內從正值變成非正值，但在幾個區塊後自然恢復，就說明協議暴露在瞬時價格風險下。真正的風險不只是“被清算”，而是“用不可逆清算結算了一個短時錯誤價格”。

TWAP 與預言機緩存的滯後風險

TWAP 被廣泛用於降低單區塊價格操縱風險。Uniswap V2 的累計價格 oracle 要求觀察者比較兩個時間點的累積價格；Uniswap V3 提供觀察窗口和 tick 累積機制。它們的共同思路是把瞬時價格變成時間平均值。但 TWAP 不是魔法，它只是在操縱成本、響應速度和滯後之間做取捨。

窗口越長，單區塊操縱成本越高，但協議對真實市場變化反應越慢。窗口越短，反應更快，但對短時衝擊更敏感。如果借貸協議、衍生品協議和路由器使用不同窗口，風險會出現在窗口錯配處。一個協議認爲價格已經恢復，另一個協議仍在讀取滯後的高價或低價；一個清算模塊用較短窗口觸發，抵押評估卻用較長窗口確認，狀態機會出現語義分裂。

預言機緩存也有類似問題。Chainlink 文檔強調數據源選擇、市場覆蓋、流動性和更新條件；Aave、Maker 等借貸協議則在預言機模塊和清算邏輯之間建立自己的安全邊界。若消費端只檢查“價格是否存在”，卻不檢查更新時間、偏離閾值、數據源深度和備用路徑，就會把 stale price 當作有效狀態。閃電貸不會破解預言機簽名，但可能利用協議讀取價格的時序和緩存策略。

一個防禦性價格讀取函數不應只返回 `price`，而應返回：

```text price, timestamp, source_set, deviation, liquidity_depth, confidence_state ```

`confidence_state` 可以是 `normal`、`stale`、`thinLiquidity`、`deviated`、`circuitBreaker`。清算、跨鏈報價和退款估值不應把這些狀態抹平爲一個數字。價格是輸入，價格質量纔是風控變量。

多維清算線與風險值約束

單資產清算模型通常看起來很簡單：抵押價值下降或債務價值上升，健康因子跌破閾值。但多池聯合風險裏，抵押品、債務資產、LP token、合成資產和跨鏈 wrapped asset 可能共享流動性來源或預言機路徑。此時風險不再是一條線，而是一個多維曲面：

```text H(P_1, P_2, ..., P_m, t, chain_state) ```

`t` 表示時間窗口，`chain_state` 表示最終性、橋狀態和執行延遲。防禦方可以對健康因子做一階近似：

```text Delta H approximately equals gradient(H) dot Delta P ```

若某個價格擾動向量 `Delta P` 在短窗口內讓 `Delta H` 接近清算邊界，就應觸發保護，而不是等待真實清算發生。這裏的風險值不是傳統金融裏直接搬來的 VaR，而是協議級滑點風險值：在當前流動性深度、預言機置信狀態和跨鏈延遲下，某個訂單或某組倉位最多能承受多大價格偏移。

防禦可以分三層。第一層是交易前限額：當目標路徑的 `slippage VaR` 超過閾值時，降低單筆額度或拆單。第二層是清算前延遲：當清算由異常價格狀態觸發時，要求二次確認、備用 oracle 或延遲窗口。第三層是跨協議熔斷：當多個相關資產同時出現異常偏移時，暫停新開倉或大額跨鏈釋放，但保留退款和退出路徑。

這類設計有代價。延遲清算可能增加壞賬；限制交易可能降低資本效率；多源預言機可能引入治理和運維複雜度。工程判斷不能只寫“加 TWAP”或“用更安全預言機”，而要明確代價由誰承擔，以及異常狀態下用戶資金如何退出。

預言機消費端的不變量

很多事故並不是預言機本身“報錯”，而是消費端把價格當成無上下文數字。一個穩健的消費端至少應維護四類不變量。第一，價格時間不變量：用於清算、報價和退款的價格必須在允許的 freshness 窗口內，且窗口要小於業務動作的不可逆結算窗口。第二，來源一致性不變量：若主源、備用源和 AMM 派生價格出現超過閾值的偏離，協議進入降級狀態，而不是選擇其中一個繼續執行。

第三，深度不變量：價格引用的市場深度必須覆蓋當前交易或倉位規模。一個 oracle 可以給出正確的中位數價格，但如果執行路徑只能在薄流動性區間成交，該價格對路由沒有執行意義。第四，方向性不變量：抵押資產價格下跌和債務資產價格上漲同時發生時，清算風險應被放大處理，因爲這通常意味着風險向量正在沿着健康因子最敏感的方向移動。

這些不變量應在鏈上和鏈下同時存在。鏈下路由器負責更復雜的相關性計算和路徑選擇；鏈上合約負責最小安全約束，例如更新時間、最大偏離、最大單筆額度和熔斷狀態。若所有判斷都放在鏈下，用戶無法驗證風控是否真的生效；若所有判斷都放在鏈上，Gas 和數據可得性會限制模型複雜度。合理邊界是：鏈下計算風險評分，鏈上強制執行不可繞過的硬閾值。

跨鏈執行前的價格質量閘門

跨鏈交換比單鏈 swap 多一個失敗面：報價和執行不在同一個原子上下文裏。源鏈鎖定或支付完成後，目標鏈可能經歷橋確認、排隊、重組等待和路由再平衡。若目標鏈執行前不重新檢查價格質量，系統就可能用舊報價穿過新的風險狀態。這個問題和傳統滑點保護不同；滑點保護只檢查成交價格，價格質量閘門還要檢查該價格是否來自健康市場。

執行前閘門可以按順序檢查五項：目標池有效深度是否仍覆蓋訂單；短 TWAP 和長 TWAP 是否分叉；外部預言機是否過期；相關資產是否同時異常偏移；橋或目標鏈是否處於延遲狀態。任一項失敗時，動作不應直接變成失敗交易，而應進入受控分支：重新報價、降低額度、等待下一窗口，或觸發退款。這樣能避免用戶資金被卡在“價格不可信但系統仍嘗試執行”的灰區。

退款定價同樣需要閘門。若訂單因爲價格異常未執行，退款不應依賴異常時刻的單點價格。更穩健的做法是記錄原始報價上下文、源鏈支付資產、目標鏈預期資產、失效原因和可驗證時間戳，再根據產品規則選擇原路退款、穩定資產退款或等待恢復。關鍵是把價格異常和用戶意圖分開，不讓短時市場扭曲改變用戶本來的資產歸屬。

檢測信號與防禦狀態機

多池聯合風險的檢測信號可以分爲鏈上、價格和執行三類。鏈上信號包括同一區塊內多個相關池的方向性交易、短窗口內異常大的 reserve 變化、LP 份額快速進出和借貸倉位健康因子集中貼近閾值。價格信號包括 AMM 價格與外部數據源偏離、短 TWAP 與長 TWAP 分叉、低深度區間價格彈性突增。執行信號包括清算交易密集失敗、跨鏈路線頻繁重新報價、目標鏈執行前後的價格狀態不一致。

一個防禦狀態機可以寫成：

```text normal -> elevatedRisk -> guardedExecution -> circuitBreaker -> recovery ```

`normal` 狀態正常報價。`elevatedRisk` 降低單筆額度並延長報價有效性檢查。`guardedExecution` 要求備用價格源、二次 TWAP 或更高滑點緩衝。`circuitBreaker` 暫停新風險敞口，但保留退款、撤單和低風險退出。`recovery` 則要求價格偏離、流動性深度和預言機更新時間恢復到閾值內，不能只靠管理員手動解除。

跨協議聯動熔斷的難點是誤報。市場真實波動時，過度保守的熔斷會傷害用戶；攻擊窗口中，過度寬鬆又會把錯誤價格寫入清算和結算。更穩健的做法是分層響應：先限額，再延遲，再切換路徑，最後才全局暫停。每一級都應該有可觀測條件和自動恢復條件。 恢復條件還必須寫入日誌，方便事後審計。

AllSwap 相關性：報價、執行和退款要分開看

AllSwap 的核心場景是跨鏈交換與路由聚合。多池價格風險會影響三件事：報價是否可信、目標鏈執行是否仍在安全滑點內、失敗後退款是否能按可解釋價格歸因。一個跨鏈路由如果只在源鏈報價時讀取價格，而不在目標鏈執行前重新驗證價格質量，就可能把短時被扭曲的價格傳遞給用戶。

路由層可以把價格狀態拆成幾個階段：`quoteObserved`、`liquidityReserved`、`oracleChecked`、`targetExecutionReady`、`releaseConfirmed`、`refundPriced`。每個階段都應該記錄價格源、更新時間、滑點 VaR、路徑深度和鏈最終性狀態。若某個階段進入 `deviated` 或 `stale`，系統不應繼續用同一報價假裝確定執行，而應切換到重新報價、限額執行或退款路徑。

這也解釋了爲什麼“最低手續費路線”不是唯一目標。低費路線如果穿過薄流動性池、短 TWAP、剛發生大額 LP 遷移的池子，或者依賴目標鏈滯後 oracle，它的真實風險成本可能高於報價顯示。AllSwap 可以把這類風險體現在路徑評分中：不需要對用戶展示覆雜矩陣，但需要把可執行性、退款確定性和價格質量納入路由選擇。

對無託管產品尤其重要的是失敗歸因。若目標鏈價格異常導致執行暫停，用戶需要知道資金在哪條鏈、哪個狀態、是否可退款、退款按哪個價格口徑計算。風控系統的目標不是永遠執行成功，而是在不可信價格出現時仍能保持資產狀態可驗證、可退出、可解釋。

未解決問題

第一，多協議價格相關性缺少統一數據結構。每個協議都能描述自己的 oracle 和池子，但很少有標準方式表達“這些價格源在風險上相關”。

第二，TWAP 窗口選擇仍然是工程和經濟學折中。窗口太短防不住瞬時操縱，窗口太長會錯過真實市場變化，跨鏈場景還要疊加最終性延遲。

第三，鏈上實時 VaR 計算成本較高。完整計算多池雅可比矩陣和倉位風險曲面會消耗 Gas，實際系統需要近似、緩存和分層閾值。

第四，熔斷治理容易被濫用。自動熔斷能降低攻擊面，但如果恢復條件不透明，也可能成爲審查、延遲或選擇性執行的工具。

第五，用戶界面仍難表達“價格質量”。展示一個價格很容易，展示該價格的深度、時效、偏離和退款含義要困難得多。

參考資料

[1] Uniswap V2 Whitepaper, Hayden Adams et al., 2020, https://app.uniswap.org/whitepaper.pdf

[2] Uniswap V3 Whitepaper, Hayden Adams et al., 2021, https://uniswap.org/whitepaper-v3.pdf

[3] Uniswap V2 Oracles Documentation, Uniswap, https://docs.uniswap.org/contracts/v2/concepts/core-concepts/oracles

[4] Uniswap V3 Oracle Library Documentation, Uniswap, https://docs.uniswap.org/contracts/v3/reference/core/libraries/Oracle

[5] Curve StableSwap NG Oracle Documentation, Curve Finance, https://docs.curve.finance/stableswap-exchange/stableswap-ng/pools/oracles/

[6] Aave Price Oracle Documentation, Aave, https://aave.com/docs/developers/smart-contracts/oracles

[7] Chainlink Data Feed Selection Documentation, Chainlink, https://docs.chain.link/data-feeds/selecting-data-feeds

[8] Flash Boys 2.0: Frontrunning in Decentralized Exchanges, Daian et al., 2019, https://arxiv.org/abs/1904.05234

[9] Flashot: A Snapshot of Flash Loan Attack on DeFi Ecosystem, Qin et al., 2021, https://arxiv.org/abs/2102.00626

[10] SoK: Decentralized Finance Security and Privacy, 2022, https://arxiv.org/abs/2208.13035

[11] MakerDAO Oracle Module Documentation, MakerDAO, https://docs.makerdao.com/smart-contract-modules/oracle-module