Zum Hauptinhalt springen

Übersicht

LaserStream ist ein verwalteter Solana-gRPC-Streamingdienst. Er ist auf Protokollebene mit dem offenen Yellowstone-gRPC-Protokoll kompatibel. Dadurch funktioniert jeder Yellowstone-Client sofort. Zusätzlich bietet er Funktionen für den Produktivbetrieb wie historische Wiedergabe, Failover über mehrere node und eine vollständig verwaltete Umgebung. LaserStream verwendet das quelloffene gRPC-Protokoll. So vermeidest du die Bindung an einen Anbieter und erhältst maximale Kompatibilität mit bestehenden gRPC-Implementierungen. Du kannst entweder den standardmäßigen @triton-one/yellowstone-grpc-Client oder das leistungsoptimierte Helius LaserStream SDK verwenden. Das SDK bietet unter anderem einen höheren Durchsatz, automatische Neuverbindungen, Subscription-Verwaltung und Fehlerbehandlung.

LaserStream SDK is 40x Faster vs. JavaScript Yellowstone Clients

Erfahre, wie wir Rust Core mit Zero-Copy-NAPI-Bindings verwendet haben, um die Leistung des JavaScript-SDK zu maximieren
Leistungshinweis: Falls bei deiner LaserStream-Verbindung Verzögerungen oder Leistungsprobleme auftreten, findest du im Abschnitt zur Fehlerbehebung häufige Ursachen und Lösungen.

Endpoints und Regionen

LaserStream ist weltweit in mehreren Regionen verfügbar. Wähle für optimale Leistung den endpoint aus, der deiner Anwendung am nächsten ist:

Mainnet-endpoints

Devnet-endpoint

Netzwerk- und Regionsauswahl:
  • Wähle für Produktionsanwendungen den Mainnet-endpoint aus, der deinem Server am nächsten ist. So erhältst du die beste Leistung. Verwende bei einem deployment in Europa beispielsweise Amsterdam (ams) oder Frankfurt (fra)
  • Verwende für Tests: https://laserstream-devnet-ewr.helius-rpc.com.

zstd-Komprimierung

Alle LaserStream-gRPC-endpoints unterstützen die zstd-Komprimierung. Die Komprimierung ist optional: responses bleiben unkomprimiert, sofern dein Client keine Unterstützung für zstd signalisiert. Aktiviere zstd im Helius LaserStream TypeScript SDK:
zstd reduziert die Netzwerkbandbreite, verursacht aber zusätzlichen Rechenaufwand für die Komprimierung. Führe Benchmarks mit deiner Subscription-Arbeitslast durch, bevor du es für latenzempfindliche stream aktivierst.

Kürzung von Protokollen

Standardmäßig kürzt LaserStream Transaktionsprotokollmeldungen auf 10 KB, um Geschwindigkeit und Leistung zu verbessern. Wenn du vollständige Protokolle benötigst, stehen spezielle ungekürzte endpoints zur Verfügung. Weitere Informationen findest du unter Kürzung von Protokollen.

Schnellstart

Starte LaserStream über dein Helius Dashboard. Für Mainnet benötigst du einen Business- oder Professional-Tarif. Devnet ist ab dem Developer-Tarif verfügbar. Weitere Informationen findest du unter Tarife und Preise.
1

Create a New Project

2

Install Dependencies

Wir verwenden tsx, weil das standardmäßige npx tsc --init in TypeScript 5.x verbatimModuleSyntax, module: "nodenext" und types: [] setzt. Diese verhindern alle eine schnelle Ausführung mit ts-node index.ts. tsx führt .ts-Dateien ohne tsconfig aus.
3

Obtain Your API Key

Generiere einen API key im Helius Dashboard.Dieser API key dient als Authentifizierungs-token für LaserStream.
Tarifanforderungen: LaserStream Devnet ist in allen Tarifen verfügbar. Für LaserStream Mainnet benötigst du einen Business- oder Professional-Tarif.
4

Create a Subscription Script

Erstelle index.ts mit folgendem Inhalt:
5

Replace Your API Key and Choose Your Region

Aktualisiere in index.ts das config-Objekt mit:
  1. Deinem tatsächlichen API key aus dem Helius Dashboard
  2. Dem LaserStream-endpoint, der deinem Serverstandort am nächsten ist
Beispiele für die Netzwerk- und Regionsauswahl:
  • Für die Produktion (Mainnet):
    • Europa: Verwende fra (Frankfurt), ams (Amsterdam) oder lon (London)
    • Osten der USA: Verwende ewr (New York)
    • Westen der USA: Verwende slc (Salt Lake City) oder lax (Los Angeles)
    • Asien: Verwende tyo (Tokio) oder sgp (Singapur)
  • Für die Entwicklung (Devnet):
    • Verwende https://laserstream-devnet-ewr.helius-rpc.com
