RPC プロバイダーの選び方
ワークロードのセルフテストを通じて、RPC メソッドのコスト、ログ範囲、無料クレジット、レート制限、対応チェーン、Push API と Data API、認証、エージェント接続を評価します。
実際のタスクを完了するためのコストと信頼性に基づいて RPC プロバイダーを選択します。まずチェーン、メソッド、履歴の対応範囲を確認し、次にクエリ数、スループット、復旧性を測定します。
アプリケーションや AI エージェントが必要とするチェーン、メソッド、固定ブロック高、日次トラフィックの分布、ピーク時の並行性、通知やデータセットへの依存関係を書き出します。以下の BlockVectra の公開値は GET /v1/plans および GET /v1/chains から取得したものです。決定を下す前に再取得してください。データの対応範囲は GET /v1/status から取得されます。仕様の宣言はテストの出発点であり、レイテンシの測定結果や SLA そのものではありません。
メソッド料金と課金単位
リクエスト数だけでワークロードの価格を算出することはできません。各メソッドの課金の重み付け、USD への換算、含まれるクレジット、超過料金、サブスクリプションやアドオン料金を記録します。クレジット、CU、リクエストユニットは、プロバイダー間で比較する前にそれぞれの基準で換算する必要があります。
BlockVectra の現在のメソッドの重み付けと定価は、ページビルド時に公開の plans エンドポイントから読み取られます:
現在の換算パラメータ
1 USD = 10,000 請求ユニット、1 請求ユニット = 1,000 CU(1 USD = 10,000,000 CU)。
換算式:呼び出しあたりの CU 重み付け × 1,000,000 ÷ (10,000 × 1,000) USD。
| メソッド | 呼び出しあたりの CU | 百万回の呼び出しあたりの料金(USD) |
|---|---|---|
eth_blockNumber | 1 | $0.10 |
eth_call | 15 | $1.50 |
eth_getLogs | 30 | $3.00 |
debug_traceTransaction | 100 | $10.00 |
data.block | 5 | $0.50 |
workload_cu = sum(calls_for_method × current_method_cu_weight)
cu_per_usd = pricing.units_per_usd × pricing.cu_per_unit
list_cost_usd = workload_cu / cu_per_usd
paid_compute_usd = max(0, workload_cu − available_free_cu) / cu_per_usd定価には、無料クレジット、Gas 代、アドオン、移行作業は含まれません。定期的な付与枠と期限付きのトライアルを区別し、追加クレジットの単価と含まれるリクエストの平均コストを区別してください。どのレスポンスが CU を消費するかについては、課金ルールを確認してください。
セルフテスト: 固定ブロック高で代表的なメソッドの組み合わせを少量リプレイし、成功した呼び出し、再試行、課金対象となるエラーを記録します。アカウントの利用量の変化とメソッドの重み付けの計算結果を照合します。ページネーションやバックフィルを含め、完全な結果を返すために必要だったリクエスト数をもとに予算を組んでください。換算については CU 料金の読み解き方を参照してください。
ログ範囲と履歴状態
eth_getLogs については、特定のチェーンおよびプランにおけるブロックスパン、結果サイズ制限、フィルターの対応状況を確認します。広いスパンはレスポンスが完全である場合にのみ有用です。BlockVectra の認証付きスパンはチェーンカタログから取得されます:
| チェーン | チェーン識別子 | max_logs_block_range(ブロック数) |
|---|---|---|
| Arbitrum One | arb_mainnet | 1,000 |
| Base | base_mainnet | 1,000 |
| BNB Smart Chain | bsc_mainnet | 1,000 |
| Ethereum | eth_mainnet | 1,000 |
| Ethereum Sepolia | eth_sepolia | 1,000 |
| HyperEVM | hyperevm_mainnet | 1,000 |
| Polygon | polygon_mainnet | 1,000 |
| Robinhood Chain | robinhood_mainnet | 1,000 |
| Robinhood Chain Testnet | robinhood_testnet | 1,000 |
履歴ログと過去のコントラクト実行は異なる機能です。eth_call については state_window_blocks を読み取り、キー不要の読み取りについては public.history_blocks も読み取ります。フィールドが存在しないか null の場合は未指定を意味し、無制限の履歴を保証するものではありません。EVM 履歴状態を参照してください。
セルフテスト: 既知のコントラクトとトピックを持つ固定区間を選択し、宣言された範囲で分割して、結果の和集合をより小さな重複クエリと比較します。ブロックハッシュ、トランザクションハッシュ、ログインデックスで重複を排除し、区間の境界を確認します。別途、同じコントラクトを最近の固定ブロック高とアプリケーションが必要とする最も古いブロック高で読み取り、実際の結果または JSON-RPC エラーを記録します。イベントが密集している区間とまばらな区間の両方をテストし、再試行回数をカウントします。進捗をチェックポイントに保存するには、ログ範囲と復旧に従ってください。
無料クレジット、レート制限、ピーク時トラフィック
BlockVectra の現在のサイクル予算とそれでカバーできる呼び出し回数は、プランから算出されます:
無料プランはアカウント登録と API キーの使用が必要です。同一アカウント配下のすべてのキーで平均毎秒 25 回の呼び出し(短時間のバーストを許容)を共有します。30 日ごとの各サイクル終了時に、残高が 30,000,000 CU 未満の場合は 30,000,000 CU まで補充されます。
| メソッド | CU 重み付け | 1 サイクルあたりの概算呼び出し回数 | 1 日あたり約 | 100 万回あたりの定価 |
|---|---|---|---|---|
eth_blockNumber | 1 | 30,000,000 | 1,000,000 | $0.10 |
eth_getBlockByNumber | 5 | 6,000,000 | 200,000 | $0.50 |
eth_getBalance | 10 | 3,000,000 | 100,000 | $1.00 |
eth_call | 15 | 2,000,000 | 66,666 | $1.50 |
eth_getLogs | 30 | 1,000,000 | 33,333 | $3.00 |
debug_traceTransaction | 100 | 300,000 | 10,000 | $10.00 |
data.block | 5 | 6,000,000 | 200,000 | $0.50 |
data.address_balances | 25 | 1,200,000 | 40,000 | $2.50 |
data.dex_prices | 15 | 2,000,000 | 66,666 | $1.50 |
data.transaction_trace | 200 | 150,000 | 5,000 | $20.00 |
無料アカウントの呼び出し上限:最大毎秒 25 回の呼び出し。アカウント内のすべてのキー、すべてのチェーン、および Data API で共有されます。 各キーには cu_per_sec および burst_cu の制限もあります。対象となるサイクルの補充は無料残高を目標値まで補充するものであり、全額が追加付与されるわけではありません。初回の有料チャージを行うと、サイクルの補充は停止しますが、残りの無料 CU は保持されます。無料プランのルールを参照してください。
1 日あたりのクォータ、サイクル残高、リクエスト/秒、CU/秒、バースト容量、同時リクエスト数は別々に管理してください。より多くの利用料金を支払ったからといって、それだけでキーごとのスループットが向上するわけではありません。
セルフテスト: 認証キーを使用し、アカウントの制限内で、タスクに必要なペースと並行性で小規模な有界バッチを実行します。HTTP ステータス、JSON-RPC エラー、レイテンシのパーセンタイル、完了した呼び出しを記録します。クォータを使い切ったら停止します。レート制限時は有界バックオフを行い、進捗を永続化してください。コストの高いメソッドは CU/秒の予算をより多く消費するため、複数のメソッドを組み合わせたサンプルでテストを繰り返します。バーストトラフィックと定常トラフィックを比較し、共有アカウント上限を確認する際は他のキーの使用量も含めてください。
チェーン、メソッド、プロトコルの対応範囲
チェーンカタログ を使用して、ネットワーク識別子、jsonrpc、methods.allow、methods.deny、public.methods、ws、subscriptions を確認します。チェーン名が存在するからといって、すべてのメソッドやプロトコルが利用可能であるとは限りません。キー不要のメソッドと認証付きのメソッドでは、制限が異なる場合があります。
セルフテスト: 選択したネットワークの public.url をコピーし、public.methods に含まれるメソッドを呼び出します。以下の Ethereum の例では、ネットワーク ID を確認した上で、認証キーと同じ固定ブロック高を使用してアプリケーションに必要なメソッドを実行します。許可ルールだけでなく拒否ルールも確認し、エンドポイント間で結果を比較する際はブロックハッシュも比較してください。
curl --fail-with-body -sS --max-time 15 https://api.blockvectra.com/v1/eth_mainnet/public \
-H 'Content-Type: application/json' \
-H 'User-Agent: curl BlockVectraQA/1' \
-d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'これは公開メソッドの確認であり、アーカイブの網羅性や認証時の容量を保証するものではありません。アプリケーションでソケットが必要な場合は、ws の対応を宣言しているネットワーク上で、必要な購読、切断、および再開の経路をテストしてください。WebSocket 購読を参照してください。
Push 配信とインデックス済みデータ
アドレスの通知については、チェーンの push 宣言とその承認設定を確認します。BlockVectra は、1 つの HTTPS 受信エンドポイントを用いた 1 つの購読で、対応する複数のチェーンにわたって同じアドレスセットを監視できます。アドレス数に応じてセルフサービスとエンタープライズの容量を確認してください。Data API のクエリについては、GET /v1/status でデータセットとインデックス範囲を確認します。インデックスされたレコードがあるからといって、過去の任意のコントラクト実行が可能であるとは限りません。RPC ポーリング、WebSocket メッセージ、配信された Push イベント、監視アドレス日数は異なる課金メーターを使用します。plans にある該当する重み付けから、必要な各ワークフローを計算してください。
セルフテスト: Push については、自身で管理する HTTPS 受信エンドポイントを使用し、署名を検証して、管理下のアドレスからのイベントを用いて重複処理、再試行、リプレイをテストします。Data API については、インデックス済みの既知のトランザクションまたは転送をクエリし、そのブロックハッシュを RPC と比較し、ページネーションを最後まで走査して、カーソルを保存してから再開します。対応範囲の不足や、課金対象となったイベントまたは呼び出しの回数を記録してください。適切な復旧手順については、Webhook Push、Webhook と WebSocket の比較、Data API リファレンスを参照してください。
認証とエージェント接続
クライアントがキーを安全に提供し、機械可読なドキュメントを探索し、アカウントを作成し、エラーから復旧できるかを確認します。BlockVectra RPC は POST /v1/{chain}/{api_key} によるパスキー、または POST /v1/{chain} での x-api-key ヘッダーを受け付けます。Data API は x-api-key を使用します。キーはサーバー環境に保持し、ブラウザーのバンドル、ログ、チャットメッセージには含めないでください。
開発者と AI エージェントは同じ料金と制限を使用します。プログラムによる登録ではウォレットベースのアカウント作成について解説しており、エージェントガイドではドキュメントと MCP エントリポイントを提供しています。エージェントは月額の RPC サブスクリプションを契約することなく、ドキュメントに記載されたチャージ手順に従ってステーブルコインでアカウントの利用残高を入金できます。チャージ対応ネットワーク、トークン、最小金額は GET /v1/topup/status から取得されます。
セルフテスト: 対象のクライアントにチェーンとメソッドを探索させ、ドキュメントを読み取り、環境からキーを読み込んで、有界な認証付きリクエストを 1 回実行させます。HTTP ステータスと JSON-RPC の error の両方を確認してください。認証情報をログに出力することなく、キーが存在しない場合のレスポンスを確認します。残高不足時にクライアントが進捗を保存し、有効なチャージネットワークとトークンを読み取り、ドキュメントに記載されたチャージ手順に従うことを検証します。アカウント作成と支払いのステップには、自身で管理するアカウントを使用してください。ドキュメント MCP に接続できたことをもって、エージェントが認証付き RPC コールを実行できることの証明とみなさないでください。
決定事項を記録する
簡単な結果シートをまとめておきます:情報ソースとサンプリング日時、チェーンとメソッド、固定ブロックハッシュ、結果の完全性、総呼び出し回数と再試行回数、利用可能なクォータ、有料タスクのコスト、レイテンシとレート制限、履歴とプロトコルのギャップ、復旧手順、移行工数。ワークロードに契約上のサポートや SLA が必要な場合は、これらの API テストとは別に適用される規約を取得してください。
ワークロードが明確になったら、特定のプロバイダーと比較します:
最終更新: