Skip to main content
Öffentliche Beta. preprocessedSubscribe ist auf allen kostenpflichtigen Plänen verfügbar und wird mit 0,1 Credits pro Nachricht berechnet (eine Nachricht pro ausgelieferter Transaktion).

Was ist preprocessedSubscribe?

preprocessedSubscribe ist eine Helius WebSocket-Methode, die vorverarbeitete Transaktionen streamt — Solana-Transaktionen vor der Ausführung geliefert bevor sie das processed-Verpflichtungsniveau erreichen. Helius aggregiert mehrere Quellen vor der Ausführung — hauptsächlich Shreds, die direkt dekodiert werden, sobald sie beim Validator eintreffen, ergänzt durch Prekonfirmationssignale — und liefert sie als einen einzelnen deduplizierten Stream kompakter binärer Nachrichten, ohne dass auf Ihrer Seite eine Deshredding-Infrastruktur notwendig ist. Transaktionen, die aus Prekonfirmationssignalen stammen, kommen später in diesem Feed an als im dedizierten Preconfirmations Produkt, das nach wie vor den frühesten Zugang zu ihnen bietet. Es ist der Nachfolger des früheren vorverarbeiteten LaserStream (gRPC) Produkts. Wenn Sie derzeit vorverarbeitete Transaktionen über gRPC konsumieren, wechseln Sie zu dieser Methode — sie liefert die gleiche Datenklasse über eine einfache WebSocket-Verbindung bei geringerer Latenz, und die gRPC-Lieferung wird eingestellt.
preprocessedSubscribe ist ein Best-Effort, Signal vor der Ausführung, kein Verpflichtungsniveau. Eine gestreamte Transaktion kann fehlschlagen, fallen gelassen oder auf einem anderen Fork landen. Vergleichen Sie mit einem verarbeiteten oder bestätigten Stream, bevor Sie sie als endgültig betrachten.

Endpoint

preprocessedSubscribe wird vom wss://beta.helius-rpc.com — dem Helius Gatekeeper-Endpoint — bereitgestellt, anstatt mainnet.helius-rpc.com. Authentifizieren Sie sich mit Ihrem API-Schlüssel als Abfrageparameter:
Jeder API-Schlüssel ist auf 10 gleichzeitige Verbindungen/Abonnements begrenzt.

Abonnieren

Senden Sie eine JSON-RPC-Anfrage mit der preprocessedSubscribe-Methode. params führt die Kontofilter und ist erforderlich — accountInclude und accountRequired müssen mindestens ein Konto zwischen sich angeben (siehe Filterung):
Der Server bestätigt das Abonnement mit einem JSON-Text-Frame, der die Abonnement-ID enthält:
Nach dieser Bestätigung kommen Transaktionsaktualisierungen als binäre WebSocket-Frames an — siehe Benachrichtigungsnutzlast.

Filterung

Jedes Abonnement ist durch die Kontofilter in params begrenzt. Die Filterung erfolgt serverseitig, sodass Sie nur die Transaktionen erhalten, die Sie interessieren:
Filterregeln:
  • Die drei Filter werden mit UND-Logik kombiniert.
  • accountInclude und accountRequired müssen mindestens ein Konto zwischen sich angeben — es gibt keinen ungefilterten vollständigen Stream.
  • Konten sind base58-codierte Pubkeys. Jede Liste akzeptiert bis zu 5.000 Adressen.

Auflösung der Address Lookup Table (ALT)

Kontofilter stimmen mit mehr als den statischen Kontoschlüsseln der Transaktion überein — Helius löst Address Lookup Tables serverseitig auf, sodass accountInclude, accountExclude und accountRequired auch Konten übereinstimmen, die eine Transaktion über eine ALT lädt. Geben Sie einfach den Pubkey des Kontos an; es ist nicht notwendig, ALT-Zuordnungen zu pflegen oder Tabellen selbst aufzulösen.

Benachrichtigungsnutzlast

Benachrichtigungen werden als binäre WebSocket-Frames (nicht JSON) geliefert. Jeder Frame enthält eine einzelne Transaktion in einem kompakten Byte-Layout: Lesen Sie das feste Präfix von 73 Byte in der Reihenfolge und dekodieren Sie dann die restlichen Bytes, um Anweisungen, Konten und Address-Table-Lookups zu lesen. Die Signatur ist im Präfix enthalten, damit Sie eine Transaktion identifizieren und deduplizieren können, ohne den vollständigen Transaktionskörper zu dekodieren. Lesen und überprüfen Sie immer zuerst das version-Byte. Wenn Helius das Nutzlastformat aktualisieren muss, wird die Version inkrementiert — verzweigen Sie darauf, damit Ihr Decoder bei Schemaänderungen weiterhin funktioniert.

