SNS上で拡散している、XRP LedgerのRPCノードが1秒あたり30,000メッセージを処理できるという主張は印象的に聞こえます。しかし、検証済みのベンチマークはその数字を実際には支持していません。これはブロックチェーン全般で見られる傾向で、見出しを飾るスループットの数字が、元のテスト条件から切り離されたまま流通し、あたかも本番性能であるかのように繰り返されることがあります。多くはラボ測定、内部メッセージ数、あるいは楽観的な予測です。

実際の数値が示すもの

XRPL Labsは、XRP Ledger向けの主要なインフラ開発企業の1つで、純粋なメッセージスループットよりもレイテンシーに重点を置いてきました。同社の公開エンドポイントは現在、ledger_current呼び出しに対してp50レイテンシー約371ミリ秒を示しており、公開XRPLサーバーの中で最も低レイテンシーの選択肢となっています。

公開サーバークラスターでは、ピーク利用時に1秒あたり10,000超の読み取り処理が観測されています。これはブロックチェーン基盤として堅実な数値ですが、主張されている30,000の3分の1にすぎません。

別のインフラ提供事業者であるGetBlockは、専用構成においてレート制限なしでXRPLノードが1秒あたり1,000件超のリクエストを処理できると主張しています。

見出しの数字に最も近づいた例は、バリデータ間メッセージングに関するものです。これは本質的に別の種類のトラフィックです。バリデータメッセージ処理は、最適なテスト条件下で平均約3,260メッセージ/秒、ピークは6,100メッセージ/秒超を記録しています。しかし、バリデータ同士のコンセンサス通信と、クライアント・サーバー間のRPCリクエストは比較対象ではありません。

本番環境では、XRPLネットワークの実際の取引スループットは、日次ピーク時に歴史的に100～230トランザクション/秒の範囲で推移してきました。制御されたテスト環境での理論上の上限は1,500 TPS超に達していますが、それでも話題になっている30,000という数字には桁違いに届きません。

なぜこの差が重要なのか

1秒あたりのメッセージ数と1秒あたりのトランザクション数の違いは重要です。RPCノードは、残高照会、台帳クエリ、サブスクリプション更新など、台帳への書き込みにつながらない多数の読み取りリクエストを処理する場合があります。ping、ステータス確認、失敗したリクエストを含む全ての受信メッセージを数えれば、実際に処理されたトランザクション数を数えるよりも常に大きな数字になります。

XRPにとっては、これは特に重要です。RippleはXRPLを、機関向けの決済処理と分散型取引所の活動を支えるインフラとして位置づけてきたからです。どちらの用途でも必要なのは、ラボ条件で達成された理論上のピークではなく、持続的な負荷の下で予測可能かつ検証可能な性能です。

XRPLインフラが実際に向かっている方向

371ミリ秒というp50レイテンシーは、すべてのリクエストで暗号学的検証を行う分散ネットワークとして、意味のある進歩を示しています。400ミリ秒未満で安定してリクエストを処理できる決済ネットワークは、天空のようなスループットを主張しながら応答時間が不安定なものよりも、銀行や決済事業者にとって実用的です。

インフラ構成も多様化しています。複数の事業者が専用のXRPLノードサービスを提供するようになり、負荷分散と単一障害点の低減が進んでいます。公開クラスターで観測された1秒あたり10,000超の読み取り処理は、専用のエンタープライズ構成が本格導入される前でも、ネットワークが相当量のクエリを処理できることを示唆しています。

XRPLのネイティブ自動マーケットメーカー（AMM）はすでにメインネットで稼働しており、EVM互換サイドチェーンも開発中です。そのため、RPCインフラへの需要は単純な決済クエリを超えて拡大する可能性があります。そうなると、XRPL Labsがパーセンタイル・レイテンシーとともに公開しているような、検証可能で文書化されたベンチマークの方が、拡散性の高いスループット主張よりも有用な基準になります。こうした新機能の採用が拡大するにつれ、注目すべき指標はこのような測定値です。