Turbine : propagation des blocs sur Solana

Quel est le sujet de cet article ?

La disponibilité des données est cruciale pour les blockchains. Elle garantit que toutes les informations nécessaires sont facilement accessibles aux nœuds à des fins de validation, ce qui préserve l’intégrité et la sécurité du réseau. Toutefois, garantir la disponibilité des données tout en maintenant un haut niveau de performance représente un défi majeur, en particulier à mesure que les réseaux évoluent.

Solana a relevé ce défi grâce à une architecture unique qui permet la création et la propagation continues des blocs. Cela repose sur plusieurs innovations clés, telles que la sélection du leader, Gulf Stream (qui élimine la nécessité d’un mempool) et Turbine (le mécanisme de propagation des blocs).

Le fonctionnement continu de Solana nécessite un système efficace afin que tous les validateurs reçoivent rapidement l’état le plus récent. Une approche simpliste consisterait à faire transmettre tous les blocs directement par le leader à chacun des autres validateurs. Cependant, compte tenu du débit élevé de Solana, cette méthode augmenterait considérablement les besoins en bande passante et autres ressources, tout en compromettant la décentralisation.

La bande passante est une ressource limitée, et Turbine est la solution ingénieuse de Solana pour optimiser la propagation des informations depuis le leader d’un bloc donné vers le reste du réseau. Turbine a été spécifiquement conçu pour réduire la charge des flux sortants (l’envoi de données) du leader vers le réseau.

Dans cet article, nous examinerons le fonctionnement de Turbine ainsi que son rôle central dans le processus global d’inclusion des transactions de Solana. Nous comparerons également Turbine à d’autres solutions de disponibilité des données et aborderons les pistes de recherche encore ouvertes dans ce domaine.

Qu’est-ce que Turbine ?

Turbine est un mécanisme multicouche de propagation des blocs utilisé par un cluster Solana pour diffuser les entrées du registre à tous les nœuds. Les principes fondamentaux de Turbine occupent les chercheurs depuis de nombreuses années, comme en témoignent cet article publié en 2004 et des travaux plus récents.

Contrairement aux blockchains traditionnelles, où un bloc est envoyé à tous les nœuds de manière séquentielle ou par inondation, Turbine adopte une approche plus structurée afin de minimiser la surcharge de communication et de réduire la charge imposée à chaque nœud. Globalement, Turbine divise un bloc en éléments plus petits et les diffuse au sein d’une hiérarchie de nœuds. Ainsi, un nœud donné n’a pas besoin d’être en contact avec tous les autres et ne doit communiquer qu’avec quelques nœuds sélectionnés. Cela devient de plus en plus important à mesure que le réseau grandit, car les méthodes de propagation traditionnelles deviendraient intenables en raison du volume considérable de communications nécessaires. Turbine garantit donc une diffusion rapide et efficace des données sur Solana. La vitesse de propagation et de vérification des blocs est essentielle au maintien du débit élevé et de la sécurité du réseau Solana.

Turbine répond également au problème de la disponibilité des données en garantissant que tous les nœuds puissent accéder efficacement aux données requises pour valider les transactions. Et ce, sans nécessiter une quantité démesurée de bande passante, un goulot d’étranglement fréquent sur d’autres réseaux blockchain.

En réduisant les goulots d’étranglement liés à la bande passante et en assurant une propagation rapide des blocs, Turbine contribue largement à la capacité de Solana à gérer d’importants volumes de transactions tout en conservant une structure réseau légère et efficace. Ce protocole innovant est l’une des pierres angulaires qui permettent à Solana de tenir sa promesse d’un réseau rapide, sécurisé et évolutif.

Examinons maintenant plus en détail les mécanismes de Turbine et la manière dont il propage les blocs sur le réseau Solana.

Comment Turbine propage-t-il les blocs ?

Avant qu’un bloc ne soit propagé (c’est-à-dire transmis aux autres validateurs du réseau), le leader le construit et l’ordonne à partir du flux de transactions entrantes. Une fois construit, le bloc est prêt à être envoyé au reste du réseau via Turbine. Ce processus est appelé propagation des blocs. Des messages de vote sont ensuite échangés entre les validateurs. Ils sont encapsulés dans les données du bloc afin d’atteindre le statut d’engagement « confirmed » ou « finalized ». Un bloc confirmé est un bloc ayant reçu une majorité qualifiée des votes du registre, tandis qu’un bloc finalisé est un bloc confirmé sur lequel au moins 31 blocs confirmés ont été construits. La différence entre les statuts d’engagement est expliquée plus en détail ici. Cette partie du consensus sera étudiée dans un prochain article.

Bien que les leaders construisent et proposent des blocs entiers, les données proprement dites sont envoyées sous forme de shreds (blocs partiels) aux autres validateurs du réseau. Les shreds sont les unités atomiques échangées entre les validateurs.