6

Run and View Results

Sobald eine Transaktion mit dem confirmed-token TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA betrifft, siehst du die Daten in deiner Konsole.

Häufige Workflows

Schritt-für-Schritt-Anleitungen für die häufigsten Workflows. Jede Anleitung verwendet das helius-laserstream SDK mit integrierter automatischer Neuverbindung und historischer Wiedergabe.

Account Subscriptions

Überwache mit Filtern Änderungen an Salden, Daten und Eigentumsverhältnissen bestimmter Konten.

Transaction Monitoring

Streame Transaktionen, die Zielkonten betreffen, und filtere nach Programm, Abstimmungs- oder Fehlerstatus.

Slot & Block Monitoring

Verfolge Netzwerkkonsens, Blockproduktion und Übergänge zwischen commitment-Stufen.

Decoding Transaction Data

Wandle die binären transactionUpdate-payloads in lesbare Solana-Transaktionen um.

Stream Pump AMM Data

Praxisbeispiel: Überwache Pump-AMM-Handel mit Filtern, die Neuverbindungen sicher überstehen.
Der @triton-one/yellowstone-grpc-Client funktioniert mit denselben endpoints, wenn du das unverarbeitete Yellowstone-Protokoll bevorzugst. Details auf Protokollebene findest du in der Yellowstone-gRPC-Referenz.

Subscribe-request

Der Subscribe-request muss die folgenden allgemeinen Parameter enthalten:
Historische Wiedergabe: Du kannst optional ein fromSlot-Feld (eine u64-Zahl) in das zentrale SubscribeRequest-Objekt aufnehmen, um Daten ab einem bestimmten slot erneut abzuspielen. Die Wiedergabe ist derzeit auf die letzten ~48 Stunden begrenzt (~691.200 slots bei aktueller Netzwerkgeschwindigkeit). Beachte, dass Wiedergaben, die mehr als ~20 Minuten zurückliegen, nur finalisierte Daten zurückgeben.
enum
Gibt das commitment-Level an. Möglich sind processed, confirmed und finalized.
array
Ein Array aus Objekten { offset: uint64, length: uint64 }, mit dem du nur die benötigten Datenausschnitte von Accounts empfangen kannst.
boolean
Einige Cloud-Anbieter wie Cloudflare schließen möglicherweise inaktive Streams nach einer gewissen Zeit. Setze diesen Wert auf true, um das zu verhindern und die Verbindung aufrechtzuerhalten, ohne Filter erneut senden zu müssen. Der Server antwortet alle 15 Sekunden mit einer Pong-Nachricht.
Gib anschließend die Filter für die Daten an, die du abonnieren möchtest, etwa Konten, Blöcke, slots oder Transaktionen.
Definiere Filter für slot-Aktualisierungen. Der verwendete Schlüssel, zum Beispiel mySlotLabel, ist eine benutzerdefinierte Bezeichnung für diese spezifische Filterkonfiguration. So kannst du bei Bedarf mehrere benannte Konfigurationen definieren, auch wenn normalerweise eine ausreicht.
boolean
Standardmäßig werden slots für alle commitment-Level gesendet. Mit diesem Filter kannst du festlegen, dass nur das ausgewählte commitment-Level empfangen wird.
boolean
Aktiviert Updates für Änderungen innerhalb eines slots, nicht nur zu Beginn neuer slots. Das ist nützlich für detailliertere slot-Daten mit niedriger Latenz.
Definiere Filter für Aktualisierungen von Kontodaten. Der verwendete Schlüssel, zum Beispiel tokenAccounts, ist eine benutzerdefinierte Bezeichnung für diese spezifische Filterkonfiguration.
array
Stimmt mit jedem öffentlichen Schlüssel aus dem angegebenen Array überein.
array
Der öffentliche Schlüssel des Kontoinhabers. Stimmt mit jedem öffentlichen Schlüssel aus dem angegebenen Array überein.
array
Ähnelt den Filtern in getProgramAccounts. Dies ist ein Array aus datasize- und/oder memcmp-Filtern. Bei memcmp wird der Vergleichswert in bytes, base58 oder base64 direkt im memcmp-Objekt angegeben.
enum
veraltet
Veraltet – seit Agave 4.2 ohne Funktion. Das Setzen von notifyOn hat keine Wirkung. Das Feld wird zu einem späteren Zeitpunkt entfernt.
Sind alle Felder leer, werden alle Konten übertragen. Andernfalls gilt:
  • Felder werden mit einem logischen UND verknüpft.
  • Werte innerhalb von Arrays werden mit einem logischen ODER verknüpft. Eine Ausnahme bilden Werte innerhalb von filters, die mit einem logischen UND verknüpft werden.
