Web3初心者シリーズ：新しいオンチェーン決済プロトコルの探究 – x402

Coinbaseは最近、新しい決済プロトコル「x402」を発表しました。x402はCoinbaseが主導しているため、当然のことながらBase Sepoliaをサポートし、デフォルトで利用可能です。さらに、既にSolanaチェーンをサポートしているため、x402は特定のチェーンに縛られていないことが証明されています。

https://github.com/coinbase/x402

プロセスを理解するために、サーバー、クライアント、ファシリテーターのすべてのコンポーネントを含む新しいリポジトリ（https://github.com/gin-lsl/x402-solana-demo）を作成しました。ここでは、クライアントがDevnetのUSDC（カスタムトークン）を支払うことで、サーバーが提供する特定のインターフェースにアクセスできるようにするために、ベースフレームワークとしてKoaを選択しました。

いくつかの説明

まず、spl-token ツールを使用して対応するトークンを作成しました。こちらで確認できます: https://solscan.io/token/9gKBTRXgVTszU31A12oJKKSy6aje8LyoVvNfSimembHo?cluster=devnet

Solanaが選ばれたのは、このチェーンが非常に開発者フレンドリーであり、誰もが開発とテストを行えるほぼ無制限のテストトークンを提供しているためです。Solanaは障壁を設けず、ログインもソーシャルメディアアカウントの連携も不要で、メインネット上に残高のあるウォレットも必要ありません。

プロジェクトを実行する必要がある場合は、.env ファイルを作成し、必要な環境変数を入力してから、サーバーを起動し、ターミナルでクライアント コードを実行する必要があります。

コードの説明

これはデモンストレーション目的のため、単に1か所にまとめられています。以下に主要なドキュメントの説明を示します。

ソラナ

「/solana/get-balance」というインターフェースを提供しています。これは、少額の手数料がかかる価値あるインターフェースであると想定しています。サーバーとして、これはシーケンス図の(5)から(8)、具体的には(7)に相当します。

通常、サーバーはビジネスロジックのみを処理し、オンチェーントランザクションを処理する必要はありません。そのため、システム開発者がWeb3に精通していなくても、ビジネスロジックに最小限の変更を加えるだけでWeb3決済手段を統合できます。

ファシリテーター.ts

これはFacilitatorの機能を実装しており、主に/supported、/verify、/settleインターフェースを提供します。これらのインターフェースは、それぞれ現在サポートされているチェーンのクエリ、トランザクションデータの検証、オンチェーン決済機能の提供に使用されます。チェーンとのやり取りはここで行われ、オンチェーン取引手数料の支払いには秘密鍵が必要です。アーキテクチャ的には、シーケンス図の(9)と(10)に対応するサーバー（solana.ts）とは独立しています。

独自のFacilitatorサービスを提供する場合でも、この部分のコードは実際には標準化されており、基本的に公式パターンを直接利用でき、独自に実装する必要はありません。ただし、現時点では公式サポートはbaseのみに完全対応しています。他のチェーンを使用する場合は、ある程度の適応作業が必要です。具体的には、シミュレートされたトランザクションをチェーンに送信して検証する（「x402」が既にサポートしているチェーンであれば、verify関数を直接呼び出すことができます）、そして正式にトランザクションをチェーンに送信して最終確認を待つ（「x402」が既にサポートしているチェーンであれば、settle関数を直接呼び出すことができます）という手順です。

Solanaチェーンでは、リクエストがPOST /settleに到達すると、「x402/facilitator」内のsettle関数が呼び出されます。いくつかの検証の後、RPCのsendTransactionが呼び出されてトランザクションが送信され、waitForRecentTransactionConfirmationがトランザクションの結果を待機して確認します。関連コードは@solana/kitによって提供されています。EVM部分も同様のロジックに従います。

x402-ミドルウェア.ts

サーバーとファシリテーターを接続するために使用され、Koaミドルウェアとして機能し、アクセスに料金が必要なAPIを保護します。コードは公式の「x402-express」を参照しています。その機能は、自動的に402ステータスを返し、/verifyおよび/settleリクエストを転送することです。

