# Auswahl eines RPC-Providers

> Source: https://docs.blockvectra.com/de/guides/choose-rpc-provider/

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](https://console-api.blockvectra.com/v1/plans) und [GET /v1/chains](https://api.blockvectra.com/v1/chains); rufen Sie diese vor einer Entscheidung erneut ab. Die Datenabdeckung stammt aus [GET /v1/status](https://api.blockvectra.com/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](https://docs.blockvectra.com/de/guides/reading-cu-pricing/), [HyperEVM-Log-Backfills](https://docs.blockvectra.com/de/guides/hyperevm-backfill/) oder [Adressbenachrichtigungen und Kapazität](https://docs.blockvectra.com/de/guides/webhook-push/#address-capacity). Preise und Limits wurden am **2026-10-09** anhand von [Plänen](https://console-api.blockvectra.com/v1/plans) und [Chains](https://api.blockvectra.com/v1/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 |

```text
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](https://docs.blockvectra.com/de/guides/billing-rules/), 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](https://docs.blockvectra.com/de/guides/reading-cu-pricing/) 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](https://docs.blockvectra.com/de/guides/evm-historical-state/).

**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](https://docs.blockvectra.com/de/guides/getlogs-block-range/), 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](https://docs.blockvectra.com/de/guides/free-plan/).

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](https://api.blockvectra.com/v1/chains), 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.

```bash
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](https://docs.blockvectra.com/de/guides/websocket-subscriptions/).

## 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](https://docs.blockvectra.com/de/guides/webhook-push/#address-capacity) mit Ihrer Adressanzahl. Prüfen Sie für Data-API-Abfragen die Datensätze und den indizierten Bereich in [GET /v1/status](https://api.blockvectra.com/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](https://console-api.blockvectra.com/v1/plans).

**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](https://docs.blockvectra.com/de/guides/webhook-push/), [Webhook im Vergleich zu WebSocket](https://docs.blockvectra.com/de/guides/webhook-vs-websocket/) und die [Data-API-Referenz](https://docs.blockvectra.com/de/api/data/) 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](https://docs.blockvectra.com/de/guides/programmatic-signup/) dokumentiert die wallet-basierte Kontoerstellung, und der [Agent-Leitfaden](https://docs.blockvectra.com/de/guides/ai-agents/) stellt Dokumentation und MCP-Einstiegspunkte bereit. Agents können das Nutzungsguthaben des Kontos über den [dokumentierten Aufladeablauf](https://docs.blockvectra.com/de/guides/agent-topup/) mit Stablecoins aufladen, ohne ein monatliches RPC-Abonnement. Aufladenetzwerke, Token und Mindestbeträge stammen aus [GET /v1/topup/status](https://api.blockvectra.com/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:

* [Mit spezifischen Anbietern vergleichen: Rechenpreise und Log-Bereiche](https://docs.blockvectra.com/de/guides/alchemy-alternative/).
* [Mit spezifischen Anbietern vergleichen: Testphasen- und Abonnementabrechnung](https://docs.blockvectra.com/de/guides/quicknode-alternative/).
* [Mit spezifischen Anbietern vergleichen: HTTPS-Anfragekosten](https://docs.blockvectra.com/de/guides/ankr-alternative/).
* [Mit spezifischen Anbietern vergleichen: Tages- und Zyklusbudgets](https://docs.blockvectra.com/de/guides/infura-alternative/).
* [Mit spezifischen Anbietern vergleichen: enthaltene Anfragen und Überschreitungen](https://docs.blockvectra.com/de/guides/chainstack-alternative/).