FAQ - レイテンシとリージョン
料金・Free プラン・RPC トークン・支払い・401 と 429 のエラーについての質問は、はじめかた にまとめています。
特定のチェーンによらない質問
距離とレイテンシの関係、サーバーと RPC の配置、プランや言語による違いなど、答えが特定のチェーンの仕組みを前提にしない質問です。
Q. 接続先のリージョンは自分で選ぶ必要がありますか？
Edge RPC では、選ぶ必要はありません。edge.erpc.global は 16 のチェーンへのリクエストを受け付けます。アプリケーションがエンドポイントにアクセスすると、通信経路上で近い入口へ自動的に接続されます。
Unlimited Endpoints（Solana・Ethereum・Avalanche C-Chain）では、注文時にプランと課金方法とあわせてリージョンを選びます。取引システムやバックエンドが稼働する場所に近い接続先を検討できます。選べるリージョンと在庫は、注文時に ERPC Webダッシュボード でご確認ください。
Solana では、リーダーの役割がリーダースケジュールに沿ってバリデータの間を移るため、一つの正解となるリージョンはありません。選び方は下の Solana の節で説明しています。
Q. レイテンシが大きいのですが？
エンドポイントに物理的に近い場所からアクセスしていますか？距離はレイテンシに大きな影響を与えます。そのため、提供されているエンドポイントに近いサーバーからのアクセスを推奨します。
Q. レイテンシはどのくらいですか？
レイテンシは計測方法やご利用環境によって異なります。具体的な数値よりも、実際のご利用シナリオで必要な性能を満たすかどうかが重要です。
Solana のレイテンシを TypeScript や Rust で測定できる、次のツールを提供しています。
Q. なぜ専有エンドポイントは速いのですか？
共有エンドポイントは複数のお客様でリソースを分け合って利用しているため、トラフィック量が増えるにつれてレイテンシ（遅延）が発生しやすくなります。サーバーのリソースには物理的な限界があり、処理できる仕事量が決まっています。多くのリクエストが同時に集中すると、処理を順番に行う必要があるため、レスポンス速度が低下します。
私たちは共有エンドポイントでも様々な対策を講じてパフォーマンスを最適化していますが、専有エンドポイントでは、あなただけがそのリソースを専有できるため、他のユーザーの影響を一切受けません。その結果、常に安定した高速なレスポンスが得られます。
さらに専有エンドポイントでは、HTTPなどTLSを利用しない通信オプションを提供しています。TLSハンドシェイク(約20ms)の処理を省略することで、HTTPSと比較してさらに通信速度が向上します。
Q. どのプランが一番速いですか？
一般的には、最上位のプランが最も高速です。これは、より高性能なCPUや大容量のメモリなど、強力なハードウェア構成を使用しているためです。
さらに強力なサーバーをお求めの場合はカスタマイズも可能ですが、基本的なプランは最適なコストパフォーマンスを追求して設計しています。
私たちはどの価格帯でも世界最高水準のパフォーマンスを提供していると自負しています。同じ価格帯で当社より高速なサービスがあれば、ぜひお知らせください。原因を特定し、改善に努めます。
Q. 聞いていたレイテンシと違います
使用しているプログラミング言語によってパフォーマンスが異なる可能性があります。一般的に言語ごとの速度を比較すると、以下の順序となります。
Rust > Go > TypeScript (JavaScript) > Python
より詳しくはこちらの比較ソースをご覧ください。
最速のパフォーマンスを求める場合は、Rustの利用を強くおすすめします。
Solana
この節の答えは、リーダーの役割がリーダースケジュールに沿ってバリデータの間を移るという Solana の仕組みを前提にしています。
Q. どのリージョンがおすすめですか？
常に一つの正解となるリージョンはありません。Solana はグローバルに動作しており、ブロックを生成するリーダーの役割は、リーダースケジュールに沿ってバリデータの間を移っていきます。バリデータ数とステーク量が多いリージョンほどリーダースロットの出現頻度が高く、トランザクションの着地で有利になります。ただし、それに比例して競合トラフィックも増えるため、戦略によっては相対的に空いているリージョンの方が成果を出しやすい場合もあります。
安定したリーダースロット供給を重視するならフランクフルトや北米東海岸などのバリデータ集中エリア、特定ターゲットへの最短経路を重視するなら近接リージョン、という使い分けが基本です。まず Validators Solutions で Solana ネットワークの公開分布を把握し、そのうえで ERPC Leader Slot API と実測値を使って、単一リージョン、二拠点構成、またはグローバル展開のどれが適切か判断してください。
Q. 少なくとも ~400msのレイテンシが必要です。
~400ms以内のレイテンシを確保するために重要なポイントは以下の通りです。
-
ping値の現実的理解: Ping値は理想環境での数値であり、実際のストリーム通信では約5倍のレイテンシとなります。例えば、大陸間のpingが100msの場合、実際のレイテンシは約500ms程度です。そのため、~400msのレイテンシを目指す場合、必ず同じリージョン内でインフラを構築する必要があります。
- Ping値の一般的な目安:
- 同一ネットワーク内：約0.1ms
- プライベート接続（PNI）：約0.2ms
- 同一データセンター：約0.3ms
- 同一都市：約1ms
- 隣国：約5〜10ms
- 大陸間：約100〜300ms
- Ping値の一般的な目安:
-
平均レイテンシに惑わされない: Solanaのバリデータは世界中に分散しており、「エポック」という周期ごとにランダムにリーダースケジュールが組まれ、リーダーバリデータが変わります。平均レイテンシを目安に~400msを目指すのは現実的ではなく、自分のリージョンのバリデータスケジュールを正確に把握し、最もレイテンシの低いスロットを特定する必要があります。常に最短のレイテンシを求める場合、関係するすべてのリージョンにインフラを構築する必要があります。同じリージョン内であれば、ストリーム通信でも数十msのネットワークレイテンシでデータ取得が可能であり、送信も数msで実行できます。
-
リーダースケジュールの追跡: 地域内のリーダーバリデータスケジュールを継続的に監視するには、ERPC の Leader Slot API（
getLeaderSlots） を利用するのが最適です。 この API は、今後のリーダースケジュール、現在のエポックのステーク量、推定されたバリデータの地理的位置、参考用 ping 値を返すため、狙うべき最小レイテンシのスロットを、そのスロットが来る前に特定できます。 公開マップ型データや標準 RPC API はネットワーク全体の把握には有用ですが、実行タイミングの判断には更新頻度・精度が不足します。Leader Slot API は、ルーティングやトレード判断に必要な粒度を補います。
Solana ネットワークデータ: Validators Solutions
Q. どのようにすればゼロブロック（ゼロスロット）トレーディングを実現できますか？
ゼロブロック（ゼロスロット）トレーディングを実現するには、より高度な戦略が必要です。主なポイントは以下の通りです。
-
チャンスゾーンの特定: Solana のバリデータは世界中に分散しており、すべてのスロットで最適なレイテンシを実現することは物理的に不可能です。そのため、自身のインフラが存在する地域のリーダーバリデータスケジュールを継続的に監視し、最も有利なチャンスゾーンを特定することが重要です。複数リージョンにインフラを展開することも有効です。たとえばフランクフルトはバリデータ密度が高く、リーダーに選出される頻度が多いため、トレード機会も多くなります。ERPC の Leader Slot API（
getLeaderSlots） を使えば、今後のリーダースケジュール、現在のエポックのステーク量、推定されたバリデータの地理情報、参考用 ping 値を、公開マップ型データや標準 RPC API よりはるかに高い精度で確認できます。これにより、スロットが来る前にチャンスゾーンを把握し、ゼロレイテンシに近いトレードを実行できます。 -
専有ノードの導入: 競合と比べて優位性がない場合は、専有ノードの導入を検討してください。共用ノードは他のユーザーの影響を受けレイテンシが増大するため推奨しません。また、自分のアプリケーションと専有ノードを同じネットワーク内に設置することで、ネットワークレイテンシを大きく減らし、パフォーマンスを最適化できます。
Q. WebSockets, gRPC, Shreds はどれが一番速いですか？
多くのお客様からのご意見はほぼ一致しており、速度は次の順序です。
Shreds > gRPC > WebSockets
もし異なる結果や条件を発見された場合は、ぜひご報告ください。
Q. このRPC（gRPC, Shreds）は他より速いですか？
私たちは、価格帯にかかわらず高いパフォーマンスを目指して設計・運用しており、同じ条件での比較はむしろ歓迎しています。実際の結果は、リージョンや共有・専有エンドポイントの違い、ご利用のプロトコル（WebSockets、gRPC、Shreds）、そしてクライアントのプログラミング言語によって変わります。
もし他のサービスより遅い場合は、具体的な条件や比較対象についてERPC Webダッシュボードでお知らせいただけると幸いです。原因を特定し、さらなる速度改善を行います。