Polymarket V2上線，幽靈訂單問題解決了嗎？

ODAILY星球日报

閱讀本文需 10 分鐘

預測市場可以交易未來，但交易系統不能讓「成交了沒」也變成一場預測。

原文標題：《Polymarket V2 上線，幽靈訂單修好了嗎？》
原文作者：Asher，Odaily 星球日報

昨晚，Polymarket 進入維護窗口，暫停交易並清空訂單簿，隨後正式上線 CLOB V2。

按照官方此前披露，這次升級包括新合約、新訂單簿、新抵押代幣 Polymarket USD，以及新版 CLOB-Client SDK。對用戶來說，PUSD、SDK、訂單結構這些變化未必馬上有明顯感知。

真正第一時間值得關注的，是長期困擾 Polymarket 的 Ghost Fills，也就是社區常說的「幽靈訂單」問題。

V2 的確對這個問題做了處理。此前最容易被利用的 nonce 機制被移除，訂單結構和撤單方式也發生了變化。

但這並不意味著幽靈訂單已經徹底消失，因為 Polymarket 的核心交易模式仍然是鏈下撮合、鏈上結算，只要這兩個環節之間存在時間差，類似問題就很難被完全抹掉。

訂單顯示成交，為什麼最後失敗？

所謂幽靈訂單，簡單說就是一筆訂單在鏈下看起來已經撮合成功，但最終沒有在鏈上完成結算。

Polymarket 採用的是鏈下訂單簿撮合，再回到鏈上完成結算的模式。這種設計的優勢很明顯，交易速度更快，成本更低，也更適合 5 分鐘市場這類短周期、高頻次的預測市場。

問題也正出在這個時間差上。鏈下訂單簿已經顯示成交，並不意味著鏈上結算一定成功。

在一些短周期市場裡，用戶可能看到訂單已經顯示成交，以為自己已經買到了對應方向；但等到交易真正提交到鏈上時，結算卻失敗了。前一秒看起來已經完成的交易，後一秒又被系統撤回。

對用戶來說，這種體驗最難受的地方不是單純失敗，而是不確定性。以為已經完成買入或賣出，結果最後沒有成交；等重新下單時，價格可能已經變了，交易機會也可能已經錯過。

舊版本的問題，是撤單成本太低

在 V1 中，幽靈訂單最容易被利用的一條路徑來自 incrementNonce。nonce 可以理解為訂單裡的狀態標識。原本它是為了幫助系統管理訂單，但在舊版本中，攻擊者可以通過呼叫 incrementNonce，讓某個地址下帶有舊 nonce 的訂單在鏈上結算時失效。

這就給了攻擊者一個時間差操作空間。攻擊者可以先讓訂單在鏈下完成撮合，讓系統顯示「成交已經發生」；隨後在結算真正上鏈之前更新 nonce，使這些訂單最終執行失敗。結果就是，一筆看似已經完成的交易，最後沒有在鏈上真正落地。

問題的關鍵在於，這種操作成本極低，卻能影響一批訂單。攻擊者只需要付出很低的 gas 成本，就能讓本應成交的訂單在結算階段失敗。前端看到的是訂單先成交、後失敗，實際造成的是交易結果不穩定，甚至讓用戶錯過原本的成交價格和交易機會。

幽靈訂單問題不是簡單的前端顯示錯誤，也不是偶發的鏈上失敗，而是會直接影響用戶對交易結果的信任。

V2 做了修補，但不是徹底根除

這次 V2 最關鍵的變化，是移除了原來的全局 nonce 設計。也就是說，過去通過 incrementNonce 一次性影響一批舊訂單的方式，已經被堵上了。同時，V2 簡化了訂單結構，撤單也轉向更細粒度的單筆 order hash。相比舊版本，撤單影響範圍被明顯壓縮，攻擊者很難再用一次低成本操作破壞大量掛單。

這對幽靈訂單問題是一次實質性修補。過去的問題在於，攻擊成本低、影響範圍大，複現門檻也不高。

V2 之後，最容易被利用的一條路徑被移除。攻擊者如果想繼續製造類似問題，需要付出更高成本，也更依賴具體的系統響應。此外，pauseUser 等機制加入延遲，也是在減少某些狀態變化在撮合和結算窗口內被即時濫用的可能。

整體來看，V2 的方向比較清楚：先處理最容易被攻擊者利用的環節，再降低類似攻擊的收益空間。

但這還不能等同於幽靈訂單被徹底解決。原因在於，Polymarket 仍然沒有改變鏈下撮合、鏈上結算的基本模式。

只要訂單不是在同一個環境中完成撮合和結算，鏈下與鏈上之間就一定存在狀態差。餘額變化、授權問題、訂單狀態變化、撤單行為或合約執行失敗，都可能讓一筆鏈下已撮合的訂單，最終無法在鏈上落地。

換句話說，V2 解決的是舊版本裡最明顯、最容易被利用的攻擊路徑，而不是幽靈訂單產生的基礎條件。