自分のワークフローに合わせてRPCプロバイダーをベンチマークする方法

RPCプロバイダーは、自分のワークロードに固有のベンチマークに基づいて選ぶべきだ。私たちは自社を含むプロバイダーを常にベンチマークしており、多くのチームが同じことをするのも見てきた。リクエストを送るのは簡単な部分だ。難しいのは、何を測るかを決め、その結果に実際に判断を委ねられるテストを組むことである。

だから私たちは方法論を書き起こし、それを実行するためにAlchemy rpcbenchを作った。任意のRPCプロバイダーの組み合わせを、自分のマシンから、アプリが実際に呼び出すメソッドでベンチマークする単一のバイナリだ。方法論そのものは、すでに使っているどのツールでも機能する。

測る価値があるのは三つ、負荷下のレイテンシー、ブロックラグ、データ整合性だ。それぞれがシステムの異なる部分を壊し、ある項目に強いプロバイダーが別の項目では遅れていることもある。そのため、混ぜ合わせたスコアは自分にとって重要な項目を埋もれさせる。アプリが実際に呼び出すものを、アプリが動く場所から測ること。

RPCプロバイダーをベンチマークするとき、何を測るべきか?

負荷下のレイテンシー、ブロックラグ、データ整合性を、それぞれ分けて測定し報告する。

データ整合性は、ほとんどのチームが一度もテストしない項目だ。プロバイダーによっては、メソッドごとに異なるバックエンドから応答しており、それらは常に同時に進むとは限らない。そのため、新しいヘッドを通知しながら、同じブロックのログが不完全なまま返ってくることがある。本が棚に並ぶ前に蔵書目録を更新する図書館を想像してほしい。目録には新着本が入ったとあるのに、棚は空だ。

どれを最初に測るべきか?

アプリがデータで何をするかに合うものから始める。新しいブロックに反応して動くなら、ブロックラグだ。ブロックが届いた瞬間にそのログや状態を読むなら、データ整合性だ。それ以外なら負荷下のレイテンシーである。Valantis、Aave、RedStone、Structのようなチームが、それぞれ異なるものを測るベンチマークを実行するのを私たちは見てきた。

次に、プロバイダーをメソッドごとに一つずつ比較する。平均では速いプロバイダーでも、アプリが最も多く行う一つの呼び出しでは遅いことがあるからだ。その差がすべてを決める。スプレッドが閉じた後に届いた見積もりは、遅い見積もりではない。約定を逃したのだ。

信頼できるRPCベンチマークはどう実行するのか?

レイテンシーを測るには、固定のスケジュールでリクエストを送る。素直な設計は、リクエストを送り、応答を待ってから次を送るというものだが、これではプロバイダーが苦しみ始めたまさにそのときに、送るリクエストが静かに減る。テストは一定の負荷を保つべき瞬間に手を緩め、探していた速度低下はデータに一切現れない。代わりに固定のクロックで送信し、各送信がそのクロックからどれだけ遅れたかを追跡する。自分のマシンが遅れ始めたら、その数値が示しているのは自分のマシンのことだ。

実行のセットアップ

実行する

ブロックラグは例外だ。「どのプロバイダーがこのブロックを最初に通知したか」は、すべてのプロバイダーを同じ瞬間に監視して初めて意味を持つ。また、1ブロックにつき小さなメッセージが一つだけなので、帯域幅を奪い合うこともない。

結果を読む

Alchemy rpcbenchとは何か?

Alchemy rpcbenchは、上記の方法論全体を、自分のマシンから自分のキーで実行する単一のバイナリだ。リクエストは設定ファイルに記載したエンドポイントにだけ送られ、生成されるHTMLレポートは直接あなたに届く。

私たちがこれを作ったのは、方法論を書き起こすのは簡単な半分にすぎないからだ。上記の各ルールは正しく実装するのに何日もかかり、しかもほとんどは間違えても目に見えない。測定ツールにとって最悪の組み合わせだ。

デフォルト設定は出発点にすぎない。workload:セクションで、自分のパラメーターとメソッドに置き換えられる:

レートの段階、実行時間、タイムアウト、ブロックラグの計測期間も同様に設定できる。また、プリフライトのパスが、負荷がマシンから出ていく前に、実行のコストをリクエスト数、時間、帯域幅で見積もる。そのコストはAlchemyのコンピュートユニットで示されるので、規模の目安として読むこと。

実行のたびに、JSONファイル、CSVの集計、自己完結型のHTMLダッシュボードが書き出される。裏付けのない数値は出さない。サンプルが少ない、プロバイダーがスロットリングされた、マシンが遅れた、といった場合はすべて冒頭でフラグが立つ。

このゲートを通過した実行からは、次の四つがこの順で得られる:

この方法論からわからないこと