Verfolgst du mehr als etwa 10.000 Konten? Verwende statt einer expliziten Liste öffentlicher Schlüssel mit 32 Byte pro Konto einen komprimierten Cuckoo-Filter mit etwa 3–4 Byte pro Konto. Damit kannst du Hunderttausende Konten in einem einzigen stream abonnieren. Verfügbar in den Rust- und JavaScript-SDKs.
Definiere Filter für Transaktionsaktualisierungen. Der verwendete Schlüssel, zum Beispiel myTxSubscription, ist eine benutzerdefinierte Bezeichnung für diese spezifische Filterkonfiguration.
boolean
Aktiviere oder deaktiviere die Übertragung von Vote-Transaktionen.
boolean
Aktiviere oder deaktiviere die Übertragung fehlgeschlagener Transaktionen.
string
Übertrage nur Transaktionen, die der angegebenen Signatur entsprechen.
array
Filtere Transaktionen, an denen mindestens ein Account aus der angegebenen Liste beteiligt ist.
array
Schließe Transaktionen aus, an denen mindestens ein Account aus der angegebenen Liste beteiligt ist (Gegenteil von accountInclude).
array
Filtere Transaktionen, an denen alle Accounts aus der angegebenen Liste beteiligt sind (alle Accounts müssen verwendet werden).
string
Optionale Erweiterung für tokenAccounts (Associated Token Account). Wenn diese Option gesetzt ist, stimmt eine accountInclude-Wallet auch mit Transaktionen überein, bei denen sie ein SPL-token-Guthaben besitzt – zum Beispiel eingehende token-Übertragungen, die den token-Account der Wallet statt ihres pubkey betreffen. Akzeptiert "balanceChanged" (Übereinstimmungen bei Guthabenänderungen), "all" (jede Referenz, höheres Volumen) oder "none" (keine Erweiterung, Standardeinstellung). Das SDK konvertiert den String in das Wire-Level-Enum TokenAccountExpansionControlFlag (Teil von yellowstone-grpc-proto 12.5.0+). Unter Filterung nach Token-Accounts (ATA) erfährst du, was die Option bewirkt und wie sie funktioniert.
boolean
Optionales Flag matchMints (Standardwert false). Wenn true festgelegt ist, werden die Listen accountInclude, accountExclude und accountRequired nicht nur mit den Account-Keys der Transaktion, sondern auch mit den Mints in ihren token-Guthaben vor und nach der Transaktion abgeglichen. Füge einen Mint zu accountInclude hinzu, um jede Transaktion zu empfangen, die dieses token betrifft. Dazu gehören auch einfache SPL-Übertragungen, die den Mint nie in ihren Account-Keys referenzieren. Diese Option muss explizit aktiviert werden und hat keine Auswirkungen auf bestehende Filter. Erfordert helius-laserstream 0.8.5+ (JS), 0.6.4+ (Rust) oder go/v0.3.0+ (Go). Unter Filterung nach Token-Mints findest du die Semantik und Beispiele.
Wenn alle Felder leer bleiben, werden alle Transaktionen übertragen. Andernfalls gilt:
  • Felder werden mit einem logischen UND verknüpft.
  • Werte innerhalb von Arrays werden als logisches ODER behandelt. Eine Ausnahme ist accountRequired, wo alle übereinstimmen müssen.
Definiere Filter für Blockaktualisierungen. Der verwendete Schlüssel, zum Beispiel myBlockLabel, ist eine benutzerdefinierte Bezeichnung für diese spezifische Filterkonfiguration.
array
Filtert Transaktionen und Accounts, an denen mindestens ein Account aus der angegebenen Liste beteiligt ist.
boolean
Nimmt alle Transaktionen in die Übertragung auf.
boolean
Nimmt alle Account-Updates in die Übertragung auf.
boolean
Nimmt alle Einträge in die Übertragung auf.
Diese Funktion arbeitet ähnlich wie Blocks, schließt jedoch Transaktionen, Konten und Einträge aus. Der verwendete Schlüssel, zum Beispiel blockmetadata, ist eine benutzerdefinierte Bezeichnung für diese Subscription. Derzeit stehen keine Filter für Blockmetadaten zur Verfügung. Standardmäßig werden alle Nachrichten übertragen.
Abonniere Ledger-Einträge. Der verwendete Schlüssel, zum Beispiel entrySubscribe, ist eine benutzerdefinierte Bezeichnung für diese Subscription. Derzeit stehen keine Filter für Einträge zur Verfügung. Alle Einträge werden übertragen.

Codebeispiele (LaserStream SDK)

SDK-Optionen

Wir bieten offizielle SDKs für mehrere Programmiersprachen an: Für andere Sprachen oder eigene Implementierungen kannst du die Yellowstone gRPC-Proto-Dateien direkt verwenden, um gRPC-Clients für deine bevorzugte Sprache zu generieren.

Fehlerbehebung / FAQ

