Réexamen de 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 fondamentale comprend l'algorithme Proof of History (POH) qui garantit l'ordre des transactions et une horloge globale, le Leader Rotation Schedule et le mécanisme de consensus Tower BFT qui augmentent la vitesse de création des 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. Tous ces éléments constituent la conception architecturale de Solana pour réaliser des performances élevées, mais ils ont également engendré certains problèmes, tels que des pannes de réseau, des échecs de transaction, des problèmes MEV, une croissance excessive de l'état et des problèmes de centralisation, que nous mettons également en avant dans cet article.

L'écosystème de 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 la DeFi, des infrastructures, du GameFi/NFT, du DePin/AI et des applications pour consommateurs. Le haut TPS de Solana, sa stratégie axée sur les applications pour consommateurs et l'environnement écologique, dont l'effet de marque est relativement faible, offrent de nombreuses opportunités aux entrepreneurs et aux développeurs. Dans le domaine des applications pour consommateurs, Solana montre 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 destinées aux 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 combinent 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 pour consommateurs soient encore à la recherche du meilleur modèle commercial et de la meilleure position sur le marché, la plateforme technologique et le soutien de l'écosystème fournis par Solana offrent sans aucun doute un solide soutien à ces tentatives d'innovation. Avec le développement technologique continu et la maturation du marché, Solana est bien placée pour réaliser davantage de percées et de cas de succès dans le domaine des applications pour 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 également face à une concurrence féroce de la part d'autres nouvelles chaînes publiques émergentes. Base, en tant que rival 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 fonds verrouillés dans le domaine DeFi de Solana ait atteint un nouveau record historique de (TVL), des concurrents comme Base s'emparent aussi rapidement de parts de marché, et le montant de 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 tels que 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 continuellement 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 le 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 ces composants fonctionne, comment ils contribuent à l'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 architecturale.

algorithme POH

POH(Preuve d'Histoire) est une technologie qui détermine le temps global, qui 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 fondamentale SHA256. SHA256 est généralement utilisé pour calculer l'intégrité des données, en donnant une entrée X, il n'y a qu'une seule sortie Y unique, 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, ce qui détermine é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 de ce bloc sont confirmées. Toute modification entraînera un changement de la valeur de hachage, et ensuite, cette valeur de hachage du bloc servira de partie de X pour la prochaine fonction sha256, ajoutant ensuite la valeur de hachage du bloc suivant. Ainsi, le bloc précédent et le bloc suivant sont tous deux confirmés, et toute modification entraînera une nouvelle valeur Y différente.

C'est le sens central de sa technologie Proof of History, le hash du bloc précédent sera utilisé comme partie de la prochaine fonction sha256, semblable à une chaîne, le dernier Y contient toujours la preuve de l'histoire.

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 des leaders 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 ainsi une séquence POH, puis un bloc est créé et propagé aux autres nœuds.

Pour éviter le point de défaillance unique 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. Dans chaque slot, le système de rotation attribue un nœud Leader, qui doit publier un bloc)400ms( dans le temps imparti du slot, sinon ce slot sera sauté et un nouveau nœud Leader sera élu pour le prochain slot.

Dans l'ensemble, les nœuds Leader utilisant le mécanisme POH permettent de confirmer toutes les transactions historiques. L'unité de temps fondamentale de Solana est le Slot, le nœud Leader doit diffuser le bloc dans un slot. Les utilisateurs envoient les transactions au Leader via le nœud RPC, le nœud Leader empaquette les transactions, les trie, puis exécute et génère le bloc, le bloc est ensuite propagé aux autres validateurs. Les validateurs doivent parvenir à un consensus sur les transactions et l'ordre dans le bloc grâce à 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 provient de l'algorithme de consensus BFT, qui en est une mise en œuvre concrète. Cet algorithme est toujours lié à l'algorithme POH. Lors de la votation sur les blocs, si le vote d'un 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 l'utilisateur ainsi que ceux du vote du validateur.

![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 é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 le flood de blocs, où un validateur reçoit un bloc puis l'envoie 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 du 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 400ms, cela entraîne une taille de bloc globale 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

Le nœud Leader divise le bloc en sous-blocs appelés shreds grâce à 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 entre un nœud et le suivant sans avoir à les diviser en unités plus petites, soit (. Ensuite, l'intégrité et la disponibilité des données sont garanties par l'utilisation d'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 encoder les quatre paquets en huit paquets. Ce système peut tolérer un taux de perte pouvant atteindre 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éexpliquer l'architecture technique de Solana : va-t-elle connaître un second printemps ?])https://img-cdn.gateio.im/webp-social/moments-e9bc35d0c790496c59c20979e5af1491.webp(

Dans le transfert de données de niveau inférieur, on considère généralement l'utilisation des 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 de manière significative le débit de Solana, et dans un environnement réel, le débit peut augmenter jusqu'à 9 fois.

Après que Turbine a fragmenté les données, il utilise un mécanisme de propagation en plusieurs couches 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 des codes de correction d'erreurs. Ce validateur commencera ensuite la propagation de Turbine. Tout d'abord, il doit se propager vers le nœud racine, puis ce nœud racine déterminera quels validateurs se trouvent à quel niveau. Le processus est illustré comme suit :

1. 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 le nombre de SOL mis en jeu ), en ordonnant ceux ayant un poids plus élevé au premier niveau, et ainsi de suite.

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

3. Formation des couches : en divisant les nœuds en couches à partir du sommet de la liste, en déterminant les valeurs de profondeur et de largeur, on peut déterminer la forme générale de l'arbre. Ce paramètre influencera la vitesse de propagation des shreds.

Les nœuds ayant une part de droits élevée, lors de la hiérarchisation, 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, il sera demandé au Leader de retransmettre directement. À ce stade, la transmission des 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 de bloc complète. Plus le temps pour que les validateurs des niveaux inférieurs complètent la construction du bloc et votent sera long.

Cette mécanique est similaire au mécanisme à nœud unique d'un nœud Leader. Dans le processus de propagation des blocs, il existe également certains nœuds prioritaires, ces nœuds obtiennent d'abord des fragments shreds pour former un bloc complet afin d'atteindre le consensus de vote. En poussant la redondance à un niveau plus profond, cela 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, donc le vote des nœuds suivants devient 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 diffusion de données Turbine. Cependant, SVM en tant que machine virtuelle pour la transition d'état, si le nœud Leader est lent dans l'exécution des transactions, cela peut réduire le débit de l'ensemble du système. Par conséquent, 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 une liste de 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 de modification d'état sont en conflit, il est possible de rendre parallèles les 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 élevées, car ils doivent avoir des GPU/CPU capables de supporter les instructions SIMD) de type SIMD### ainsi que les capacités d'extensions vectorielles avancées AVX.

Écosystème