Globalement, Turbine envoie les shreds à un ensemble prédéterminé de validateurs, qui les transmettent ensuite à un nouvel ensemble de validateurs. Le schéma suivant présente le processus continu de propagation des shreds :

Dans cet exemple, le Validateur 1 est le leader désigné du slot. Pendant son slot (les validateurs sont désignés comme leaders pendant 4 slots consécutifs), le Validateur 1 construit et propose un bloc. Il commence par diviser ce bloc en sous-blocs appelés shreds, au moyen d’un processus nommé shredding. Le shredding divise les données du bloc en shreds de données de la taille d’une unité de transmission maximale (MTU), c’est-à-dire la quantité maximale de données pouvant être envoyée d’un nœud au suivant sans être fragmentée en unités plus petites. Il génère également les shreds de récupération correspondants au moyen du code d’effacement Reed-Solomon. Ce mécanisme facilite la récupération des données et garantit leur intégrité pendant la transmission, ce qui est essentiel au maintien de la sécurité et de la fiabilité du réseau.

Ce processus de shredding et de propagation garantit une distribution rapide et efficace des données de bloc sur Solana, tout en préservant le débit élevé et la sécurité du réseau.

Code d’effacement

Avant d’être propagés dans l’arbre Turbine, les shreds sont d’abord encodés au moyen du code d’effacement Reed-Solomon, un mécanisme polynomial de détection et de correction des erreurs. Le code d’effacement sert de méthode de protection des données afin que les données d’origine puissent être récupérées même si certaines parties sont perdues ou corrompues pendant la transmission. Le code d’effacement Reed-Solomon est un type spécifique d’algorithme de correction d’erreurs sans voie de retour (FEC).

Turbine reposant fondamentalement sur une série de retransmissions de paquets par les validateurs en aval, ceux-ci peuvent être malveillants (nœuds byzantins adverses) et choisir de rediffuser des données incorrectes, ou recevoir des données incomplètes en raison de la perte de paquets réseau. Du fait de la structure arborescente de retransmission de Turbine, toute perte de paquets à l’échelle du réseau s’accumule et la probabilité qu’un paquet n’atteigne pas sa destination augmente à chaque saut.

Globalement, si le leader transmet 33 % des paquets du bloc sous forme de codes d’effacement, le réseau peut perdre n’importe quels 33 % des paquets sans perdre le bloc. Les leaders peuvent ajuster dynamiquement ce nombre, appelé taux FEC, en fonction de l’état du réseau et en tenant compte de variables telles que les pertes de paquets récemment observées à l’échelle du réseau et la profondeur de l’arbre.

Pour simplifier, examinons un groupe de shreds avec un taux FEC de 4:4.

Les shreds de données sont des blocs partiels issus du bloc d’origine construit par le leader, tandis que les shreds de récupération sont les blocs encodés avec le code d’effacement générés par Reed-Solomon.

Sur Solana, les blocs utilisent généralement un taux FEC de 32:32 (32 paquets sur 64 peuvent être perdus sans nécessiter de retransmission). Comme l’indique la documentation Solana, cela repose sur les hypothèses réseau prudentes suivantes :

• Taux de perte de paquets de 15 %
• 50 000 TPS générant 6 400 shreds par seconde

Un taux FEC de 32:32 produit un taux de réussite des blocs de ~99 %. De plus, les leaders peuvent augmenter le taux FEC s’ils souhaitent accroître la probabilité de réussite d’un bloc.

Turbine utilise actuellement UDP pour la propagation des blocs, ce qui offre des avantages considérables en matière de latence. Selon un opérateur de validateur, la transmission de 6 Mo de données, plus les données du code d’effacement, de us-east-1 à eu-north-1 prend 100 ms avec UDP, contre 900 ms avec TCP.

Arbre Turbine

Un arbre Turbine est une topologie réseau structurée utilisée par Solana pour faciliter la propagation efficace des shreds (données de bloc encodées) entre les validateurs. Une fois correctement encodés dans leurs groupes respectifs, les shreds sont prêts à être diffusés dans l’arbre Turbine afin d’informer les autres validateurs du réseau de l’état le plus récent.

Chaque groupe de shreds est envoyé dans un paquet réseau à un nœud racine spécial, qui détermine les validateurs appartenant à la première couche, à un saut de distance. Les étapes suivantes sont alors exécutées :

