x402曝31漏洞：開放協議爲何急需中心化問責層？

據 Woofun AI 消息，x402 支付協議近期暴露出嚴重的安全隱患，Akiba（@akibablade）基於即將在 USENIX Security 2026 會議上發表的論文指出，該協議存在 31 個新漏洞，導致 99% 的交易面臨資產盜竊風險。

這一發現不僅揭示了當前加密支付基礎設施的脆弱性，更引發了關於開放協議是否需要引入中心化問責層的深層討論。核心問題在於，當驗證與結算邏輯被委託給第三方時，缺乏相應的資本約束與責任機制，使得系統極易受到攻擊。

深入剖析這些漏洞，研究者定義了 facilitator（支付促進者）應遵守的八條安全規則，違反這些規則會引發四類攻擊：免費購物、資產盜竊、服務拒絕和 Gas 濫用。在對 15 家主要 facilitator 進行的評估中，發現了 49 項規則違規和 31 個此前未知的漏洞。研究結果已私下披露給相關運營方，部分問題已得到修復，其餘問題的修復工作正在進行中。這項研究之所以能開展，是因爲 x402 從一開始就作爲開放協議開發，其協議規範和參考 SDK 均公開。

x402 協議已於 4 月 2 日移交 Linux 基金會，x402 Foundation 也於 7 月 14 日正式啓動運營，擁有 40 名成員。這爲在規範和參考實現層面討論發現結果提供了官方論壇。研究者還發布了 x402scope 的公開版本，已移除敏感的利用代碼，並正與 Coinbase 及其他主要生態參與者討論，如何將其規則檢查整合進開發和部署前驗證流程。

從信任架構的角度看，x402 的實際運作方式存在根本缺陷。任何人都可以運營服務器或成爲 facilitator，但系統並非完全無信任。論文把 facilitator 定義爲"承擔信任的中介"。一旦驗證和結算被委託出去，用戶就必須對 facilitator 投入相當程度的信任。

然而，信任被集中了，協議卻沒有要求相應的資本、問責機制或支付確定性。這一缺口體現在設計的三個部分。第一，verify（驗證）更像是在預測"此時結算仍然可行"，而不是像信用卡授權那樣。它檢查簽名、餘額、nonce 和過期時間，但既不鎖定資金，也不消耗 nonce。第二，verify → 業務邏輯 → settle（結算）的分離本意是保護消費者和商家，但協議沒有機制通過共享狀態把驗證和結算綁定在一起。

如果商家基於 facilitator 的驗證結果採取行動，而後續結算失敗，商家就要承擔全部損失。第三，許多 facilitator 會贊助鏈上結算成本，攻擊者可以操縱執行路徑，讓 facilitator 支付由此產生的 Gas 費用。在 Solana 上，攻擊者甚至可能誘導 facilitator 爲攻擊者控制的賬戶支付租金。

Woofun AI 整理數據顯示，相比之下，信用卡支付也分離了授權和扣款，但髮卡行在授權時會預留持卡人的部分信用額度或資金，網絡規則隨後爲商家提供一定程度的支付確定性。

如果出問題，還有授權撤銷、拒付、商家制裁和爭議處理程序可用。x402 沒有髮卡行來鎖定資金並擔保支付，服務器因此通過 verify 檢查支付可行性，執行業務邏輯，然後再調用 settle。問題在於，兩端並不共享狀態，驗證之後，餘額、nonce 或有效期都可能發生變化。

如果服務器在結算前執行了不可逆操作，商家就可能蒙受損失。如果 facilitator 提交了被操縱的交易，它可能損失 Gas 或自己控制的資產。卡網絡通過髮卡行資本和風險管理團隊承擔了這種信任成本，再通過手續費收回。x402 移除了那個角色，卻沒有移除成本。因此，實際路徑是否需要在開放協議之上建立一個問責層？這裏的中心化並不意味着把整個 x402 協議交給單一運營方，每條支付路由都應有明確的責任主體。多個運營方仍可在同一開放標準下競爭，用戶也能切換 facilitator。

這種結構集中了運營責任，同時保留了協議開放性和提供商之間的競爭。

Cloudflare 的 Monetization Gateway 就是一個可能的例子，它保留了 x402 的可編程支付格式，同時在單一控制層處理支付策略、驗證和訪問控制。另一條路徑是使用專業 facilitator，提供服務等級協議、Gas 限額、結算前再驗證和事件響應。ERC-8004 和聲譽系統看似提供了替代方案，但聲譽只是評估風險的額外信號，它既不預留資金，也不提供支付擔保。單靠聲譽無法填補問責缺口。

這一視角也要求重新審視發現層的角色和結構，該層可以超越單純列出可用服務，成爲信任和路由層，篩選哪些資源和 facilitator 符合既定安全標準。如果需要支付擔保，它可以明確區分提供擔保的中心化運營方和支付路由。從這個角度看，有兩個關鍵玩家值得關注：CDP（@CoinbaseDev）的整合策略把 Agentic Wallet、CDP Facilitator 和 Bazaar 結合在一起，在一個技術棧中提供錢包、支付、合規和發現功能。

Orthogonal（@orthogonal_sh）的整合策略把服務發現、API 密鑰池、響應標準化和計費統一在一個賬戶、一個餘額和一張發票下。它支持 credits、x402 和 MPP，這把管理多個提供商和支付方式的複雜性放進了中央網關。這些策略目前還談不上支付擔保或損失吸收，但它們把碎片化的錢包、驗證、計費和發現功能置於單一運營方之下，爲中心化問責層提供了基礎。

如果中心化問責層變得普遍，支付結構本身也可能改變。一種可能的模型是把 verify → 業務邏輯 → settle 替換爲 verify → settle → 業務邏輯。當前順序保護消費者，前提是結算不可逆。一旦運營方接受退款和爭議處理責任，這一假設就會改變。可以先確認結算，消除商家的未付款風險。

如果後續執行失敗，運營方可以退款給消費者。運營方則需承擔最終結算前的流動性需求和結算義務，這讓其資本和問責結構變得更加重要。這種模型並不遵循 x402 當前的逐筆結算流程，x402 將繼續作爲溝通支付條款和授權數據的開放接口。運營方會聚合實際資金流動，並在鏈上完成最終結算。單筆支付記錄保留在運營方內部賬本，區塊鏈則記錄聚合後的最終結算。因爲內部賬本可逆，這種結構降低了不可逆支付的問題。運營方也可以像髮卡行一樣處理退款和爭議。有人可能會問："這不就是把區塊鏈當成共享支付數據庫嗎？"是的。更準確地說，區塊鏈會成爲記錄運營方之間最終餘額的共享結算賬本。單筆支付則留在鏈外。至少在這個市場中，可靠地扮演這一角色或許已經足夠。系統仍可利用低結算成本和可編程貨幣的優勢。