跨鏈 AMP 防搶跑：時間鎖謎題與樂觀佇列如何約束目標鏈排序

摘要：跨鏈訊息的風險，不只在驗證，也在目標鏈排序

任意訊息傳遞（Arbitrary Message Passing, AMP）通常被描述為“鏈 A 的合約呼叫鏈 B 的合約”。這個描述太乾淨，掩蓋了真正危險的部分：源鏈訊息被觀察到之後，目標鏈並不會自動按照源鏈時間順序執行。中繼器、Builder、私有 RPC、目標鏈驗證者和 MEV 搜尋者都可能在訊息到達目標鏈前看到足夠多的意圖資訊，並利用排序權搶跑、夾擊或延遲執行。

本文研究第 87 題：基於時間鎖謎題（Time-Lock Puzzle）與樂觀排隊機制（Optimistic Queue）的跨鏈 AMP 防搶跑設計。核心結論是：跨鏈安全不能只證明“訊息來自源鏈”，還必須約束“訊息何時可見、何時入隊、按什麼規則執行、失敗後如何退款”。時間鎖或可驗證延遲函式（Verifiable Delay Function, VDF）可以降低提前解密和目標鏈搶跑空間；樂觀佇列可以把跨鏈訊息先提交到一個可爭議的順序層，再在超時窗口後執行。

對 [AllSwap 跨鏈兌換](/exchange-swap) 這類無託管跨鏈交換而言，使用者關心的是目標鏈資產能否按報價執行，以及失敗時是否可退款。只要目標鏈排序被操縱，滑點、到賬時間和退款責任都會偏離報價。相關基礎路徑包括 [費用說明](/fees)、[USDT TRC20 兌換](/swap/usdt-trc20)、[USDT ERC20 兌換](/swap/usdt-erc20) 和 [TRX 資產頁面](/assets/trx)。

1. 系統邊界：AMP 的核心不是“能傳訊息”，而是“訊息被如何執行”

在 AMP 系統裡，源鏈合約產生訊息 m，訊息包含目標鏈地址、payload、nonce、費用和執行約束。中繼層觀察源鏈事件，等待最終性或確認閾值，然後把訊息及其證明提交到目標鏈。目標鏈合約驗證訊息來源，再呼叫目標合約或釋放資產。

這個流程至少有五個時鐘：

- 源鏈出塊和最終性時鐘； - 中繼器觀察和證明生成時鐘； - 目標鏈 mempool 或私有交易通道時鐘； - 目標鏈出塊和排序時鐘； - 使用者設定的超時和退款時鐘。

LayerZero V2 文件在 message execution options 中明確指出，源鏈傳送跨鏈訊息時並不知道目標鏈狀態或執行所需資源，因此需要把目標鏈執行要求序列化給鏈下基礎設施處理。[1] Chainlink CCIP 把跨鏈訊息、代幣轉移和可程式設計轉移放在同一互操作層，並強調風險管理網路用於異常監控。[2][3] Axelar 的 General Message Passing 允許跨鏈函式呼叫和狀態同步。[4] Wormhole 的跨鏈 messaging 也讓合約在多鏈之間傳送和接收訊息。[5]

這些協議解決了“訊息真實性”和“跨鏈可達性”的一部分，但它們並不自動解決目標鏈排序公平性。一個跨鏈交換意圖可能在源鏈已經鎖定資金，但目標鏈執行仍暴露在目標鏈 mempool、Builder 排序和中繼器選擇性提交之下。換句話說，AMP 的安全邊界不是訊息驗證合約結束的地方，而是目標鏈執行確定、失敗可歸因、退款可觸發之後才結束。

2. 攻擊模型：跨鏈搶跑利用的是時間差，不一定需要偽造證明

跨鏈搶跑者不需要破解簽名，也不需要偽造訊息證明。它只需要在源鏈觀察到敏感訊息，然後在目標鏈提前佈局。

典型流程如下：

```text T0: 使用者在源鏈提交跨鏈意圖，資金或訂單被鎖定。 T1: 中繼器、搜尋者或公開索引器觀察到訊息內容。 T2: 攻擊者在目標鏈預測執行路徑，提交搶跑交易。 T3: 合法訊息證明到達目標鏈，但目標狀態已經改變。 T4: 使用者收到更差價格、交易失敗、或進入退款流程。 ```

Flash Boys 2.0 早就說明，交易排序依賴會產生搶跑、重排和優先 Gas 競價，並把 MEV 變成共識層安全問題。[6] 跨鏈 AMP 把這個問題放大了，因為源鏈和目標鏈之間存在物理延遲。目標鏈攻擊者不需要比使用者更快簽名，只要比合法跨鏈訊息更快進入目標鏈排序。

