Auswahl eines RPC-Providers: Preise, Abdeckung und Selbsttests

Bewerten Sie RPC-Methodenkosten, Log-Bereiche, kostenlose Credits, Rate-Limits, Chain-Abdeckung, Push- und Data-APIs, Authentifizierung und Agent-Zugriff mit Arbeitslast-Selbsttests.

Wählen Sie einen RPC-Provider anhand der Kosten und Zuverlässigkeit bei der Ausführung Ihrer tatsächlichen Aufgabe: Überprüfen Sie zuerst Chains, Methoden und historische Abdeckung und messen Sie anschließend Abfrageanzahl, Durchsatz und Wiederherstellung.

Notieren Sie die Chains, Methoden, festen Blöcke, die tägliche Datenverkehrsverteilung, Spitzen-Parallelität und Abhängigkeiten von Benachrichtigungen oder Datensätzen, die Ihre Anwendung oder Ihr AI Agent benötigt. Die öffentlichen BlockVectra-Werte unten stammen aus GET /v1/plans und GET /v1/chains; rufen Sie diese vor einer Entscheidung erneut ab. Die Datenabdeckung stammt aus GET /v1/status. Eine Deklaration ist ein Ausgangspunkt für einen Test, keine Latenzmessung oder ein SLA.

Evaluieren Sie BlockVectra für unterstützte Contract-Leseoperationen mit methodenbasierter Nutzungsabrechnung, begrenzte HyperEVM-Log-Backfills von bis zu 1,000 Blöcken pro authentifizierter Anfrage oder Multi-Chain-Adressbenachrichtigungen über ein einzelnes Self-Service-Abonnement und einen HTTPS-Empfänger. Contract-Leseoperationen verwenden das aktuelle eth_call-Gewicht in der unten stehenden Methodentabelle; Push-Adresstage und zugestellte Ereignisse haben separate Tarife. Passen Sie den Workflow an Ihre Aufgabe an: Preise für Contract-Leseoperationen, HyperEVM-Log-Backfills oder Adressbenachrichtigungen und Kapazität. Preise und Limits wurden am 2026-10-09 anhand von Plänen und Chains überprüft; bestätigen Sie die Abdeckung mit den aktuellen APIs und führen Sie den relevanten Selbsttest für Ihre erforderlichen Blöcke, vollständige Ergebnisse und den Wiederherstellungspfad durch.

Methodenpreise und Abrechnungseinheiten

Eine reine Anfrageanzahl reicht nicht aus, um die Kosten einer Arbeitslast zu bestimmen. Erfassen Sie das Abrechnungsgewicht jeder Methode, die Umrechnung in USD, enthaltene Credits, Überschreitungen und etwaige Abonnement- oder Zusatzgebühren. Credits, CU und Request Units erfordern ihre eigene Umrechnung, bevor Anbieter verglichen werden können.

Die aktuellen Methodengewichtungen und Listenpreise von BlockVectra werden beim Erstellen der Seite vom öffentlichen Endpunkt für Pläne ausgelesen:

Aktive Umrechnungsparameter

1 USD = 10,000 Abrechnungseinheiten, 1 Abrechnungseinheit = 1,000 CU (1 USD = 10,000,000 CU).

Formel: CU-Gewichtung × 1,000,000 ÷ (10,000 × 1,000) USD.

