Gulf Stream de Solana : plus de mempool, plus de problèmes

Enseignements pratiques

• Le terme « Gulf Stream » peut être défini au sens large comme le processus qui se déroule entre le moment où un nœud récupère une transaction sur le réseau et celui où elle atteint le leader du slot actuel et est reçue par la Fetch Stage de la TPU (unité de traitement des transactions).
• Solana se distingue par sa conception initiale visant à fonctionner sans mempool. Contrairement aux blockchains plus traditionnelles, qui utilisent des protocoles de gossip pour propager largement les transactions sur le réseau, Solana transfère toutes les transactions à un validateur principal prédéterminé, appelé leader, pour chaque slot. Le leader change tous les 4 slots et le calendrier des leaders est connu à l’avance par tous les nœuds actifs du réseau, ce qui garantit un transfert efficace des transactions.
• Par défaut, les transactions Solana doivent inclure un blockhash récent, que les développeurs peuvent facilement demander au moyen d’un simple appel API. Un blockhash récent reste valide pendant 150 slots au maximum, soit environ 1 minute. Passé ce délai, il devient obsolète et les transactions qui y font référence sont abandonnées par le réseau. Cela empêche les transactions non traitées de persister. Les blockhashes récents contribuent aussi à la déduplication des transactions. Les développeurs disposent également de méthodes pour ajouter des nonces durables.
• Dans Gulf Stream, les transactions sont encodées et envoyées au leader via des flux QUIC. L’adoption de QUIC fin 2022 a constitué une mise à niveau majeure du réseau, remplaçant les connexions UDP utilisées auparavant. Ce changement visait principalement à améliorer la capacité du réseau à filtrer le spam. Le passage à QUIC s’est toutefois révélé quelque peu controversé, Solana ayant connu des niveaux d’activité sans précédent tout au long de 2024.
• L’introduction de la qualité de service pondérée par le stake (SWQoS) début 2024 a profondément modifié la manière dont les transactions atteignent le leader via Gulf Stream. Les leaders donnent désormais la priorité aux messages de transaction relayés par d’autres validateurs disposant de stake. Plus précisément, 80 % de la capacité d’un leader (2 000 connexions) est réservée aux pairs disposant de stake, tandis que les 20 % restants (500 connexions) sont alloués aux messages de transaction provenant de nœuds sans stake.
• Actuellement, plus de 80 % du stake sur Solana est délégué à des validateurs exécutant le client Jito-Solana plutôt que le client Agave d’origine. Jito introduit une vente aux enchères de l’espace de bloc hors protocole, ce qui complexifie davantage le parcours des transactions jusqu’au leader. Plus précisément, le relais Jito ajoute un « ralentisseur » de 200 millisecondes au flux des messages de transaction entrants, laissant aux chercheurs suffisamment de temps pour soumettre des bundles.

Introduction

Le terme « Gulf Stream » provient d’une série d’articles de blog introductifs rédigés en 2019 par l’équipe fondatrice de Solana, qui avait attribué des noms inspirés de l’aviation à de nombreux mécanismes parmi les plus innovants de Solana. Dans ces articles, Gulf Stream était défini comme le « protocole de transfert des transactions sans mempool » de Solana. Cependant, une recherche du terme « Gulf Stream » dans la base de code actuelle de Solana ne renvoie qu’une seule mention sans importance.

Dans le contexte plus large du cycle de vie des transactions Solana, « Gulf Stream » peut désigner l’ensemble du processus qui se déroule entre le moment où une transaction est récupérée par un nœud du réseau, généralement un RPC, et celui où elle atteint le leader du slot actuel, c’est-à-dire lorsqu’elle est récupérée par la « Fetch Stage » de la TPU. Gulf Stream peut également être considéré comme le pendant de Turbine, le mécanisme de propagation des blocs de Solana : Gulf Stream permet aux transactions d’atteindre le leader, tandis que Turbine permet aux transactions traitées de quitter le leader.

Commençons par définir les nœuds RPC (Remote Procedure Call) dans le contexte de Solana. Ces nœuds peuvent être considérés comme des passerelles permettant d’interagir avec le réseau et d’en lire les données. Ils servent d’intermédiaires entre les utilisateurs et les validateurs de Solana. Les RPC exécutent le même logiciel que les validateurs complets, mais avec des paramètres différents. Ils peuvent ainsi simuler avec précision les transactions et conserver une vue à jour de l’état actuel, appelé bank. Cependant, les nœuds RPC ne disposent d’aucun stake et ne participent donc pas au consensus. Sans stake, ils ne peuvent ni voter ni construire de blocs. Cette configuration diffère de celle de nombreuses autres blockchains, où les validateurs et les nœuds RPC sont généralement identiques. Dans le cadre de Gulf Stream, le rôle du RPC peut se résumer ainsi : recevoir les transactions via HTTP, les convertir en QUIC — nous y reviendrons —, rechercher l’adresse et le port du leader actuel à l’aide du calendrier des leaders, puis transférer la transaction aux leaders actuel et suivants.

