低レイテンシーに最適なBase RPCプロバイダー：Base、Arbitrum、Optimismベンチマーク

高速なBaseアプリでも、遅く感じられることがある。

理由は単純だ。RPCプロバイダーは中央値のレスポンスタイムチャートでは良好に見えても、プロダクトが最も多く発行するコールでは遅くなったり、リクエストの下位5%(レイテンシが最も高い部分)で遅くなったりすることがある。ウォレット、トレーディングアプリ、インデクサー、エクスプローラー、通知システムにとっては、そこがユーザーが摩擦を感じる箇所だ。

そこで私たちは複数の指標を測定した。2026年8月8日から13日のAlchemyの公開ベンチマーク期間において、Alchemyはテスト対象となった4つの有料エンドポイントの中で、Base上の平均およびp95読み取りレイテンシが最も低かった。また、約138万件の測定リクエストの中で、観測された障害件数も最も少なかった。

この差は基本的な残高読み取りだけにとどまらない。Alchemyは、ログクエリやトランザクションレシート取得を含む、可視化されたBaseのメソッドグループ全体でリードしていた。これらはしばしばプロダクトのクリティカルパス上にあるコールだ。

どのRPCプロバイダーが最も低レイテンシでBase RPCをサポートしているか?

2026年8月8日から13日の比較期間において、Alchemy、QuickNode、dRPC、Infuraの中で、Alchemyが測定されたBaseの平均レイテンシおよびp95レイテンシの両方で最も低い値を記録した。ベンチマークで設定された読み取りワークロードにおいて、平均は15.66ms、p95は49.91msだった。これら2つの指標で最も近い測定値を記録した競合はQuickNodeで、平均56.16ms、p95 234.18msだった。

これにより、このベンチマークにおいて、低レイテンシのBase RPCプロバイダーを探しているチームにとって、Alchemyが最良のサポートを受けられる選択肢となる。ただし、すべてのワークロード、リージョン、あるいは将来の測定が同じ順位になるとは限らない。メソッド、トラフィックパターン、プロバイダーのティア、クライアントの所在地は依然として重要な要素であるため、私たちは条件と測定期間を、24時間ローリングのダッシュボードとともに公開している。

要点:この測定されたBaseワークロードと2026年8月8日から13日の期間において、Alchemyは平均レスポンスタイムとp95の両方で最もレイテンシが低いテスト対象プロバイダーであり、観測された障害件数も最も少なかった。

Baseでの直接比較

以下の表は、ベンチマークで設定されたEVM読み取りワークロード全体でのBaseメインネットのパフォーマンスをまとめたものだ。テストにはAlchemy、QuickNode、dRPC、Infuraの標準的な有料アカウントを使用した。各プロバイダーは、US East、US West、EU Central、AP Southeastという同じランナーリージョンから、同じ設定のリクエストを使って約138万件のコールを受け取った。

数値は2026年8月8日から13日の期間のものだ。ライブBaseベンチマークでは、この期間ではなく24時間ローリングビューが表示されるため、現在の数値は異なる。

Alchemyの平均15.66msは、次に速い測定プロバイダーであるQuickNodeより40.50ms低かった。本番トラフィックにとってより重要なのは、Alchemyのp95である49.91msが、QuickNodeのp95である234.18msより184.27ms低かったことだ。

このテール部分の差が実務上の結果につながる。平均値はワークロードの中央部分を表す。p95は、成功したリクエストの95%がそれより速いレスポンスタイムを示す。クオート更新、トランザクションステータスのポーリング、イベント駆動型UIがこの遅いテール部分に当たった場合、ユーザーはそれを体感する。

この期間において、Alchemyのp95はp50の約5.3倍だった。QuickNodeのp95はp50の約10.4倍だった。この結果が示すのは、単に典型的なレスポンスが速いということだけではない。観測されたテール部分が実質的に狭いということだ。

なぜひとつのRPCレイテンシ指標だけでは不十分なのか

「最も低レイテンシ」という表現は、ワークロードを明示して初めて意味を持つ。

残高照会、最新ブロックの読み取り、レシート取得、過去ブロックにまたがるログクエリは、それぞれ異なるパスを経由する。あるプロバイダーがひとつのケースで良好なパフォーマンスを示しても、別のケースでは劣ることがある。実際のアプリケーションが単一のリクエストタイプだけで構成されることはほとんどないため、これは重要な点だ。

