Zum Hauptinhalt springen
Öffentliche Beta. preprocessedSubscribe ist in allen kostenpflichtigen Tarifen verfügbar und wird mit 0,1 Credits pro Nachricht abgerechnet (eine Nachricht pro zugestellter Transaktion).

Was ist preprocessedSubscribe?

preprocessedSubscribe ist eine WebSocket-Methode von Helius, die vorverarbeitete Transaktionen streamt – Solana-Transaktionen vor ihrer Ausführung, die zugestellt werden, bevor sie das commitment processed erreichen. Helius aggregiert mehrere Quellen vor der Ausführung – hauptsächlich shred, die direkt bei ihrer Ankunft am Validator dekodiert werden, ergänzt durch Preconfirmation-Signale – und liefert sie als einen einzelnen deduplizierten stream kompakter binärer Nachrichten. Du benötigst dafür keine eigene Infrastruktur zum Zusammensetzen der shred. Transaktionen aus Preconfirmation-Signalen treffen in diesem Feed später ein als im dedizierten Produkt Preconfirmations, das weiterhin den frühesten Zugriff darauf bietet. Diese Methode ist der Nachfolger des früheren Produkts preprocessed LaserStream (gRPC). Wenn du vorverarbeitete Transaktionen derzeit über gRPC empfängst, wechsle zu dieser Methode. Sie liefert dieselbe Datenklasse über eine einfache WebSocket-Verbindung mit geringerer Latenz. Die Bereitstellung über gRPC wird eingestellt.
preprocessedSubscribe ist ein Best-Effort-Signal vor der Ausführung, kein commitment. Eine gestreamte Transaktion kann fehlschlagen, verworfen werden oder in einem anderen Fork landen. Gleiche sie mit einem verarbeiteten oder bestätigten stream ab, bevor du sie als endgültig behandelst.

Endpoint

preprocessedSubscribe wird über wss://beta.helius-rpc.com bereitgestellt – den Helius Gatekeeper endpoint – und nicht über mainnet.helius-rpc.com. Authentifiziere dich mit deinem API key als Abfrageparameter:
Jeder API key ist auf 10 gleichzeitige Verbindungen/Abonnements begrenzt.

Abonnieren

Sende einen JSON-RPC request mit der Methode preprocessedSubscribe. params enthält die Filter für accounts und ist erforderlich. accountInclude und accountRequired müssen zusammen mindestens einen account angeben (siehe Filterung):
Der Server bestätigt das Abonnement mit einem JSON-Textframe, der die Abonnement-ID enthält:
Nach dieser Bestätigung treffen Transaktionsaktualisierungen als binäre WebSocket-Frames ein – siehe Payload der Benachrichtigung.

Filterung

Jedes Abonnement wird durch die Filter für accounts in params eingegrenzt. Die Filterung erfolgt serverseitig, sodass du nur relevante Transaktionen erhältst:
Filterregeln:
  • Die drei Filter werden mit UND-Logik kombiniert.
  • accountInclude und accountRequired müssen zusammen mindestens einen account angeben – es gibt keinen ungefilterten vollständigen stream.
  • Accounts sind Base58-kodierte öffentliche Schlüssel. Jede Liste akzeptiert bis zu 5.000 Adressen.

Auflösung von Address Lookup Tables (ALT)

Die Filter für accounts gleichen mehr als nur die statischen Schlüssel der Transaktion ab. Helius löst Address Lookup Tables serverseitig auf. Dadurch gleichen accountInclude, accountExclude und accountRequired auch accounts ab, die eine Transaktion über eine ALT lädt. Übergib einfach den öffentlichen Schlüssel des account. Du musst weder ALT-Zuordnungen verwalten noch Tabellen selbst auflösen.

Payload der Benachrichtigung

Benachrichtigungen werden als binäre WebSocket-Frames zugestellt, nicht als JSON. Jeder Frame enthält eine einzelne Transaktion in einem kompakten Byte-Layout: Lies zuerst der Reihe nach das feste 73-Byte-Präfix. Dekodiere dann die verbleibenden Bytes, um Anweisungen, accounts und Lookups in Adresstabellen zu lesen. Die Signatur ist im Präfix enthalten. So kannst du eine Transaktion identifizieren und deduplizieren, ohne den vollständigen Transaktionskörper zu dekodieren. Lies und prüfe immer zuerst das Byte version. Wenn Helius das payload-Format aktualisieren muss, wird die Version erhöht. Verzweige anhand der Version, damit dein Decoder auch nach Schemaänderungen funktioniert.