Depuis le lancement du réseau, Gulf Stream a connu au moins deux mises à niveau majeures, QUIC et la qualité de service pondérée par le stake, qui seront présentées en détail plus loin dans cet article. C’est aussi probablement la partie du protocole central qui a subi le plus de pression ces dernières années en raison du volume sans précédent du trafic sur le réseau Solana. Pour donner un ordre de grandeur, lorsqu’un validateur devient leader, son trafic entrant peut augmenter brutalement et dépasser un gigaoctet par seconde, car l’ensemble du réseau dirige ses paquets vers lui. La gestion d’un tel volume de données entrantes constitue un formidable défi d’ingénierie.

Plus de mempool, plus de problèmes

La définition initiale de Gulf Stream donnée par l’équipe fondatrice insiste sur l’absence de mempool. Une mempool, littéralement un « pool de mémoire », peut être définie comme un ensemble de transactions soumises par les utilisateurs et en attente de traitement par le réseau. Ces transactions ne sont généralement ni chiffrées ni protégées pendant leur attente publique. Elles sont propagées sur l’ensemble du réseau au moyen d’un protocole de gossip. Selon le réseau, les transactions signées peuvent potentiellement rester indéfiniment dans la mempool jusqu’à ce que les conditions nécessaires à leur exécution soient réunies. C’est particulièrement vrai pour les transactions dont les frais, c’est-à-dire le prix par unité de calcul, sont nettement inférieurs à la fourchette habituelle du marché. Dans les cas extrêmes, leur exécution peut prendre des jours, voire des semaines, si les conditions du réseau ne favorisent pas leur inclusion dans un bloc.

Un tel scénario n’est pas possible sur Solana, qui non seulement ne possède aucun concept natif de mempool, mais exige aussi que tous les messages de transaction incluent un blockhash récent. Les développeurs peuvent facilement demander un blockhash récent au moyen d’un appel API JSON RPC à la méthode getLatestBlockhash. Ce blockhash est intégré au message de transaction et reste valide pendant 150 slots au maximum, soit environ 1 minute, chaque slot ayant une durée cible de 400 millisecondes. Après 150 slots, le blockhash devient obsolète et les transactions qui y font référence sont abandonnées par le réseau. Par défaut, les RPC tentent de retransmettre les transactions toutes les 2 secondes, mais dès que le blockhash récent expire, la transaction est abandonnée, ce qui garantit qu’elle ne sera jamais exécutée on-chain.

Le blockhash récent permet également de détecter et de supprimer les transactions en double. Sur d’autres réseaux, cela nécessiterait l’inclusion d’un nonce, c’est-à-dire un nombre utilisé une seule fois. Bien que les développeurs disposent de méthodes pour ajouter des nonces durables aux transactions Solana dans certains cas d’usage très spécifiques, les transactions Solana standard n’ont pas besoin d’inclure de nonce.

Le système Gulf Stream de Solana est possible parce que tous les nœuds actifs connaissent toujours le calendrier des leaders à l’avance. Les nœuds mettent à jour leur calendrier des leaders chaque fois que la hauteur de slot franchit la limite d’une époque, soit environ tous les 2 jours. Le calendrier des leaders d’une époque est calculé à partir de l’état du registre au début de l’époque précédente. Le processus algorithmique de génération de ce calendrier est le suivant :

• Utiliser périodiquement la hauteur de tick de la preuve d’historique (PoH), c’est-à-dire un compteur croissant de façon monotone, pour initialiser un algorithme pseudo-aléatoire stable.
• À cette hauteur, échantillonner dans la bank tous les comptes disposant de stake et d’une identité de leader ayant voté au cours d’un nombre de ticks configuré pour le cluster. Cet échantillon est appelé l’ensemble actif.
• Trier l’ensemble actif en fonction du poids du stake.
• Utiliser une graine aléatoire pour sélectionner les nœuds en fonction du poids de leur stake et créer un ordre pondéré par le stake.
• Cet ordre devient valide après un nombre de ticks configuré pour le cluster.

Source : documentation officielle de Solana

La pondération par le stake garantit que les nœuds de confiance disposant d’un stake plus élevé ont davantage de chances d’être choisis plus souvent comme leaders, tandis que ceux dont le stake est inférieur sont choisis moins fréquemment, voire pas du tout. 

