Analyse approfondie de l'architecture technique de Solana : est-ce que le printemps de la deuxième chance est imminent ?
Solana est une plateforme blockchain hautes performances qui utilise une architecture technique unique pour réaliser un haut débit et une faible latence. Ses technologies de base incluent l'algorithme Proof of History (POH) qui garantit l'ordre des transactions et l'horloge globale, le calendrier de rotation des leaders et le mécanisme de consensus Tower BFT qui augmentent la vitesse de génération des blocs. Le mécanisme Turbine optimise la diffusion 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. Ce sont là des conceptions architecturales qui permettent à Solana d'atteindre de hautes performances, mais cela a également entraîné certains problèmes, tels que des pannes réseau, des échecs de transactions, des problèmes de MEV, une croissance trop rapide de l'état et des problèmes de centralisation.
L'écosystème Solana se développe rapidement, avec des indicateurs de données qui ont fortement progressé au cours du premier semestre, notamment dans les domaines de DeFi, des infrastructures, de GameFi/NFT, de DePin/IA et des applications grand public. Le TPS élevé de Solana, sa stratégie axée sur les applications grand public et un environnement écologique avec un effet de marque relativement faible offrent aux entrepreneurs et aux développeurs de nombreuses opportunités d'affaires. En ce qui concerne les applications grand public, Solana a démontré sa vision pour promouvoir l'application de la technologie blockchain dans des domaines plus larges. En soutenant des initiatives comme Solana Mobile et en construisant des SDK spécifiquement pour les applications grand public, 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 combinent la blockchain et la technologie mobile pour offrir aux utilisateurs une expérience novatrice de fitness et de socialisation. Bien que de nombreuses applications grand public explorent encore les meilleurs modèles commerciaux et le positionnement sur le marché, la plateforme technologique et le soutien de l'écosystème fournis par Solana constituent sans aucun doute un solide soutien pour ces tentatives d'innovation. Avec le développement technologique continu et la maturation du marché, Solana devrait connaître davantage de percées et de cas de succès dans le domaine des applications grand public.
Bien que Solana ait réussi à obtenir une part de marché significative dans l'industrie de la blockchain en raison de sa haute capacité de traitement et de ses faibles coûts de transaction, elle fait face à une concurrence féroce de la part d'autres chaînes de blocs émergentes. Une plateforme d'échange, en tant que concurrent potentiel dans l'écosystème EVM, voit le nombre d'adresses actives sur sa chaîne augmenter rapidement. Parallèlement, le montant total des actifs verrouillés (TVL) de Solana, qui a atteint un nouveau sommet historique (, est également confronté à une concurrence rapide de la part de rivaux comme cette plateforme d'échange, dont le montant de financement de l'écosystème a également pour la première fois dépassé celui de Solana au deuxième trimestre.
Bien que Solana ait réalisé des progrès notables en termes de technologie et d'acceptation sur le marché, il 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 les problèmes de MEV et ralentir la croissance de l'état, Solana doit continuer à optimiser son architecture technique et ses protocoles réseau afin de maintenir sa position de leader dans l'industrie de la blockchain.
![Réexpliquer l'architecture technique de Solana : va-t-elle connaître un second printemps ?])https://img-cdn.gateio.im/webp-social/moments-224796bc8e080649730bb8736334abba.webp(
Architecture technique
Solana est connue pour son algorithme POH, son mécanisme de consensus Tower BFT, ainsi que pour son réseau de transmission de données Trubine et sa machine virtuelle SVM, qui offrent un haut TPS et une finalité rapide. Nous allons brièvement présenter le fonctionnement de chacun de ses composants, comment ils atteignent leur objectif de haute performance pour la conception architecturale, ainsi que les inconvénients et les problèmes dérivés de cette conception architecturale.
) algorithme POH
POH###Preuve d'Histoire( est une technologie qui détermine le temps global, elle n'est pas un mécanisme de consensus, mais un algorithme qui détermine l'ordre des transactions. La technologie POH provient de la technique cryptographique de base SHA256. SHA256 est généralement utilisé pour calculer l'intégrité des données, étant donné une entrée X, il y a et il n'y a qu'une seule sortie Y, donc toute modification de X entraînera une Y complètement différente.
Dans la séquence POH de Solana, l'intégrité de l'ensemble de la séquence peut être assurée en appliquant l'algorithme sha256, ce qui garantit également l'intégrité des transactions. Par exemple, si nous regroupons les transactions en 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, tout changement entraînera une modification de la valeur de hachage. Ensuite, ce hachage de bloc sera utilisé comme une partie de X de la prochaine fonction sha256, puis le hachage du prochain bloc sera ajouté, de sorte que le bloc précédent et le bloc suivant soient tous deux déterminés, tout changement entraînera une valeur Y différente.
C'est le sens central de sa technologie Proof of History, le hash du bloc précédent servira de partie à la prochaine fonction sha256, semblable à une chaîne, le dernier Y contenant toujours la preuve historique.
![Revisiter l'architecture technique de Solana : va-t-elle connaître un second printemps ?])https://img-cdn.gateio.im/webp-social/moments-46a028270f3c2da92e7056c17c1d9e16.webp(
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 des leaders appelé Leader Rotation Schedule, un nœud Leader est désigné 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 crée un bloc qui est propagé aux autres nœuds.
Pour éviter les pannes de point unique au niveau du nœud Leader, une limite de temps a été introduite. Dans Solana, l'unité de temps est divisée en epochs, chaque epoch contenant 432 000 slots), chaque slot durant 400 ms. Dans chaque slot, le système de rotation attribue un nœud Leader à chaque slot, et le nœud Leader doit publier un bloc(400ms) dans le temps imparti, sinon, ce slot sera ignoré et un nouveau nœud Leader sera réélu pour le slot suivant.
En général, les nœuds Leader utilisant le mécanisme POH permettent de finaliser toutes les transactions historiques. L'unité de temps de base de Solana est le Slot, et le nœud Leader doit diffuser le bloc dans un slot. Les utilisateurs envoient leurs transactions au Leader via des nœuds RPC, le nœud Leader regroupe et ordonne les transactions, puis exécute la génération du bloc, qui est ensuite propagé aux autres validateurs. Les validateurs doivent parvenir à un consensus sur les transactions et l'ordre dans le bloc via un mécanisme, et le consensus utilisé est 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, qui en est une réalisation concrète. Cet algorithme est toujours lié à l'algorithme POH. Lors du vote sur un bloc, si le vote des validateurs constitue lui-même une transaction, alors le hachage 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 des transactions des utilisateurs et les détails des votes des validateurs.
![Revisiter l'architecture technique de Solana : va-t-elle connaître un second printemps ?])https://img-cdn.gateio.im/webp-social/moments-d55d3cfbc13036ed0d5747abb521cc1a.webp###
Dans l'algorithme Tower BFT, il est stipulé que si tous les validateurs votent pour ce bloc, et que plus de 2/3 des validateurs ont voté pour l'approbation, alors ce bloc peut être confirmé. Le bénéfice de ce mécanisme est qu'il permet d'économiser 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 qui reçoit le bloc 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 du grand nombre de transactions de vote des validateurs et de l'efficacité apportée par la centralisation des nœuds Leader ainsi que du temps de Slot de 400 ms, la taille globale des blocs et la fréquence de création de blocs sont particulièrement élevées. Lors de la propagation de grands blocs, cela exerce également une pression considérable sur le réseau. Solana utilise le mécanisme Turbine pour résoudre le problème de propagation des grands blocs.
( Turbine
Le nœud Leader divise les blocs en sous-blocs appelés shreds par un processus appelé Sharding, dont la taille est spécifiée par l'unité maximale de transmission MTU), représentant la quantité maximale de données pouvant être envoyée d'un nœud à l'autre sans être divisée en unités plus petites, qui est de ###. Ensuite, l'intégrité et la disponibilité des données sont garanties en utilisant un schéma de code d'effacement Reed-Solomon.
En divisant le bloc en quatre Data Shreds, puis pour 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, et ce système peut tolérer jusqu'à 50% de taux de perte. Dans les tests réels, le taux de perte de Solana est d'environ 15%, donc ce système s'adapte très bien à l'architecture actuelle de Solana.
Dans le transfert de données sous-jacent, on envisage généralement d'utiliser les protocoles UDP/TCP. Étant donné que la tolérance de Solana à la perte de paquets est relativement élevée, le protocole UDP est utilisé pour le transfert. Son inconvénient est qu'il ne retransmet pas en cas de perte de paquets, mais son avantage réside dans une vitesse de transfert plus rapide. En revanche, le protocole TCP retransmet plusieurs fois en cas de perte de paquets, ce qui réduit considérablement la vitesse de transfert et le débit. Avec l'utilisation de Reed-Solomon, ce système peut considérablement augmenter le débit de Solana, permettant d'obtenir une augmentation de 9 fois dans un environnement réel.
Après que Turbine ait fragmenté les données, il utilise un mécanisme de propagation multi-niveaux pour la diffusion. Le nœud Leader remettra le bloc à n'importe quel validateur de bloc avant la fin de chaque Slot, puis ce validateur fragmentera le bloc en Shreds et générera un code de correction d'erreur, après quoi ce validateur lancera la propagation Turbine. Il doit d'abord être propagé vers le nœud racine, puis ce nœud racine déterminera quels validateurs se trouvent à quel niveau. Le processus est illustré comme suit :
Créer la liste des nœuds : le nœud racine rassemblera tous les validateurs actifs dans une liste, puis les classera en fonction de la participation de chaque validateur dans le réseau, c'est-à-dire le montant de SOL mis en jeu (, le poids le plus élevé se trouvant au premier niveau, et ainsi de suite.
Groupement de nœuds : Ensuite, chaque validateur 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 depuis le sommet de la liste, en déterminant deux valeurs, la profondeur et la largeur, permet de définir la forme générale de l'arbre. Ce paramètre influencera le taux de propagation des shreds.
Les nœuds ayant une part de droits plus élevée, lors de la classification hiérarchique, se situent à un niveau supérieur, ce qui leur permet d'obtenir à l'avance des shreds complets. À ce moment-là, ils peuvent restaurer des blocs complets, tandis que les nœuds des niveaux inférieurs, en raison des pertes lors du transfert, verront leur probabilité d'obtenir des shreds complets diminuer. Si ces shreds ne suffisent pas à construire des fragments complets, le Leader demandera un retransfert direct. À ce stade, le transfert de données se dirigera vers l'intérieur de l'arbre, et les nœuds de la première couche auront déjà construit une confirmation complète du bloc. Plus le temps nécessaire pour que les validateurs des niveaux inférieurs terminent la construction du bloc et votent est long.
L'idée de ce mécanisme est similaire à celle du mécanisme à nœud unique du nœud Leader. Au cours du processus de propagation des blocs, certains nœuds prioritaires existent, ces nœuds obtiennent d'abord les fragments shreds pour reconstruire 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 grâce à son mécanisme POH, son consensus Tower BFT et son mécanisme de diffusion de données Turbine. Cependant, SVM, en tant que machine virtuelle pour la transformation d'état, si le nœud Leader est lent dans l'exécution des transactions, cela peut réduire le débit global du système. Ainsi, pour 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, les instructions se composent de 4 parties, comprenant l'ID du programme, les instructions du programme et la liste des comptes pour la lecture/écriture des données. En déterminant si le compte actuel est en état de lecture ou d'écriture et si les opérations à effectuer pour le changement 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 aussi l'une des raisons pour lesquelles les exigences pour les validateurs de Solana sont très élevées, car il est demandé aux GPU/CPU des validateurs de pouvoir supporter SIMD### les instructions multiples de données( et la capacité d'extension vectorielle avancée AVX.
Développement écologique
Dans le cadre du développement actuel de l'écosystème Solana, l'accent est de plus en plus mis sur l'utilité réelle, comme Blinks, Actions et même Solana Mobile, tandis que la direction de développement des applications soutenue par l'officiel.
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.
25 J'aime
Récompense
25
7
Reposter
Partager
Commentaire
0/400
FlyingLeek
· Il y a 14h
Sol veut encore faire un big pump ?
Voir l'originalRépondre0
NervousFingers
· 08-15 01:45
Courir si vite, c'est juste vendre.
Voir l'originalRépondre0
MemeTokenGenius
· 08-13 22:07
Le rythme revient, je ne crois pas que SOL puisse se redresser.
Voir l'originalRépondre0
SnapshotStriker
· 08-13 22:06
le vieux porridge sol est délicieusement parfumé
Voir l'originalRépondre0
CoinBasedThinking
· 08-13 21:50
Il se peut qu'il faille encore attendre un peu pour cette vague.
Analyse approfondie de l'architecture technique de Solana : défis et opportunités derrière un TPS élevé
Analyse approfondie de l'architecture technique de Solana : est-ce que le printemps de la deuxième chance est imminent ?
Solana est une plateforme blockchain hautes performances qui utilise une architecture technique unique pour réaliser un haut débit et une faible latence. Ses technologies de base incluent l'algorithme Proof of History (POH) qui garantit l'ordre des transactions et l'horloge globale, le calendrier de rotation des leaders et le mécanisme de consensus Tower BFT qui augmentent la vitesse de génération des blocs. Le mécanisme Turbine optimise la diffusion 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. Ce sont là des conceptions architecturales qui permettent à Solana d'atteindre de hautes performances, mais cela a également entraîné certains problèmes, tels que des pannes réseau, des échecs de transactions, des problèmes de MEV, une croissance trop rapide de l'état et des problèmes de centralisation.
L'écosystème Solana se développe rapidement, avec des indicateurs de données qui ont fortement progressé au cours du premier semestre, notamment dans les domaines de DeFi, des infrastructures, de GameFi/NFT, de DePin/IA et des applications grand public. Le TPS élevé de Solana, sa stratégie axée sur les applications grand public et un environnement écologique avec un effet de marque relativement faible offrent aux entrepreneurs et aux développeurs de nombreuses opportunités d'affaires. En ce qui concerne les applications grand public, Solana a démontré sa vision pour promouvoir l'application de la technologie blockchain dans des domaines plus larges. En soutenant des initiatives comme Solana Mobile et en construisant des SDK spécifiquement pour les applications grand public, 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 combinent la blockchain et la technologie mobile pour offrir aux utilisateurs une expérience novatrice de fitness et de socialisation. Bien que de nombreuses applications grand public explorent encore les meilleurs modèles commerciaux et le positionnement sur le marché, la plateforme technologique et le soutien de l'écosystème fournis par Solana constituent sans aucun doute un solide soutien pour ces tentatives d'innovation. Avec le développement technologique continu et la maturation du marché, Solana devrait connaître davantage de percées et de cas de succès dans le domaine des applications grand public.
Bien que Solana ait réussi à obtenir une part de marché significative dans l'industrie de la blockchain en raison de sa haute capacité de traitement et de ses faibles coûts de transaction, elle fait face à une concurrence féroce de la part d'autres chaînes de blocs émergentes. Une plateforme d'échange, en tant que concurrent potentiel dans l'écosystème EVM, voit le nombre d'adresses actives sur sa chaîne augmenter rapidement. Parallèlement, le montant total des actifs verrouillés (TVL) de Solana, qui a atteint un nouveau sommet historique (, est également confronté à une concurrence rapide de la part de rivaux comme cette plateforme d'échange, dont le montant de financement de l'écosystème a également pour la première fois dépassé celui de Solana au deuxième trimestre.
Bien que Solana ait réalisé des progrès notables en termes de technologie et d'acceptation sur le marché, il 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 les problèmes de MEV et ralentir la croissance de l'état, Solana doit continuer à optimiser son architecture technique et ses protocoles réseau afin de maintenir sa position de leader dans l'industrie de la blockchain.
![Réexpliquer l'architecture technique de Solana : va-t-elle connaître un second printemps ?])https://img-cdn.gateio.im/webp-social/moments-224796bc8e080649730bb8736334abba.webp(
Architecture technique
Solana est connue pour son algorithme POH, son mécanisme de consensus Tower BFT, ainsi que pour son réseau de transmission de données Trubine et sa machine virtuelle SVM, qui offrent un haut TPS et une finalité rapide. Nous allons brièvement présenter le fonctionnement de chacun de ses composants, comment ils atteignent leur objectif de haute performance pour la conception architecturale, ainsi que les inconvénients et les problèmes dérivés de cette conception architecturale.
) algorithme POH
POH###Preuve d'Histoire( est une technologie qui détermine le temps global, elle n'est pas un mécanisme de consensus, mais un algorithme qui détermine l'ordre des transactions. La technologie POH provient de la technique cryptographique de base SHA256. SHA256 est généralement utilisé pour calculer l'intégrité des données, étant donné une entrée X, il y a et il n'y a qu'une seule sortie Y, donc toute modification de X entraînera une Y complètement différente.
Dans la séquence POH de Solana, l'intégrité de l'ensemble de la séquence peut être assurée en appliquant l'algorithme sha256, ce qui garantit également l'intégrité des transactions. Par exemple, si nous regroupons les transactions en 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, tout changement entraînera une modification de la valeur de hachage. Ensuite, ce hachage de bloc sera utilisé comme une partie de X de la prochaine fonction sha256, puis le hachage du prochain bloc sera ajouté, de sorte que le bloc précédent et le bloc suivant soient tous deux déterminés, tout changement entraînera une valeur Y différente.
C'est le sens central de sa technologie Proof of History, le hash du bloc précédent servira de partie à la prochaine fonction sha256, semblable à une chaîne, le dernier Y contenant toujours la preuve historique.
![Revisiter l'architecture technique de Solana : va-t-elle connaître un second printemps ?])https://img-cdn.gateio.im/webp-social/moments-46a028270f3c2da92e7056c17c1d9e16.webp(
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 des leaders appelé Leader Rotation Schedule, un nœud Leader est désigné 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 crée un bloc qui est propagé aux autres nœuds.
Pour éviter les pannes de point unique au niveau du nœud Leader, une limite de temps a été introduite. Dans Solana, l'unité de temps est divisée en epochs, chaque epoch contenant 432 000 slots), chaque slot durant 400 ms. Dans chaque slot, le système de rotation attribue un nœud Leader à chaque slot, et le nœud Leader doit publier un bloc(400ms) dans le temps imparti, sinon, ce slot sera ignoré et un nouveau nœud Leader sera réélu pour le slot suivant.
En général, les nœuds Leader utilisant le mécanisme POH permettent de finaliser toutes les transactions historiques. L'unité de temps de base de Solana est le Slot, et le nœud Leader doit diffuser le bloc dans un slot. Les utilisateurs envoient leurs transactions au Leader via des nœuds RPC, le nœud Leader regroupe et ordonne les transactions, puis exécute la génération du bloc, qui est ensuite propagé aux autres validateurs. Les validateurs doivent parvenir à un consensus sur les transactions et l'ordre dans le bloc via un mécanisme, et le consensus utilisé est 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, qui en est une réalisation concrète. Cet algorithme est toujours lié à l'algorithme POH. Lors du vote sur un bloc, si le vote des validateurs constitue lui-même une transaction, alors le hachage 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 des transactions des utilisateurs et les détails des votes des validateurs.
![Revisiter l'architecture technique de Solana : va-t-elle connaître un second printemps ?])https://img-cdn.gateio.im/webp-social/moments-d55d3cfbc13036ed0d5747abb521cc1a.webp###
Dans l'algorithme Tower BFT, il est stipulé que si tous les validateurs votent pour ce bloc, et que plus de 2/3 des validateurs ont voté pour l'approbation, alors ce bloc peut être confirmé. Le bénéfice de ce mécanisme est qu'il permet d'économiser 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 qui reçoit le bloc 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 du grand nombre de transactions de vote des validateurs et de l'efficacité apportée par la centralisation des nœuds Leader ainsi que du temps de Slot de 400 ms, la taille globale des blocs et la fréquence de création de blocs sont particulièrement élevées. Lors de la propagation de grands blocs, cela exerce également une pression considérable sur le réseau. Solana utilise le mécanisme Turbine pour résoudre le problème de propagation des grands blocs.
( Turbine
Le nœud Leader divise les blocs en sous-blocs appelés shreds par un processus appelé Sharding, dont la taille est spécifiée par l'unité maximale de transmission MTU), représentant la quantité maximale de données pouvant être envoyée d'un nœud à l'autre sans être divisée en unités plus petites, qui est de ###. Ensuite, l'intégrité et la disponibilité des données sont garanties en utilisant un schéma de code d'effacement Reed-Solomon.
En divisant le bloc en quatre Data Shreds, puis pour 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, et ce système peut tolérer jusqu'à 50% de taux de perte. Dans les tests réels, le taux de perte de Solana est d'environ 15%, donc ce système s'adapte très bien à l'architecture actuelle de Solana.
Dans le transfert de données sous-jacent, on envisage généralement d'utiliser les protocoles UDP/TCP. Étant donné que la tolérance de Solana à la perte de paquets est relativement élevée, le protocole UDP est utilisé pour le transfert. Son inconvénient est qu'il ne retransmet pas en cas de perte de paquets, mais son avantage réside dans une vitesse de transfert plus rapide. En revanche, le protocole TCP retransmet plusieurs fois en cas de perte de paquets, ce qui réduit considérablement la vitesse de transfert et le débit. Avec l'utilisation de Reed-Solomon, ce système peut considérablement augmenter le débit de Solana, permettant d'obtenir une augmentation de 9 fois dans un environnement réel.
Après que Turbine ait fragmenté les données, il utilise un mécanisme de propagation multi-niveaux pour la diffusion. Le nœud Leader remettra le bloc à n'importe quel validateur de bloc avant la fin de chaque Slot, puis ce validateur fragmentera le bloc en Shreds et générera un code de correction d'erreur, après quoi ce validateur lancera la propagation Turbine. Il doit d'abord être propagé vers le nœud racine, puis ce nœud racine déterminera quels validateurs se trouvent à quel niveau. Le processus est illustré comme suit :
Créer la liste des nœuds : le nœud racine rassemblera tous les validateurs actifs dans une liste, puis les classera en fonction de la participation de chaque validateur dans le réseau, c'est-à-dire le montant de SOL mis en jeu (, le poids le plus élevé se trouvant au premier niveau, et ainsi de suite.
Groupement de nœuds : Ensuite, chaque validateur 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 depuis le sommet de la liste, en déterminant deux valeurs, la profondeur et la largeur, permet de définir la forme générale de l'arbre. Ce paramètre influencera le taux de propagation des shreds.
Les nœuds ayant une part de droits plus élevée, lors de la classification hiérarchique, se situent à un niveau supérieur, ce qui leur permet d'obtenir à l'avance des shreds complets. À ce moment-là, ils peuvent restaurer des blocs complets, tandis que les nœuds des niveaux inférieurs, en raison des pertes lors du transfert, verront leur probabilité d'obtenir des shreds complets diminuer. Si ces shreds ne suffisent pas à construire des fragments complets, le Leader demandera un retransfert direct. À ce stade, le transfert de données se dirigera vers l'intérieur de l'arbre, et les nœuds de la première couche auront déjà construit une confirmation complète du bloc. Plus le temps nécessaire pour que les validateurs des niveaux inférieurs terminent la construction du bloc et votent est long.
L'idée de ce mécanisme est similaire à celle du mécanisme à nœud unique du nœud Leader. Au cours du processus de propagation des blocs, certains nœuds prioritaires existent, ces nœuds obtiennent d'abord les fragments shreds pour reconstruire 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 grâce à son mécanisme POH, son consensus Tower BFT et son mécanisme de diffusion de données Turbine. Cependant, SVM, en tant que machine virtuelle pour la transformation d'état, si le nœud Leader est lent dans l'exécution des transactions, cela peut réduire le débit global du système. Ainsi, pour 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, les instructions se composent de 4 parties, comprenant l'ID du programme, les instructions du programme et la liste des comptes pour la lecture/écriture des données. En déterminant si le compte actuel est en état de lecture ou d'écriture et si les opérations à effectuer pour le changement 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 aussi l'une des raisons pour lesquelles les exigences pour les validateurs de Solana sont très élevées, car il est demandé aux GPU/CPU des validateurs de pouvoir supporter SIMD### les instructions multiples de données( et la capacité d'extension vectorielle avancée AVX.
Développement écologique
Dans le cadre du développement actuel de l'écosystème Solana, l'accent est de plus en plus mis sur l'utilité réelle, comme Blinks, Actions et même Solana Mobile, tandis que la direction de développement des applications soutenue par l'officiel.