Passer au contenu principal

Vue d’ensemble

LaserStream est un service de streaming gRPC Solana géré. Il est compatible avec le protocole ouvert Yellowstone gRPC — donc tout client Yellowstone fonctionne immédiatement — et ajoute des fonctionnalités de production comme la relecture historique, le basculement multi-nœuds, et un environnement entièrement géré. LaserStream utilise le protocole open source gRPC, garantissant aucune dépendance vis-à-vis d’un fournisseur et une compatibilité maximale avec les implémentations gRPC existantes. Vous pouvez vous connecter soit avec le client standard @triton-one/yellowstone-grpc soit utiliser le Helius LaserStream SDK optimisé pour des performances accrues, y compris un débit plus élevé, des reconnexions automatiques, une gestion des abonnements, la gestion des erreurs, et plus encore.

Le SDK LaserStream est 40x plus rapide que les clients JavaScript Yellowstone

Découvrez comment nous avons utilisé Rust Core avec des liaisons NAPI sans copie pour optimiser les performances du SDK JavaScript
Avis de performance: Si vous rencontrez un décalage ou des problèmes de performance avec votre connexion LaserStream, veuillez consulter la section Dépannage pour les causes courantes et les solutions.

Endpoints et Régions

LaserStream est disponible dans plusieurs régions dans le monde. Choisissez le endpoint le plus proche de votre application pour des performances optimales :

Endpoints Mainnet

Endpoint Devnet

Sélection du réseau et de la région :
  • Pour les applications de production, choisissez le endpoint mainnet le plus proche de votre serveur pour de meilleures performances (par exemple, si déployé en Europe, utilisez Amsterdam (ams) ou Francfort (fra))
  • Pour tester, utilisez : https://laserstream-devnet-ewr.helius-rpc.com.

zstd Compression

Tous les endpoints gRPC LaserStream prennent en charge la compression zstd. La compression est facultative : les réponses restent non compressées à moins que votre client ne prenne en charge zstd. Activez zstd dans le Helius LaserStream TypeScript SDK :
zstd réduit la bande passante réseau, mais ajoute du travail de compression. Évaluez cela avec votre charge de souscription avant de l’activer pour les flux sensibles à la latence.

Troncature des journaux

Par défaut, LaserStream tronque les messages des journaux de transactions à 10 KB pour améliorer la vitesse et la performance. Si vous avez besoin de journaux complets, des endpoints dédiés sans troncature sont disponibles — voir Troncature des journaux.

Démarrage rapide

Commencez avec LaserStream depuis votre Tableau de bord Helius. Mainnet nécessite un plan Business ou Professional ; Devnet est disponible sur Developer et au-delà. Voir Plans & Tarification pour plus de détails.
1

Créer un nouveau projet

2

Installer les dépendances

Nous utilisons tsx car le défaut npx tsc --init sur TypeScript 5.x définit verbatimModuleSyntax, module: "nodenext", et types: [], ce qui casse un rapide ts-node index.ts run. tsx exécute les fichiers .ts sans tsconfig.
3

Obtenir votre clé API

Générez une clé depuis le Tableau de bord Helius.Cette clé servira de jeton d’authentification pour LaserStream.
Exigences du plan: LaserStream devnet est disponible sur tous les plans. LaserStream mainnet nécessite un plan Business ou Professional.
4

Créer un script de souscription

Créez index.ts avec ce qui suit :
5

Remplacer votre clé API et choisir votre région

Dans index.ts, mettez à jour l’objet config avec :
  1. Votre clé API réelle du Tableau de bord Helius
  2. Le endpoint LaserStream le plus proche de l’emplacement de votre serveur
Exemples de sélection de réseau et de région :
  • Pour la production (Mainnet) :
    • Europe : Utilisez fra (Francfort), ams (Amsterdam), ou lon (Londres)
    • US Est : Utilisez ewr (New York)
    • US Ouest : Utilisez slc (Salt Lake City) ou lax (Los Angeles)
    • Asie : Utilisez tyo (Tokyo) ou sgp (Singapour)
  • Pour le développement (Devnet) :
    • Utilisez https://laserstream-devnet-ewr.helius-rpc.com
6

