Analyse de l'architecture technique de Solana : un deuxième printemps ?

Solana est une plateforme de blockchain haute performance, utilisant une architecture technologique unique pour réaliser un haut débit et une faible latence. Sa technologie clé comprend l'algorithme Proof of History (POH) qui assure l'ordre des transactions et une horloge globale, le programme de rotation des leaders et le mécanisme de consensus Tower BFT qui améliorent le taux de production des blocs. Le mécanisme Turbine optimise la propagation des gros 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. Tout cela fait partie de la conception architecturale de Solana pour réaliser des performances élevées, mais cela a également entraîné certains problèmes, tels que les pannes de réseau, les échecs de transactions, le problème MEV, la croissance rapide de l'état et les problèmes de centralisation.

L'écosystème Solana se développe rapidement, avec des indicateurs de données qui ont connu une forte croissance au cours du premier semestre, notamment dans les domaines de DeFi, des infrastructures, de GameFi/NFT, de DePin/IA et des applications consommateurs. Les TPS élevés de Solana et sa stratégie axée sur les applications consommateurs, ainsi qu'un environnement écologique moins impactant, offrent de nombreuses opportunités d'entrepreneuriat pour les entrepreneurs et les développeurs. En ce qui concerne les applications consommateurs, Solana a démontré sa vision de 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 consommateurs, Solana s'engage à 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 de fitness et sociale novatrice en combinant la blockchain et la technologie mobile. Bien que de nombreuses applications consommateurs 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 ultérieur et la maturation du marché, Solana est bien positionné pour réaliser davantage de percées et de cas de succès dans le domaine des applications consommateurs.

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 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 son nombre d'adresses actives sur la chaîne augmenter rapidement. Pendant ce temps, le volume total des actifs verrouillés (TVL) de Solana a atteint un niveau record de (, mais des concurrents comme Base s'emparent rapidement de parts de marché, et le montant du financement de l'écosystème Base a également dépassé pour la première fois celui de Solana au cours du deuxième trimestre.

Bien que Solana ait réalisé certains succès en termes de technologie et d'acceptation sur le 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 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.

Architecture technique

Solana est connue pour son algorithme POH, son mécanisme de consensus Tower BFT, ainsi que 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 l'objectif de haute performance pour la conception architecturale, ainsi que les inconvénients et les problèmes dérivés de cette conception architecturale.

![Revisiter l'architecture technique de Solana : va-t-elle connaître un second printemps ?])https://img-cdn.gateio.im/webp-social/moments-224796bc8e080649730bb8736334abba.webp(

) algorithme POH

POH###Preuve d'Histoire( est une technologie qui permet de déterminer 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'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 dans un bloc et générons la valeur de hachage sha256 correspondante, alors les transactions dans ce bloc sont confirmées, et toute modification entraînera un changement de la valeur de hachage. Ensuite, ce hachage de bloc servira de partie de X pour la prochaine fonction sha256, ajoutant le hachage du prochain bloc. Ainsi, le bloc précédent et le prochain bloc sont tous deux confirmés, et toute modification entraînera un Y différent.

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 contient toujours la preuve de l'histoire.

