Web3新手系列：探索鏈上支付新協定－ x402

Coinbase 在前幾天公佈了新的支付協議：x402。由於x402 由coinbase 發起，所以理所當然的支援base sepolia，並且預設可用。並且已經對Solana 鏈提供了支持，證明了x402 並沒有綁定某個鏈。

https://github.com/coinbase/x402

為了弄清楚流程，我新建了一個倉庫（https://github.com/gin-lsl/x402-solana-demo），裡麵包含全部的Server、Client 和Facilitator。這裡選擇Koa 作為基礎框架，實作client 能夠透過支付Devnet 的USDC（自訂的Token），取得伺服器提供的某個介面的存取權限。

一些說明

首先我使用spl-token 工具建立了對應的token，可以在這裡看到https://solscan.io/token/9gKBTRXgVTszU31A12oJKKSy6aje8LyoVvNfSimembHo?cluster=devnet

這裡選擇Solana 是因為這條鏈對開發者很友好，幾乎提供了無限量的測試代幣供所有人開發和測試，它不設置任何門檻，不需要登錄、不需要綁定任何社交帳號、不需要錢包在主網上有餘額。

如果需要運行項目，需要建立一個.env 並填寫所需的環境變量，然後在終端啟動伺服器並執行客戶端程式碼：

程式碼解釋

由於只是作為演示所用，所以僅僅是簡單的將它們放在了同一個地方。以下是一些主要的文件說明：

solana.ts

它提供了一個“ /solana/get-balance ”接口，我們假設這是一個很有價值的接口，調用它需要支付一小筆錢。作為Server 的角色，對應序列圖中(5) ~ (8) 部分，更深入地說，是其中的(7)。

通常Server 只涉及業務需求的處理，不需要涉及鏈上交易等邏輯。所以，如果某個系統的開發人員不懂Web3，也能夠在盡量不改變自己的業務代碼的前提下，接取Web3 的支付方式。

facilitator.ts

它實現了Facilitator 的能力，主要是提供了/supported, /verify, /settle 接口，分別用於查詢當前支援的鏈、驗證交易資料以及上鍊結算能力。這裡是與鏈互動的地方，它需要私鑰以便能夠支付鏈上交易的費用。它在架構上是獨立於Server（也就是solana.ts）的，對應序列圖中的(9) 和(10)；

即使你決定自己提供Facilitator 服務，這部分的程式碼其實也是標準化的，基本上可以直接使用官方提供的模式而不需要自行實作。不過目前官方只對base 有完整的支持，如果想要使用其他鏈，就需要一些適配工作。其中主要是需要將模擬交易傳送到鏈上來驗證交易（如果是「 x402 」已經支援的鏈，則可以直接呼叫verify 函數），以及將交易正式提交到鏈上並等待交易最終確認（如果是「 x402 」已經支援的鏈，則可以直接呼叫settle 函數）。

對於Solana 鏈來說，在請求走到POST /settle 後，調用了“ x402/facilitator ”中的settle 函數，裡面經過一些驗證後，調用了rpc 上的sendTransaction 發送交易，然後通過waitForRecentTransactionConfirmation 等待並確認交易結果，所涉及到的代碼通過。 EVM 部分也是類似的邏輯。

x402-middleware.ts

用於將Server 和Facilitator 關聯起來，它作為一個Koa 中間件，能守衛需要付款才能調用的接口，代碼參考了官方提供的“ x402-express ”。作用是自動回傳402 狀態、轉送/verify 和/settle 請求；

我在這部分的程式碼實際上只是在拼裝各種參數，並將其轉發給facilitator 或返回給客戶端。為了方便測試，避免涉及太多細節，我將大部分參數寫成了固定值。其中包括：

• 將maxAmountRequired 設定的非常大，這個值實際上在client 中會被校驗，如果使用者需要支付的金額高於它，則直接會拋出例外。
• 將asset 設定為了我們自己創建的Token: 9gKBTRXgVTszU31A12oJKKSy6aje8LyoVvNfSimembHo，而不是x402 中內建的Token 位址。在主網，它應該是USDC 官方的地址。

有趣的是，x402-express 透過重寫Response 上的函數，實現了類似Koa 的洋蔥模型。所以在他們對express 提供的中間件中，實際流程是verify -> 業務邏輯-> settle。提交上鍊是在執行業務邏輯之後進行的，這確實符合上面的序列圖。在Koa 中實作這個邏輯非常簡單，Express 中則需要一些額外的程式碼，這也可能是他們優先提供了express 中介軟體的原因。

payment-client-fetch.ts

扮演客戶端角色，對伺服器發起請求，對應流程圖中1 ~ 4。其中使用了「 x402-fetch 」提供的幫助函數，自動處理402 狀態、使用客戶端錢包的私鑰產生簽章並重新發送等；

它會嘗試直接請求接口，遇到402 錯誤後，會讀取返回的內容（裡面應該包含伺服器支援的x402 版本，目前固定為1, 以及伺服器需要的必填參數），透過你的私鑰對交易簽名，然後將交易資訊序列化後透過X-PAYMENT Header 再次發送到原url。

了解專案的基本結構後，我們可以透過以下命令執行Server 和Client：

客戶端的執行結果及日誌：

思考

個人認為，如果說Web3 開發者們之前所做的努力，是為了降低一般用戶使用Web3 的門檻，讓最終用戶能夠更方便的使用Web3 的生態（付款、投資等）。那麼現在的x402，則是為了能夠降低Web2 開發者們接觸到Web3 支付管道的門檻而誕生的。

x402/client 部分提供的幫助函數雖然有用，但也只是做了它應該做的事情。現在用戶能夠透過錢包支付USDC 等，實際上已經很方便了。所以相對來說，x402 對於開發者和服務提供者的意義可能更大。

但是x402 真正大範圍應用仍然會遇到很多問題。有些大型公司內部會有結算系統，在如何對接新的標準方面，會有自己的態度和節奏，想要將一個新的支付方式整合到自己現有的系統中，必然還需要很遠的路要走。而大型公司在對接支付時，必然要考慮監管方面的影響，這也可能導致他們不得不放棄更方便的支付方式，依舊使用流程複雜的傳統方案。

也許Node RPC 提供方會對它更加青睞，RPC 提供者除了提供基礎接口，還會提供許多Advance API、交易加速接口等，這部分如果能透過x402 提供，也許能讓更多人體驗他們的服務。

最後請注意，x420 本身只是一個基礎的支付協議，它的意義是提出了一套規範的技術標準，而有了公認的標準後，則能更方便的讓開發者和各個大中小型公司一起針對標準完善整個生態。我們應該理性的看待新標準的提出，避免陷入炒作者們的敘事陷阱。

本文由 ZAN Team（X 帳號@zan_team ）撰寫。