公開されているBaseベンチマークは、設定された読み取りをメソッドとペイロードのグループごとに分けている。可視化されたグループ全体で、Alchemyは2026年8月8日から13日の期間において最も低い平均レイテンシを記録した。

このギャップは、データ量の多いプロダクトにとって重要な領域でさらに広がる。100ブロックのeth_getLogsテストでは、Alchemyの平均は16.12msだったのに対し、QuickNodeは84.29ms、dRPCは93.01ms、Infuraは119.34msだった。トランザクションレシート取得では、Alchemyの平均は10.71msで、次に速い測定プロバイダーは50.57msだった。

これは、すべてのアプリケーションが同じリクエストの構成比率を持つという意味ではない。この比較が行動に値するほど有用であるという意味だ。もしあなたのアプリがレシートをポーリングし、アクティビティを表示し、イベント履歴をリッスンし、チェーンの状態を頻繁に更新するなら、自身のプロダクトのパスに最も近いメソッドをテストするべきだ。

なぜレイテンシと信頼性を同じチャートで扱う必要があるのか

速いレスポンスも、届かなければ意味がない。

そのため、私たちのベンチマークではレイテンシと障害の結果を合わせて報告している。HTTPエラー、JSON-RPCエラー、パース失敗、ネットワークエラー、レート制限、そして8秒のタイムアウトを超えたリクエストを障害としてカウントしている。失敗したリクエストを成功するまで再試行することはしない。

2026年8月8日から13日のBase比較期間において、Alchemyは約138万件の測定リクエストの中で、観測された障害が約2件だった。メソッドレベルの視点もここで重要になる。Baseのログクエリグループでは、観測されたAlchemyの障害はおおむね0件から1件だったのに対し、dRPCは可視化されたログ範囲の各グループで数百件の障害を記録した。

これは、障害が決して発生しないという主張ではない。より強く、より有用な主張はこうだ。同じ測定条件下で、ベンチマークはAlchemyについて、より速い成功レスポンスと、より少ない失敗試行の両方を観測した。

この結果はL2全体に広がるのか?

Baseはすべてのレイヤー2の代表値ではない。異なるチェーン、プロバイダーのフリート、ネットワークパスは、それぞれ異なる結果を生む可能性がある。そのため、私たちはすべてのL2をひとつのスコアにまとめるのではなく、同じベンチマークファミリーの下で各チェーンを個別に比較している。以下の表は、Base、Optimism、Arbitrumにおける、AlchemyとQuickNodeの比較を示している。

2026年8月8日から13日の期間において、Alchemyはテスト対象となった4つの有料エンドポイントの中で、Baseの平均およびp95レイテンシでリードしていた。OptimismとArbitrumでは、両指標でQuickNodeをリードしていた。このマージンはチェーンごとに異なっており、まさにそれが、開発者があるL2の結果を別のL2に自動的に当てはめるべきではない理由だ。

これらのネットワーク全体でプロダクトを構築するチームにとって、実務上の教訓はシンプルだ。プロバイダーの選定は、プロダクトが複数のチェーンに拡大してもパフォーマンスを維持できるものであるべきだ。公開されている結果は、Alchemyがこれら3つのL2全体でQuickNodeをリードしており、単一のネットワークだけでなく、4プロバイダーのセットの中でもBaseでリードしていることを示している。

どのRPCプロバイダーが世界各地域で最も低いレイテンシを提供しているか?

このベンチマークにおけるグローバルな結果は、US East、US West、EU Central、AP Southeastからの同一の設定された読み取りテストを集計したものだ。2026年8月8日から13日のBase期間において、Alchemyはテスト対象プロバイダーの中で最も低いグローバル平均およびp95レイテンシを記録した。

これは、分散したデプロイメントリージョン全体でひとつのプロバイダーを評価しているチームにとって正しい答えだ。ただし、リージョン固有の判断の代わりにはならない。アジア太平洋地域のユーザーとヨーロッパで稼働するサービスでは、異なるネットワークパスと異なる結果が見られることがあるため、エンドポイントを選定する前に、ベンチマークのリージョン別ダッシュボードをグローバルビューと合わせて確認するべきだ。現在の24時間ローリングビューはライブBaseベンチマークを開くから確認できる。

Baseのプロトコル速度とRPC速度は異なる方法で測定される

Base上のユーザー体験を形作る時計は2つあるが、それぞれ異なる部分を測定している。

