Gagner la course à la milliseconde : shreds, LaserStream et l’avantage sur Solana

Que sont les shreds ?

Les shreds sont l’unité fondamentale qui permet à Solana de propager les données à hautes performances et offrent un accès anticipé aux changements d’état on-chain.

Solana est conçue pour maximiser la vitesse et le débit. Pour y parvenir, elle ne peut pas transmettre les blocs sur le réseau sous la forme d’une seule unité volumineuse. Les blocs sont donc divisés en paquets plus petits appelés shreds, les unités atomiques de propagation des données dans Solana. 

Ces shreds représentent des portions de données de transaction avant leur assemblage en bloc. Chaque shred mesure environ 1,2 Ko et est optimisé pour tenir dans l’unité de transmission maximale (MTU) des paquets réseau standard, afin d’assurer une livraison ultrarapide sans fragmentation. 

Il existe deux types de shreds :

Shreds de données

Les shreds de données encapsulent les données de transaction essentielles d’un bloc, divisées en segments de taille fixe. Ils comprennent des lots d’entrées sérialisées, c’est-à-dire des groupes de transactions précédés d’un compteur pour permettre un traitement efficace.

Shreds de codage

Les shreds de codage assurent la redondance grâce au code d’effacement Reed-Solomon, une technique de correction anticipée des erreurs qui génère des données de parité. Elle permet de reconstruire les shreds manquants ou corrompus. Les shreds de codage sont organisés avec les shreds de données en ensembles de correction anticipée des erreurs (FEC), généralement selon des proportions équilibrées (par exemple, 32 shreds de données pour 32 shreds de codage), afin de tolérer jusqu’à 50 % de perte de paquets. Les leaders peuvent ajuster cette proportion selon les conditions du réseau afin de maintenir une fiabilité élevée.

Comment les shreds sont-ils propagés sur Solana ?

Le processus commence lorsque le leader (c’est-à-dire le validateur actuellement chargé de produire les blocs) regroupe et sérialise les transactions en entrées. Ces entrées sont ensuite divisées, ou découpées, en segments plus petits appelés shreds. Tous les shreds sont signés par le leader à l’aide soit d’un système historique (c’est-à-dire la signature individuelle de chaque shred), soit d’un mécanisme basé sur Merkle (c’est-à-dire la signature de la racine de Merkle de l’ensemble FEC), conformément à la spécification des shreds de Solana. Cela garantit l’authenticité et l’intégrité des données. 

Les shreds sont envoyés aux autres validateurs à l’aide de Turbine, le système de propagation multicouche en éventail de Solana. Avec Turbine, le leader transmet les shreds à un nœud racine, qui les distribue aux couches successives de validateurs selon une structure arborescente. Chaque couche les transmet à la suivante, avec un éventail de 200 nœuds par couche. Selon le nombre de validateurs actifs, le parcours comprend généralement 2 à 3 sauts. Cette structure arborescente minimise la bande passante tout en distribuant les transactions à l’échelle du réseau en quelques millisecondes.

Le brassage pondéré par le stake donne la priorité aux validateurs disposant du stake le plus élevé. Turbine trie d’abord les validateurs selon le montant de stake qu’ils détiennent (c’est-à-dire leur poids de stake). Les validateurs au stake le plus élevé sont placés plus tôt dans cette liste et, après un brassage déterministe, ils ont tendance à se retrouver dans les premières couches de l’arbre, plus près du leader. Moins de sauts signifie donc une latence plus faible. Ainsi, les validateurs disposant de plus de stake reçoivent les shreds plus tôt.   

Remarque : Turbine sera remplacé à l’avenir par Rotor une fois Alpenglow implémenté. Même après ces changements, le stake d’un validateur continuera d’influencer les pairs auxquels il diffusera les données.

Comment les shreds sont-ils réassemblés en blocs ?

Une fois reçus par un validateur, les shreds sont réassemblés. Leurs signatures sont d’abord vérifiées pour garantir leur authenticité, puis le code d’effacement Reed-Solomon permet de reconstruire les shreds de données manquants ou corrompus à partir des shreds de codage disponibles dans l’ensemble FEC. 

Les shreds de données reconstruits sont ensuite désassemblés. Autrement dit, leurs charges utiles sont concaténées dans l’ordre à l’aide des indices des shreds afin de reformer les lots d’entrées sérialisées. 

Ces lots sont ensuite désérialisés en transactions et entrées individuelles, qui peuvent être assemblées en un bloc complet.

Pourquoi les shreds sont-ils importants ? 

Les shreds sont importants parce qu’ils réduisent la fenêtre de réaction sur un réseau où chaque instant compte. 

