x402協議2.0版本借鑑產品部署實踐經驗，實現了架構層面的根本性變革。該協議在處理超1億筆交易後，研發團隊鎖定了關鍵痛點問題，並圍繞三大目標重新設計協議，分別是層級劃分清晰化、跨區塊鏈擴展性及契合網絡標準。
2.0版本有哪些更新
傳統支付與x402智能代理支付對比
傳統支付流程需經過多個手動操作步驟，且離不開人工干預。而x402通過實現自主即時支付，徹底解決了這一繁瑣問題。
2.0版本的架構優化
統一支付接口
2.0版本默認支持多鏈支付。僅需一個API，無需修改代碼，就能接收基於Base、Solana等所有兼容區塊鏈上的USDC支付。
網絡標識：採用CAIP-2標準
1.0版本採用“base-sepolia”“base”等自定義網絡標識，2.0版本則採用了CAIP-2（跨鏈通用改進提案2，Chain Agnostic Improvement Proposal 2），該標準採用“命名空間：引用標識”的格式。這一調整使其不僅能適配各類區塊鏈，甚至可兼容非區塊鏈支付通道。
支付請求結構優化
1.0版本中，每一種支付方式都需重複填寫資源元數據。若某服務器支持三種代幣支付，就需重複填寫三次URL、描述信息及內容類型。2.0版本將這類信息整合至共享資源對象中，既縮減了信息傳輸體量，也避免了數據不一致的問題。
擴展功能框架
2.0版本新增標準化擴展功能體系，其涵蓋的可選功能可獨立於核心支付機制運行。每一項擴展功能都包含一個info對象與一個schema對象，info對象存儲該擴展的專屬數據，schema對象則通過JSON Schema定義數據結構。
支付方式明確化
1.0版本依靠字段匹配規則判斷客户端選定的支付方式，2.0版本則新增“accepted”字段，該字段會完整記錄用户選定的支付需求，使支付方式選擇更加明確。
HTTP傳輸層優化
符合RFC 6648標準
互聯網工程任務組（IETF）已棄用HTTP請求頭中“X-”前綴。原因是很多實驗性請求頭雖已成為事實標準，卻始終被標記為實驗性狀態。2.0版本刪除了這類前綴，並將支付相關配置信息從響應體遷移至請求頭中。如此調整的原因在於：將協議元數據與應用內容分離後，服務器既能向瀏覽器返回定製化的HTML付費牆頁面，又能在請求頭中保留機器可讀取的支付配置信息，進而提升中間件兼容性與框架集成度。
SDK重構
從硬編碼到模塊化架構
1.0版本的SDK將區塊鏈專屬邏輯嵌套在多層條件判斷語句（if/else chains）中。若要新增適配的區塊鏈，需修改核心文件併發布SDK新版本。2.0版本新增三大接口，實現了區塊鏈適配的即插即用功能。
構建器模式註冊機制
開發人員可通過CAIP-2通配符註冊區塊鏈適配方案。SDK會依據網絡模式，將操作指令定向至對應的適配方案。
通配符匹配規則具體如下：
- eip155:* 可匹配所有EVM鏈；
- solana:* 可匹配所有Solana網絡；
- eip155:8453 則專門匹配Base主網。
Lambda策略引擎
1.0版本中錢包類型與支付方案均採用硬編碼形式。2.0版本引入可組合策略函數，用於支付過程中的實時支付授權操作。
Hook系統
1.0版本的業務邏輯執行於驗證完成後、支付結算前。一旦結算失敗，服務器可能已執行文件傳輸、API調用、數據庫寫入等不可逆操作。2.0版本新增六個生命週期鈎子（lifecycle hooks）以解決該問題。
動態配置功能
2.0版本的中間件（middleware）支持按路由配置參數，同時搭配回調函數，實現運行時決策。
Facilitator API升級
功能公示
如今“/supported”端點可公示三項核心功能，分別是按協議版本分類的兼容支付類型、結算專用簽名地址以及已啓用的擴展功能。
自動識別功能
自動識別擴展功能支持服務端對外公示結構化元數據，以便系統自動建立索引。協調器（Facilitators）可自動檢索支持x402協議的端點，實時更新價格目錄，無需人工手動提交信息。
版本遷移方案
2.0版本藉助命名空間隔離（namespace isolation）技術，保障了對舊版本的向後兼容性。同一套SDK、協調器（Facilitator）及服務器可同時兼容兩個版本。客户端通過“x402Version”字段指定所需版本，系統會匹配對應的協議版本並作出響應。
原文：https://x.com/yq_acc/status/1999606689641955337
作者：@yq_acc
（OpenBuild 翻譯整理，原文有刪減）