跨鏈場景比單鏈 DEX 更難處理。單鏈交易至少共享同一個 mempool 和同一個區塊排序；跨鏈訊息的可見性、證明延遲和目標鏈執行在不同系統裡發生。中繼器可能出於費用、擁堵或策略原因延遲提交；目標鏈 Builder 可能優先打包本地套利交易；私有 RPC 可能把訊息洩露給特定搜尋者。攻擊面變成一個跨系統的時序差。

因此，AMP 防搶跑不能只依賴“更快中繼”。更快中繼會變成速度軍備競賽，最終獎勵靠近目標鏈 Builder 或私有訂單流的參與者。協議級設計應該讓敏感 payload 在入隊前不可利用，或者讓任何提前利用都能被檢測和懲罰。

3. 時間鎖謎題與 VDF：把訊息內容延遲到排序之後

時間鎖謎題的基本思想來自 Rivest、Shamir 和 Wagner：傳送者可以構造一個需要順序計算才能解開的謎題，讓資訊在未來某個計算時間後才可讀。[7] 這類機制不依賴某個受信任保管人按時釋出金鑰，而是依賴順序計算難以並行加速。

VDF 進一步給這個思想加上可公開驗證的輸出。Boneh、Bonneau、Bünz 和 Fisch 對 VDF 的定義是：評估需要指定數量的順序步驟，但結果可以高效公開驗證。[8] 對跨鏈 AMP 來說，VDF 的吸引力在於它能把“延遲”從中繼器承諾變成可驗證物件。

一個簡化模型可以這樣寫：

```text payload = Enc_k(message) puzzle = VDFCommit(k, delay = D) packet = {sourceProof, target, payload, puzzle, deadline}

目標鏈先接收 packet 併入隊； 等待 D 或驗證 VDF output； 解出 k 後公開 message； 按佇列順序執行 message。 ```

這裡的關鍵不是隱藏所有跨鏈資訊。金額範圍、目標鏈、費用和收款約束可能仍然需要暴露給系統做風控和報價。真正需要延遲的是會被搶跑利用的細節：目標池、交易方向、最小輸出、策略引數、回撥路徑或清算條件。

時間鎖也不是免費午餐。D 設定太短，攻擊者仍能提前解密；D 設定太長，使用者體驗和目標鏈資金效率會下降。VDF 驗證雖然比求值便宜，但在鏈上直接驗證仍有成本；若把求值或驗證放到鏈下，又要解決誰提交結果、誰挑戰錯誤結果、挑戰窗口多長的問題。

所以時間鎖適合處理“訊息在排序前不應被知道”的部分，而不適合替代最終性確認、訊息證明或退款狀態機。它是時序防護層，不是完整跨鏈安全層。

4. 樂觀排隊：先固定順序，再揭示和執行

樂觀排隊的目標是把跨鏈訊息從“誰先把交易塞進目標鏈”改成“誰先在目標鏈提交可驗證佇列承諾”。最小狀態機如下：

```text Submit(packet): verify sourceProof or committee attestation append hash(packet) to queue set status = Pending

Reveal(packet, key): require hash(packet) in queue require delay elapsed or VDF output valid decode payload set status = Revealed

Execute(packet): require status = Revealed require all earlier executable packets handled or timed out call target with payload set status = Executed or Failed

Timeout(packet): if deadline passed and not Executed mark Refundable or Slashable ```

這個模型有兩個約束。第一，入隊順序必須可驗證。可以用目標鏈交易時間、目標鏈合約 nonce、批次 Merkle root 或跨鏈訊息序號作為排序依據。第二，執行不能無限阻塞。若某個早期訊息因 gas 不足、目標合約 revert 或證明缺失而卡住，佇列必須能跳過、標記失敗或觸發退款，否則攻擊者可以用一個壞訊息阻塞後續全部訊息。

Themis 和 Aequitas 這類公平排序協議關注的是拜占庭共識中的訊息順序公平性。Aequitas 試圖在共識中同時提供安全性、活性和 order-fairness；Themis 在 n >= 4f + 1 的設定下給出更強的公平排序性質。[9][10] AMP 不一定直接採用這些共識協議，但它們給出了關鍵啟發：排序公平不是“先到先得”這麼簡單，因為不同節點看到訊息的時間不同。跨鏈系統也不能只看某個中繼器提交時間，而應考慮源鏈順序、目標鏈入隊順序和可爭議證據。

