Analyse de l'architecture technique de Solana : performance élevée et défis coexistants, le développement de l'écosystème accueille de nouvelles opportunités.
Réexamen de l'architecture technique de Solana : va-t-il connaître un second printemps ?
Solana est une plateforme blockchain haute performance, utilisant une architecture technologique unique pour réaliser un haut débit et une faible latence. Ses technologies clés incluent l'algorithme Proof of History (POH) qui assure l'ordre des transactions et une horloge globale, le Leader Rotation Schedule et le mécanisme de consensus Tower BFT qui augmentent le taux de production des blocs. Le mécanisme Turbine optimise la propagation de grands blocs grâce au codage Reed-solomon. La Solana Virtual Machine (SVM) et le moteur d'exécution parallèle Sealevel accélèrent la vitesse d'exécution des transactions. Tous ces éléments font partie de la conception architecturale de Solana pour atteindre une haute performance, mais ils ont également entraîné certains problèmes, tels que les pannes réseau, les échecs de transactions, les problèmes MEV, la croissance trop rapide de l'état et des problèmes de centralisation, que nous avons également soulignés dans cet article.
L'écosystème Solana se développe rapidement, avec des indicateurs de données qui ont tous connu une forte croissance au premier semestre, en particulier dans les domaines de DeFi, des infrastructures, de GameFi/NFT, de DePin/IA et des applications pour consommateurs. Le TPS élevé de Solana et sa stratégie orientée vers les applications pour consommateurs, ainsi qu'un environnement écologique moins marqué par l'effet de marque, offrent de nombreuses opportunités d'entrepreneuriat aux créateurs et aux développeurs. Dans le domaine des applications pour consommateurs, Solana a démontré sa vision pour promouvoir l'application de la technologie blockchain dans des domaines plus larges. En soutenant des projets comme Solana Mobile et en construisant des SDK spécifiquement pour les applications pour consommateurs, Solana s'efforce d'intégrer la technologie blockchain dans les applications quotidiennes, augmentant ainsi l'acceptation et la commodité pour les utilisateurs. Par exemple, des applications comme Stepn offrent aux utilisateurs une expérience novatrice de fitness et de socialisation en combinant blockchain et technologie mobile. Bien que de nombreuses applications pour consommateurs soient encore en train d'explorer les meilleurs modèles commerciaux et le positionnement sur le marché, la plateforme technologique et le soutien de l'écosystème offerts par Solana constituent sans aucun doute un puissant soutien pour ces tentatives d'innovation. Avec le développement technologique et la maturation du marché, Solana devrait réaliser davantage de percées et de cas de succès dans le domaine des applications pour consommateurs.
Bien que Solana ait obtenu une part de marché significative dans l'industrie de la blockchain grâce à son haut débit et à ses faibles coûts de transaction, elle fait également face à une concurrence féroce de la part d'autres blockchains émergentes. Une certaine plateforme de trading, en tant que concurrent potentiel dans l'écosystème EVM, voit rapidement le nombre d'adresses actives sur sa chaîne augmenter. Parallèlement, bien que le montant total des actifs bloqués (TVL) dans le domaine DeFi de Solana ait atteint un niveau record, des concurrents comme cette plateforme de trading occupent rapidement une part de marché, et le montant des financements de l'écosystème de cette plateforme a également dépassé pour la première fois celui de Solana au deuxième trimestre.
Bien que Solana ait réalisé certains succès sur le plan technique et de l'acceptation sur le marché, elle doit continuer à innover et à s'améliorer pour faire face aux défis posés par des concurrents tels que certaines plateformes de trading. En particulier, pour améliorer la stabilité du réseau, réduire le taux d'échec des transactions, résoudre le problème de MEV et ralentir la croissance de l'état, Solana doit continuer à optimiser son architecture technique et ses protocoles de réseau pour maintenir sa position de leader dans l'industrie de la blockchain.
Architecture technique
Solana est réputé pour son algorithme POH, son mécanisme de consensus Tower BFT, ainsi que pour son réseau de transmission de données Trubine et la machine virtuelle SVM qui offrent un TPS élevé et une finalité rapide. Nous allons brièvement présenter comment chacun de ses composants fonctionne, comment ils atteignent leur objectif de haute performance pour la conception de l'architecture, ainsi que les inconvénients et les problèmes dérivés de cette conception.
algorithme POH
POH (Proof of History) est une technologie qui détermine le temps global. Ce n'est pas un mécanisme de consensus, mais un algorithme qui détermine l'ordre des transactions. La technologie POH provient de la technologie cryptographique de base SHA256. SHA256 est généralement utilisé pour calculer l'intégrité des données. Pour une entrée donnée X, il n'y a qu'une seule sortie unique Y, donc toute modification de X entraînera une Y complètement différente.
Dans la séquence POH de Solana, l'application de l'algorithme sha256 permet d'assurer l'intégrité de l'ensemble de la séquence, et donc d'assurer l'intégrité des transactions. Par exemple, si nous regroupons les transactions dans un bloc et générons la valeur de hachage sha256 correspondante, alors les transactions à l'intérieur de ce bloc sont déterminées ; toute modification entraînerait un changement de la valeur de hachage. Ensuite, ce hachage de bloc sera utilisé comme partie de X pour la prochaine fonction sha256, puis le hachage du bloc suivant sera ajouté. Ainsi, le bloc précédent et le bloc suivant sont tous deux déterminés, et toute modification entraînera une nouvelle valeur Y différente.
C'est la signification centrale de sa technologie Proof of History, le hash du bloc précédent sera une partie de la prochaine fonction sha256, semblable à une chaîne, le dernier Y inclut toujours la preuve historique.
Dans le schéma d'architecture des flux de transactions de Solana, le processus de transaction sous le mécanisme POH est décrit. Dans un mécanisme de rotation appelé Leader Rotation Schedule, un nœud Leader est sélectionné parmi tous les validateurs de la chaîne, ce nœud Leader collecte les transactions, les trie et les exécute, générant une séquence POH, puis un bloc est créé et propagé aux autres nœuds.
Pour éviter les points de défaillance uniques au niveau du nœud Leader, une limite de temps a été introduite. Dans Solana, l'unité de temps est divisée en époques, chaque époque contenant 432 000 slots, chaque slot durant 400 ms. À chaque slot, le système de rotation attribue un nœud Leader pour chaque slot. Le nœud Leader doit publier un bloc dans le temps imparti (400 ms) pour ce slot, sinon, ce slot sera sauté et un nouveau nœud Leader sera élu pour le slot suivant.
Dans l'ensemble, le nœud Leader utilisant le mécanisme POH permet de valider toutes les transactions historiques. L'unité de temps de base de Solana est le Slot, le nœud Leader doit diffuser le bloc dans un slot. Les utilisateurs envoient des transactions au Leader via le nœud RPC, le nœud Leader empaquette et ordonne les transactions, puis exécute la génération du bloc, le bloc est propagé aux autres validateurs, qui doivent parvenir à un consensus sur les transactions et l'ordre à l'intérieur du bloc à l'aide d'un mécanisme, ce consensus utilise le mécanisme de consensus Tower BFT.
Mécanisme de consensus Tower BFT
Le protocole de consensus Tower BFT est dérivé de l'algorithme de consensus BFT, et constitue une mise en œuvre technique spécifique de celui-ci. Cet algorithme est toujours lié à l'algorithme POH. Lors du vote sur un bloc, si le vote d'un validateur est lui-même une transaction, alors le hash du bloc formé par la transaction de l'utilisateur et la transaction du validateur peut également servir de preuve historique, permettant de confirmer de manière unique les détails de la transaction de l'utilisateur ainsi que les détails du vote du validateur.
Dans l'algorithme Tower BFT, il est stipulé que si tous les validateurs votent pour le bloc et que plus de 2/3 des validateurs ont voté en faveur, alors ce bloc peut être confirmé. L'avantage de ce mécanisme est qu'il économise une grande quantité de mémoire, car il suffit de voter sur la séquence de hachage pour confirmer le bloc. Cependant, dans les mécanismes de consensus traditionnels, on utilise généralement l'inondation de blocs, c'est-à-dire qu'un validateur reçoit un bloc et l'envoie ensuite aux validateurs environnants, ce qui entraîne une grande redondance dans le réseau, car un validateur reçoit le même bloc plusieurs fois.
Dans Solana, en raison d'un grand nombre de transactions de vote des validateurs et de l'efficacité apportée par la centralisation des nœuds Leader ainsi qu'un temps de Slot de 400 ms, cela entraîne une taille de bloc globalement élevée et une fréquence de production de blocs particulièrement élevée. La propagation de grands blocs exerce également une pression importante sur le réseau. Solana utilise le mécanisme Turbine pour résoudre le problème de la propagation des grands blocs.
Turbine
Le nœud Leader divise le bloc en sous-blocs appelés shreds par un processus appelé Sharding, dont la taille est spécifiée en unités de MTU (unité maximale de transmission, qui représente la quantité maximale de données pouvant être envoyées d'un nœud à un autre sans avoir besoin d'être fragmentées en unités plus petites). Ensuite, l'intégrité et la disponibilité des données sont garanties en utilisant le schéma de codes d'effacement de Reed-Solomon.
En divisant le bloc en quatre Data Shreds, et afin de prévenir la perte et la corruption des données pendant le transfert, l'encodage Reed-Solomon est utilisé pour encoder les quatre paquets en huit paquets. Ce système peut tolérer jusqu'à 50 % de taux de perte. Lors des tests réels, le taux de perte de Solana est d'environ 15 %, donc ce système est bien compatible avec l'architecture actuelle de Solana.
Dans le transfert de données au niveau de la couche inférieure, on considère généralement l'utilisation des protocoles UDP/TCP. Étant donné que Solana a une tolérance relativement élevée au taux de perte de paquets, le protocole UDP est utilisé pour le transfert. Son inconvénient est qu'il ne retransmet pas les paquets perdus, mais son avantage réside dans un taux de transfert plus rapide. En revanche, le protocole TCP retransmet plusieurs fois en cas de perte de paquets, ce qui réduit considérablement le taux de transfert et le débit. Avec l'arrivée de Reed-Solomon, ce système peut augmenter considérablement le débit de Solana, permettant dans un environnement réel d'augmenter le débit jusqu'à 9 fois.
Après que Turbine a fragmenté les données, il utilise un mécanisme de propagation multicouche pour les diffuser. Le nœud Leader remet le bloc à un validateur de bloc aléatoire avant la fin de chaque Slot, puis ce validateur fragmentera le bloc en Shreds et générera des codes de correction d'erreurs. Ce validateur commencera ensuite la propagation Turbine. Tout d'abord, il doit se propager jusqu'au nœud racine, puis ce nœud racine déterminera quels validateurs se trouvent à quel niveau. Le processus est illustré comme suit :
Créer une liste de nœuds : le nœud racine regroupe tous les validateurs actifs dans une liste, puis les classe en fonction des droits de chaque validateur dans le réseau (c'est-à-dire la quantité de SOL mise en jeu), ceux ayant un poids plus élevé se trouvant au premier niveau, et ainsi de suite.
Groupement de nœuds : Ensuite, chaque validateurs situé au premier niveau créera également sa propre liste de nœuds pour construire son propre premier niveau.
Formation des couches : Diviser les nœuds en couches à partir du haut de la liste, en déterminant les valeurs de profondeur et de largeur, permet de définir la forme générale de l'arbre. Ce paramètre affectera la vitesse de propagation des shreds.
Les nœuds ayant une part de droits plus élevée, lors de la classification hiérarchique, se trouvant à un niveau supérieur, peuvent alors obtenir des shreds complets à l'avance. À ce moment-là, il est possible de restaurer le bloc complet, tandis que les nœuds des niveaux inférieurs, en raison de la perte de transmission, auront une probabilité réduite d'obtenir des shreds complets. Si ces shreds ne suffisent pas à construire des fragments complets, le Leader devra demander une retransmission directe. Dans ce cas, le transfert de données se fera vers l'intérieur de l'arbre, tandis que les nœuds du premier niveau auront déjà construit une confirmation de bloc complète. Plus le temps nécessaire pour que les validateurs des niveaux inférieurs terminent la construction du bloc et votent est long.
Cette mécanique s'apparente au mécanisme à nœud unique des nœuds Leader. Dans le processus de propagation des blocs, il existe également certains nœuds prioritaires qui obtiennent d'abord des fragments shreds pour former des blocs complets afin d'atteindre le consensus de vote. Pousser la redondance à un niveau plus profond peut considérablement accélérer le processus de Finalité et maximiser le débit et l'efficacité. En effet, les premières couches peuvent représenter 2/3 des nœuds, rendant ainsi le vote des nœuds suivants sans importance.
SVM
Solana peut traiter des milliers de transactions par seconde, principalement en raison de son mécanisme POH, du consensus Tower BFT et du mécanisme de propagation des données Turbine. Cependant, en tant que machine virtuelle de transition d'état, si le nœud Leader ralentit le traitement des transactions dans l'exécution, la vitesse de traitement de la SVM peut réduire le débit global du système. Par conséquent, pour la SVM, Solana a proposé le moteur d'exécution parallèle Sealevel pour accélérer la vitesse d'exécution des transactions.
Dans SVM, une instruction se compose de 4 parties : l'ID du programme, l'instruction du programme et une liste de comptes pour lire/écrire des données. En déterminant si le compte actuel est en mode lecture ou écriture et si les opérations de modification d'état sont en conflit, il est possible de permettre la parallélisation des instructions de transaction du compte sans conflit d'état, chaque instruction étant représentée par l'ID du programme. C'est également l'une des raisons pour lesquelles les exigences pour les validateurs de Solana sont élevées, car il est requis que le GPU/CPU des validateurs puisse supporter SIMD (Single Instruction Multiple Data) et AVX.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
13 J'aime
Récompense
13
5
Partager
Commentaire
0/400
FancyResearchLab
· 07-30 11:46
Encore à étudier quelle fonctionnalité fantaisiste, je me sens vraiment désolé pour votre Portefeuille.
Voir l'originalRépondre0
FundingMartyr
· 07-28 11:16
la foi dans sol a propulsé ce qui appartient à
Voir l'originalRépondre0
FarmHopper
· 07-28 11:15
sol est arrivé !
Voir l'originalRépondre0
ChainSauceMaster
· 07-28 11:13
sol est vraiment agréable
Voir l'originalRépondre0
LuckyBlindCat
· 07-28 11:11
Cela mérite-t-il vraiment d'être appelé un deuxième printemps ? Tu t'éloignes trop.
Analyse de l'architecture technique de Solana : performance élevée et défis coexistants, le développement de l'écosystème accueille de nouvelles opportunités.
Réexamen de l'architecture technique de Solana : va-t-il connaître un second printemps ?
Solana est une plateforme blockchain haute performance, utilisant une architecture technologique unique pour réaliser un haut débit et une faible latence. Ses technologies clés incluent l'algorithme Proof of History (POH) qui assure l'ordre des transactions et une horloge globale, le Leader Rotation Schedule et le mécanisme de consensus Tower BFT qui augmentent le taux de production des blocs. Le mécanisme Turbine optimise la propagation de grands blocs grâce au codage Reed-solomon. La Solana Virtual Machine (SVM) et le moteur d'exécution parallèle Sealevel accélèrent la vitesse d'exécution des transactions. Tous ces éléments font partie de la conception architecturale de Solana pour atteindre une haute performance, mais ils ont également entraîné certains problèmes, tels que les pannes réseau, les échecs de transactions, les problèmes MEV, la croissance trop rapide de l'état et des problèmes de centralisation, que nous avons également soulignés dans cet article.
L'écosystème Solana se développe rapidement, avec des indicateurs de données qui ont tous connu une forte croissance au premier semestre, en particulier dans les domaines de DeFi, des infrastructures, de GameFi/NFT, de DePin/IA et des applications pour consommateurs. Le TPS élevé de Solana et sa stratégie orientée vers les applications pour consommateurs, ainsi qu'un environnement écologique moins marqué par l'effet de marque, offrent de nombreuses opportunités d'entrepreneuriat aux créateurs et aux développeurs. Dans le domaine des applications pour consommateurs, Solana a démontré sa vision pour promouvoir l'application de la technologie blockchain dans des domaines plus larges. En soutenant des projets comme Solana Mobile et en construisant des SDK spécifiquement pour les applications pour consommateurs, Solana s'efforce d'intégrer la technologie blockchain dans les applications quotidiennes, augmentant ainsi l'acceptation et la commodité pour les utilisateurs. Par exemple, des applications comme Stepn offrent aux utilisateurs une expérience novatrice de fitness et de socialisation en combinant blockchain et technologie mobile. Bien que de nombreuses applications pour consommateurs soient encore en train d'explorer les meilleurs modèles commerciaux et le positionnement sur le marché, la plateforme technologique et le soutien de l'écosystème offerts par Solana constituent sans aucun doute un puissant soutien pour ces tentatives d'innovation. Avec le développement technologique et la maturation du marché, Solana devrait réaliser davantage de percées et de cas de succès dans le domaine des applications pour consommateurs.
Bien que Solana ait obtenu une part de marché significative dans l'industrie de la blockchain grâce à son haut débit et à ses faibles coûts de transaction, elle fait également face à une concurrence féroce de la part d'autres blockchains émergentes. Une certaine plateforme de trading, en tant que concurrent potentiel dans l'écosystème EVM, voit rapidement le nombre d'adresses actives sur sa chaîne augmenter. Parallèlement, bien que le montant total des actifs bloqués (TVL) dans le domaine DeFi de Solana ait atteint un niveau record, des concurrents comme cette plateforme de trading occupent rapidement une part de marché, et le montant des financements de l'écosystème de cette plateforme a également dépassé pour la première fois celui de Solana au deuxième trimestre.
Bien que Solana ait réalisé certains succès sur le plan technique et de l'acceptation sur le marché, elle doit continuer à innover et à s'améliorer pour faire face aux défis posés par des concurrents tels que certaines plateformes de trading. En particulier, pour améliorer la stabilité du réseau, réduire le taux d'échec des transactions, résoudre le problème de MEV et ralentir la croissance de l'état, Solana doit continuer à optimiser son architecture technique et ses protocoles de réseau pour maintenir sa position de leader dans l'industrie de la blockchain.
Architecture technique
Solana est réputé pour son algorithme POH, son mécanisme de consensus Tower BFT, ainsi que pour son réseau de transmission de données Trubine et la machine virtuelle SVM qui offrent un TPS élevé et une finalité rapide. Nous allons brièvement présenter comment chacun de ses composants fonctionne, comment ils atteignent leur objectif de haute performance pour la conception de l'architecture, ainsi que les inconvénients et les problèmes dérivés de cette conception.
algorithme POH
POH (Proof of History) est une technologie qui détermine le temps global. Ce n'est pas un mécanisme de consensus, mais un algorithme qui détermine l'ordre des transactions. La technologie POH provient de la technologie cryptographique de base SHA256. SHA256 est généralement utilisé pour calculer l'intégrité des données. Pour une entrée donnée X, il n'y a qu'une seule sortie unique Y, donc toute modification de X entraînera une Y complètement différente.
Dans la séquence POH de Solana, l'application de l'algorithme sha256 permet d'assurer l'intégrité de l'ensemble de la séquence, et donc d'assurer l'intégrité des transactions. Par exemple, si nous regroupons les transactions dans un bloc et générons la valeur de hachage sha256 correspondante, alors les transactions à l'intérieur de ce bloc sont déterminées ; toute modification entraînerait un changement de la valeur de hachage. Ensuite, ce hachage de bloc sera utilisé comme partie de X pour la prochaine fonction sha256, puis le hachage du bloc suivant sera ajouté. Ainsi, le bloc précédent et le bloc suivant sont tous deux déterminés, et toute modification entraînera une nouvelle valeur Y différente.
C'est la signification centrale de sa technologie Proof of History, le hash du bloc précédent sera une partie de la prochaine fonction sha256, semblable à une chaîne, le dernier Y inclut toujours la preuve historique.
Dans le schéma d'architecture des flux de transactions de Solana, le processus de transaction sous le mécanisme POH est décrit. Dans un mécanisme de rotation appelé Leader Rotation Schedule, un nœud Leader est sélectionné parmi tous les validateurs de la chaîne, ce nœud Leader collecte les transactions, les trie et les exécute, générant une séquence POH, puis un bloc est créé et propagé aux autres nœuds.
Pour éviter les points de défaillance uniques au niveau du nœud Leader, une limite de temps a été introduite. Dans Solana, l'unité de temps est divisée en époques, chaque époque contenant 432 000 slots, chaque slot durant 400 ms. À chaque slot, le système de rotation attribue un nœud Leader pour chaque slot. Le nœud Leader doit publier un bloc dans le temps imparti (400 ms) pour ce slot, sinon, ce slot sera sauté et un nouveau nœud Leader sera élu pour le slot suivant.
Dans l'ensemble, le nœud Leader utilisant le mécanisme POH permet de valider toutes les transactions historiques. L'unité de temps de base de Solana est le Slot, le nœud Leader doit diffuser le bloc dans un slot. Les utilisateurs envoient des transactions au Leader via le nœud RPC, le nœud Leader empaquette et ordonne les transactions, puis exécute la génération du bloc, le bloc est propagé aux autres validateurs, qui doivent parvenir à un consensus sur les transactions et l'ordre à l'intérieur du bloc à l'aide d'un mécanisme, ce consensus utilise le mécanisme de consensus Tower BFT.
Mécanisme de consensus Tower BFT
Le protocole de consensus Tower BFT est dérivé de l'algorithme de consensus BFT, et constitue une mise en œuvre technique spécifique de celui-ci. Cet algorithme est toujours lié à l'algorithme POH. Lors du vote sur un bloc, si le vote d'un validateur est lui-même une transaction, alors le hash du bloc formé par la transaction de l'utilisateur et la transaction du validateur peut également servir de preuve historique, permettant de confirmer de manière unique les détails de la transaction de l'utilisateur ainsi que les détails du vote du validateur.
Dans l'algorithme Tower BFT, il est stipulé que si tous les validateurs votent pour le bloc et que plus de 2/3 des validateurs ont voté en faveur, alors ce bloc peut être confirmé. L'avantage de ce mécanisme est qu'il économise une grande quantité de mémoire, car il suffit de voter sur la séquence de hachage pour confirmer le bloc. Cependant, dans les mécanismes de consensus traditionnels, on utilise généralement l'inondation de blocs, c'est-à-dire qu'un validateur reçoit un bloc et l'envoie ensuite aux validateurs environnants, ce qui entraîne une grande redondance dans le réseau, car un validateur reçoit le même bloc plusieurs fois.
Dans Solana, en raison d'un grand nombre de transactions de vote des validateurs et de l'efficacité apportée par la centralisation des nœuds Leader ainsi qu'un temps de Slot de 400 ms, cela entraîne une taille de bloc globalement élevée et une fréquence de production de blocs particulièrement élevée. La propagation de grands blocs exerce également une pression importante sur le réseau. Solana utilise le mécanisme Turbine pour résoudre le problème de la propagation des grands blocs.
Turbine
Le nœud Leader divise le bloc en sous-blocs appelés shreds par un processus appelé Sharding, dont la taille est spécifiée en unités de MTU (unité maximale de transmission, qui représente la quantité maximale de données pouvant être envoyées d'un nœud à un autre sans avoir besoin d'être fragmentées en unités plus petites). Ensuite, l'intégrité et la disponibilité des données sont garanties en utilisant le schéma de codes d'effacement de Reed-Solomon.
En divisant le bloc en quatre Data Shreds, et afin de prévenir la perte et la corruption des données pendant le transfert, l'encodage Reed-Solomon est utilisé pour encoder les quatre paquets en huit paquets. Ce système peut tolérer jusqu'à 50 % de taux de perte. Lors des tests réels, le taux de perte de Solana est d'environ 15 %, donc ce système est bien compatible avec l'architecture actuelle de Solana.
Dans le transfert de données au niveau de la couche inférieure, on considère généralement l'utilisation des protocoles UDP/TCP. Étant donné que Solana a une tolérance relativement élevée au taux de perte de paquets, le protocole UDP est utilisé pour le transfert. Son inconvénient est qu'il ne retransmet pas les paquets perdus, mais son avantage réside dans un taux de transfert plus rapide. En revanche, le protocole TCP retransmet plusieurs fois en cas de perte de paquets, ce qui réduit considérablement le taux de transfert et le débit. Avec l'arrivée de Reed-Solomon, ce système peut augmenter considérablement le débit de Solana, permettant dans un environnement réel d'augmenter le débit jusqu'à 9 fois.
Après que Turbine a fragmenté les données, il utilise un mécanisme de propagation multicouche pour les diffuser. Le nœud Leader remet le bloc à un validateur de bloc aléatoire avant la fin de chaque Slot, puis ce validateur fragmentera le bloc en Shreds et générera des codes de correction d'erreurs. Ce validateur commencera ensuite la propagation Turbine. Tout d'abord, il doit se propager jusqu'au nœud racine, puis ce nœud racine déterminera quels validateurs se trouvent à quel niveau. Le processus est illustré comme suit :
Créer une liste de nœuds : le nœud racine regroupe tous les validateurs actifs dans une liste, puis les classe en fonction des droits de chaque validateur dans le réseau (c'est-à-dire la quantité de SOL mise en jeu), ceux ayant un poids plus élevé se trouvant au premier niveau, et ainsi de suite.
Groupement de nœuds : Ensuite, chaque validateurs situé au premier niveau créera également sa propre liste de nœuds pour construire son propre premier niveau.
Formation des couches : Diviser les nœuds en couches à partir du haut de la liste, en déterminant les valeurs de profondeur et de largeur, permet de définir la forme générale de l'arbre. Ce paramètre affectera la vitesse de propagation des shreds.
Les nœuds ayant une part de droits plus élevée, lors de la classification hiérarchique, se trouvant à un niveau supérieur, peuvent alors obtenir des shreds complets à l'avance. À ce moment-là, il est possible de restaurer le bloc complet, tandis que les nœuds des niveaux inférieurs, en raison de la perte de transmission, auront une probabilité réduite d'obtenir des shreds complets. Si ces shreds ne suffisent pas à construire des fragments complets, le Leader devra demander une retransmission directe. Dans ce cas, le transfert de données se fera vers l'intérieur de l'arbre, tandis que les nœuds du premier niveau auront déjà construit une confirmation de bloc complète. Plus le temps nécessaire pour que les validateurs des niveaux inférieurs terminent la construction du bloc et votent est long.
Cette mécanique s'apparente au mécanisme à nœud unique des nœuds Leader. Dans le processus de propagation des blocs, il existe également certains nœuds prioritaires qui obtiennent d'abord des fragments shreds pour former des blocs complets afin d'atteindre le consensus de vote. Pousser la redondance à un niveau plus profond peut considérablement accélérer le processus de Finalité et maximiser le débit et l'efficacité. En effet, les premières couches peuvent représenter 2/3 des nœuds, rendant ainsi le vote des nœuds suivants sans importance.
SVM
Solana peut traiter des milliers de transactions par seconde, principalement en raison de son mécanisme POH, du consensus Tower BFT et du mécanisme de propagation des données Turbine. Cependant, en tant que machine virtuelle de transition d'état, si le nœud Leader ralentit le traitement des transactions dans l'exécution, la vitesse de traitement de la SVM peut réduire le débit global du système. Par conséquent, pour la SVM, Solana a proposé le moteur d'exécution parallèle Sealevel pour accélérer la vitesse d'exécution des transactions.
Dans SVM, une instruction se compose de 4 parties : l'ID du programme, l'instruction du programme et une liste de comptes pour lire/écrire des données. En déterminant si le compte actuel est en mode lecture ou écriture et si les opérations de modification d'état sont en conflit, il est possible de permettre la parallélisation des instructions de transaction du compte sans conflit d'état, chaque instruction étant représentée par l'ID du programme. C'est également l'une des raisons pour lesquelles les exigences pour les validateurs de Solana sont élevées, car il est requis que le GPU/CPU des validateurs puisse supporter SIMD (Single Instruction Multiple Data) et AVX.