このセクションのコードは、基本的に様々なパラメータを組み立ててファシリテーターに転送したり、クライアントに返したりするだけです。テストを容易にし、詳細に踏み込みすぎないようにするため、ほとんどのパラメータを固定値として記述しました。具体的には以下のとおりです。

• maxAmountRequired を非常に大きな値に設定すると、クライアント側で実際に検証されます。ユーザーが支払う必要のある金額がこの値よりも高い場合は、例外が直接スローされます。
• アセットは、x402に組み込まれているトークンアドレスではなく、独自に作成したトークン（9gKBTRXgVTszU31A12oJKKSy6aje8LyoVvNfSimembHo）に設定されました。メインネットでは、これが公式USDCアドレスとなるはずです。

興味深いことに、x402-expressはレスポンスの関数を書き換えることで、Koaライクなオニオンモデルを実装しています。そのため、Express向けミドルウェアでは、実際のフローは検証→ビジネスロジック→決済となります。ブロックチェーンへの送信はビジネスロジックの実行後に行われ、これは確かに上記のシーケンス図と一致しています。このロジックの実装はKoaでは非常にシンプルですが、Expressでは追加のコードが必要になります。これが、Expressミドルウェアの提供を優先した理由かもしれません。

支払いクライアントフェッチ.ts

クライアントとして動作し、フローチャートのステップ1から4に対応するリクエストをサーバーに発行します。この処理では、「x402-fetch」が提供するヘルパー関数を利用して、402ステータスを自動的に処理し、クライアントウォレットの秘密鍵を使用して署名を生成し、データを再送信します。

インターフェースへの直接リクエストを試みます。402エラーが発生した場合、返されたコンテンツ（サーバーがサポートするx402バージョン（現在は1に固定）とサーバーに必要なパラメータを含む）を読み取り、秘密鍵を使用してトランザクションに署名し、トランザクション情報をシリアル化して、X-PAYMENTヘッダーを介して元のURLに再送信します。

プロジェクトの基本構造を理解した後、次のコマンドを使用してサーバーとクライアントを実行できます。

クライアント実行結果とログ:

考える

私の意見では、Web3 開発者のこれまでの取り組みが、一般ユーザーが Web3 を使用するための参入障壁を下げ、エンドユーザーが Web3 エコシステム (支払い、投資など) をより簡単に利用できるようにすることを目的としていたとすれば、現在の x402 は、Web2 開発者が Web3 支払いチャネルにアクセスするための参入障壁を下げるために作成されたものです。

x402/clientセクションで提供されているヘルパー関数は便利ですが、本来の機能しか果たしません。ユーザーは既にウォレット経由でUSDCやその他の通貨で簡単に支払いを行うことができます。そのため、相対的に言えば、x402は開発者やサービスプロバイダーにとってより重要な機能と言えるでしょう。

しかし、x402の普及には依然として多くの課題が伴います。大企業は独自の社内決済システムを有しており、新しい標準規格の導入に対する姿勢やペースもそれぞれ異なります。新しい決済手段を既存のシステムに統合することは、必然的に長く困難なプロセスとなります。さらに、大企業は決済手段の統合に際して規制上の影響を考慮する必要があり、より利便性の高い決済手段を放棄し、従来型の複雑なソリューションを使い続けざるを得なくなる可能性もあります。

おそらくNode RPCプロバイダーはそれを好むでしょう。RPCプロバイダーは、基本的なインターフェースの提供に加えて、多くの高度なAPIやトランザクションアクセラレーションインターフェースなどを提供しています。これらがx402を通じて提供されれば、より多くの人々が彼らのサービスを体験できるかもしれません。

最後に、x420自体は基本的な決済プロトコルに過ぎないことに留意してください。その意義は、標準化された技術仕様を提案することにあります。標準化が認められることで、開発者やあらゆる規模の企業がエコシステム全体の改善に向けて協力しやすくなります。新しい標準の提案は合理的に捉え、誇大広告を出す人たちが仕掛ける物語の罠に陥らないようにすべきです。

この記事はZAN Team（Xアカウント@zan_team ）によって書かれました。