樂觀排隊的“樂觀”在於預設訊息按承諾執行，不為每個訊息都做昂貴爭議；但系統保留挑戰窗口。如果有人證明 packet 內容、sourceProof、佇列位置或 VDF 輸出無效，該訊息被標記失敗，中繼器或提交者被懲罰。這樣可以把大部分訊息保持低延遲，同時給異常路徑留出可歸因機制。

工程上還需要把“佇列證明”和“退款證明”分開。佇列證明回答的是：某條訊息是否在目標鏈某個批次中佔據確定位置；退款證明回答的是：該訊息是否在 deadline 前未進入 `Executed` 狀態，或進入 `Failed` 狀態且失敗原因符合退款規則。兩者不能混在一個布林值裡。否則使用者只能看到“失敗”，卻無法判斷是中繼器未提交、目標鏈執行失敗、VDF 揭示超時，還是目標合約狀態不滿足約束。對跨鏈交換來說，這個差別直接決定是退還源鏈資金、重新報價，還是懲罰提交者。

5. 防目標鏈夾擊：排序約束必須覆蓋 Builder 和中繼器

跨鏈夾擊不是簡單的“中繼慢”。攻擊者可以在目標鏈上圍繞合法訊息構造前後交易：先改變池子價格，再讓跨鏈訊息以較差狀態執行，最後反向套利。若訊息 payload 在源鏈公開，攻擊者甚至不需要等待中繼器提交。

防禦可以拆成三層。

第一層是 payload 可見性控制。敏感欄位在入隊前以承諾或加密形式存在，只有佇列位置固定後才揭示。時間鎖謎題、VDF、閾值加密或延遲揭示都屬於這一層。

第二層是執行窗口約束。目標鏈合約可以要求訊息在揭示後只在固定窗口內執行，或者要求執行價格、狀態根、池子版本和 slippage 與入隊時的承諾一致。這樣即使攻擊者能觀察揭示，也很難在無限時間裡等待最佳夾擊點。

第三層是失敗歸因和退款。若目標鏈狀態因排序操縱而不再滿足使用者約束，系統不應強行執行，而應進入退款或重新報價路徑。對使用者來說，“訊息最終執行了”不等於“按原意圖執行了”。

PBS 和 MEV-Boost 的存在說明，現代區塊構建已經把交易排序從單一驗證者行為擴充套件成 Builder 市場。[11][12] AMP 設計必須承認這一點。只要目標鏈執行進入 Builder 選擇範圍，跨鏈訊息就會面對本地 MEV 生態。協議不能假設目標鏈排序天然中立。

6. 失敗模式：公平排序層本身也會成為攻擊面

第一個失敗模式是延遲引數錯誤。時間鎖延遲 D 太短，攻擊者仍能在訊息執行前恢復 payload；D 太長，正常使用者承擔不必要等待和價格風險。D 不應是全域常數，而應按鏈對、資產、訂單型別、目標鏈出塊時間和歷史 MEV 風險動態配置。

第二個失敗模式是佇列阻塞。攻擊者提交一個合法入隊但必然執行失敗的訊息，佔據隊頭。如果系統要求嚴格順序執行，後續訊息被拖住。防禦是把狀態拆成 `Pending`、`Revealed`、`Executable`、`Failed`、`Refundable`，並允許超時跳過，同時記錄失敗原因。

第三個失敗模式是中繼器選擇性提交。中繼器看到某些訊息對自己不利，就延遲提交或提交到私有通道。防禦需要多中繼器競爭、提交者保證金、延遲證明和“任何人可提交”的 fallback 路徑。

第四個失敗模式是 VDF 外包中心化。如果只有少數高效能節點能按時求解 VDF，延遲層會變成新的中心化入口。VDF 適合驗證時間約束，但不應讓求解者擁有排他執行權。結果提交和執行權應分離。

第五個失敗模式是退款窗口錯配。源鏈認為訊息超時可退款，目標鏈卻已執行；或目標鏈執行失敗，源鏈資金仍被鎖定。跨鏈退款必須繫結訊息狀態證明，而不能只看單鏈時鐘。

7. AllSwap 相關性：使用者看到的是報價，系統必須處理全域時序

AllSwap 的使用者不關心 AMP 的內部訊息格式，但會直接承受目標鏈排序風險。比如使用者從一條鏈換到另一條鏈上的穩定幣，報價時目標池狀態是 A；訊息到目標鏈執行時，池子狀態可能已經變成 B。若這個變化來自正常市場波動，系統需要 slippage 控制；若來自觀察跨鏈訊息後的搶跑，系統需要時序防護和失敗歸因。