Dekodierung der Transaktion

Die Transaktionsbytes werden genau so weitergeleitet, wie sie im Netzwerk beobachtet wurden, in der Standard-Wire-Codierung für die Version der Transaktion. Legacy- und v0-Transaktionen verwenden das signaturerste Layout, das bincode erzeugt. Die Transaktion v1 (SIMD-0385) verwendet ein Nachrichten-erste-Layout mit den Signaturen am Ende, sodass bincode bei v1-Nutzlasten fehlschlägt. Verwenden Sie einen Decoder, der jede Version handhabt:
  • Rust: agave-transaction-view analysiert Legacy-, v0- und v1-Transaktionen an Ort und Stelle, ohne eine Zwischenkopie. Dies ist die empfohlene Option. wincode, der mit Bincode kompatible Serializer, der von aktuellen Solana-SDKs verwendet wird, dekodiert auch v1 in VersionedTransaction.
  • JavaScript / TypeScript: Stellen Sie sicher, dass Ihre Bibliotheksversion die Transaktion v1 unterstützt. Ältere VersionedTransaction.deserialize-Implementierungen behandeln nur Legacy und v0. Verwenden Sie @solana/kit 8.0+ oder @solana/web3.js v3. Siehe Transaktion v1 Unterstützung.

Beispiel

Welche Daten sind verfügbar?

Jede Benachrichtigung enthält die unterzeichnete Transaktion, ihre erste Signatur und ihren Slot. Da die Lieferung vor der Ausführung erfolgt, enthält der Stream nicht:
  • Ausführungsstatus oder Fehler
  • Vor-/Nach-Salden oder Token-Saldenänderungen
  • Log-Nachrichten oder innere Anweisungen
  • Verbrauchte Computereinheiten
Betrachten Sie es als den Erhalt des “Vorschlags” ohne das “Ergebnis” — Sie sehen, was der Absender versucht hat zu tun, aber nicht, was tatsächlich passiert ist. Konto- und Programmstatusaktualisierungen existieren in diesem Stadium ebenfalls noch nicht; wenn Sie Echtzeit-Kontostatus benötigen, verwenden Sie LaserStream gRPC bei processed-Verpflichtung.

Rückstau

Der Stream puffert nicht unbegrenzt für langsame Konsumenten. Wenn Ihr Client zu langsam liest und mehr als 4.000 Nachrichten serverseitig aufstauen, schließt Helius die Verbindung — Sie erhalten einen sauberen WebSocket-Schluss-Frame. Entleeren Sie Frames schneller, als sie ankommen: halten Sie schwere Arbeiten wie Transaktionsdekodierung und Strategie-Logik von der Empfängerschleife fern und stellen Sie nach einer Trennung die Verbindung erneut her und abonnieren Sie neu.

Liefergarantien

Die Lieferung ist best-effort und nicht garantiert, und es gibt keinen historischen Replay. Clients sollten:
  1. Nach dem Schließen einer Verbindung erneut verbinden und abonnieren.
  2. Nach Transaktionssignatur deduplizieren.
  3. Behandeln Sie den Slot als Beobachtung, nicht als Finalität.
  4. Vergleichen Sie mit einem verarbeiteten oder bestätigten Stream, wenn Ausführungsergebnisse wichtig sind.

Preisgestaltung

preprocessedSubscribe ist auf allen kostenpflichtigen Plänen verfügbar und wird mit 0,1 Credits pro Nachricht berechnet — eine Nachricht pro ausgelieferter Transaktion, die von Ihrem Plan abgerechnet wird. Siehe Credits für Details.

Verwandte Themen

Preconfirmations

Transaktionen, die gestreamt werden, bevor sie zu Shreds werden — das früheste Transaktionssignal.

Roh-Shreds (UDP)

Unverarbeitete Shred-Pakete über UDP. Sie implementieren das Deshredding.

transactionSubscribe

Post-Ausführungs-Transaktionen mit umfangreicher Filterung und Ausführungsmetadaten.