1. Création de la liste : Le nœud racine regroupe tous les validateurs actifs dans une liste, qui est ensuite triée selon la quantité mise en staking par chaque validateur sur le réseau. Les validateurs dont le poids de staking est le plus élevé reçoivent les shreds en priorité, ce qui leur permet de répondre plus rapidement avec leurs propres messages de vote pour le consensus.
2. Mélange de la liste : Cette liste est ensuite mélangée de manière déterministe. Cela crée un « arbre Turbine » généré à partir de l’ensemble des nœuds validateurs pour chaque shred, en utilisant une graine dérivée de l’identifiant du leader du slot, du slot, de l’index du shred et du type de shred. Un nouvel arbre est généré lors de l’exécution pour chaque groupe de shreds afin d’atténuer les risques de sécurité potentiels associés à une structure arborescente statique.
3. Formation des couches : Les nœuds sont ensuite répartis en couches, en partant du haut de la liste. Cette répartition repose sur la valeur DATA_PLANE_FANOUT, qui détermine la largeur et la profondeur de l’arbre Turbine. Cette valeur influence la vitesse à laquelle les shreds peuvent être propagés sur le réseau. La valeur actuelle de DATA_PLANE_FANOUT est de 200, de sorte que la plupart des validateurs ne sont distants que de 2 à 3 sauts (leader -> racine -> L1 -> L2).

L’arbre Turbine étant connu de tous, chaque validateur sait exactement où il doit relayer un shred donné. Il comporte généralement 2 ou 3 sauts, selon le nombre de validateurs actifs, compte tenu de la valeur DATA_PLANE_FANOUT actuelle de 200.

De plus, les nœuds peuvent se rabattre sur le gossip et la réparation s’ils ne reçoivent pas suffisamment de shreds ou si le taux de perte dépasse le taux FEC. Dans l’implémentation actuelle, un nœud qui ne dispose pas d’assez de shreds pour reconstruire le bloc envoie au leader une demande de retransmission. Avec Turbine déterministe, tout nœud ayant reçu le bloc complet peut envoyer les shreds de réparation nécessaires au nœud demandeur, ce qui achemine les données plus loin vers les zones de l’arbre qui les réclament.

Comparaison de la propagation des blocs entre Solana et Ethereum

La propagation des blocs sur Solana diffère de celle d’Ethereum. Voici quelques différences générales :

• Les besoins idéaux de Solana en bande passante (>1 Gbit/s) sont nettement supérieurs à ceux d’Ethereum (geth recommande >25 Mbit/s). Cette exigence supérieure s’explique par la taille plus importante des blocs et par les temps de bloc plus courts de Solana. La conception de Solana permet d’exploiter efficacement toute la bande passante pour accélérer la transmission des données et ainsi réduire la latence. Même si la bande passante peut atteindre ponctuellement 1 Gbit/s, elle ne reste pas constamment à ce niveau. L’architecture de Solana permet spécifiquement ces pics de demande en bande passante.
• Solana utilise Turbine pour propager les données de bloc, tandis qu’Ethereum emploie un protocole gossip standard. Sur Ethereum, la propagation des données de bloc s’effectue simplement : chaque nœud communique avec tous les autres nœuds complets du réseau. Lorsqu’un nouveau bloc est créé, les clients le vérifient en l’envoyant à leurs pairs et en approuvant les transactions qu’il contient. Ce mécanisme convient à Ethereum en raison de blocs plus petits et de temps de bloc plus longs que sur Solana. Pour les données des rollups L2 d’Ethereum, à l’exclusion des validiums, la propagation suit également le protocole gossip, les données de bloc étant stockées dans le champ « calldata » des blocs L1 d’Ethereum.
• Ethereum utilise TCP, via le protocole DevP2P, pour la propagation des blocs, tandis que Solana utilise UDP (avec un certain soutien de la communauté en faveur d’une transition vers QUIC). Plusieurs compromis entre UDP et QUIC doivent être pris en compte :
• Le caractère unidirectionnel d’UDP réduit la latence par rapport à QUIC, qui nécessite des flux QUIC. Des discussions sont en cours concernant l’implémentation de flux unidirectionnels dans QUIC.
• Les partisans de QUIC affirment que, même s’il est possible de créer un contrôle de flux personnalisé sur UDP, cela exige un travail d’ingénierie considérable que QUIC réduit grâce à sa prise en charge native de ces fonctionnalités. L’objectif final est le même, mais la limite supérieure des performances de QUIC, notamment en matière de latence et de débit, correspond à l’état actuel d’UDP pur.

Ces différences soulignent les choix architecturaux uniques adoptés par Solana et Ethereum, qui contribuent aux performances, à l’évolutivité et à la robustesse propres à chaque réseau. Pour une analyse plus approfondie de TCP, UDP et QUIC, consultez notre article sur Solana et QUIC.

Futures questions de recherche

La propagation des blocs et la disponibilité des données restent des domaines de recherche ouverts, dans lesquels de nombreuses équipes élaborent leurs propres approches. Même si les métriques sont susceptibles d’évoluer, nous souhaitons présenter les différentes approches et les compromis qui leur sont associés :