Transaktion dekodieren

Die Transaktionsbytes werden genau so weitergeleitet, wie sie im Netzwerk beobachtet wurden: in der standardmäßigen Wire-Kodierung der jeweiligen Transaktionsversion. Legacy- und v0-Transaktionen verwenden das Signaturen-zuerst-Layout, das bincode erzeugt. Transaction v1 (SIMD-0385) verwendet ein Nachricht-zuerst-Layout mit den Signaturen am Ende. Deshalb schlägt bincode bei v1-payloads fehl. Verwende einen Decoder, der jede Version unterstützt:
  • Rust: agave-transaction-view parst Legacy-, v0- und v1-Transaktionen direkt und ohne Zwischenkopie. Dies ist die empfohlene Option. wincode, der mit bincode kompatible Serializer aktueller Solana SDKs, dekodiert v1 ebenfalls in VersionedTransaction.
  • JavaScript / TypeScript: Stelle sicher, dass deine Bibliotheksversion Transaction v1 unterstützt. Ältere Implementierungen von VersionedTransaction.deserialize unterstützen nur Legacy und v0. Verwende @solana/kit 8.0+ oder @solana/web3.js v3. Siehe Unterstützung für Transaction v1.

Beispiel

Welche Daten sind verfügbar?

Jede Benachrichtigung enthält die signierte Transaktion, ihre erste Signatur und ihren slot. Da die Zustellung vor der Ausführung erfolgt, enthält der stream nicht:
  • Ausführungsstatus oder Fehler
  • Kontostände vor/nach der Ausführung oder Änderungen an token-Beständen
  • Protokollnachrichten oder innere Anweisungen
  • Verbrauchte Compute Units
Stell dir vor, du erhältst den „Vorschlag“ ohne das „Ergebnis“: Du siehst, was der Sender versucht hat, aber nicht, was tatsächlich passiert ist. Auch Statusaktualisierungen für accounts und Programme existieren in dieser Phase noch nicht. Wenn du den Status eines account in Echtzeit benötigst, verwende LaserStream gRPC mit dem commitment processed.

Backpressure

Der stream puffert für langsame Consumer nicht unbegrenzt. Wenn dein Client zu langsam liest und sich serverseitig mehr als 4.000 Nachrichten aufstauen, schließt Helius die Verbindung. Du erhältst dabei einen ordnungsgemäßen WebSocket-Close-Frame. Verarbeite Frames schneller, als sie eintreffen. Führe aufwendige Arbeiten wie das Dekodieren von Transaktionen und die Strategielogik außerhalb der Empfangsschleife aus. Stelle nach einer Trennung die Verbindung wieder her und abonniere erneut.

Zustellgarantien

Die Zustellung erfolgt nach dem Best-Effort-Prinzip, ist nicht garantiert und bietet keine historische Wiedergabe. Clients sollten:
  1. Nach dem Schließen einer Verbindung erneut eine Verbindung herstellen und das Abonnement erneuern.
  2. Anhand der Transaktionssignatur deduplizieren.
  3. Den slot als Beobachtung und nicht als Endgültigkeit behandeln.
  4. Mit einem verarbeiteten oder bestätigten stream abgleichen, wenn die Ausführungsergebnisse relevant sind.

Preise

preprocessedSubscribe ist in allen kostenpflichtigen Tarifen verfügbar und wird mit 0,1 Credits pro Nachricht abgerechnet – eine Nachricht pro zugestellter Transaktion, abgerechnet über deinen Tarif. Weitere Informationen findest du unter Credits.

Verwandte Themen

Preconfirmations

Transaktionen, die gestreamt werden, bevor sie zu shred werden – das früheste Transaktionssignal.

Raw Shreds (UDP)

Unverarbeitete shred-Pakete über UDP. Du implementierst das Zusammensetzen der shred.

transactionSubscribe

Transaktionen nach der Ausführung mit umfassender Filterung und Ausführungsmetadaten.