‍L’allocation des ressources pondérée par le stake est un principe récurrent dans l’ensemble du protocole central de Solana. Elle concerne notamment les récompenses de vote, les arbres Turbine, les calendriers des leaders et le réseau de gossip*. Même Gulf Stream utilise une pondération par le stake, comme nous le verrons plus loin dans cet article.

Une remarque sur QUIC

La première mise à jour majeure de Gulf Stream a eu lieu fin 2022  avec l’adoption du protocole réseau QUIC pour transmettre les messages de transaction au leader. Cette mise à niveau répondait aux perturbations provoquées sur le réseau par les attaques DDoS et les transactions indésirables qui saturaient la blockchain lors des frappes de NFT. Après l’intégration complète de QUIC à Mainnet-Beta dans la version 1.13.4, la stabilité du réseau s’est améliorée.

Auparavant, Solana utilisait le protocole réseau UDP (User Datagram Protocol) pour envoyer les transactions des nœuds RPC au leader actuel. Bien que rapide et efficace, UDP fonctionne sans connexion et ne propose ni contrôle de flux ni accusé de réception. Il n’offre donc aucun moyen efficace de décourager ou de limiter les comportements abusifs. Afin de contrôler le trafic réseau, le protocole d’ingestion des transactions du validateur, c’est-à-dire la Fetch Stage de la TPU, a été réimplémenté avec QUIC.

Initialement développé par Google en 2012, QUIC cherche à réunir le meilleur de TCP et d’UDP. Il facilite une communication rapide et asynchrone, semblable à UDP, tout en offrant les sessions sécurisées et les stratégies avancées de contrôle de flux de TCP. Des limites peuvent ainsi être imposées aux différentes sources de trafic afin que le réseau se concentre sur le traitement des transactions légitimes. QUIC repose également sur des flux distincts : si une transaction est abandonnée, elle ne bloque pas les autres. Google a été le principal moteur de l’adoption de QUIC dans le Web2. Les connexions aux serveurs Google sont établies avec QUIC, ce qui signifie que de nombreuses applications de l’écosystème Google, comme Hangouts, Gmail et YouTube, reposent sur QUIC. À noter que QUIC n’est pas un acronyme, mais bien le nom du protocole. 

Cela dit, l’efficacité de l’implémentation de QUIC sur Solana reste sujette à débat. Lors des pics de trafic, les validateurs peuvent être submergés par les négociations de connexion QUIC. Force est de constater que QUIC n’a pas été la solution miracle que certains espéraient initialement pour résoudre les problèmes de congestion au niveau du réseau. Il convient également de noter qu’en dehors de son implémentation sur Solana, QUIC reste peu adopté dans le secteur de la blockchain. Certains membres de la communauté des validateurs Solana ont ouvertement critiqué le protocole, estimant que son adoption était une erreur.

Qualité de service pondérée par le stake (SWQoS)

Début 2024, la qualité de service pondérée par le stake (SWQoS) a été adoptée comme mécanisme de prévention du spam et de renforcement de la résistance aux attaques Sybil. Ce système permet aux leaders de donner la priorité aux messages de transaction acheminés par des validateurs disposant de stake. Les validateurs dont le stake est plus élevé bénéficient d’une capacité proportionnellement supérieure pour transmettre au leader des paquets de messages de transaction. Cela limite efficacement les attaques Sybil provenant de nœuds sans stake ou disposant d’un faible stake sur le réseau. Cette segmentation est possible parce que les adresses IP peuvent être vérifiées via QUIC, ce qui permet aux validateurs de prioriser et de limiter le trafic de connexions spécifiques. 

Avec SWQoS, les validateurs peuvent louer aux nœuds RPC leur capacité pondérée par le stake. En échange, les nœuds RPC bénéficient d’une bande passante accrue, ce qui leur permet d’obtenir un meilleur taux d’inclusion des transactions dans les blocs. Plus précisément, 80 % de la capacité d’un leader (2 000 connexions) est réservée à la qualité de service pondérée par le stake, tandis que les 20 % restants (500 connexions) sont alloués aux messages de transaction provenant d’autres nœuds. Cette stratégie d’allocation rappelle les voies prioritaires d’une autoroute, où les conducteurs paient un péage pour éviter les embouteillages.

Le stake minimal nécessaire pour être considéré comme un pair disposant de stake représente actuellement 0,04 % du stake total. Au moment de la rédaction de cet article, le stake total s’élève à 384 millions de SOL, ce qui fixe ce minimum à 15 360 SOL.‍