Exécuter et voir les résultats

Chaque fois qu’une transaction sur le token confirmed implique TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA, vous verrez les données dans votre console.

Flux de travail courants

Guides étape par étape pour les flux de travail que nous voyons le plus souvent. Chaque guide utilise le SDK helius-laserstream avec reconnexion automatique et relecture historique intégrées.

Abonnements aux comptes

Surveillez les changements de solde, de données et de propriété sur des comptes spécifiques avec des filtres.

Surveillance des transactions

Diffusez des transactions impliquant des comptes cibles, filtrer par programme, vote ou statut d’échec.

Surveillance des slots et des blocs

Suivez le consensus du réseau, la production de blocs et les transitions de niveau d’engagement.

Décodage des données de transaction

Analysez les charges utiles binaires transactionUpdate en transactions Solana lisibles.

Flux des données AMM Pump

Exemple réel : surveillez les échanges AMM Pump avec des filtres sûrs pour la reconnexion.
Le client @triton-one/yellowstone-grpc fonctionne avec les mêmes endpoints si vous préférez le protocole Yellowstone brut. Consultez la référence gRPC Yellowstone pour les détails au niveau du protocole.

Demande de souscription

Dans la demande de souscription, vous devez inclure les paramètres généraux suivants :
Relecture historique : vous pouvez éventuellement inclure un champ fromSlot (un nombre u64) dans l’objet principal SubscribeRequest afin de relire les données à partir d’un slot spécifique. La relecture est actuellement limitée aux dernières ~48 heures (~691 200 slots à la vitesse actuelle du réseau). Notez que les relectures datant de plus de ~20 minutes renvoient uniquement des données finalisées.
enum
Spécifie le niveau d’engagement, qui peut être processed, confirmed ou finalized.
array
Tableau d’objets { offset: uint64, length: uint64 } qui vous permet de recevoir uniquement les tranches de données requises provenant des comptes.
boolean
Certains fournisseurs cloud, comme Cloudflare, peuvent fermer les flux inactifs après une certaine période d’inactivité. Pour éviter cela et maintenir la connexion active sans avoir à renvoyer les filtres, définissez cette valeur sur true. Le serveur répondra par un message Pong toutes les 15 secondes.
Ensuite, vous devrez spécifier les filtres pour les données auxquelles vous souhaitez vous abonner, telles que les comptes, blocs, slots, ou transactions.
Définissez des filtres pour les mises à jour de slot. La clé que vous utilisez (par exemple, mySlotLabel) est un label défini par l’utilisateur pour cette configuration de filtre spécifique, vous permettant de définir potentiellement plusieurs configurations nommées si nécessaire (bien que généralement une seule soit suffisante).
boolean
Par défaut, les slots sont envoyés pour tous les niveaux d’engagement. Ce filtre vous permet de recevoir uniquement le niveau d’engagement sélectionné.
boolean
Permet à l’abonnement de recevoir les mises à jour liées aux changements au sein d’un slot, et pas seulement au début de nouveaux slots. Cette option est utile pour obtenir des données de slot plus granulaires avec une faible latence.
Définissez des filtres pour les mises à jour de données de compte. La clé que vous utilisez (par exemple, tokenAccounts) est un label défini par l’utilisateur pour cette configuration de filtre spécifique.
array
Correspond à toute clé publique de la liste fournie.
array
La clé publique du propriétaire du compte. Correspond à toute clé publique de la liste fournie.
array
Similaire aux filtres dans getProgramAccounts. C’est un tableau de filtres datasize et/ou memcmp. Pour memcmp, le comparant se trouve sur l’un de bytes, base58, ou base64 directement sur l’objet memcmp.
enum
obsolète
Obsolète — sans effet à partir de Agave 4.2. Définir notifyOn n’a aucun effet. Le champ sera supprimé à une date ultérieure.
Si tous les champs sont vides, tous les comptes sont diffusés. Sinon :
  • Les champs fonctionnent comme un ET logique.
  • Les valeurs dans les tableaux agissent comme un OU logique (sauf dans filters, qui fonctionnent comme un ET logique).
