ERPC、Solana RPC（HTTP / WebSocket）を全リージョンで Firedancer クライアントへ移行。共有 HTTPS エンドポイントにおいても低レイテンシと安定性を向上

本移行により、共有 HTTPS RPC エンドポイントを含む ERPC の Solana RPC において、低レイテンシのさらなる改善と、処理の安定性向上を確認

ELSOUL LABO B.V.

2026年1月2日 04時13分

ELSOUL LABO B.V.（本社：オランダ・アムステルダム、代表取締役 CEO：川崎文武）および Validators DAO が運営する ERPC は、Solana RPC（HTTP / WebSocket）について、Frankfurt リージョンにおける SWQoS 用ノードを除く全リージョンの RPC ノードを、Firedancer クライアントへ切り替えたことをお知らせいたします。

本移行により、共有 HTTPS RPC エンドポイントを含む ERPC の Solana RPC において、低レイテンシのさらなる改善と、処理の安定性向上が確認されています。実際のご利用者の皆様からも、他社の専有 RPC ノードと比較しても ERPC の共有エンドポイントが高速であるという評価が寄せられています。

Solana RPC におけるレイテンシと安定性の構造的課題

Solana 開発および運用において、RPC は不可欠な基盤です。トランザクション送信、アカウント状態の取得、リアルタイムなアプリケーション挙動の観測など、あらゆる処理が RPC を介して行われます。

一方で、RPC のレイテンシは、物理的な距離、ネットワーク経路、TLS による暗号化処理、ノード実装の効率、負荷集中といった複数の要因が積み重なって決まります。特に共有 RPC 環境では、HTTPS 利用による TLS オーバーヘッドや、同一ノードを複数利用者が共有する構造上、レイテンシやばらつきが発生しやすいという課題がありました。

ERPC はこれまで、グローバル配置、エッジ配信、Shreds フィードの全ノード適用といった基盤設計によって、これらの課題に継続的に取り組んできました。今回の Firedancer への移行は、その延長線上に位置づけられるものです。

Firedancer の設計思想と目的

Firedancer は、C 言語を用いてフルチューニングされている Solana クライアントであり、理論上の性能ではなく、実運用における性能限界を引き上げることを目的として開発されています。

従来広く使われてきた agave クライアントと比較し、メモリ管理、処理パス、ネットワーク処理の最適化が徹底されており、同一ハードウェア条件下でも、より安定した低レイテンシと高い処理効率を発揮できる設計となっています。

Testnet / Devnet における検証結果と実運用上の知見

ERPC では、Firedancer を testnet および devnet の RPC 環境に導入し、継続的な検証を行ってきました。その結果、通常の agave クライアントと比較して、メモリ使用量を抑えつつ、低レイテンシをより安定させ、処理の限界を高められることを確認しています。

また、agave クライアントでは安定稼働が難しかったサーバー構成においても、Firedancer であれば稼働可能である事例も確認されています。これは、単に高速であるだけでなく、省エネルギーかつ高効率な運用を可能にする点においても重要な特性です。

これらの知見は、理論値やベンチマーク上の数値ではなく、ERPC における実運用と継続的な観測に基づくものです。

ERPC における全リージョン移行の内容

今回 ERPC は、Frankfurt リージョンにおける SWQoS 用ノードを除き、すべてのリージョンの Solana RPC ノードを Firedancer クライアントへ切り替えました。

この移行は、共有 HTTPS RPC エンドポイントを含む構成全体に適用されています。既存のご利用者の皆様においては、特別な設定変更や移行作業を行うことなく、Firedancer による低レイテンシ化および安定化の恩恵を受けていただいています。

Frankfurt リージョンについても、Firedancer による SWQoS 機能対応の完了を待ち、段階的に移行を進める予定です。

グローバル配置と Shreds フィード前提の ERPC 構成

ERPC は、Solana RPC を世界 7 拠点に配置されたフルノードで提供しています。さらに、300 以上のエッジデータセンターから、最寄りの地点を経由した最短経路でデータ配信を行う構成を採用しています。

すべての拠点・すべてのノードにおいて Shreds を配信およびフィードしており、Solana バリデータネットワーク上を流通する Shreds を直接バイパスする構成を採用しています。

Shreds は UDP によって伝播され、ステーク量に応じた優先度が付与されるため、ステークを持たない RPC ノードは、通常の構成ではデータの取得が後回しになりやすく、結果としてブロック追従が遅れる傾向があります。

ERPC では、この Shreds の伝播経路を RPC ノード側で直接取り込むことで、RPC でありながらバリデータ級のブロック追従速度を実現しており、全リージョン・全ノードで一貫して高速な応答特性が得られています。

共有 RPC、Unlimited エンドポイント、VPS の位置づけ

今回の Firedancer 移行により、共有 HTTPS RPC エンドポイントにおいても、低レイテンシと安定性の改善が確認されています。

さらに、Unlimited エンドポイントを利用することで、TPS 制限なく、TLS（HTTPS）による約 20ms のオーバーヘッドを排除した HTTP / WebSocket RPC を利用できます。ERPC プラットフォーム上の VPS と組み合わせることで、基本的な Solana RPC メソッドを 2ms で実行可能な構成が成立します。

従来、このような構成を実現するには、数千ドル規模の専有 RPC ノードと、その隣接サーバーを個別に用意する必要がありました。ERPC では、これらを約 1/10 のコストで、同等のパフォーマンスとして提供できます。

料金表について

共有 Solana RPC、Unlimited エンドポイント、VPS については、それぞれ以下の料金表をご参照ください。

用途や構成に応じて、最適なプランを選択いただけます。

今後の研究開発について

ERPC は今後も、レイテンシと安定性の両立を軸に、Solana RPC 基盤の研究開発を継続していきます。Firedancer による SWQoS 対応完了後の Frankfurt リージョン移行を含め、段階的かつ継続的な改善を積み重ねていく方針です。実運用に耐え続けるプラットフォームとしての進化を重視しています。