jakiro
著者: ハオティアン;出典: X、@tmel0211
x402 トラックの大規模インフラはまだ空白の状態です。大きな市場によって奪われた「タイミング」は、Launchpad などのアプリケーション層や Facilitator などの中間層を一時的に沈黙させましたが、基盤となるインフラストラクチャ層に、より多くのビルド時間枠を与えます;
Switchboard は、Solana エコシステムによって開発されたオラクル プロジェクトです。最近、x402 プロトコルにデータ サービス層を提供することが提案されました。具体的にはどうすればよいでしょうか？
1) 技術アーキテクチャの点で、Switchboard は TEE の信頼された実行環境を使用します。これは、ネットワーク検証に依存する Chainlink や Pyth などの従来のコンセンサス モデルとは異なります。データは安全なエンクレーブに基づいてチェーンに直接送信されます。
2) プロトコルの互換性の点では、Switchboard は x402 プロトコル標準と互換性があり、AI エージェントが HTTP 402 経由でデータ要求を直接開始し、オンチェーンのマイクロペイメントを使用して承認を完了すると、データがすぐに返されます。プロセス全体では、追加のアダプテーション層や中間コントラクトは必要ありません。
3) In terms of billing model, it breaks the traditional oracle subscription model and supports pay-per-call – the agent is paid based on the number of calls and data points, and you pay for how much you use.これは、x402 プロトコルの従量課金制の設計概念と完全に一致しています。
4)) さらに根本的な点は、Switchboard が API キー メカニズムを完全に削除していることです。従来のモデルでは、データ サービスを呼び出すには、まず登録し、キーを申請し、アクセス許可を管理する必要があります。このプロセスはエージェントにとって大きな負担となります。現在、402 トランザクション リクエストに十分な量を入力しているユーザーは、登録や承認なしであらゆるデータ ソースに即座にアクセスできるようになりました。
ここで問題が発生します。x402 プロトコルには専用の Oracle サービス層が必要ですか?
まずはコンセプトを明確にしましょう。 x402 プロトコル アーキテクチャでは、ファシリテーターは支払い促進、つまり代理支払い、ブロードキャスト トランザクション、ステータス確認を担当し、「お金の流れ」の問題を解決します。価格の取得、計算の実行、LLM 推論の呼び出しなど、エージェントが実際に呼び出す API サービスは、プロバイダー層によって提供されます。
Switchboard がやりたいことは特別なプロバイダーです: チェーン上で信頼できるデータ サービスを提供することに特化し、エージェントの価値を伝達するためのコア情報層を構築するプロバイダー。
想像してみてください。プロバイダーが集中型 API であり、データが改ざんされたり、サービスがダウンしたりしたらどうなるでしょうか? Web2 シナリオでは、これらのリスクはチャネル ブランドと法的契約によってカバーされますが、オンチェーン実行環境、特に複雑な DeFi 運用に関しては、検証可能なオンチェーン データが必要です。
ERC-8004 が購入者エージェントの ID の信頼性と評判の問題を解決する場合、このタイプのオラクル指向のプロバイダーは、販売者 (API) データの信頼性検証の観点から信頼性保証の層を提供することになります。
本質的に、x402 プロトコルはエージェント サービス マーケットの支払い層を構築し、スイッチボードはデータ サービス層を構築します。支払い層がお金の流通を許可する場合、データ サービス層は信頼できるデータの流通を許可します。
この 2 つを組み合わせることで、Agentic Economy は完全なインフラストラクチャを実現します。
