Analyse de l'architecture technique de Solana : coexistence de la haute performance et des défis, un écosystème en plein essor face à de nouvelles opportunités.
Redécouvrir l'architecture technique de Solana : va-t-elle connaître un second printemps ?
Solana est une plateforme de blockchain haute performance, utilisant une architecture technique unique pour réaliser un haut débit et une faible latence. Sa technologie de base inclut l'algorithme Proof of History (POH) qui assure l'ordre des transactions et une horloge globale, le calendrier de rotation des leaders et le mécanisme de consensus Tower BFT qui améliorent le taux de génération de blocs. Le mécanisme Turbine optimise la propagation des grands blocs grâce à l'encodage 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 tous des éléments de conception architecturale de Solana qui réalisent une haute performance, mais cela a également entraîné certains problèmes, tels que des pannes de réseau, des échecs de transaction, des problèmes de MEV, une croissance trop rapide de l'état et des problèmes de centralisation, que nous mettons également en avant dans cet article.
L'écosystème Solana se développe rapidement, avec des indicateurs de données qui ont fortement progressé au cours du premier semestre, en particulier dans les domaines de DeFi, des infrastructures, de GameFi/NFT, de DePin/IA et des applications grand public. La haute TPS de Solana et sa stratégie axée sur les applications grand public, ainsi qu'un environnement écologique avec un effet de marque relativement faible, offrent aux entrepreneurs et aux développeurs de nombreuses opportunités de création. En ce qui concerne les applications grand public, Solana montre sa vision de promouvoir l'application de la technologie blockchain dans des domaines plus larges. En soutenant des initiatives telles que 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, une application de fitness combine blockchain et technologie mobile pour offrir aux utilisateurs une expérience novatrice en matière de fitness et de socialisation. Bien que de nombreuses applications grand public explorent encore les meilleurs modèles économiques et le positionnement sur le marché, la plateforme technologique et le soutien de l'écosystème offerts par Solana fournissent sans aucun doute un solide soutien à ces tentatives d'innovation. Avec le développement continu de la technologie et la maturation du marché, Solana est prometteuse pour réaliser davantage de percées et de succès dans le domaine des applications grand public.
Bien que Solana ait acquis 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 nouvelles chaînes publiques émergentes. Base, en tant que concurrent potentiel dans l'écosystème EVM, voit le nombre d'adresses actives sur sa chaîne croître rapidement. Pendant ce temps, le montant total des actifs verrouillés dans le domaine DeFi de Solana, (TVL), bien qu'ayant atteint un niveau record, est également rapidement concurrencé par des rivaux tels que Base, dont le montant de financement dans l'écosystème a également dépassé celui de Solana pour la première fois au cours du deuxième trimestre.
Bien que Solana ait réalisé certains progrès sur le plan technique et de l'acceptation du marché, elle doit continuer à innover et à s'améliorer pour faire face aux défis posés par des concurrents comme Base. 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 réseau afin de maintenir sa position de leader dans l'industrie de la blockchain.
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 la 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 contribuent à atteindre l'objectif de haute performance dans la conception architecturale, ainsi que les inconvénients et les problèmes dérivés qui en résultent dans cette conception architecturale.
algorithme POH
POH(Preuve d'Histoire) 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, étant donné une entrée X, 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'application de l'algorithme sha256 permet d'assurer l'intégrité de l'ensemble de la séquence, et donc de déterminer l'intégrité des transactions qu'elle contient. Par exemple, si nous regroupons les transactions dans un bloc et générons la valeur de hachage sha256 correspondante, alors les transactions dans ce bloc sont confirmées, toute modification entraînera un changement de la valeur de hachage. Ensuite, cette valeur de hachage de bloc sera utilisée comme une partie de X dans la prochaine fonction sha256, en y ajoutant la valeur de hachage du prochain bloc, alors le bloc précédent et le prochain bloc seront tous deux confirmés, toute modification entraînera une nouvelle valeur Y différente.
Ceci est la signification centrale de sa technologie Proof of History, le hash du bloc précédent servira de partie de la fonction sha256 du suivant, semblable à une chaîne, le plus récent Y inclut toujours la preuve de l'histoire.
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 généré 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 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 pour chaque slot, le nœud Leader doit publier un bloc)400ms( dans le temps imparti du slot, sinon, ce slot sera sauté et le nœud Leader pour le slot suivant sera réélu.
Dans l'ensemble, le nœud Leader utilisant le mécanisme POH permet de finaliser 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 les transactions au Leader via un nœud RPC, le nœud Leader regroupe et trie les transactions, puis exécute et génère le bloc, le bloc est ensuite propagé aux autres validateurs, qui doivent parvenir à un consensus sur les transactions et l'ordre dans le bloc, ce consensus utilise le mécanisme de consensus Tower BFT.
) Mécanisme de consensus Tower BFT
Le protocole de consensus Tower BFT est basé sur l'algorithme de consensus BFT, qui en est une implémentation concrète. Cet algorithme est toujours lié à l'algorithme POH. Lors du vote sur les blocs, si le vote du validateur est lui-même une transaction, alors le hachage du bloc formé par la transaction de l'utilisateur et celle du validateur peut également servir de preuve historique, permettant de confirmer de manière unique les détails de la transaction de chaque utilisateur et 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é pour l'approbation, alors ce bloc peut être confirmé. L'avantage 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 le flooding de blocs, où un validateurs reçoit un bloc puis l'envoie aux validateurs environnants, ce qui entraîne une grande redondance dans le réseau, car un validateurs reçoit le même bloc plus d'une fois.
Dans Solana, en raison du grand nombre de transactions de vote des validateurs, et en raison de l'efficacité apportée par la centralisation des nœuds Leaders ainsi que du temps de Slot de 400 ms, cela entraîne une taille de bloc global et une fréquence de production de blocs particulièrement élevées. Les grands blocs, lors de leur propagation, peuvent également exercer une forte pression sur le réseau. Solana utilise le mécanisme Turbine pour résoudre le problème de propagation des grands blocs.
Turbine
Les nœuds Leader divisent les blocs en sous-blocs appelés shreds par un processus connu sous le nom de Sharding, dont la taille spécifiée est de l'unité de transmission maximale MTU###, permettant d'envoyer la quantité maximale de données sans avoir besoin de les diviser en unités plus petites de ( d'un nœud à l'autre. Ensuite, l'intégrité et la disponibilité des données sont garanties en utilisant le schéma de codes d'effacement Reed-solomon.
En divisant le bloc en quatre Data Shreds, puis en utilisant le codage Reed-Solomon pour coder les quatre paquets en huit paquets afin de prévenir la perte et la corruption de données pendant le transport, ce système peut tolérer un taux de perte allant jusqu'à 50 %. Dans les 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.
![Réexploration de 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 transfert de données de base, on considère généralement l'utilisation des protocoles UDP/TCP. Étant donné que Solana a une tolérance relativement élevée aux pertes 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 une vitesse de transfert plus rapide. En revanche, le protocole TCP retransmet plusieurs fois en cas de perte de paquet, ce qui réduit considérablement la vitesse de transfert et le débit. Avec Reed-Solomon, ce système peut augmenter considérablement le débit de Solana, avec une augmentation jusqu'à 9 fois dans des environnements réels.
Après que Turbine ait fragmenté les données, il utilise un mécanisme de propagation multicouche pour les transmettre. 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. Ce validateur démarrera ensuite la propagation de Turbine. Il doit d'abord 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 intérêts de chaque validateur dans le réseau, c'est-à-dire la quantité de SOL mise en jeu ), et ceux ayant un poids plus élevé sont placés au premier niveau, et ainsi de suite.
Groupement des 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 : en divisant les nœuds en couches à partir du sommet de la liste, en déterminant deux valeurs de profondeur et de largeur, on peut établir 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 élevée, lors de la classification hiérarchique, se trouvent à un niveau supérieur, ce qui leur permet d'obtenir à l'avance des shreds complets. À ce moment-là, ils peuvent restaurer le bloc complet, tandis que les nœuds des niveaux inférieurs, en raison des pertes de transmission, verront leur probabilité d'obtenir des shreds complets diminuer. Si ces shreds ne suffisent pas à construire des fragments complets, cela demandera au Leader de retransmettre directement. À ce moment-là, le transfert de données se fera vers l'intérieur de l'arbre, et les nœuds du premier niveau ont déjà construit la confirmation du bloc complet. Plus le temps nécessaire pour que les validateurs des niveaux inférieurs complètent la construction du bloc et votent est long.
Cette approche est similaire au mécanisme à nœud unique du nœud Leader. Dans le processus de propagation des blocs, il existe également certains nœuds prioritaires qui obtiennent d'abord les fragments shreds pour former un bloc complet 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 réalité, les premières couches peuvent représenter 2/3 des nœuds, donc le vote des nœuds suivants devient 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 diffusion de données Turbine. Cependant, en tant que machine virtuelle pour la transformation d'état, si le nœud Leader est lent dans l'exécution des transactions, la vitesse de traitement de la SVM peut réduire le débit de tout le système. C'est pourquoi 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 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 des comptes qui n'ont pas de 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 nécessaire que le GPU/CPU des validateurs puisse prendre en charge la SIMD) et les capacités AVX d'extension vectorielle avancée.
![Réexpliquer l'architecture technique de Solana : va-t-elle connaître un second printemps ?]###https://img-cdn.gateio.im/webp-social/moments-e9bc35d0c790496c59c20979e5af1491.webp(
Développement écologique
Dans le cadre du développement actuel de l'écosystème Solana, il s'oriente de plus en plus vers une utilité réelle, comme certains projets de smartphones ainsi que certaines boutiques d'applications ou même certains appareils mobiles. De plus, la direction de développement des applications soutenues par l'officiel tend également à se concentrer sur les applications consommateur plutôt que sur une compétition infinie pour les infrastructures. Actuellement, les performances de Solana sont suffisantes.
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.
10 J'aime
Récompense
10
5
Partager
Commentaire
0/400
OnchainArchaeologist
· 07-08 02:05
Quand ces vieux problèmes seront-ils résolus ?
Voir l'originalRépondre0
WalletDoomsDay
· 07-05 08:55
sol est toujours To the moon sans bouger, allons-y
Voir l'originalRépondre0
MetaNomad
· 07-05 08:50
Qui parie encore sur sol ? Continuez à tout mettre !
Voir l'originalRépondre0
screenshot_gains
· 07-05 08:34
SOL bull à fond
Voir l'originalRépondre0
TokenDustCollector
· 07-05 08:27
J'ai déjà entré dans une position, maintenant j'attends To the moon.
Analyse de l'architecture technique de Solana : coexistence de la haute performance et des défis, un écosystème en plein essor face à de nouvelles opportunités.
Redécouvrir l'architecture technique de Solana : va-t-elle connaître un second printemps ?
Solana est une plateforme de blockchain haute performance, utilisant une architecture technique unique pour réaliser un haut débit et une faible latence. Sa technologie de base inclut l'algorithme Proof of History (POH) qui assure l'ordre des transactions et une horloge globale, le calendrier de rotation des leaders et le mécanisme de consensus Tower BFT qui améliorent le taux de génération de blocs. Le mécanisme Turbine optimise la propagation des grands blocs grâce à l'encodage 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 tous des éléments de conception architecturale de Solana qui réalisent une haute performance, mais cela a également entraîné certains problèmes, tels que des pannes de réseau, des échecs de transaction, des problèmes de MEV, une croissance trop rapide de l'état et des problèmes de centralisation, que nous mettons également en avant dans cet article.
L'écosystème Solana se développe rapidement, avec des indicateurs de données qui ont fortement progressé au cours du premier semestre, en particulier dans les domaines de DeFi, des infrastructures, de GameFi/NFT, de DePin/IA et des applications grand public. La haute TPS de Solana et sa stratégie axée sur les applications grand public, ainsi qu'un environnement écologique avec un effet de marque relativement faible, offrent aux entrepreneurs et aux développeurs de nombreuses opportunités de création. En ce qui concerne les applications grand public, Solana montre sa vision de promouvoir l'application de la technologie blockchain dans des domaines plus larges. En soutenant des initiatives telles que 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, une application de fitness combine blockchain et technologie mobile pour offrir aux utilisateurs une expérience novatrice en matière de fitness et de socialisation. Bien que de nombreuses applications grand public explorent encore les meilleurs modèles économiques et le positionnement sur le marché, la plateforme technologique et le soutien de l'écosystème offerts par Solana fournissent sans aucun doute un solide soutien à ces tentatives d'innovation. Avec le développement continu de la technologie et la maturation du marché, Solana est prometteuse pour réaliser davantage de percées et de succès dans le domaine des applications grand public.
Bien que Solana ait acquis 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 nouvelles chaînes publiques émergentes. Base, en tant que concurrent potentiel dans l'écosystème EVM, voit le nombre d'adresses actives sur sa chaîne croître rapidement. Pendant ce temps, le montant total des actifs verrouillés dans le domaine DeFi de Solana, (TVL), bien qu'ayant atteint un niveau record, est également rapidement concurrencé par des rivaux tels que Base, dont le montant de financement dans l'écosystème a également dépassé celui de Solana pour la première fois au cours du deuxième trimestre.
Bien que Solana ait réalisé certains progrès sur le plan technique et de l'acceptation du marché, elle doit continuer à innover et à s'améliorer pour faire face aux défis posés par des concurrents comme Base. 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 réseau afin de maintenir sa position de leader dans l'industrie de la blockchain.
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 la 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 contribuent à atteindre l'objectif de haute performance dans la conception architecturale, ainsi que les inconvénients et les problèmes dérivés qui en résultent dans cette conception architecturale.
algorithme POH
POH(Preuve d'Histoire) 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, étant donné une entrée X, 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'application de l'algorithme sha256 permet d'assurer l'intégrité de l'ensemble de la séquence, et donc de déterminer l'intégrité des transactions qu'elle contient. Par exemple, si nous regroupons les transactions dans un bloc et générons la valeur de hachage sha256 correspondante, alors les transactions dans ce bloc sont confirmées, toute modification entraînera un changement de la valeur de hachage. Ensuite, cette valeur de hachage de bloc sera utilisée comme une partie de X dans la prochaine fonction sha256, en y ajoutant la valeur de hachage du prochain bloc, alors le bloc précédent et le prochain bloc seront tous deux confirmés, toute modification entraînera une nouvelle valeur Y différente.
Ceci est la signification centrale de sa technologie Proof of History, le hash du bloc précédent servira de partie de la fonction sha256 du suivant, semblable à une chaîne, le plus récent Y inclut toujours la preuve de l'histoire.
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 généré 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 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 pour chaque slot, le nœud Leader doit publier un bloc)400ms( dans le temps imparti du slot, sinon, ce slot sera sauté et le nœud Leader pour le slot suivant sera réélu.
Dans l'ensemble, le nœud Leader utilisant le mécanisme POH permet de finaliser 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 les transactions au Leader via un nœud RPC, le nœud Leader regroupe et trie les transactions, puis exécute et génère le bloc, le bloc est ensuite propagé aux autres validateurs, qui doivent parvenir à un consensus sur les transactions et l'ordre dans le bloc, ce consensus utilise le mécanisme de consensus Tower BFT.
) Mécanisme de consensus Tower BFT
Le protocole de consensus Tower BFT est basé sur l'algorithme de consensus BFT, qui en est une implémentation concrète. Cet algorithme est toujours lié à l'algorithme POH. Lors du vote sur les blocs, si le vote du validateur est lui-même une transaction, alors le hachage du bloc formé par la transaction de l'utilisateur et celle du validateur peut également servir de preuve historique, permettant de confirmer de manière unique les détails de la transaction de chaque utilisateur et 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é pour l'approbation, alors ce bloc peut être confirmé. L'avantage 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 le flooding de blocs, où un validateurs reçoit un bloc puis l'envoie aux validateurs environnants, ce qui entraîne une grande redondance dans le réseau, car un validateurs reçoit le même bloc plus d'une fois.
Dans Solana, en raison du grand nombre de transactions de vote des validateurs, et en raison de l'efficacité apportée par la centralisation des nœuds Leaders ainsi que du temps de Slot de 400 ms, cela entraîne une taille de bloc global et une fréquence de production de blocs particulièrement élevées. Les grands blocs, lors de leur propagation, peuvent également exercer une forte pression sur le réseau. Solana utilise le mécanisme Turbine pour résoudre le problème de propagation des grands blocs.
Turbine
Les nœuds Leader divisent les blocs en sous-blocs appelés shreds par un processus connu sous le nom de Sharding, dont la taille spécifiée est de l'unité de transmission maximale MTU###, permettant d'envoyer la quantité maximale de données sans avoir besoin de les diviser en unités plus petites de ( d'un nœud à l'autre. Ensuite, l'intégrité et la disponibilité des données sont garanties en utilisant le schéma de codes d'effacement Reed-solomon.
En divisant le bloc en quatre Data Shreds, puis en utilisant le codage Reed-Solomon pour coder les quatre paquets en huit paquets afin de prévenir la perte et la corruption de données pendant le transport, ce système peut tolérer un taux de perte allant jusqu'à 50 %. Dans les 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.
![Réexploration de 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 transfert de données de base, on considère généralement l'utilisation des protocoles UDP/TCP. Étant donné que Solana a une tolérance relativement élevée aux pertes 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 une vitesse de transfert plus rapide. En revanche, le protocole TCP retransmet plusieurs fois en cas de perte de paquet, ce qui réduit considérablement la vitesse de transfert et le débit. Avec Reed-Solomon, ce système peut augmenter considérablement le débit de Solana, avec une augmentation jusqu'à 9 fois dans des environnements réels.
Après que Turbine ait fragmenté les données, il utilise un mécanisme de propagation multicouche pour les transmettre. 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. Ce validateur démarrera ensuite la propagation de Turbine. Il doit d'abord 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 intérêts de chaque validateur dans le réseau, c'est-à-dire la quantité de SOL mise en jeu ), et ceux ayant un poids plus élevé sont placés au premier niveau, et ainsi de suite.
Groupement des 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 : en divisant les nœuds en couches à partir du sommet de la liste, en déterminant deux valeurs de profondeur et de largeur, on peut établir 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 élevée, lors de la classification hiérarchique, se trouvent à un niveau supérieur, ce qui leur permet d'obtenir à l'avance des shreds complets. À ce moment-là, ils peuvent restaurer le bloc complet, tandis que les nœuds des niveaux inférieurs, en raison des pertes de transmission, verront leur probabilité d'obtenir des shreds complets diminuer. Si ces shreds ne suffisent pas à construire des fragments complets, cela demandera au Leader de retransmettre directement. À ce moment-là, le transfert de données se fera vers l'intérieur de l'arbre, et les nœuds du premier niveau ont déjà construit la confirmation du bloc complet. Plus le temps nécessaire pour que les validateurs des niveaux inférieurs complètent la construction du bloc et votent est long.
Cette approche est similaire au mécanisme à nœud unique du nœud Leader. Dans le processus de propagation des blocs, il existe également certains nœuds prioritaires qui obtiennent d'abord les fragments shreds pour former un bloc complet 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 réalité, les premières couches peuvent représenter 2/3 des nœuds, donc le vote des nœuds suivants devient 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 diffusion de données Turbine. Cependant, en tant que machine virtuelle pour la transformation d'état, si le nœud Leader est lent dans l'exécution des transactions, la vitesse de traitement de la SVM peut réduire le débit de tout le système. C'est pourquoi 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 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 des comptes qui n'ont pas de 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 nécessaire que le GPU/CPU des validateurs puisse prendre en charge la SIMD) et les capacités AVX d'extension vectorielle avancée.
![Réexpliquer l'architecture technique de Solana : va-t-elle connaître un second printemps ?]###https://img-cdn.gateio.im/webp-social/moments-e9bc35d0c790496c59c20979e5af1491.webp(
Développement écologique
Dans le cadre du développement actuel de l'écosystème Solana, il s'oriente de plus en plus vers une utilité réelle, comme certains projets de smartphones ainsi que certaines boutiques d'applications ou même certains appareils mobiles. De plus, la direction de développement des applications soutenues par l'officiel tend également à se concentrer sur les applications consommateur plutôt que sur une compétition infinie pour les infrastructures. Actuellement, les performances de Solana sont suffisantes.