Suivez plus de ~10,000 comptes ? Au lieu d’une liste de clés publiques explicite (32 octets par compte), utilisez un filtre de cuckoo (~3–4 octets par compte) pour vous abonner à des centaines de milliers de comptes en un seul flux. Disponible dans les SDK Rust et JavaScript.
Définissez des filtres pour les mises à jour de transactions. La clé que vous utilisez (par exemple, myTxSubscription) est un label défini par l’utilisateur pour cette configuration de filtre spécifique.
boolean
Active ou désactive la diffusion des transactions de vote.
boolean
Active ou désactive la diffusion des transactions ayant échoué.
string
Diffuse uniquement les transactions correspondant à la signature spécifiée.
array
Filtre les transactions impliquant au moins un compte de la liste fournie.
array
Exclut les transactions impliquant au moins un compte de la liste fournie (à l’inverse de accountInclude).
array
Filtre les transactions impliquant tous les comptes de la liste fournie (tous les comptes doivent être utilisés).
string
Extension tokenAccounts facultative (compte de token associé). Lorsqu’elle est définie, un portefeuille accountInclude correspond également aux transactions dans lesquelles il détient un solde de tokens SPL, par exemple les transferts de tokens entrants qui concernent le compte de tokens du portefeuille plutôt que sa clé publique. Accepte "balanceChanged" (correspondances selon la variation du solde), "all" (toute référence, volume plus élevé) ou "none" (aucune extension, valeur par défaut). Le SDK convertit la chaîne en énumération TokenAccountExpansionControlFlag au niveau du protocole (qui fait partie de yellowstone-grpc-proto 12.5.0+). Consultez Filtrage des comptes de tokens (ATA) pour comprendre son fonctionnement.
boolean
Indicateur matchMints facultatif (valeur par défaut : false). Lorsque sa valeur est true, les listes accountInclude, accountExclude et accountRequired sont également comparées aux mints figurant dans les soldes de tokens avant et après la transaction, et pas seulement aux clés de ses comptes. Ajoutez un mint à accountInclude pour recevoir toutes les transactions concernant ce token, y compris les simples transferts SPL qui ne font jamais référence au mint dans les clés de leurs comptes. Cette option est facultative et n’a aucun effet sur les filtres existants. Nécessite helius-laserstream 0.8.5+ (JS), 0.6.4+ (Rust) ou go/v0.3.0+ (Go). Consultez Filtrage par mint de token pour connaître la sémantique et voir des exemples.
Si tous les champs sont laissés vides, toutes les transactions sont diffusées. Sinon :
  • Les champs fonctionnent comme un ET logique.
  • Les valeurs dans les tableaux sont traitées comme un OU logique (sauf pour accountRequired, où tous doivent correspondre).
Définissez des filtres pour les mises à jour de bloc. La clé que vous utilisez (par exemple, myBlockLabel) est un label défini par l’utilisateur pour cette configuration de filtre spécifique.
array
Filtre les transactions et les comptes impliquant au moins un compte de la liste fournie.
boolean
Inclut toutes les transactions dans la diffusion.
boolean
Inclut toutes les mises à jour de comptes dans la diffusion.
boolean
Inclut toutes les entrées dans la diffusion.
Cela fonctionne de manière similaire aux Blocs mais exclut les transactions, les comptes et les entrées. La clé que vous utilisez (par exemple, blockmetadata) est un label défini par l’utilisateur pour cette souscription. Actuellement, aucun filtre n’est disponible pour les métadonnées de bloc — tous les messages sont diffusés par défaut.
Abonnez-vous aux entrées du registre. La clé que vous utilisez (par exemple, entrySubscribe) est un label défini par l’utilisateur pour cette souscription. Actuellement, il n’existe pas de filtres disponibles pour les entrées ; toutes les entrées sont diffusées.

Exemples de code (SDK LaserStream)

Options de SDK

Nous fournissons des SDK officiels pour plusieurs langages de programmation : Pour les autres langages ou les implémentations personnalisées, vous pouvez utiliser directement les fichiers proto Yellowstone gRPC afin de générer des clients gRPC pour le langage de votre choix.

Dépannage / FAQ

