ERPC、Solana Leader Slot APIを世界7リージョンのping計測に拡張—Validators Information APIも公開

Leader Slot API が世界7リージョンの参考RTTに対応。エポック全体のリーダー情報を一覧取得できる Validators Information API も同時公開

ELSOUL LABO B.V.（本社：オランダ・アムステルダム、代表取締役 CEO：川崎文武）および Validators DAO が運営する ERPC は、Solana のリーダー情報、推定位置、遅延を把握するための API を強化し、Leader Slot API の世界 7 リージョンからの参考RTT（ping計測）対応と、新しい Validators Information API の提供を開始しました。

まず、Leader Slot API（getLeaderSlots）を拡張し、世界 7 つの ERPC 観測リージョン（フランクフルト、アムステルダム、ニューヨーク、ロンドン、東京、シンガポール、シドニー）からの参考RTTを取得できるようにしました。これまではフランクフルトからのみ計測していました。

あわせて、Validators Information API（getValidatorsInformation）を新たに公開しました。この API は、現在のエポックで少なくとも 1 つのリーダースロットを持つすべてのバリデータを、1 回の呼び出しで一覧取得できるものです。担当スロット数とアクティブステーク量に加え、取得可能な場合には、推定ロケーション、ネットワークエンドポイント、クライアントバージョン、7 リージョンからの参考RTTも返します。

両 API は、標準的な JSON-RPC インターフェースを通じて、すべての ERPC ユーザーにご利用いただけます。

Leader Slot API ドキュメント: https://erpc.global/ja/doc/rpc/leader-slot-api/

Validators Information API ドキュメント: https://erpc.global/ja/doc/rpc/validators-information-api/

従来の取引インフラとの違い：Solana では通信先が動的に変わる

従来型の取引所や金融システムでは、注文を送信する先となる取引所、ゲートウェイ、マッチングエンジンなどは、通常、特定のデータセンターやネットワークに固定されています。

そのため、利用者は一度接続先を把握すれば、その接続先に対するネットワーク経路を継続的に最適化できます。対象となるサーバーの位置が頻繁に変わらないため、インフラの配置や通信経路も比較的固定的に設計できます。

一方、Solana では、ブロックを生成する責任を持つリーダーが、リーダースケジュールに従って数スロットごとに交代します。リーダーを担当するバリデータは世界各地に分散しているため、トランザクションを届けるべき相手と、その相手に近いネットワーク経路は継続的に変化します。

つまり、Solana では、最適化すべき通信先を、固定された単一の接続先として扱うことができません。

現在および将来のリーダーが誰であるかを、まずリーダースケジュールから把握する必要があります。そのうえで、各バリデータがどの地域やネットワークに存在する可能性が高いか、また各送信拠点からどの程度の遅延があるかを確認し、送信経路を判断します。

この構造を正しく理解することが、Solana における低遅延なトランザクション送信と、グローバルなインフラ設計の出発点になります。

リーダースケジュールとネットワーク位置をデータとして扱う

通信先が動的に変わる環境では、人がその都度リーダーや送信拠点を確認し、手動で経路を切り替えることは現実的ではありません。

必要になるのは、次の情報を継続的に取得し、アプリケーションやインフラの判断ロジックに組み込むことです。

・現在および今後のスロットを担当するリーダー

・各バリデータが担当するスロット数

・各バリデータの推定される国、都市、リージョン

・TPUやQUICなどのネットワークエンドポイント

・各観測リージョンから取得した参考RTT

・計測値の取得時刻と応答状態

推定ロケーションと実測遅延は、それぞれ異なる役割を持ちます。

位置情報は、どの地域にインフラやキャパシティを配置すべきかという中長期的な判断に利用できます。一方、各リージョンからの参考RTTは、現在どの拠点から短い経路で到達できる可能性が高いかを判断する材料になります。

物理的または地理的に近い場所が、常にネットワーク上でも最短になるとは限りません。そのため、推定位置と実際の観測値を組み合わせて判断することが重要です。

ERPC の Leader Slot API と Validators Information API は、これらの判断をデータに基づいてプログラムできるようにするための API です。

Leader Slot API：世界 7 リージョンから参考 RTT を計測

Leader Slot API は、今後のリーダースロットを、バリデータの識別情報、アクティブステーク量、ネットワークエンドポイント、推定ロケーション、参考RTTなどとともに返します。

これまで pingToLeaders の計測は、フランクフルトのオリジンからのみ収集していました。これは、グローバルに分散した Solana ネットワークに対する単一の観測点でした。

今回のアップデートにより、次の 7 リージョンから計測した参考RTTを取得できるようになりました。

・frankfurt

・amsterdam

・ny

・london

・tokyo

・singapore

・sydney

各リーダーについて、7 つの観測リージョンからの参考RTTを比較することで、どの送信拠点から短いネットワーク経路で到達できる可能性が高いかを判断できます。