![Une nouvelle explication de l'architecture technique de Solana : va-t-elle connaître un nouvel essor ?])https://img-cdn.gateio.im/webp-social/moments-46a028270f3c2da92e7056c17c1d9e16.webp(

Dans le diagramme 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 élu 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 donc é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 dans chaque slot, et le nœud Leader doit publier le bloc(400ms) dans le temps imparti de ce slot, sinon ce slot sera sauté et un nouveau nœud Leader sera élu pour le slot suivant.

En général, les nœuds Leader utilisant le mécanisme POH peuvent rendre toutes les transactions historiques définitives. L'unité de temps fondamentale de Solana est le Slot, le nœud Leader doit diffuser le bloc dans un slot. Les utilisateurs envoient des transactions au Leader via des nœuds RPC, le nœud Leader emballe et trie les transactions, puis exécute la génération du bloc, qui est ensuite diffusé aux autres validateurs. Les validateurs doivent parvenir à un consensus sur les transactions et l'ordre à l'intérieur du bloc, et le mécanisme de 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 est une réalisation concrète de celui-ci, cet algorithme étant toujours lié à l'algorithme POH. Lors du vote sur un bloc, si le vote du validateurs est lui-même une transaction, alors le hachage du bloc formé par la transaction de l'utilisateur et celle du validateurs peut également servir de preuve historique, permettant de confirmer de manière unique les détails de la transaction de chaque utilisateur ainsi que les détails du vote du validateurs.

![Réexpliquer 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 la diffusion 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 plus d'une fois.

Dans Solana, en raison d'un grand nombre de validateurs votant sur les transactions 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 production des blocs sont particulièrement élevées. Lors de la propagation de grands blocs, cela peut également exercer une pression considérable 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 les blocs en sous-blocs appelés shreds par un processus appelé Sharding, dont la taille est spécifiée par l'unité de transmission maximale MTU), permettant d'envoyer la quantité maximale de données de ### d'un nœud à l'autre sans avoir à les diviser en unités plus petites. 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 éviter la perte et la corruption de données lors du transfert, le codage Reed-Solomon est utilisé pour coder les quatre paquets en huit paquets, 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.

Dans le transfert de données de base, on envisage généralement d'utiliser les protocoles UDP/TCP. Étant donné que Solana a une tolérance relativement élevée à la perte de paquets, 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 Reed-Solomon, ce système peut augmenter significativement le débit de Solana, dans des environnements réels, le débit peut être multiplié par 9.

Après le découpage des données par Turbine, un mécanisme de propagation multicouche est utilisé. Le nœud Leader remettra le bloc à n'importe quel validateur de bloc avant la fin de chaque Slot, puis ce validateur découpera le bloc en Shreds et générera un code de correction d'erreur. Ce validateur activera ensuite la propagation Turbine. La propagation doit d'abord atteindre le nœud racine, puis ce nœud racine déterminera quels validateurs se trouvent à quel niveau. Le processus est comme suit :

1. Créer une liste de nœuds : le nœud racine compilera tous les validateurs actifs dans une liste, puis triera chaque validateurs en fonction de leur participation dans le réseau (, c'est-à-dire le nombre de SOL mis en jeu ). Ceux avec un poids plus élevé seront placés au premier niveau, et ainsi de suite.

2. 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.

3. Formation des couches : Divisez les nœuds en couches à partir du haut de la liste. En déterminant les valeurs de profondeur et de largeur, vous pouvez déterminer 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 élevée, lors de la hiérarchisation, se retrouvent à un niveau supérieur, ce qui leur permet d'obtenir à l'avance des shreds complets. À ce moment-là, ils peuvent récupérer 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 exigera que le Leader retransmette directement. À ce stade, le transfert de données se dirigera vers l'intérieur de l'arbre, et les nœuds du premier niveau auront déjà construit une confirmation de bloc complet, ce qui signifie que plus le temps nécessaire pour que les validateurs des niveaux inférieurs achèvent la construction du bloc et votent sera long.

Cette mécanique est semblable 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 des blocs complets afin d'atteindre un consensus de vote. Pousser la redondance à un niveau plus profond peut considérablement accélérer le processus de Finalité, tout en maximisant le débit et l'efficacité. En réalité, les premières couches peuvent représenter 2/3 des nœuds, rendant par conséquent 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, au consensus Tower BFT et au mécanisme de propagation des données Turbine. Cependant, en tant que machine virtuelle pour la transition d'état, si le nœud Leader est lent lors de l'exécution des transactions, la vitesse de traitement de la SVM diminuera, ce qui réduira 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.

![Réexpliquer l'architecture technique de Solana : va-t-elle connaître un second printemps ?])https://img-cdn.gateio.im/webp-social/moments-9fd8693259e2864d6978d2b4e8ef2e85.webp###

Dans SVM, les instructions sont composées de quatre parties, incluant 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 changement d'état sont en conflit, il est possible de permettre la parallélisation des instructions de transaction du compte 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 demandé aux validateurs que leur GPU/CPU puisse supporter SIMD( des instructions multiples sur des données uniques) ainsi que des capacités d'extension vectorielle avancées AVX.

Développement écologique

Dans le processus de développement actuel de l'écosystème Solana, il y a une tendance croissante vers l'utilité pratique, comme Blinks et Actions, voire Solana Mobile, tandis que la direction de développement des applications soutenues par l'officiel tend également davantage vers les applications pour consommateurs, plutôt que vers l'infrastructure.