R : les problèmes de performances des connexions LaserStream sont généralement dus aux causes suivantes :
  • Lenteur du client JavaScript : le client JavaScript peut prendre du retard lorsqu’il traite trop de messages ou consomme trop de bande passante. Envisagez de filtrer plus précisément vos abonnements afin de réduire le volume de messages, de passer au SDK JavaScript LaserStream ou d’utiliser un autre langage.
  • Bande passante locale limitée : les abonnements volumineux peuvent saturer les clients dont la bande passante réseau est limitée. Surveillez votre utilisation du réseau et envisagez d’améliorer votre connexion ou de réduire la portée de l’abonnement.
  • Distance géographique : les longs trajets réseau augmentent la latence et la perte de paquets. Utilisez le point de terminaison le plus proche de votre serveur. Pour les connexions à forte latence, augmentez la taille des tampons de lecture réseau (cela peut multiplier la bande passante par 5 ou plus) :
    Pour conserver ces paramètres après les redémarrages, ajoutez-les à /etc/sysctl.conf :
    Augmentez à 64 Mo la taille des fenêtres HTTP/2 du flux et de la connexion afin d’éviter les goulots d’étranglement liés au contrôle de flux. Les deux sont nécessaires — augmenter uniquement la fenêtre du flux laisse la fenêtre au niveau de la connexion comme contrainte limitante :
  • Goulots d’étranglement du traitement côté client : assurez-vous que votre logique de traitement des messages est optimisée et qu’elle ne bloque pas le thread principal pendant de longues périodes.
Débogage des ralentissements du client : pour vous aider à déboguer votre client, nous avons créé un outil qui teste la bande passante maximale entre votre nœud et un serveur gRPC LaserStream. Pour l’utiliser, exécutez :
La sortie indique la capacité réseau maximale entre votre serveur et le serveur LaserStream. Vous avez besoin d’au moins 10MB/s pour vous abonner à toutes les données de transaction et de 80MB/s pour vous abonner à toutes les données de compte. Pour des performances optimales, nous recommandons de disposer d’au moins 2x la capacité requise.
R : vérifiez que votre clé API et votre point de terminaison sont corrects, et que votre réseau autorise les connexions gRPC sortantes vers le point de terminaison spécifié. Consultez la page d’état de Helius pour vérifier si des incidents sont en cours.
R : vérifiez à nouveau les opérateurs logiques (AND/OR) décrits dans les sections consacrées aux filtres. Assurez-vous que les clés publiques sont correctes. Vérifiez le niveau de confirmation spécifié dans votre requête.
R : oui, vous pouvez définir des configurations de filtres sous plusieurs clés (par exemple, accounts, transactions) dans le même objet SubscribeRequest.
R : nous n’implémentons pas de groupes de consommateurs. LaserStream fournit plutôt les mêmes fonctionnalités recherchées par les équipes : reprise, relecture et fiabilité multinœud, sans couche de coordination ni la latence et la surcharge qui l’accompagnent. Nous estimons que les groupes de consommateurs ne sont pas nécessaires pour la plupart des charges de travail et qu’ils ajoutent de la latence ainsi qu’une surcharge opérationnelle. Par exemple, une seule connexion gRPC LaserStream peut émettre jusqu’à 10 fois le volume combiné des données de transaction et de compte de Solana, tandis que la plupart des clients ne s’abonnent qu’à une petite partie filtrée. Dans ce cas, l’utilisation de groupes de consommateurs réduit la marge de performances et introduit un point de défaillance supplémentaire.
R : par défaut, LaserStream tronque les messages des journaux de transaction à 10 Ko afin d’améliorer la vitesse et les performances. Si vous avez besoin des journaux complets, connectez-vous à un point de terminaison dédié sans troncature — consultez Troncature des journaux pour obtenir la liste.
R : l’inclusion d’un champ ping dans votre objet SubscribeRequest initial amène LaserStream à ignorer silencieusement tous les filtres d’abonnement — seul un Pong est renvoyé, sans aucune donnée de compte, de transaction ou de slot. Pour résoudre ce problème, supprimez ping de la requête d’abonnement initiale, puis envoyez les pings séparément via le récepteur du flux une fois l’abonnement établi. Cela maintient la connexion active sans interférer avec vos filtres.