これは、トランザクションのルーティングだけでなく、RPC、gRPC、Direct Shreds、トランザクション送信サーバーなどのキャパシティを、どの地域に配置するかを決定する際の判断材料にもなります。

計測結果には、ICMPへの応答有無を示す icmpReplied と、最後に正常な計測値を取得した時刻を示す measuredAt が含まれます。

ICMPに応答しないバリデータであっても、TPUやQUICなどのサービスが正常に稼働している場合があります。そのため、icmpReplied が false の場合は「遠い」ではなく「ICMPでは計測できない」として扱う必要があります。

また、更新時に正常な計測値を取得できなかった場合には、未計測の値で上書きせず、最後に正常に取得できた実測値とその計測時刻を保持します。

Validators Information API：エポック全体のリーダー情報を一覧取得

Leader Slot API は、「次のスロットを担当するリーダーは誰か」という、スロット単位の判断に適しています。

一方、インフラの配置やキャパシティ計画では、より広い視点が必要になります。

・現在のエポックでリーダーを担当するバリデータは誰か

・それぞれが何スロットを担当するのか

・どの国やリージョンに分散しているのか

・どの地域にインフラを配置すると、多くのリーダーに近づけるのか

新しい Validators Information API（getValidatorsInformation）は、これらの問いに答えるための API です。

パラメータなしで呼び出すと、現在のエポックで少なくとも 1 スロットのリーダーを務めるすべてのバリデータを、バリデータごとに 1 行で返します。デフォルトでは、担当するリーダースロット数が多い順に取得できます。

各行には、次の情報が含まれます。

・slotCount

・stakeWeight（SOL単位のアクティブステーク量）

・バリデータの識別情報

取得可能な場合には、さらに次の情報も返されます。

・推定リージョン、都市、国

・ネットワークエンドポイント

・クライアントバージョン

・7 リージョンからの参考RTT

データは定期的に更新されるため、APIを定期的に呼び出すことで、計画用のデータセットを最新の状態に保つことができます。

また、オプションの limit（1〜2000）、country、region パラメータを利用して、結果を絞り込むこともできます。

課金は返されたバリデータ数に応じて行われます。リーダーバリデータ数はエポックごとに変動しますが、執筆時点の例では、全673台の取得に6,800 APIトークン（ERPCのAPI利用クレジット）、10台までの取得に100 APIトークンを使用します。

データに基づくプログラマブルなルーティングへ

これらの API は、単にバリデータの一覧や参考RTTを表示するためのものではありません。

最終的な目的は、リーダースケジュール、バリデータの推定位置、各観測リージョンからの参考RTTを、アプリケーションの判断ロジックに組み込めるようにすることです。

例えば、アプリケーションは今後のリーダースケジュールを取得し、リーダーごとに7つの観測リージョンからの参考RTTを比較したうえで、利用するRPCやトランザクション送信経路を選択できます。

また、エポック全体のリーダー分布を分析し、担当スロット数の多いバリデータに近い地域へ、あらかじめインフラを配置することもできます。

主な用途は次のとおりです。

・スロット単位での送信経路の選択

・エポック単位でのキャパシティプランニング

・リージョン別のリーダーバリデータ分析

・アクティブステーク量と担当スロット数を考慮した優先順位付け

・エポックごとの地理的・ネットワーク的な分布変化の監視

・複数リージョンに配置したRPCや送信サーバーの自動選択

通信先が動的に変わる Solana では、静的なネットワーク最適化だけでは十分ではありません。

変化するリーダーを継続的に把握し、その位置とネットワーク状態に応じて、送信経路やインフラを動的に選択することが重要になります。

グローバル運用を前提とした Solana インフラへ

ERPC は、Solana 向けの高性能インフラストラクチャとして、初日からグローバル運用を前提に設計されています。

エッジネットワーク、ベアメタルおよびVPS、Direct Shreds、Geyser gRPC、SWQoSエンドポイント、そして今回のオペレーショナルインテリジェンスAPIは、すべて共通の目的に基づいて提供されています。

それは、ユーザーとリーダーが世界各地に分散する環境において、低遅延かつ効率的な実行を求めるビルダーに、データとインフラの両方を提供することです。

世界7リージョンからの参考RTTと、エポック全体のバリデータ情報を、シンプルなRPC呼び出しで取得できるようになりました。Solanaアプリケーションは、変化し続けるリーダーに応じた送信拠点やネットワーク経路を、データに基づいて選択できるようになります。

これは、Solana上で低遅延な送信、グローバルなインフラ配置、動的なルーティング最適化を求めるビルダーにとって、実運用に直結する判断材料となります。

低遅延な送信経路の選択、不要な長距離転送を抑えるインフラ設計、グローバルなキャパシティ配置にお役立てください。

詳細はドキュメントをご覧ください。

Leader Slot API: https://erpc.global/ja/doc/rpc/leader-slot-api/

Validators Information API: https://erpc.global/ja/doc/rpc/validators-information-api/

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