開放協議的信任陷阱：x402 為何需要中心化責任層？

By: rootdata|2026/07/30 11:00:31

x402 支付協議曝出 31 個新漏洞，99% 交易面臨資產盜竊風險。

撰文：@Jun__Yoo

編譯：AididiaoJP，Foresight News

CryptoSlate 的 Akiba（@akibablade）近日發表文章，標題為《新發現的 31 個漏洞讓 99% 的 x402 加密支付面臨資產盜竊和免費購物風險》。

這篇文章基於一篇題為《當 HTTP 402 遇上區塊鏈：新興 x402 支付的風險》的論文。該論文已被接受，將在 USENIX Security 2026 會議上發表。

論文重點研究了 x402 如何將支付證明驗證和鏈上結算委託給第三方 facilitator（支付促進者）。這種設計把信任和驗證邏輯集中到多個獨立商家共用的支付基礎設施上。一旦某個 facilitator 出現漏洞，就可能影響大量服務。

研究者還定義了 facilitator 應遵守的八條安全規則。違反這些規則會引發四類攻擊：免費購物、資產盜竊、服務拒絕和 Gas 濫用。他們對 15 家主要 facilitator 進行了評估，發現了 49 項規則違規和 31 個此前未知的漏洞。研究結果已私下披露給相關運營方。部分問題已得到修復，其餘問題的修復工作正在進行中。

這項研究之所以能開展，是因為 x402 從一開始就作為開放協議開發。其協議規範和參考 SDK 均公開，研究者得以從中推導出支付流程的安全規則。他們使用開源 SDK 和自己搭建的測試商家完成了研究。

開源並不能消除漏洞，但它提供了一條路徑，讓外部發現的缺陷可以轉化為共享的安全標準。x402 協議已於 4 月 2 日移交 Linux 基金會，x402 Foundation 也於 7 月 14 日正式啟動運營，擁有 40 名成員。這為在規範和參考實現層面討論發現結果提供了官方論壇，而不再局限於單個供應商的補丁。

研究者還發布了 x402scope 的公開版本，已移除敏感的利用代碼。他們正與 Coinbase 及其他主要生態參與者討論，如何將其規則檢查整合進開發和部署前驗證流程。

協議成熟度的討論到此為止。我想從這些發現中再提出一個更基礎的問題。

與其把 x402 本身中心化，一個開放協議是否需要一個中心化的問責層，來強制執行驗證標準，並承擔安全事件帶來的結算成本和損失？

中心化並不自動等於安全。但在支付領域，行使權力的一方，也應該承擔失敗的代價。

看看 x402 的實際運作方式。任何人都可以運營伺服器或成為 facilitator。但系統並非完全無信任。論文也把 facilitator 定義為「承擔信任的中介」。一旦驗證和結算被委託出去，用戶就必須對 facilitator 投入相當程度的信任。

問題在於，信任被集中了，協議卻沒有要求相應的資本、問責機制或支付確定性。這一缺口體現在設計的三個部分。

第一，verify（驗證）更像是在預測「此時結算仍然可行」，而不是像信用卡授權那樣。它檢查簽名、餘額、nonce 和過期時間，但既不鎖定資金，也不消耗 nonce。

第二，verify → 業務邏輯 → settle（結算）的分離本意是保護消費者和商家。協議沒有機制通過共享狀態把驗證和結算綁定在一起。如果商家基於 facilitator 的驗證結果採取行動，而後續結算失敗，商家就要承擔全部損失。

第三，許多 facilitator 會贊助鏈上結算成本。攻擊者可以操縱執行路徑，讓 facilitator 支付由此產生的 Gas 費用。在 Solana 上，攻擊者甚至可能誘導 facilitator 為攻擊者控制的賬戶支付租金。

信用卡支付也分離了授權和扣款。區別在於，發卡行在授權時會預留持卡人的部分信用額度或資金。網絡規則隨後為商家提供一定程度的支付確定性。如果出問題，還有授權撤銷、拒付、商家制裁和爭議處理程序可用。

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 將繼續作為溝通支付條款和授權數據的開放接口。運營方會聚合實際資金流動，並在鏈上完成最終結算。單筆支付記錄保留在運營方內部賬本，區塊鏈則記錄聚合後的最終結算。因為內部賬本可逆，這種結構降低了不可逆支付的問題。運營方也可以像發卡行一樣處理退款和爭議。

有人可能會問：

這不就是把區塊鏈當成共享支付數據庫嗎？

是的。

更準確地說，區塊鏈會成為記錄運營方之間最終餘額的共享結算賬本。單筆支付則留在鏈外。至少在這個市場中，可靠地扮演這一角色或許已經足夠。系統仍可利用低結算成本和可編程貨幣的優勢。