Webhooks, WebSocket oder RPC-Polling wählen
Vergleichen Sie Adressbenachrichtigungen, Socket-Abonnements und begrenztes Polling nach Chain-Unterstützung, Wiederherstellung, Empfängeranforderungen und Abrechnung.
Verwenden Sie Adress-Webhooks für die Zustellung an einen HTTPS-Empfänger, WebSocket für unterstützte Live-Abonnements und begrenztes Polling, wenn der Workflow einen eigenen Cursor und eine eigene Wiederherstellung benötigt.
Das Erstellen von On-Chain-Event-Listenern für Entwickler und KI-Agenten erfordert die Abstimmung der Anwendungsarchitektur auf Netzwerkfähigkeiten, Zustellgarantien, Empfängereinschränkungen und Betriebskosten.
Entscheidungsmatrix
Die folgende Tabelle stellt alle drei Integrationsmechanismen hinsichtlich unterstützter Netzwerkfähigkeiten, Infrastrukturanforderungen, Wiederherstellungsstrategien und Abrechnungsmodelle gegenüber:
| Dimension | Adress-Webhooks | WebSocket-Abonnements | Begrenztes RPC-Polling |
|---|---|---|---|
| Primärer Mechanismus | Per HTTPS-POST an einen öffentlichen Endpunkt zugestellte Push-Benachrichtigung | Pull-Stream-Abonnement über eine dauerhafte TLS-Verbindung (wss://) | Client-initiierte HTTP-JSON-RPC-Batch- oder geplante Abfragen |
| Chain-Verfügbarkeit | Alle unterstützten Netzwerke, die in GET /v1/push/chains deklariert sind | Unterstützt auf Robinhood Chain (robinhood_mainnet und robinhood_testnet); nicht bediente Netzwerke haben ws: false und geben HTTP 404 zurück | Alle unterstützten Netzwerke in GET /v1/chains über schlüssellosen öffentlichen RPC oder authentifizierten JSON-RPC |
| Empfängeranforderungen | Öffentlich erreichbare HTTPS-URL, gültiges TLS-Zertifikat, 2xx-Antwort innerhalb des Timeouts, HMAC-SHA-256-Signaturverifizierung über den Raw-Body | Ausgehende TCP/TLS-Client-Verbindung (wss://); verarbeitet Ping/Pong-Heartbeats und Wiederverbindungs-Backoff | Zustandsloser HTTP-Client oder geplanter Worker; speichert lokalen Block-Cursor |
| Zustellung & Reihenfolge | Mindestens-einmal-Zustellung mit exponentiellem Wiederholungs-Backoff; Empfänger muss nach Ereignis-id bzw. über Abonnements hinweg nach ref + type deduplizieren | Streng geordnete Frames auf einem einzelnen aktiven Socket; Benachrichtigungen werden bei Verbindungsabbrüchen verworfen | Deterministische Pull-Antworten für bestätigte Blockhöhen; Client steuert die Ausführungsgeschwindigkeit |
| Chain-Reorganisationen | Steuerbenachrichtigungen für chain.reorg ausgegeben; Empfänger verwirft ersetzte Ereignisse vor dem Anwenden kanonischer Replays | Log-Benachrichtigungen tragen "removed": true für reorganisierte Logs; newHeads erfordert Prüfung des Parent-Hashs | Client verfolgt die Kontinuität der parentHash-Kette über Poll-Zyklen hinweg, um Reorgs zu erkennen |
| Wiederherstellung bei Fehlern | Server-Aufbewahrungsfenster erlaubt Replay über POST /v1/push/subscriptions/{id}/replay; Lücken vor dem Aktivierungsblock erfordern eth_getLogs-Nachfüllung | Keine serverseitige Warteschlange; Client verbindet sich erneut und füllt verpasste Bereiche per eth_getLogs nach, dedupliziert nach (blockHash, transactionHash, logIndex) | Setzt Abfragen ab dem gespeicherten last_synced_block fort; unterteilt Chunks anhand von max_logs_block_range des Netzwerks aus GET /v1/chains |
| Abrechnungsmodell | Tägliche Adressgebühr pro Gruppe, basierend auf der höchsten Adressanzahl während der Online-Zeit am UTC-Tag, zuzüglich CU für zugestellte Datenereignisse; siehe Webhook-Abrechnung | Handshake und Heartbeats unberechnet; eth_subscribe / eth_unsubscribe und übertragene Socket-Benachrichtigungseinheiten werden in CU abgerechnet | Abrechnung pro Anfrage in Compute Units: eth_blockNumber, eth_call, eth_getLogs; Methodengewichte und CU pro 1 $ aus GET /v1/plans, unten dargestellt |
| Am besten geeignet für | Überwachung von Benutzereinzahlungen, Hot-Wallet-Adress-Tracking, Händler-Checkouts, asynchrone Ereignis-Webhooks | Live-newHeads und gefilterte logs, reaktive Bots, interaktive UIs auf unterstützten Netzwerken | Batch-Abgleich, Cronjobs, ETL-Pipelines, Chains ohne WebSocket-Unterstützung (wie HyperEVM) |
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 |
Wann Adress-Webhooks zu wählen sind
Wählen Sie die Blockchain Webhook API, wenn Ihr Backend als Standard-Webdienst betrieben wird, der eingehende HTTPS-Anfragen empfangen kann:
- Große Adresslisten: Überwachen Sie Einzahlungen oder Abhebungen über Tausende von Kundenadressen hinweg, ohne dauerhafte Sockets pro Wallet aufrechtzuerhalten.
- Serverlose oder containerisierte Empfänger: Serverlose Funktionen (AWS Lambda, Cloudflare Workers) starten bei eingehenden Webhooks und müssen keine kontinuierlichen Verbindungen aufrechterhalten.
- Automatisierte Wiederholungen und Replay: Vorübergehende Ausfälle des Empfängers werden durch automatischen Wiederholungs-Backoff abgefedert. Innerhalb des Server-Aufbewahrungsfensters können verpasste Zustellungen über den Replay-Endpunkt erneut zugestellt werden.
- Überlegungen zur Aktivierungsgrenze: Der Abgleich beginnt erst nach der Anwendung der Abonnementänderung (
applied_from_block). Ereignisse, die vor dem Hinzufügen einer Adresse oder während des Statusofflineeines Abonnements aufgetreten sind, müssen über historische RPC-Logs abgefragt werden.
Prüfen Sie die Signaturverifizierungs- und Replay-Workflows, bevor Sie produktive Webhook-Empfänger bereitstellen.
Wann WebSocket-Abonnements zu wählen sind
Wählen Sie WebSocket-Abonnements, wenn niedrige Latenz erforderlich ist und Ihr Prozess einen langlebigen ausgehenden Socket aufrechterhalten kann:
- Live-Block-Header: Streamen Sie
newHeads, sobald jeder Block an die Spitze der Chain angehängt wird. - Contract-Event-Filter: Streamen Sie Echtzeit-Contract-
logs, die einer Adresse oder einem bestimmtentopic0entsprechen. - Private Umgebungen: Ideal für lokale Skripte, CLI-Agenten oder Backend-Dienste hinter NAT oder Firewalls, die keinen eingehenden öffentlichen HTTPS-Port öffnen können.
- Prüfung der Netzwerkverfügbarkeit: WebSocket wird auf Robinhood Chain unterstützt (Netzwerk-Slug
robinhood_mainnet, Chain-ID 4663 undrobinhood_testnet). HyperEVM bietet derzeit keine WebSocket-Unterstützung (ws: false); ein Verbindungsversuch per WebSocket zu einer nicht bedienten Chain gibt HTTP 404 zurück (unknown_chain). - Disziplin bei Verbindungsabbrüchen: WebSocket-Benachrichtigungen werden bei Verbindungsabbrüchen nicht serverseitig vorgehalten. Wenn der Socket abbricht, müssen Clients die Verbindung mit zufälligem exponentiellem Backoff wiederherstellen und verpasste Blöcke über
eth_getLogsnachfüllen.
Konsultieren Sie den Leitfaden zu WebSocket-Abonnements für Filterlimits, Verbindungsobergrenzen (20 pro Schlüssel, 50 pro Konto) und viem-Verbindungsbeispiele.
Wann begrenztes RPC-Polling zu wählen ist
Wählen Sie begrenztes JSON-RPC-Polling beim Betrieb von geplanten Workern, Daten-Pipelines oder auf Netzwerken, auf denen WebSocket nicht verfügbar ist:
- Netzwerke ohne WebSocket: HyperEVM (
hyperevm_mainnet) bietet derzeit JSON-RPC-HTTP-Zugriff, aber kein WebSocket (ws: false). Das Polling voneth_blockNumberund das Abfragen voneth_getLogsinnerhalb unterstützter Blockbereiche ermöglicht die HyperEVM-Ereignisverarbeitung. - Gesteuertes Abfragetempo: Polling ermöglicht es Entwicklern und KI-Agenten, die Anfragehäufigkeit zu steuern, den Verbrauch von Compute Units gegenüber Limits pro Schlüssel zu verwalten und Socket-Abbrüche bei lang andauernden Aufgaben zu vermeiden. Limits pro Schlüssel — Standardwerte sind 400 CU/s und Burst 1,600 CU.
- Blockbereichslimits: Authentifizierte
eth_getLogs-Abfragen sind durch dasmax_logs_block_rangedes Netzwerks aus GET /v1/chains begrenzt. Das Überschreiten dieses Limits gibt den Fehlercode-32602(logs_range_too_large) zurück. Teilen Sie breitere Intervalle in aufeinanderfolgende Abschnitte auf, die dasmax_logs_block_rangedes Zielnetzwerks nicht überschreiten.
| 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 |
Siehe den HyperEVM-Log-Backfill-Leitfaden und den Leitfaden zum eth_getLogs-Blockbereich für Chunking-Algorithmen.
Für eine vollständige Workload-Checkliste und Selbsttests beginnen Sie mit Wie Sie einen RPC-Anbieter auswählen.
Wenn Sie einen Anbieter für Polling mit geringem Volumen wählen, vergleichen Sie Anbieter hinsichtlich Standard-RPC-Abrechnung und -Abdeckung. Vergleichen Sie nutzungsbasierte Abrechnung mit Test- und Abonnementkosten; Benachrichtigungs- und Backfill-Kosten nutzen andere Messungen als RPC-Leseoperationen.
Implementierungsleitfäden
WebSocket auf Robinhood Chain
Für Live-newHeads oder gefilterte logs auf Robinhood Chain folgen Sie dem Leitfaden zu WebSocket-Abonnements für Authentifizierung und Abonnementanfragen. Stellen Sie nach einem Verbindungsabbruch die Verbindung mit Backoff wieder her, abonnieren Sie erneut und füllen Sie verpasste Blöcke von einem gespeicherten Cursor aus mit eth_getLogs nach; deduplizieren Sie Logs anhand von (blockHash, transactionHash, logIndex).
Begrenztes Polling auf HyperEVM
Für HyperEVM (hyperevm_mainnet) folgen Sie dem HyperEVM-Log-Backfill-Leitfaden für begrenztes Polling und Wiederherstellung. Fragen Sie vom gespeicherten Cursor aus in Abschnitten innerhalb von max_logs_block_range ab, speichern Sie Ereignisse und Fortschritt nach erfolgreicher Verarbeitung gemeinsam dauerhaft und wiederholen Sie unvollständige Bereiche. Prüfen Sie die Chain-Kontinuität und scannen Sie überlappende Bereiche, um Reorgs zu behandeln.
Nächste Schritte
- Datensatzverzeichnis durchsuchen, um alle von BlockVectra indexierten Datensätze zu sehen.
- Kostenlosen Tarif und Preise ansehen, um zu prüfen, was Ihr Konto beinhaltet.
- In der Konsole anmelden, um einen API-Schlüssel zu erstellen.
Zuletzt aktualisiert:
Webhook-Push
Erstellen Sie Adress-Abonnements über HTTP, verifizieren Sie Raw-Body-Signaturen, deduplizieren Sie Ereignis-IDs und stellen Sie gespeicherte Treffer oder fehlende Blöcke wieder her.
WebSocket-Abonnements
Verbinden Sie sich mit den WebSocket-Endpunkten von BlockVectra für eth_subscribe newHeads und logs. Erfahren Sie mehr über Verbindungsmethoden, Filterregeln, Wiederverbindungs-Backoff und Wiederherstellung.