ERPC、ニューヨーク（NY）リージョンの Solana Geyser gRPC に XDP 高速パスと zero-copy を本番適用 — p99 で約 530ms の配信ラグ差を確認

ELSOUL LABO B.V.（本社：オランダ・アムステルダム、代表取締役 CEO：川崎文武）および Validators DAO が運営する ERPC は、ニューヨーク（NY）リージョンの Solana Geyser gRPC 共用エンドポイントに、Solana v4（Agave 4.x）の XDP 高速パスと AF_XDP zero-copy を本番適用したことをお知らせいたします。

XDP 高速パスと AF_XDP zero-copy は、Agave 4.x 系で実験的な位置づけを脱し、--xdp-interface / --xdp-cpu-cores / --xdp-zero-copy という正式な起動フラグで利用できる機能として整理されたものです。今回 ERPC は、高性能な Solana バリデータ領域で採用が進むこのネットワーク最適化を、NY リージョンの Geyser gRPC を支える配信元バリデータに本番適用しました。オープンソースの Solana 運用ツール SLV の slv check geyserbench による最適化前後の比較計測では、最適化前の同一 NY リージョン配信元ノードが、新構成に対して p50 63ms / p95 490ms / p99 530ms 遅れる結果となりました。これらは最適化後ノードの絶対的な配信ラグではなく、最適化前後の差分であり、特に p95・p99 のテール領域では数百ミリ秒規模の改善が確認されています。本対応はすでに本番環境で稼働しています。first-arrival 性能を重視するお客様は、NY リージョンの Geyser gRPC を、時間課金（1 時間単位）でも、Crypto Pay（SOL / USDC / EURC）でも、すぐにお試しいただけます。

ERPC 公式サイト: https://erpc.global/ja

ERPC ダッシュボード: https://dashboard.erpc.global/ja

ニューヨーク（NY）リージョンの Geyser gRPC が重要な理由

Solana では、ブロック生成を担うリーダーが短い周期で切り替わり、通信の起点が常に移動します。この構造においては、特定の単一点に近いことよりも、主要ノードやバリデータが集積するネットワークに近接している確率が高いことが、実運用上のレイテンシや再送率、失敗率に直接影響します。

ニューヨーク（NY）リージョンは、北米の取引時間帯において、リアルタイムのオンチェーンデータを必要とするトレーディング、インデックス処理、監視・分析の需要が集中するリージョンです。Geyser gRPC は、アカウント・スロット・ブロック・トランザクションの更新を、ポーリングではなくストリームとして受け取る経路であり、ここでの 1 ミリ秒の差が、約定機会の捕捉やフロントエンドの体感速度に直結します。だからこそ、NY リージョンの Geyser gRPC を、設計と最適化の両面で最速水準に保つことに意味があります。

計測結果 — slv check geyserbench による最適化前後の配信ラグ差

XDP 高速パスと AF_XDP zero-copy を有効化した新構成と、最適化前の同一 NY リージョン配信元ノードを、オープンソースの Solana 運用ツール SLV の slv check geyserbench で比較計測しました。その結果、最適化前のノードは、新構成に対して以下のラグ差で遅れる結果となりました。

p50 ラグ差: 63ms

p95 ラグ差: 490ms

p99 ラグ差: 530ms

これらの数値は、最適化後ノードの絶対的な配信ラグではなく、最適化前の配信元ノードが新構成に対してどれだけ遅れていたかを示す比較値です。

特に p95・p99 のテール領域では、数百ミリ秒規模の差が出ています。テール領域は、通常時よりも遅れが大きくなる上位側のケースであり、first-arrival 性能を重視するトレーディングやリアルタイム処理では、意思決定の遅れとして表面化しやすい領域です。最適化前のノードが新構成に対して p99 で約 530ms 遅れていたことは、テール領域における配信元側の取り込み・伝播経路の差が、Geyser gRPC の低遅延ストリーミング品質に直接影響することを示しています。

計測手段はオープンソースです。お客様は、同じ slv check geyserbench の計測方法で、ご自身の接続元から見た実際のラグを確認できます。配信ラグは接続元、経路、時間帯、leader の分布によって変わるため、確認できるのは固定の数値ではなく計測方法そのものです。SLV の導入から計測の実行までの手順は、SLV の Getting Started で公開しています。ERPC は、配信品質を主観や宣伝文句ではなく、誰もが同じ方法で確かめられる計測で示すことを重視しています。

SLV 公式サイト: https://slv.dev/ja

SLV Getting Started: https://slv.dev/ja/doc/general/getting-started/

Solana v4 の XDP 高速パスと zero-copy とは

XDP（eXpress Data Path）は、高性能なネットワークコードが、カーネル通常のパケット処理経路の多くをバイパスできるようにする Linux カーネルの技術です。データのコピーとコンテキストスイッチを削減することで、標準のネットワークスタックよりもはるかに少ないオーバーヘッドでパケットを処理します。

Agave（Solana のバリデータクライアント）では、XDP は、バリデータネットワーク間でブロックを伝播するプロトコルである Turbine に適用されています。受信した shred は、ネットワークインターフェースカード（NIC）の近くにアタッチされた eBPF プログラムで処理され、AF_XDP を通じてユーザー空間のバッファにマッピングされます。このとき zero-copy モードを用いると、受信データをカーネルからユーザー空間へコピーすることなく直接受け渡せます。送信側の shred は XDP_TX を用いて直接送出され、ホットパス上のシステムコールとコピーを排除します。

Anza は Turbine 向けの XDP を Agave 3.x 系で導入し、Solana v4（Agave 4.x）の基盤へと引き継いでいます。Agave 4.x 系では、XDP は実験的な位置づけを脱し、正式な起動フラグで利用できる機能として整理されました。Anza のセットアップガイドによれば、XDP を用いると、大規模バリデータでは送信パケットが毎秒 150,000 に迫るとされています。

Anza Agave XDP Setup Guide: https://www.anza.xyz/blog/agave-xdp-setup-guide

NY の配信元バリデー