SWQoS a profondément transformé l’écosystème Solana en renforçant les exigences liées au transfert des transactions vers le leader et en réduisant l’efficacité des attaques par spam. Ce changement a incité les applications générant beaucoup de trafic à intégrer verticalement leurs opérations. En exploitant leurs propres nœuds validateurs, les applications peuvent s’assurer un accès privilégié au leader et ainsi améliorer leurs capacités de traitement des transactions. Chez Helius, nous sommes fiers d’exploiter l’un des principaux validateurs du réseau en matière de stake, ce qui nous permet d’obtenir un meilleur taux d’inclusion des transactions. Découvrez comment staker avec nous dans notre guide détaillé consacré au staking disponible ici.

Le ralentisseur de Jito

Cet article ne serait pas complet sans mentionner Jito, puisqu’au moment de sa rédaction, plus de 80 % du stake du réseau utilise le client de validation Jito, ce qui complexifie davantage le parcours habituel des transactions jusqu’au leader. Le client de validation Jito-Solana (Github) est un fork du client Agave (Github), anciennement le client Solana Labs. Il introduit une vente aux enchères de l’espace de bloc hors protocole et permet aux validateurs de recevoir des incitations économiques supplémentaires sous forme de pourboires.

Une analyse complète du client Jito dépassant le cadre de cet article, nous nous limiterons à étudier son impact sur le flux des transactions ordinaires via Gulf Stream. Deux itinéraires sont possibles : les transactions circulent d’un RPC vers un validateur associé, puis vers le leader actuel — l’itinéraire pondéré par le stake —, ou sont transférées directement au leader — l’itinéraire par connexion ouverte. Dans les deux cas, si le leader exécute le client Jito-Solana, ces transactions sont d’abord envoyées à Jito-Relayer (Github), un logiciel open source servant de routeur proxy pour les transactions. 

Les autres nœuds du réseau n’ont aucune connaissance de Jito-Relayer. Ils envoient simplement les transactions à l’adresse et au port que le leader a choisi de diffuser sur le réseau de gossip comme ingress_socket. Le relais retarde les transactions de 200 millisecondes avant de les transférer au leader. Ce mécanisme de « ralentisseur » réduit le débit des messages de transaction entrants et permet d’organiser efficacement des enchères en temps discret. Après 200 millisecondes, le relais libère les transactions de manière optimiste, quels que soient les résultats de l’enchère.

Jito exploitait auparavant un service canonique de mempool hors protocole, désormais abandonné. Lorsqu’un validateur Jito-Solana est leader, les chercheurs peuvent toujours soumettre des groupes de transactions exécutées de manière atomique, appelés bundles, pour d’autres types de transactions MEV qui ne dépendent pas de la mempool, comme les opérations d’arbitrage et les liquidations.

Pour en savoir plus, consultez notre article de blog Helius disponible ici, qui présente une introduction au MEV sur Solana.

Conclusion

Dans cet article, nous avons examiné différents aspects de Gulf Stream de Solana, notamment le protocole réseau QUIC, la qualité de service pondérée par le stake et la configuration des validateurs Jito. Nous avons comparé Gulf Stream à l’architecture plus traditionnelle basée sur une mempool et présenté les avantages de l’approche de Solana en matière d’efficacité accrue et de réduction de la latence. 

Gulf Stream continuera sans aucun doute d’évoluer. Le protocole Solana et son écosystème progressent rapidement, et d’importantes mises à niveau sont attendues. À titre d’exemple, Anatoly Yakovenko, cofondateur de Solana, soutient activement la mise en œuvre de plusieurs leaders simultanés. Les leaders simultanés multiples permettraient à plusieurs nœuds répartis dans le monde d’ordonner simultanément les transactions des utilisateurs, réduisant ainsi la latence et éliminant le besoin d’un aller-retour mondial complet dans le pire des cas avant l’ajout d’une transaction à la blockchain.

Solana ne restera pas immobile, et un avenir prometteur attend l’ensemble du protocole, y compris Gulf Stream. Les développeurs doivent donc s’attendre à de nombreuses autres mises à jour et optimisations.

Si vous avez lu jusqu’ici, merci ! Rejoignez notre communauté sur Discord, suivez-nous sur X ou inscrivez-vous à notre liste de diffusion ci-dessous.‍

Un grand merci à Jacob Creech et 0xIchigo pour leur relecture des versions précédentes de cet article.‍

Ressources supplémentaires

• Gulf Stream : le protocole de transfert des transactions sans mempool de Solana
• QUIC, un transport multiplexé sur UDP
• Guide complet de HTTP/3 et QUIC
• Compilation de liens sur SWQoS
• Guide de la qualité de service pondérée par le stake sur Solana
• Formation sur les validateurs Solana : QoS pondérée par le stake
• Documentation de Jito Relayer
• Exécution asynchrone, architecture finale

‍