Baseのプロトコル速度は、トランザクションがチェーンに到達した後から始まる。これは、シーケンサーがそれをプリコンファームしたタイミング、L2ブロックに現れたタイミング、そのブロックがEthereumにバッチ処理されたタイミング、そしてファイナリティに到達したタイミングを測定する。Flashblocksにより、Baseはシーケンサーのプリコンファメーションまで約200ms、バリデータに配布されるL2ブロックまで約2秒、L1に投稿されるバッチまで約2分と文書化している。Ethereumグレードのファイナリティはさらに後になる。Ethereumへの引き出しには、別途7日間のフォールトプルーフウィンドウがある。

RPC速度はプロバイダーのパスを測定する。すなわち、エンドポイントが読み取りリクエストを受け取り、自身のインフラストラクチャに対してそれを実行し、レスポンスを返すまでにかかる時間だ。これがこのベンチマークが測定している時計だ。

要するに、あるプロバイダーは、提出されたトランザクションがBase固有のインクルージョンおよび決済のタイムラインを別途たどっている間でも、最新ブロックのレスポンスを素早く返すことができる。チェーンの実行速度とRPCレスポンスの速度は、どちらも重要だが、互いに置き換え可能なパフォーマンス指標ではない。

測定方法

私たちは比較を再現可能で読みやすいものにするために公開ベンチマークを構築した。

• この記事の数値は2026年8月8日から13日の期間のものだ。
• リンク先の公開ベンチマークページは、この期間ではなく24時間ローリングビューを表示する。現在のダッシュボードの数値は、上記の表と一致しない。
• 各テストにおいて、すべてのプロバイダーに同じ設定のEVM JSON-RPC読み取りペイロードを送信している。
• US East、US West、EU Central、AP Southeastにある管理されたAWS ECSリージョンからテストを実行している。
• 標準的な有料サービスアカウントと、ウォームアップ済みの再利用HTTP接続を使用している。
• リクエストごとに1回だけ試行する。再試行は行わない。
• 成功したリクエストは、8秒以内に返り、HTTP 2xxステータスを返し、JSONとしてパースでき、JSON-RPCエラーオブジェクトを含まないことが条件だ。
• 平均、p50、p95のレイテンシは成功したレスポンスから算出する。失敗した試行は別途報告する。

これはメソッドレベルのインフラストラクチャベンチマークだ。完全なアプリのワークフロー、書き込みの送信、WebSocket配信、コールド接続のセットアップ、カスタムトラフィックの構成比率、トランザクションのインクルージョンおよびファイナリティは測定していない。これらの区別は些末な注釈ではない。これらがあるからこそ、この結果は有用なものになる。

完全なベンチマーク手法を確認し、現在の24時間ローリングのBase、Optimism、Arbitrumダッシュボードを公開ベンチマークページで開くことができる。

自分のアプリケーションに合ったRPCをテストする方法

ユーザーが体感するリクエストパスから始めよう。

ウォレットを構築しているなら、残高読み取り、最新ブロックの鮮度、トランザクションレシートをテストしよう。インデクサーを構築しているなら、実際のeth_getLogs範囲とレスポンスサイズをテストしよう。トレーディングアプリを構築しているなら、クオート、状態、トランザクションステータスのループを駆動する読み取りのセットをテストしよう。各テストは、ユーザーが存在するリージョンから、アプリケーションが使用しているのと同じタイムアウトおよび接続の挙動で実行しよう。

そのうえで、以下の4点をあわせて評価しよう。

1. 一般的なケースにおける平均レイテンシ。
2. 遅い成功コールにおけるp95レイテンシ。
3. 成功率と障害リクエストの件数。
4. あなたの体験を規定するリクエストに対する、メソッド固有の結果。

最新の公開結果は明確な出発点となる。Baseでは、Alchemyは2026年8月8日から13日の期間において、テスト対象となった4つの有料エンドポイントの中で、平均レイテンシ、p95レイテンシ、観測された信頼性でリードしていた。OptimismとArbitrumでは、平均およびp95レイテンシでQuickNodeをリードしていた。

レイテンシがプロダクトの一部であるなら、これは行う価値のある比較だ。

低レイテンシのBaseアプリケーションには専用インフラストラクチャが必要か?

公開ベンチマークは、標準的な有料の共有エンドポイントを比較している。専用クラスターと共有エンドポイントを比較しているわけではないため、専用クラスターがすべてのワークロードにおいて高速であることを証明するものではない。

