Skip to main content

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 inclure facultativement un champ fromSlot (un nombre u64) dans l’objet principal SubscribeRequest pour relire les données à partir d’un slot spécifique. La relecture est actuellement limitée aux 216,000 derniers slots (≈24 heures) ; notez que les relectures plus anciennes que ~20 minutes retournent uniquement des données finalisées.
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).
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.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.
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 d’autres langages ou implémentations personnalisées, vous pouvez utiliser directement les fichiers proto gRPC Yellowstone pour générer des clients gRPC pour votre langage préféré.

Dépannage / FAQ

A: Les problèmes de performance avec les connexions LaserStream sont généralement causés par :
  • Lenteur du client JavaScript: Le client JavaScript peut prendre du retard lors du traitement de trop nombreux messages ou de la consommation d’une bande passante excessive. Envisagez de filtrer vos souscriptions plus étroitement pour réduire le volume de messages, passez au SDK JavaScript LaserStream, ou essayez d’utiliser un autre langage.
  • Bande passante locale limitée: Les souscriptions lourdes peuvent submerger les clients avec une bande passante réseau limitée. Surveillez votre utilisation du réseau et envisagez de mettre à niveau votre connexion ou de réduire la portée de la souscription.
  • Distance géographique: Les longs trajets réseau augmentent la latence et la perte de paquets. Utilisez le endpoint le plus proche de votre serveur. Pour les connexions à haute latence, augmentez vos tailles de tampon de lecture réseau (peut améliorer la bande passante de 5x+) :
    Pour persister après les redémarrages, ajoutez à /etc/sysctl.conf :
    Augmentez les tailles de fenêtre de flux et de connexion HTTP/2 à 64 Mo pour éviter les goulots d’étranglement du contrôle de flux. Les deux sont nécessaires — élever seulement la fenêtre de flux laisse la fenêtre de niveau de connexion comme contrainte de liaison :
  • Goulots d’étranglement côté client: Assurez-vous que votre logique de traitement des messages est optimisée et ne bloque pas le thread principal pendant de longues périodes.
Débogage du décalage client: Pour vous aider à déboguer le client, nous avons construit un outil pour tester la bande passante maximale de votre nœud à un serveur gRPC Laserstream. Pour l’utiliser, exécutez :
La sortie retourne la capacité réseau maximale entre votre serveur et le serveur Laserstream. Au minimum, vous avez besoin de 10 Mo/s pour vous abonner à toutes les données de transaction et de 80 Mo/s pour vous abonner à toutes les données de compte. Nous recommandons d’avoir au moins 2x la capacité requise pour des performances optimales.
A: Vérifiez que votre clé API et votre endpoint sont corrects et que votre réseau permet les connexions gRPC sortantes vers le endpoint spécifié. Vérifiez la page de statut Helius pour tout incident en cours.
A: Revérifiez les opérateurs logiques (ET/OU) décrits dans les sections de filtres. Assurez-vous que les clés publiques sont correctes. Vérifiez le niveau d’engagement spécifié dans votre demande.
A: Oui, vous pouvez définir des configurations de filtre sous plusieurs clés (par exemple, accounts, transactions) dans le même objet SubscribeRequest.
A: Nous n’implémentons pas de groupes de consommateurs. Au lieu de cela, LaserStream offre les résultats mêmes que souhaitent les équipes : reprise, relecture, et fiabilité multi-nœuds sans couche de coordination (et la latence/surcharge qui l’accompagnent). Nous croyons que les groupes de consommateurs ne sont pas nécessaires pour la plupart des charges de travail et qu’ils ajoutent de la latence et une surcharge opérationnelle. Par exemple, une seule connexion gRPC LaserStream peut émettre jusqu’à 10× les données de transaction + compte de Solana, et la plupart des clients s’abonnent à une petite tranche filtrée. Utiliser des groupes de consommateurs dans ce cas consomme des ressources de performance et introduit un autre point de défaillance.
A: LaserStream tronque les messages de journal de transaction à 10 KB par défaut pour une meilleure vitesse et performance. Si vous avez besoin de journaux complets, connectez-vous à un endpoint dédié sans troncature — voir Troncature des journaux pour la liste.
A: Inclure un champ ping dans votre initiale SubscribeRequest amène LaserStream à ignorer silencieusement tous les filtres d’abonnement — seul un Pong est retourné sans données de compte, de transaction, ou de slot. Pour corriger cela, retirez ping de la demande de souscription initiale et envoyez plutôt des pings séparément via le récepteur du flux après l’établissement de la souscription. Cela maintient la connexion active sans interférer avec vos filtres.