一個更穩健的 AllSwap 跨鏈執行層可以分四步演進。

第一，明確跨鏈訊息狀態機。每筆訂單至少應有 `SourceLocked`、`QueuedOnTarget`、`Revealed`、`Executed`、`Refundable`、`Refunded` 等狀態，讓使用者和系統都能定位失敗發生在哪裡。

第二，對敏感路徑使用延遲揭示。並非所有跨鏈兌換都需要 VDF 或時間鎖；小額、低 MEV 風險路徑可以走普通中繼。但大額、低流動性、目標鏈容易被夾擊的訂單，應考慮隱藏目標執行細節直到排序固定。

第三，把 [費用說明](/fees) 和時間風險拆開。使用者支付的不是單一跨鏈費用，而是源鏈 gas、目標鏈執行 gas、中繼服務費、可能的延遲保護成本和退款處理成本。系統越早把這些拆清楚，越容易解釋為什麼某些路徑更貴。

第四，把無託管安全邊界寫進產品規則。AllSwap 不需要接管使用者資產，也不需要承諾目標鏈絕對無 MEV；但必須讓使用者知道何時會執行、何時會退款、哪種失敗歸誰負責。對 [USDT TRC20](/swap/usdt-trc20) 和 [USDT ERC20](/swap/usdt-erc20) 這類高頻路徑，狀態機透明度比宣傳“秒級到賬”更重要。

報價層也應讀取這些狀態，而不是隻讀取最終結果。若某條路徑經常停在 `QueuedOnTarget`，問題可能是目標鏈排序或中繼擁堵；若經常停在 `Revealed` 後失敗，問題更可能是目標合約狀態、滑點或執行窗口。只有把這些狀態回灌到路由評分，後續報價才會逐漸反映真實風險。

8. 開放問題：跨鏈公平排序還遠沒有收斂

第一，時間鎖引數如何定價。D 是安全性、延遲和資金效率的共同變數。不同鏈對、資產和訂單大小需要不同 D，但動態 D 又可能被攻擊者作為風險訊號利用。

第二，VDF 驗證應放在哪裡。鏈上驗證可審計但有 gas 成本；鏈下驗證便宜但需要挑戰機制。不同目標鏈的預編譯、gas 模型和證明成本差異會直接影響設計。

第三，公平排序與最終性如何組合。源鏈順序、目標鏈入隊順序和目標鏈執行順序可能衝突。系統需要定義哪個順序優先，以及發生重組時如何回滾或退款。

第四，隱私和可恢復性的衝突。payload 加密能降低搶跑，但也讓風控、模擬和失敗診斷更難。系統可能需要分層披露：公開約束摘要，延遲揭示敏感路徑。

第五，誰來懲罰跨鏈排序作惡。若作惡者是中繼器，鏈上保證金可以處理；若作惡者是目標鏈 Builder 或私有 RPC，協議只能透過替代執行通道、價格保護和退款規則間接防禦。這個邊界必須寫清楚。

References

[1] LayerZero V2 Message Execution Options, LayerZero Docs, https://docs.layerzero.network/v2/tools/sdks/options

[2] Chainlink CCIP Documentation, Chainlink Docs, https://docs.chain.link/ccip

[3] Chainlink CCIP Risk Management Network, Chainlink Blog, https://blog.chain.link/ccip-risk-management-network/

[4] General Message Passing and How Can It Change Web3, Axelar, https://www.axelar.network/blog/general-message-passing-and-how-can-it-change-web3

[5] Wormhole Cross-Chain Messaging Contracts, Wormhole Docs, https://wormhole.com/docs/products/messaging/tutorials/cross-chain-contracts/

[6] Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges, arXiv, https://arxiv.org/abs/1904.05234

[7] Time-lock puzzles and timed-release Crypto, Rivest, Shamir, Wagner, 1996, https://people.csail.mit.edu/rivest/pubs/RSW96.pdf

[8] Verifiable Delay Functions, Boneh, Bonneau, Bünz, Fisch, IACR ePrint 2018/601, https://eprint.iacr.org/2018/601

[9] Order-Fairness for Byzantine Consensus, Kelkar et al., IACR ePrint 2020/269, https://eprint.iacr.org/2020/269

[10] Themis: Fast, Strong Order-Fairness in Byzantine Consensus, IACR ePrint 2021/1465, https://eprint.iacr.org/2021/1465

[11] Proposer-builder separation, ethereum.org, https://ethereum.org/roadmap/pbs/

[12] MEV-Boost Overview, Flashbots Docs, https://docs.flashbots.net/flashbots-mev-boost/introduction