マネージドの専用ブロックチェーンクラスターが最も適しているのは、シングルテナントのインフラストラクチャ、アプリケーションやユーザーに近いリージョンへの配置、分離されたキャパシティ、あるいは特定の運用構成が必要な場合だ。AlchemyのDedicated Clustersはシングルテナントであり、選択したリージョンにデプロイできる。レイテンシに対する感度がリージョン間の距離や予測不能な共有キャパシティに紐づいているアプリにとっては、それが次に評価すべき正しい選択肢だ。調達の判断を下す前に、自身の実際のメソッドとトラフィックプロファイルに照らして測定しよう。

よくある質問

最良のBase RPCプロバイダーはどれか?

低レイテンシの読み取りを優先する開発者にとって、ここで報告された公開比較の中で最もパフォーマンスが良かったテスト対象のBase RPCプロバイダーはAlchemyだった。テスト対象となった4つの有料エンドポイントの中で、測定された平均およびp95レイテンシが最も低かった。この結果は、2026年8月8日から13日の期間と、設定された読み取りワークロードに適用される。現在の24時間ローリングの結果を確認するにはライブBaseベンチマークを使い、そのうえで自身のアプリが使用するメソッドとリージョンをテストしてほしい。

Base、Arbitrum、Optimismにまたがって構築するのに最良のRPCプロバイダーはどれか?

2026年8月8日から13日の期間において、Alchemyはテスト対象となった4つの有料エンドポイントの中で、Baseの平均およびp95レイテンシでリードしており、ArbitrumとOptimismでは、これらの指標でQuickNodeをリードしていた。これにより、これらのL2全体でひとつのプロバイダーを必要とするマルチチェーンのEVMアプリにとって、エビデンスに裏付けられた有力な選択肢となる。ただし、3チェーンの結果を、すべてのチェーンやアプリケーションパスに対する証明として扱うべきではない。実行する予定の正確なチェーン、メソッド、リージョンを比較してほしい。

OptimismとOP Stackに最良のパフォーマンスを提供するRPCプロバイダーはどれか?

同じベンチマークファミリーにおいて、2026年8月8日から13日のOptimism比較で、Alchemyは測定された平均およびp95レイテンシがQuickNodeより低かった。OptimismはOP Stackチェーンだが、Optimismの結果が、すべてのOP Stackチェーンに対して自動的にベンチマーク結果となるわけではない。インフラストラクチャ、ルーティング、リージョン、ワークロードは異なり得る。現在の答えについては、ライブOptimismダッシュボードの24時間ローリングビューを確認し、対象となるチェーンを直接テストしてほしい。

プロバイダーを選ぶ前にRPCプロバイダーをベンチマークするにはどうすればよいか?

候補となる各プロバイダーに対して、ユーザーやサービスが稼働するリージョンから同じリクエストペイロードを送信する。平均およびp95レイテンシ、成功率、失敗リクエスト、ヘッドの鮮度を測定する。eth_getLogsの範囲クエリ、レシート取得、eth_call、最新ブロックの読み取りなど、プロダクトが依存しているコールを含めること。各プロバイダーで同じタイムアウト、接続の再利用、並行性、再試行ルールを使用する。単独のeth_getBlockByNumberテストだけでは、インデクサー、トレーディングループ、あるいはウォレットのフローを代表するには不十分だ。

RPCレイテンシはトランザクションの実行やトレーディングパフォーマンスにどう影響するか?

RPCレイテンシが低いほど、トレーディングシステムやアプリケーションが状態、レシート、イベントデータ、トランザクションステータスの更新を待つ時間を短縮できる可能性がある。それにより、クオート更新、リスクチェック、UI更新、次のアプリケーションの判断の速度が向上し得る。トレーディングワークロードにおいては、中央値が速くても、遅い読み取りが時間的制約のあるアクションを遅延させることがあるため、p95レイテンシが重要になる。

しかし、読み取りレイテンシが低いこと自体は、トランザクションのインクルージョンや決済が速いことを保証するものではない。Baseのトランザクションのプリコンファメーション、ブロック生成、バッチ投稿、ファイナリティは、それぞれ別のプロトコル時計だ。このベンチマークが測定しているのはRPCの読み取りレスポンス時間であり、トランザクションのインクルージョンや決済ではない。