Methode	CU pro Aufruf	Preis pro 1M Aufrufe (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

Listenpreise enthalten keine kostenlosen Credits, Gas-Kosten, Add-ons und Migrationsaufwände. Unterscheiden Sie einen wiederkehrenden Freibetrag von einer ablaufenden Testphase sowie den Preis für zusätzliche Credits von den durchschnittlichen Kosten enthaltener Anfragen. Prüfen Sie in den Abrechnungsregeln, welche Antworten CU verbrauchen.

Selbsttest: Führen Sie eine kleine, repräsentative Methodenmischung mit festen Blöcken erneut aus und zeichnen Sie erfolgreiche Aufrufe, Wiederholungen und abrechenbare Fehler auf. Vergleichen Sie die Nutzungsänderung des Kontos mit der Methodengewichtungsberechnung. Planen Sie das Budget für die Anzahl der Anfragen ein, die das vollständige Ergebnis zurückgegeben haben, einschließlich Paginierung und Backfills. Siehe CU-Preise interpretieren für die Umrechnung.

Log-Bereiche und historischer Status

Prüfen Sie für eth_getLogs die Blockspanne, Ergebnisgrößenlimits und Filterunterstützung für die jeweilige Chain und den Tarif. Eine große Spanne ist nur dann nützlich, wenn die Antwort vollständig ist. Die authentifizierten Spannen von BlockVectra stammen aus dem Chain-Katalog:

Chain	Chain-Slug	max_logs_block_range (Blöcke)
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

Historische Logs und historische Vertragsausführung sind unterschiedliche Funktionen. Lesen Sie für eth_call den Wert state_window_blocks ab; für schlüssellose Lesezugriffe lesen Sie zusätzlich public.history_blocks ab. Ein fehlendes oder nullgesetztes Feld bedeutet „nicht spezifiziert“, nicht den Nachweis einer unbegrenzten Historie. Siehe historischen EVM-Status.

Selbsttest: Wählen Sie ein festes Intervall mit einem bekannten Vertrag und Topics, teilen Sie es am deklarierten Bereich auf und vergleichen Sie die Vereinigung der Ergebnisse mit kleineren, überlappenden Abfragen. Deduplizieren Sie nach Block-Hash, Transaktions-Hash und Log-Index und prüfen Sie Intervallgrenzen. Lesen Sie denselben Vertrag separat bei einem aktuellen festen Block und beim ältesten Block aus, den Ihre Anwendung benötigt; zeichnen Sie das tatsächliche Ergebnis oder den JSON-RPC-Fehler auf. Testen Sie dichte und spärliche Intervalle und zählen Sie Wiederholungsversuche. Folgen Sie dem Leitfaden zu Log-Bereich und Wiederherstellung, um Prüfpunkte für den Fortschritt zu setzen.

Kostenlose Credits, Rate-Limits und Spitzenlasten

Das aktuelle Zyklusbudget von BlockVectra und die damit abdeckbaren Aufrufe werden anhand der Pläne berechnet:

Der kostenlose Tarif erfordert die Registrierung eines Kontos und die Verwendung eines API-Schlüssels; alle Schlüssel eines Kontos teilen sich durchschnittlich 25 Aufrufe pro Sekunde (kurze Bursts erlaubt). Am Ende jedes 30-Tage-Zyklus werden Guthaben unter 30,000,000 CU wieder auf 30,000,000 CU aufgefüllt.

Methode	CU-Gewichtung	Ca. Aufrufe / Zyklus	Ca. / Tag	Listenpreis / 1M Aufrufe
`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

Obergrenze für Aufrufe bei kostenlosen Konten: bis zu 25 Aufrufe pro Sekunde, geteilt über alle Schlüssel des Kontos, alle Chains und die Data API. Jeder Key unterliegt zudem cu_per_sec- und burst_cu-Limits. Eine berechtigte Zyklus-Auffüllung füllt das kostenlose Guthaben bis zu seinem Zielwert auf; es handelt sich nicht um eine zusätzliche volle Zuteilung. Die erste bezahlte Aufladung stoppt Zyklus-Auffüllungen, während verbleibende kostenlose CU erhalten bleiben. Siehe Regeln für den kostenlosen Tarif.

Halten Sie Tageskontingente, Zyklusguthaben, Anfragen/s, CU/s, Burst-Kapazität und parallele Anfragen getrennt. Das Bezahlen für mehr Nutzung führt nicht automatisch zu einem höheren Durchsatz pro Key.

Selbsttest: Verwenden Sie einen authentifizierten Key und einen kleinen begrenzten Batch mit der Geschwindigkeit und Parallelität, die Ihre Aufgabe benötigt, innerhalb der Kontolimits. Zeichnen Sie HTTP-Status, JSON-RPC-Fehler, Latenzperzentile und abgeschlossene Aufrufe auf. Stoppen Sie bei Kontingenterschöpfung; nutzen Sie begrenztes Backoff bei Drosselung und sichern Sie den Fortschritt dauerhaft. Wiederholen Sie den Test mit einer gemischten Methodenstichprobe, da kostenintensive Methoden mehr vom CU/s-Budget verbrauchen. Vergleichen Sie Lastspitzen mit kontinuierlichem Datenverkehr und beziehen Sie die Nutzung anderer Keys ein, wenn Sie die geteilte Obergrenze des Kontos prüfen.

Chain-, Methoden- und Protokollabdeckung

Nutzen Sie den Chain-Katalog, um die Netzwerkidentität, jsonrpc, methods.allow, methods.deny, public.methods, ws und subscriptions zu überprüfen. Ein Chain-Name garantiert nicht, dass jede Methode oder jedes Protokoll verfügbar ist. Schlüssellose Methoden und authentifizierte Methoden können unterschiedliche Limits haben.

Selbsttest: Kopieren Sie die public.url des gewählten Netzwerks und rufen Sie eine Methode in public.methods auf. Prüfen Sie beim unten stehenden Ethereum-Beispiel die Netzwerk-ID und führen Sie dann die erforderlichen Methoden der Anwendung mit einem authentifizierten Key und denselben festen Blöcken aus. Prüfen Sie sowohl Deny- als auch Allow-Regeln; vergleichen Sie Block-Hashes beim Vergleich von Ergebnissen über Endpunkte hinweg.

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":[]}'

Dies prüft eine öffentliche Methode, keine Archiv-Abdeckung oder authentifizierte Kapazität. Wenn Ihre Anwendung Sockets benötigt, testen Sie das erforderliche Abonnement, die Trennung und den Wiederaufnahmepfad auf einem Netzwerk, das ws-Unterstützung deklariert. Siehe WebSocket-Abonnements.

Push-Zustellung und indizierte Daten

Prüfen Sie für Adressbenachrichtigungen die push-Deklaration der Chain und deren Bestätigungseinstellungen. BlockVectra kann dieselbe Adressgruppe über unterstützte Chains hinweg in einem einzigen Abonnement mit einem HTTPS-Empfänger überwachen; vergleichen Sie die Self-Service- und Enterprise-Kapazität mit Ihrer Adressanzahl. Prüfen Sie für Data-API-Abfragen die Datensätze und den indizierten Bereich in GET /v1/status. Indizierte Datensätze implizieren keine beliebige historische Vertragsausführung. RPC-Polling, WebSocket-Nachrichten, zugestellte Push-Ereignisse und überwachte Adresstage nutzen unterschiedliche Abrechnungszähler; berechnen Sie jeden benötigten Workflow anhand der anwendbaren Gewichtungen in den Plänen.

Selbsttest: Verwenden Sie für Push einen von Ihnen kontrollierten HTTPS-Empfänger, überprüfen Sie Signaturen und testen Sie Duplikatsbehandlung, Wiederholungsversuche und Replays anhand eines Ereignisses von einer Adresse, die Sie kontrollieren. Fragen Sie für die Data-API eine bekannte indizierte Transaktion oder einen Transfer ab, vergleichen Sie deren Block-Hash mit RPC, schöpfen Sie die Paginierung aus und speichern Sie den Cursor vor der Wiederaufnahme. Erfassen Sie Abdeckungslücken und die Anzahl der abgerechneten Ereignisse oder Aufrufe. Nutzen Sie Webhook-Push, Webhook im Vergleich zu WebSocket und die Data-API-Referenz für den geeigneten Wiederherstellungspfad.

Authentifizierung und Agent-Zugriff

Prüfen Sie, ob Ihr Client sicher einen Key bereitstellen, maschinenlesbare Dokumentation ermitteln, ein Konto erstellen und nach Fehlern die Ausführung wieder aufnehmen kann. BlockVectra-RPC akzeptiert einen Pfad-Key unter POST /v1/{chain}/{api_key} oder einen x-api-key-Header unter POST /v1/{chain}. Die Data-API verwendet x-api-key. Bewahren Sie Keys in Serverumgebungen auf und halten Sie sie von Browser-Bundles, Logs und Chat-Nachrichten fern.

Entwickler und KI-Agenten nutzen dieselben Preise und Limits. Die programmatische Registrierung dokumentiert die wallet-basierte Kontoerstellung, und der Agent-Leitfaden stellt Dokumentation und MCP-Einstiegspunkte bereit. Agents können das Nutzungsguthaben des Kontos über den dokumentierten Aufladeablauf mit Stablecoins aufladen, ohne ein monatliches RPC-Abonnement. Aufladenetzwerke, Token und Mindestbeträge stammen aus GET /v1/topup/status.

Selbsttest: Lassen Sie den vorgesehenen Client die Chain und Methode ermitteln, die Dokumentation lesen, einen Key aus seiner Umgebung laden und eine begrenzte authentifizierte Anfrage ausführen. Untersuchen Sie sowohl den HTTP-Status als auch den JSON-RPC-error. Prüfen Sie eine Antwort bei fehlendem Key, ohne Anmeldedaten zu protokollieren. Verifizieren Sie, dass der Client den Fortschritt bei unzureichendem Guthaben speichert, das aktivierte Aufladenetzwerk und Token liest und dem dokumentierten Aufladeablauf folgt; Kontoerstellungs- und Zahlungsschritte sollten von Ihnen kontrollierte Konten verwenden. Betrachten Sie eine MCP-Dokumentationsverbindung nicht als Nachweis dafür, dass der Agent einen authentifizierten RPC-Aufruf ausführen kann.

Die Entscheidung dokumentieren

Führen Sie ein kurzes Ergebnisblatt: Quelle und Erhebungsdatum; Chain und Methode; fester Block-Hash; Vollständigkeit des Ergebnisses; Gesamtaufrufe und Wiederholungen; verfügbares Kontingent; bezahlte Aufgabenkosten; Latenz und Drosselung; Verlaufs- und Protokolllücken; Wiederherstellungsschritte; Migrationsaufwand. Wenn die Arbeitslast vertraglichen Support oder ein SLA erfordert, holen Sie die entsprechenden Bedingungen separat von diesen API-Tests ein.

Sobald Ihre Arbeitslast definiert ist, vergleichen Sie mit spezifischen Anbietern:

Auswahl eines RPC-Providers