Polygonが報告した内容
Polygonは9月24日、高頻度の従量課金向けエージェント決済チャネルを発表しました。支払側は複数回利用できるチャネルへ資金を預け、セッションキーを紐付けます。サービス提供に応じてエージェントが累積額を署名した決済更新をハブへ送り、ハブは署名、価格、リプレイ識別子、認可上限、残存エスクローを検証してレシートを返します。その後、ハブは状態をエポック単位のMerkle rootへまとめてPolygonへ記録し、提供者は収益を証明して請求できます。
Polygonによると、ライブのdevnetでx402の全経路を試したテストは240万件を成功率100%、毎秒約4万件で処理しました。24コアサーバー1台のエンジン直接試験は毎秒53.3万〜53.6万件、独立してスケールする16 vCPUのハブ25台は毎秒1,100万件超の検証済み更新に達しました。Polygonは、見出しの結果がオフチェーンのハブ処理を測るものであり、毎秒1,100万件のオンチェーントランザクションではないと明記しています。ここまではPolygonの報告であり、以下の運用上の考察はIneezaの分析です。
決済更新の処理能力と最終決済の処理能力は別物
Ineezaの分析: 利用イベントごとの処理をオフチェーンへ移したことが、このベンチマークを拡張できる理由です。同時に二つの時間軸が生まれます。ハブのレシートに基づく高速なサービス提供判断と、オンチェーンのrootおよび請求に基づく遅い金融上の確定です。プロダクト台帳は両方を明示的に記録しなければなりません。「認可済み」「ハブ受理済み」「root記録済み」「提供者請求済み」は同じ結果ではありません。
本番連携では、バウチャー、セッション識別子、累積額、価格バージョン、サービス単位、ハブレシート、エポック、rootのトランザクション、請求結果を一つの冪等性キーで結びます。その上でサービス利用台帳、チャネル状態、ハブのエポック、オンチェーン請求を最低限照合します。この証跡がなければ、高速なレシート経路の裏で価値の漏れ、サービスの重複提供、提供者残高の滞留を見落とします。
ハブは低遅延の信頼境界になる
Ineezaの分析: 提供者が処理結果を渡す前に、ハブが重要な判断を検証するため、その障害時挙動はベンチマーク速度と同じくらい重要です。各ハブの運営者、支払側の振り分け方法、レシートを生成したソフトウェアとポリシーのバージョン、鍵の保護方法、二重提示や停止の検知方法を定義する必要があります。Merkle rootは後の請求を証明可能にしますが、有効な更新がすべて迅速に含まれたことや、購入内容とサービス応答が一致したことまで単独で証明するものではありません。
提供者はroot記録間のエクスポージャーに上限を設け、累積額が単調に増えることとエポックへの包含を独立に検証し、レシート証跡が古い・不整合な場合は提供を停止すべきです。復旧手順には、最後に受理したバウチャー、包含に関する異議、rootの巻き戻り、ハブ交換、チャネル終了を含めて試験します。水平スケールは高速経路の協調を減らす一方、安全に監視・更新すべき運用対象を増やします。
セッションキーには残高上限を超えるポリシーが必要
Ineezaの分析: 資金を預けたチャネルとセッションキーは決済の摩擦を下げますが、利用可能残高だけでは自律エージェントへの十分な認可になりません。提供者、サービス、資産、単価、累積額と時間の上限、許可ネットワーク、目的でキーを制約すべきです。あるAPI呼び出しへの許可が別の請求へ転用されないよう、価格条件も署名対象の更新へ結び付ける必要があります。
エージェントは再試行も行います。決済受理後かつサービス提供前のタイムアウトは、双方で決済IDとサービスIDが冪等でなければ、未払いの処理または二重払いを生みます。高リスクのタスクでは支出ポリシーをモデルのループ外に置き、セッションキーの署名前に決定的な検査と人へのエスカレーション閾値を適用すべきです。
ベンチマークには本番のエンドツーエンド条件が必要
Ineezaの分析: 毎秒1,100万件という数値は、水平分割された検証能力の有用な証拠です。ただし容量計画は全経路の結果から始め、実際の構成で測るべきです。ネットワーク距離、署名方式、ポリシー参照、永続化、可観測性、root構築、チェーン混雑、請求負荷、障害復旧のどれもが律速段階になり得ます。
レシート遅延、受理の正確性、root公開、請求の確定、照合遅延には個別のSLOを設定します。負荷試験には、有効な更新を各ハブへ均等に配るケースだけでなく、支払側の偏り、残高枯渇、リプレイ試行、価格変更、鍵の失効、ハブ停止、チェーン再編成、請求の再実行を含めるべきです。
Ineezaの見解
Polygonの設計は、利用イベントをすべてオンチェーントランザクションにせず、API呼び出し単位やストリーミング型のエージェント決済を現実的にする点で重要です。本番への教訓は、決済制約が消えることではなく、階層化されたプロトコルへ移ることです。ハブのレシートを暫定的なサービス認可、オンチェーンのrootを決済証跡、照合を両者の整合性を証明する統制として扱う設計が堅牢です。