Les shreds sont essentiels pour exploiter les avantages de Solana en matière de performances, notamment dans les applications sensibles à la latence comme le trading haute fréquence, les desks de demande de cotation (RFQ), les moteurs de liquidation et les mises à jour d’oracles. 

Les shreds offrent la visibilité la plus précoce sur les événements on-chain en cours d’apparition, contrairement à la plupart des autres blockchains, où les applications doivent attendre la production et la confirmation complètes du bloc, ce qui peut ajouter un délai de plusieurs centaines de millisecondes à plusieurs secondes. 

Les shreds bruts peuvent être difficiles à exploiter, car le destinataire doit vérifier leur authenticité, reconstruire les shreds de données manquants, les désassembler et les désérialiser en transactions et en entrées, puis enfin les analyser pour identifier les événements exploitables, comme les swaps ou les changements de compte.

Si vous voulez bénéficier de l’avantage de latence des shreds sans créer ce pipeline, Preprocessed Transactions les désassemble pour vous et diffuse les transactions signées via WebSocket jusqu’à 8 ms avant le niveau d’engagement processed.

Cependant, cet « aperçu anticipé » des transactions et des mises à jour de comptes en attente offre un avantage inégalé, qui se traduit directement par des taux de réussite plus élevés dans les scénarios concurrentiels.

Par exemple, un bot de liquidation surveillant les ratios de garantie pourrait détecter une position vulnérable et intervenir à l’aide des shreds bien avant ses concurrents utilisant des méthodes plus lentes comme les WebSockets, et ainsi remporter la liquidation. 

De même, les traders d’arbitrage qui détectent les inefficacités du marché et les agrégateurs DEX à faible latence qui fournissent des cotations peuvent bénéficier de cet avantage, puisque quelques millisecondes déterminent la rentabilité.

La hiérarchie de latence des shreds

Il est important de noter que la latence des shreds n’est pas uniforme entre toutes les sources.

Validateurs à stake élevé

Les validateurs disposant d’un stake important bénéficient de la priorité la plus élevée dans l’arbre de propagation de Turbine. Ils reçoivent souvent les shreds directement du leader ou dans les premières couches de diffusion, et bénéficient de la qualité de service pondérée par le stake (SWQoS).

Validateurs avec stake

Les validateurs disposant d’un stake modeste subissent des délais modérés en raison de leur priorité plus faible dans la file de propagation, car les shreds doivent effectuer des sauts supplémentaires. Leur participation au consensus garantit un accès fiable, mais la latence peut varier légèrement selon leur position sur le réseau et la distribution actuelle du stake. Par rapport aux validateurs à stake élevé, ceux dont le stake est faible conviennent moins aux opérations ultra-concurrentielles et sensibles au temps.

Validateurs sans stake

Les validateurs sans stake ne bénéficient pas des avantages de qualité de service des nœuds avec stake et ne conviennent pas au streaming de données Solana en temps réel pour les opérations où la latence est critique. Ils reçoivent les shreds en dernier dans la diffusion en éventail de Turbine.

Plus vous êtes placé tôt dans l’arbre, plus vous disposez de temps pour réagir avant que le reste du réseau ne vous rattrape. 

Variabilité mondiale 

Point important, Turbine ne tient pas compte de la localisation. La propagation mondiale peut amplifier la variabilité de la latence, car la distance physique et les conditions du réseau ajoutent des délais au-delà des sauts de Turbine. 

Par exemple, les shreds qui circulent entre différentes régions (d’un leader basé aux États-Unis vers des validateurs d’Asie-Pacifique, par exemple) peuvent subir des délais dus au routage intercontinental, aux retransmissions de paquets ou même à des problèmes de peering, y compris pour les validateurs à stake élevé situés dans les premières couches de Turbine.

Cette répartition géographique crée des possibilités d’optimisation. Si un validateur unique à stake élevé peut exceller localement, il peut prendre du retard à l’échelle mondiale s’il n’est pas positionné de manière optimale. Un réseau distribué de shreds pourrait limiter ce problème en agrégeant les shreds les plus rapides provenant de diverses sources, réduisant ainsi la variance et assurant des vitesses d’ingestion constantes. Dans les scénarios mondiaux, un tel système pourrait systématiquement surpasser un validateur au stake maximal.

Pour que les développeurs de systèmes où la latence est critique conservent un avantage concurrentiel, ils doivent accéder de manière fiable à des shreds issus de sources optimisées. Cela exige toutefois une infrastructure robuste capable de gérer efficacement la récupération, la vérification et la distribution mondiale. De plus, la plupart des outils populaires de streaming de données Solana en temps réel n’exploitent actuellement pas les shreds.

Streaming de données sur Solana