A: Leistungsprobleme bei LaserStream-Verbindungen haben in der Regel folgende Ursachen:
  • Langsamer JavaScript-Client: Der JavaScript-Client kann ins Hintertreffen geraten, wenn er zu viele Nachrichten verarbeitet oder zu viel Bandbreite verbraucht. Grenze die Filter deiner Abonnements stärker ein, um das Nachrichtenvolumen zu reduzieren. Wechsle zum LaserStream JavaScript SDK oder verwende eine andere Sprache.
  • Begrenzte lokale Bandbreite: Umfangreiche Abonnements können Clients mit begrenzter Netzwerkbandbreite überlasten. Überwache deine Netzwerkauslastung und erwäge, deine Verbindung aufzurüsten oder den Umfang des Abonnements zu reduzieren.
  • Geografische Entfernung: Lange Netzwerkrouten erhöhen die Latenz und den Paketverlust. Verwende den endpoint, der deinem Server am nächsten ist. Erhöhe bei Verbindungen mit hoher Latenz die Größe deiner Netzwerk-Lesepuffer. Das kann die Bandbreite um das Fünffache oder mehr verbessern:
    Füge Folgendes zu /etc/sysctl.conf hinzu, damit die Einstellungen auch nach Neustarts erhalten bleiben:
    Erhöhe die Fenstergrößen für den HTTP/2-stream und die Verbindung auf 64 MB, um Engpässe bei der Flusssteuerung zu vermeiden. Beides ist erforderlich — wenn du nur das stream-Fenster vergrößerst, bleibt das Fenster auf Verbindungsebene der begrenzende Faktor:
  • Engpässe bei der clientseitigen Verarbeitung: Stelle sicher, dass deine Logik zur Nachrichtenverarbeitung optimiert ist und den Haupt-Thread nicht über längere Zeit blockiert.
Client-Verzögerungen debuggen: Um dir beim Debuggen des Clients zu helfen, haben wir ein Tool entwickelt, das die maximale Bandbreite von deinem node zu einem LaserStream-gRPC-Server testet. Führe dazu Folgendes aus:
Die Ausgabe zeigt die maximale Netzwerkkapazität zwischen deinem Server und dem LaserStream-Server. Du benötigst mindestens 10 MB/s, um alle Transaktionsdaten zu abonnieren, und 80 MB/s für alle Kontodaten. Für optimale Leistung empfehlen wir mindestens das Doppelte der erforderlichen Kapazität.
A: Prüfe, ob dein API key und endpoint korrekt sind und dein Netzwerk ausgehende gRPC-Verbindungen zum angegebenen endpoint zulässt. Prüfe auf der Helius-Statusseite, ob derzeit Störungen vorliegen.
A: Prüfe die in den Filterabschnitten beschriebenen logischen Operatoren (AND/OR) noch einmal. Stelle sicher, dass die öffentlichen Schlüssel korrekt sind. Prüfe die in deinem request angegebene commitment-Stufe.
A: Ja, du kannst innerhalb desselben SubscribeRequest-Objekts Filterkonfigurationen unter mehreren Schlüsseln definieren, zum Beispiel accounts und transactions.
A: Wir implementieren keine Consumer Groups. Stattdessen liefert LaserStream die Ergebnisse, die Teams benötigen: Fortsetzen, Wiedergabe und Zuverlässigkeit über mehrere nodes hinweg — ohne Koordinationsschicht und die damit verbundene Latenz und Zusatzlast. Wir sind überzeugt, dass Consumer Groups für die meisten Workloads nicht nötig sind und zusätzliche Latenz sowie betrieblichen Aufwand verursachen. Eine einzelne LaserStream-gRPC-Verbindung kann beispielsweise bis zum Zehnfachen der Transaktions- und Kontodaten von Solana ausgeben. Die meisten Clients abonnieren jedoch nur einen kleinen, gefilterten Ausschnitt. Consumer Groups verbrauchen in diesem Fall Leistungsreserven und schaffen eine weitere potenzielle Fehlerquelle.
A: LaserStream kürzt Transaktionsprotokollmeldungen standardmäßig auf 10 KB, um Geschwindigkeit und Leistung zu verbessern. Wenn du vollständige Protokolle benötigst, verbinde dich mit einem dedizierten endpoint ohne Kürzung. Eine Liste findest du unter Protokollkürzung.
A: Wenn du ein ping-Feld in deinen ersten SubscribeRequest aufnimmst, ignoriert LaserStream stillschweigend alle Abonnementfilter. Es wird nur ein Pong ohne Konto-, Transaktions- oder slot-Daten zurückgegeben. Entferne zur Behebung ping aus dem ersten request zum Abonnieren. Sende Pings stattdessen separat über die Senke des stream, nachdem das Abonnement eingerichtet wurde. So bleibt die Verbindung aktiv, ohne deine Filter zu beeinträchtigen.