• Plusieurs discussions ont porté sur le statut de Turbine en tant que mécanisme de « disponibilité des données » (DA). Turbine sert de mécanisme de disponibilité des données au sens où toutes les données du bloc sont publiées et téléchargées par l’ensemble des autres validateurs de Solana. Toutefois, Turbine ne prend pas en charge l’échantillonnage de disponibilité des données (DAS), une fonctionnalité qui aide les nœuds légers à vérifier l’état avec des besoins matériels réduits. Il s’agit d’un axe de développement actif pour des équipes telles que Celestia. Comme Turbine, DAS utilise également des codes d’effacement, mais dans le but explicite de détecter et d’empêcher les attaques par rétention de données.
• Pour les L2 de la Solana Virtual Machine (SVM), telles qu’Eclipse, Turbine perd de sa pertinence, car aucun ensemble de validateurs ne doit échanger les données. Dans le cas d’Eclipse, les données de bloc sont publiées sur Celestia à des fins de disponibilité, ce qui permet à des observateurs externes d’exécuter des preuves de fraude afin de vérifier l’exactitude de l’exécution et des transitions d’état. Eclipse sera l’une des premières implémentations de la SVM en dehors du réseau Solana lui-même. Pyth a également créé un fork de la SVM pour son propre réseau d’oracles appelé « Pythnet », qui fonctionne de fait comme sa propre sidechain.
• Sur Solana, les nœuds complets gèrent la propagation des blocs tout en participant à d’autres segments de la pile blockchain intégrée, comme l’ordonnancement des transactions et le consensus. Quelles seraient les métriques quantitatives de Turbine s’il fonctionnait comme composant modulaire sur du matériel spécialisé ?
• Turbine donne la priorité aux nœuds dont le poids de staking est le plus élevé pour recevoir les données de bloc en premier. Cela entraînera-t-il une centralisation accrue de la MEV au fil du temps ?
• Comment les différentes approches de la disponibilité des données, telles qu’EigenDA (relais unique en monodiffusion, évolutif horizontalement) et Celestia (échantillonnage de disponibilité des données), se compareront-elles à Turbine en production en matière de débit brut et de minimisation de la confiance ?
• Firedancer vise à accroître davantage la propagation des données et est optimisé pour une connexion robuste offrant 10 Gbit/s de bande passante. Quelles seront, en production, les performances des optimisations système apportées à Turbine, aussi bien sur du matériel grand public que professionnel ?
• Actuellement, tous les nœuds de Solana sont des nœuds complets (les implémentations de clients légers sont toujours en cours de développement). Sreeram Kannan (EigenLayer) a récemment décrit une implémentation de DAS-S au-dessus de Turbine. Une version de DAS sera-t-elle prise en charge pour Turbine ? Des clients légers intégrant DAS peuvent-ils être implémentés afin de conserver un débit de données élevé tout en assurant la minimisation de la confiance avec des besoins en ressources bien moindres ?

Conclusion

Félicitations ! Dans cet article, nous avons examiné Turbine et son fonctionnement dans le processus global d’inclusion des transactions de Solana. Nous avons comparé Turbine à d’autres solutions de disponibilité des données et abordé les différentes pistes de recherche ouvertes dans ce domaine. Le protocole Turbine de Solana témoigne de l’engagement du réseau à offrir un débit élevé et une faible latence en s’appuyant sur une topologie réseau structurée pour diffuser efficacement les données de bloc entre les validateurs.

La recherche de moyens permettant d’améliorer la disponibilité des données et de rendre la propagation des blocs plus efficace stimule l’innovation dans l’ensemble de la communauté blockchain. L’analyse comparative des mécanismes de propagation des blocs de Solana et d’Ethereum met en lumière leurs forces et leurs compromis respectifs. Elle ouvre également une discussion plus approfondie sur la façon dont les solutions blockchain émergentes, telles qu’EigenDA, Celestia et Firedancer, pourraient façonner cet écosystème à l’avenir.

La recherche d’une solution efficace à la propagation et à la disponibilité des données est loin d’être terminée. Cependant, l’approche de Solana et son engagement constant à optimiser les performances du réseau sans compromettre la sécurité ni la minimisation de la confiance sont particulièrement bienvenus.

Merci à @dubbel06 et @jon_charb pour leur relecture et leurs commentaires.

Ressources complémentaires / Lectures supplémentaires

• Propagation des blocs avec Turbine
• Comprendre le code d’effacement
• Blocs Ethereum
• Mise à niveau Perseus du réseau Pyth
• Présentation d’EigenDA : disponibilité des données à très grande échelle pour les rollups
• Firedancer