Sur Solana, les développeurs qui souhaitent streamer des données en temps réel disposent de plusieurs options, chacune avec ses propres compromis en matière de latence, de fiabilité et de complexité :

Webhooks

Les webhooks permettent d’obtenir des mises à jour déclenchées par des événements en transmettant des données à votre application lorsqu’un compte ou un programme spécifique est modifié. Leur intégration par programmation est simple, et vous pouvez même les configurer sans écrire de code directement dans le tableau de bord Helius. Les développeurs peuvent streamer des données analysées et lisibles pour certains types de transactions, des charges utiles de transactions brutes, et même transmettre directement ces mises à jour dans un canal Discord donné sous la forme d’un message formaté.

Bien que les webhooks soient très fiables et utilisés par de nombreuses entreprises de premier plan sur Solana, ils envoient les notifications après la confirmation d’une transaction. Ils peuvent donc accuser plusieurs centaines de millisecondes de retard sur les données au niveau des shreds, ce qui les rend trop lents pour les opérations où la latence est critique, comme le trading haute fréquence ou les liquidations.

WebSockets standard

L’API JSON RPC de Solana prend en charge les abonnements WebSocket, comme accountSubscribe pour les changements de compte, logSubscribe pour les journaux de transactions et programSubscribe pour les événements de programme. Les WebSockets maintiennent une connexion persistante entre un client et un fournisseur RPC, et transmettent les mises à jour dès que les transactions et les changements de comptes sont traités. Les WebSockets sont bidirectionnels et adaptés à la surveillance en temps réel de comptes ou d’événements spécifiques, tout en réduisant la surcharge liée aux interrogations répétées.

Cependant, comme les webhooks, les WebSockets transmettent les données après le réassemblage des shreds (c’est-à-dire aux niveaux d’engagement processed, confirmed ou finalized), ce qui ajoute entre 400 ms et 30 s de latence selon le niveau d’engagement. 

Les WebSockets sont également considérés comme un type de connexion fragile : les connexions peuvent être interrompues pour de nombreuses raisons et nécessiter une logique de nouvelle tentative personnalisée. Les déconnexions peuvent entraîner une perte permanente de données si elles ne sont pas compensées par des interrogations répétées, ce qui compromet la fiabilité en temps réel. 

Enhanced WebSockets

Les Enhanced WebSockets représentent une amélioration significative par rapport aux WebSockets standard, avec plusieurs optimisations des performances et des capacités de filtrage avancées. Une meilleure analyse des événements et une réduction du bruit les rendent notamment plus adaptés aux développeurs pour une utilisation en production.

Les Enhanced WebSockets peuvent réduire la latence par rapport aux WebSockets standard et conviennent parfaitement aux applications générales de streaming. Par exemple, la différence de performances est notable lorsque vous streamez les données de Pump AMM avec les Enhanced WebSockets, comparativement aux WebSockets standard et aux webhooks. 

Cependant, les Enhanced WebSockets transmettent toujours fondamentalement les données après le réassemblage des shreds. Là encore, cela limite leur utilité pour les applications où chaque milliseconde compte. De plus, malgré leurs améliorations, ils ne proposent ni relecture ni basculement automatiques, ce qui impose une gestion manuelle des données manquantes. 

Yellowstone gRPC

Yellowstone gRPC est un protocole de streaming à faible latence entre validateur et client qui peut donner accès aux données au niveau des shreds. Il est donc nettement plus rapide que les WebSockets et les webhooks, car il peut transmettre plus rapidement les mises à jour pour le niveau d’engagement concerné. 

Yellowstone offre un streaming bidirectionnel avec création et annulation immédiates des abonnements, ainsi que des capacités de filtrage avancées pour contrôler précisément les données reçues en réponse à des mises à jour spécifiques de transactions, de comptes ou de programmes.

Yellowstone est idéal pour les utilisateurs qui ne veulent ni limites de débit ni crédits, et souhaitent disposer d’un matériel isolé garanti pour des configurations de nœuds personnalisées. Il présente toutefois plusieurs compromis majeurs :

1. Charge d’infrastructure

Vous devez disposer de votre propre nœud dédié pour exploiter pleinement Yellowstone gRPC. Cela nécessite un accès au matériel, une configuration appropriée, une gestion continue de ce matériel et une expertise spécialisée pour diagnostiquer tout problème matériel.

2. Variabilité de la latence

Le fait que Yellowstone gRPC puisse transmettre des données au niveau des shreds ne signifie pas qu’il le fera de manière optimale. La latence peut varier selon votre fournisseur et selon que votre nœud dédié est associé ou non à des sources optimisées pour les shreds (c’est-à-dire des validateurs à stake élevé). Avec des validateurs au stake moyen ou faible, ceux-ci ne se trouveront pas systématiquement dans la première couche de Turbine. Vous resterez donc en aval pour de nombreux shreds.