• あるリージョンの結果は、別のリージョンについて何も語らない。システムが別の場所で動いているなら、そこから実行すること。
• ブロックラグは、テストした中で最も速いプロバイダーに対する相対値であり、真のチェーン先端に対する値ではない。
• メソッドは一つずつ実行されるので、実行結果が本番トラフィックの構成を再現することはない。
• 1回の実行は一つのデータポイントにすぎない。チェーン全体の問題を含め、多くの要因が測定値に影響しうるので、性能について確かなシグナルを得るために複数回の実行を強く推奨する。
• Alchemy rpcbenchツールはEVMネットワーク専用で、1回の実行で対応するのは一つのネットワークだけだ。

Alchemy rpcbenchを利用するには?

Alchemy rpcbenchはプライベートアルファ版だ。アクセスをリクエストするにはこちらのフォームに記入すること。

すでに持っているツールで自作したいなら、上記の方法論がそのすべてだ。最終的に判断の根拠とする数値が、自分で出したものである限り、どちらでも私たちは歓迎する。

よくある質問

RPCプロバイダーはどう比較すべきか?

システムが動くリージョンから、システムが実際に呼び出すメソッドで、すべてのプロバイダーに同じワークロードを実行する。固定のスケジュールで送信し、プロバイダーは一つずつテストし、一つのブロックを固定して全員が同じ問いに答えるようにする。結果はメソッドごとに、すべてのレイテンシーの数値に失敗数とレート制限の回数を並べて読み、時間を変えてもう一度繰り返す。自分で構築したくなければ、Alchemy rpcbenchへのアクセスについてお問い合わせを。

RPCのレイテンシー、ブロックラグ、データ整合性の違いは何か?

レイテンシーは、送ったリクエストにプロバイダーが応答するまでの時間だ。ブロックラグは、新しいブロックの存在を知らせるまでの時間だ。データ整合性は、そう知らせた瞬間に、そのブロックのログ、レシート、トランザクションを提供できるかどうかだ。プロバイダーは三つすべてに強いこともあれば、一つに強く別の一つで遅れていることもある。だからこそ、これらは別々の列に置くべきなのだ。

プロバイダーが作ったベンチマークツールの結果は信頼できるのか?

できる。しかも私たちの言葉を鵜呑みにする必要はない。Alchemy rpcbenchには、通信先のプロバイダーによって分岐するコードパスが一つもないので、プロバイダー固有のタイムアウトやリトライを隠す余地はない。READMEにある監査用プロンプトを使って、任意のコーディングエージェントにクローンを調べさせれば、代わりに確認してくれる。ツールは自分のマシン上で自分のキーを使って動作し、結果が出力フォルダーの外に出ることはない。

RPCプロバイダーは、単一の総合パフォーマンススコアで選ぶべきか?

いいえ。総合スコアは重み付けを勝手に決めてしまうが、正しい重み付けはアプリケーションによって異なる。履歴をバックフィルするインデクサーと、ブロックと競争するアービトラージボットが、プロバイダーに求めるものにはほとんど共通点がない。構築しているものに合った項目を読み、それをメソッドごとに読むこと。

RPCベンチマークはどこから実行すべきか?

アプリケーションが動くリージョンからだ。RPCのレイテンシーは、クライアントとプロバイダーの間のネットワーク経路に大きく左右される。そのため、ノートPCや、デプロイしていないクラウドリージョンから実行したベンチマークは、本番トラフィックが決して通らない経路を測ることになる。

RPCベンチマークの実行にはどれくらい時間がかかるか?

実行時間はテストの設定次第だが、デフォルト設定では約2時間かかる。テストの設定と開始は10分もかからない。Alchemy rpcbenchに同梱の設定では、Ethereum上で7つのメソッドと3つのレート段階にわたり、プロバイダーあたり28万リクエストを約48分で送信し、ブロックラグの計測期間がさらに1時間加わる。プロバイダーは順番に実行されるので、レイテンシーのフェーズはテストするプロバイダーの数に応じて長くなる。確かな結果にはサンプルが必要なので、午後いっぱいを見込んでおくこと。

RPCプロバイダーをベンチマークするにはWebSocketエンドポイントが必要か?

レイテンシーには不要だ。ブロックラグとデータ整合性には必要だ。どちらもeth_subscribeとnewHeadsの購読に依存するからだ。また、ブロックラグは各ブロックを誰が最初に通知したかを測るので、少なくとも二つのプロバイダーが必要になる。

どのRPCプロバイダーをテストできるか?

テスト対象のチェーンでEVMのJSON-RPCエンドポイントを持つプロバイダーなら、どれでもよい。URLとキーは自分で用意する。方法論にもツールにも、プロバイダーが誰かに依存する部分はない。

Alchemyは自社のRPCベンチマークを公開しているか?

している。私たちのベンチマークページでは、継続的なプロバイダー比較を公開しており、今すぐ読める。Alchemy rpcbenchは、自分のアプリケーションのワークロードで、アプリケーションが動くリージョンから、自分自身のベンチマークを出すためのものだ。