3. Risques de panne

Dépendre d’un seul nœud dédié crée un point de défaillance unique, un problème aggravé par l’absence de capacités de relecture natives dans Yellowstone gRPC.

4. Besoins en ressources

Surcharger un nœud dédié avec des appels RPC intensifs tout en streamant des données via Yellowstone peut dégrader les performances. 

Pendant longtemps, et pour de nombreuses équipes, Yellowstone gRPC a été le service de streaming de référence pour les données Solana en temps réel. Il est rapide et adapté aux utilisateurs avancés, mais il reste difficile à exploiter pour assurer une couverture mondiale cohérente à faible latence sans disposer d’un parc de nœuds dédiés répartis dans le monde entier.

LaserStream

LaserStream associe la vitesse d’ingestion au niveau des shreds à la fiabilité et à la portée d’un service distribué mondialement, sans le coût ni les contraintes opérationnelles liés à l’exécution de plusieurs nœuds dédiés. 

LaserStream y parvient grâce aux éléments suivants :

• Ingestion multisource : LaserStream ingère les shreds à la latence la plus faible et surpasse systématiquement ses concurrents partout dans le monde.
• Couverture mondiale : LaserStream est disponible dans plusieurs régions du monde, ce qui permet aux développeurs d’utiliser l’endpoint le plus proche de leur infrastructure. Chaque région exécute plusieurs serveurs pour assurer la redondance, avec un basculement automatique.
• Aucune interruption : la relecture historique de LaserStream permet aux développeurs de relire des données blockchain récentes remontant jusqu’à 48 heures. Elle permet de gérer les déconnexions et d’assurer la continuité des données. 
• Une expérience adaptée aux développeurs : LaserStream remplace directement Yellowstone gRPC, sans migration, nouvelle syntaxe ni difficultés.

En bref, LaserStream constitue une amélioration évolutive, à faible latence et tolérante aux pannes par rapport à Yellowstone gRPC et aux WebSockets. Il fournit systématiquement les événements on-chain dès qu’ils se produisent sur le réseau, sans vous imposer des millions en stake ni l’exploitation de votre propre infrastructure haute performance. 

LaserStream est le moyen le plus simple d’exploiter la puissance des shreds pour streamer des données Solana avec une latence ultrafaible.

Clients et performances

LaserStream propose des clients en Go, Rust et JavaScript/TypeScript. Ces clients gèrent la relecture automatique après une déconnexion en suivant continuellement le slot qui a été streamé. Si une déconnexion se produit, quelle qu’en soit la raison, le client se reconnecte automatiquement et reprend le streaming au dernier slot traité.

Le client JavaScript de LaserStream est particulièrement intéressant, car il utilise des bindings Rust natifs. Il atteint ainsi un débit de 1,3 Go/s. Cela représente une amélioration de 40 fois par rapport au client JavaScript Yellowstone gRPC actuel, dont le débit maximal est de 30 Mo/s. 

À mesure que Solana poursuit son développement, le client JavaScript Yellowstone gRPC aura du mal à suivre. La marge de performance du client JavaScript de LaserStream garantit que votre application pourra évoluer en toute sécurité avec le réseau lorsque la demande augmentera. 

Des résultats concrets

DFlow, un agrégateur DEX à faible latence, a récemment intégré LaserStream pour alimenter son moteur de prix. Cette décision reposait sur la possibilité d’évoluer à l’échelle mondiale sans avoir à se soucier des nœuds dédiés, tout en préservant les ressources d’ingénierie pour se concentrer sur le routage et le code métier. 

Depuis cette intégration, DFlow aurait économisé plus de huit heures de travail d’ingénierie récurrent, maintenu une disponibilité de 100 % avec un streaming de données ininterrompu et accéléré ses cotations grâce à des confirmations de transactions plus rapides. 

Un streaming plus rapide, dès aujourd’hui.

Les millisecondes ne sont pas qu’une question de latence : elles représentent des opportunités. Avec LaserStream, vous ne vous contentez pas de suivre le réseau. Vous gardez une longueur d’avance. 

Vous voulez des données en moins d’une seconde pour le trading, les liquidations ou les oracles ? Utilisez LaserStream et accédez aux données Solana les plus rapides disponibles. 

Si vous êtes un utilisateur avancé et que la livraison de shreds bruts vous intéresse, vous pouvez également nous contacter en remplissant le formulaire suivant.

Ressources complémentaires

• LaserStream
• Module Shred d’Agave
• Spécification des shreds de Solana