Analyse de l'architecture technique et du développement de l'écosystème Solana

Solana est une plateforme blockchain haute performance, utilisant une architecture technique unique pour réaliser un haut débit et une faible latence. Ses technologies clés incluent l'algorithme Proof of History (POH) qui assure l'ordre des transactions et une horloge mondiale, le calendrier de rotation des leaders et le mécanisme de consensus Tower BFT qui augmentent le taux de production des blocs. Le mécanisme Turbine optimise la propagation des gros 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 de l'architecture de Solana pour réaliser des performances élevées, mais cela a également apporté certains problèmes, tels que les pannes de réseau, les échecs de transaction, les problèmes 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 tous connu une forte croissance 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. Le TPS élevé de Solana et sa stratégie orientée vers les applications grand public, ainsi qu'un environnement écologique avec un effet de marque relativement faible, offrent de nombreuses opportunités aux entrepreneurs et aux développeurs. Dans le domaine des applications grand public, Solana a démontré sa vision pour promouvoir l'application de la technologie blockchain dans des domaines plus vastes. En soutenant des initiatives comme Solana Mobile et en construisant des SDK spécialement pour les applications grand public, Solana s'engage à intégrer la technologie blockchain dans les applications quotidiennes, afin d'améliorer l'acceptation et la commodité pour les utilisateurs.

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. Base, en tant que concurrent potentiel dans l'écosystème EVM, voit le nombre d'adresses actives sur sa chaîne croître rapidement. Parallèlement, le montant total des actifs verrouillés dans le domaine DeFi de Solana, ( TVL ), bien qu'atteignant un niveau historique, est également rapidement pris en charge par des concurrents comme Base, qui a également dépassé pour la première fois le montant de financement de Solana au cours du deuxième trimestre.

Bien que Solana ait réalisé certains succè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 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 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

algorithme POH

POH(Proof of History) 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 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 n'y a qu'une seule sortie Y, donc tout changement dans X entraînera un Y complètement différent.

Dans la séquence POH de Solana, l'application de l'algorithme sha256 permet de garantir l'intégrité de l'ensemble de la séquence, ce qui assure 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 validées, toute modification entraînera un changement de la valeur de hachage. Ensuite, ce hachage de bloc servira de partie X pour la prochaine fonction sha256, et nous ajouterons le hachage du prochain bloc, de sorte que le bloc précédent et le prochain bloc soient tous deux validés, toute modification entraînera une nouvelle valeur Y différente.

Dans le schéma d'architecture des flux de transactions de Solana, le processus de transaction sous le mécanisme POH est décrit. Dans un mécanisme de rotation appelé Leader Rotation Schedule, un nœud Leader est sélectionné parmi tous les validateurs (Validator) 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, après quoi un bloc est créé et diffusé aux autres nœuds.

Pour éviter les points de défaillance uniques au niveau du nœud Leader, une limite de temps a été introduite. Dans Solana, l'unité de temps est divisée en époques, chaque époque contenant 432 000 slots(, chaque slot durant 400 ms. Dans chaque slot, le système de rotation attribue un nœud Leader pour chaque slot. Le nœud Leader doit publier un bloc)400 ms( dans le temps imparti du slot, sinon, ce slot sera sauté et un nouveau nœud Leader sera élu pour le slot suivant.

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

![Revisiter l'architecture technique de Solana : va-t-elle connaître un second printemps ?]###panews/images/90Jj8P8FH5.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 validé. 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 le flooding de blocs, c'est-à-dire qu'un validateur qui a reçu le bloc 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 400 ms, la taille globale des blocs et la fréquence de création 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 propagation des grands blocs.

) Turbine

Le nœud Leader divise les blocs en sous-blocs appelés shreds grâce à un processus appelé Sharding, dont la taille spécifiée est de MTU###, soit la quantité maximale de données pouvant être envoyée d'un nœud à l'autre sans avoir besoin de les diviser en unités plus petites, équivalente à (. Ensuite, l'intégrité et la disponibilité des données sont garanties grâce à l'utilisation d'un schéma de codes d'effacement Reed-Solomon.

En divisant le bloc en quatre Data Shreds, puis afin d'éviter la perte de paquets et les dommages pendant le transfert de données, le codage Reed-Solomon est utilisé pour coder les quatre paquets en huit paquets, ce qui permet de tolérer un taux de perte de paquets allant jusqu'à 50 %. Dans les tests réels, le taux de perte de paquets 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 sous-jacent, on envisage généralement d'utiliser les 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 paquets, 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, permettant d'augmenter ce dernier jusqu'à 9 fois dans un environnement réel.

Après que Turbine ait fragmenté les données, il utilise un mécanisme de propagation à plusieurs niveaux pour les transmettre. Le nœud Leader remettra le bloc à n'importe quel validateur de blocs 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 lancera ensuite la propagation Turbine. Il doit d'abord se propager au 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 va rassembler tous les validateurs actifs dans une liste, puis trier chaque validateurs selon leur participation dans le réseau ), c'est-à-dire le montant de SOL mis en jeu (, ceux avec un poids plus élevé étant placés au premier niveau, et ainsi de suite.

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

![再解Solana技术架构：将要迎来第二春吗？])panews/images/iQ41c4b6DM.webp(

Les nœuds avec une part de droits plus élevée, lors de la classification par niveaux, se trouvent à un niveau supérieur, ce qui leur permet d'obtenir plus tôt des shreds complets. À ce moment-là, ils peuvent récupérer le bloc complet. En revanche, les nœuds des niveaux inférieurs, en raison des pertes durant la transmission, verront leur probabilité d'obtenir des shreds complets diminuer. Si ces shreds ne sont pas suffisants pour construire des fragments complets, cela demandera au Leader de retransmettre directement. À ce stade, la transmission des données se fera vers l'intérieur de l'arbre, tandis que les nœuds du premier niveau ont déjà construit la confirmation du bloc complet. Plus le temps passe avant que les validateurs des niveaux inférieurs terminent la construction du bloc et votent, plus cela prendra de temps.

L'idée de ce mécanisme est similaire à celle du mécanisme à nœud unique du nœud Leader. Dans le processus de propagation des blocs, il existe également certains nœuds prioritaires, qui reçoivent d'abord les fragments de shreds pour constituer des blocs complets afin d'atteindre le processus de 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 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 peut réduire le débit global du système. Par conséquent, pour la SVM, Solana a proposé le moteur d'exécution parallèle Sealevel pour accélérer la vitesse d'exécution des transactions.

Dans le SVM, une instruction est composée de 4 parties, y compris 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 de changement d'état à effectuer sont en conflit, il est possible d'autoriser la parallélisation des instructions de transaction du compte qui n'ont pas de conflits d'état, chaque instruction étant représentée par l'ID du programme. Et c'est aussi l'une des raisons pour lesquelles les exigences pour les validateurs de Solana sont si élevées, car il est exigé que le GPU/CPU des validateurs puisse supporter SIMD### des instructions multiples sur des données multiples( ainsi que la capacité d'AVX pour des extensions vectorielles avancées.

![Réexpliquer l'architecture technique de Solana : va-t-elle connaître un second printemps ?])panews/images/Czi5MR4h94.webp(

Développement écologique

Dans le cadre du développement actuel de l'écosystème Solana, il y a une tendance croissante vers une utilité pratique, comme Blinks et Actions, voire Solana Mobile, tandis que la direction de développement des applications soutenue par les autorités se concentre davantage sur les applications destinées aux consommateurs, plutôt que sur une compétition infinie pour les infrastructures. Avec des performances suffisamment élevées sur Solana, la diversité des applications est plus riche. En ce qui concerne Ethereum, en raison de son faible TPS, l'écosystème Ethereum reste principalement axé sur les infrastructures et les technologies d'extensibilité. Dans les situations où les infrastructures ne peuvent pas supporter les applications, il devient impossible de construire des applications destinées aux consommateurs, ce qui a entraîné un état de déséquilibre avec trop d'investissements dans les infrastructures, mais trop peu dans les applications.

) DeFi

Dans les protocoles DeFi sur Solana, il existe de nombreux projets non lancés, y compris Kamino### premier Lending(, Marginfi) Lending + Restaking(, SoLayer) Restaking(, Meteora, etc. En raison de l'atmosphère d'écosystème solidaire de Solana, un projet essaie généralement d'éviter la période de lancement d'un autre projet pour attirer suffisamment d'attention sur le marché.

La compétition est actuellement intense dans tout l'espace DEX, avec ses leaders ayant connu plusieurs migrations, passant de Raydium, Orca à Jupiter qui occupe désormais la position dominante.

Il convient de noter qu'environ 50 % des transactions sur les DEX sont initiées par des bots MEV, principalement en raison de leurs faibles frais et de l'activité des transactions Meme qui favorisent la rentabilité du MEV. C'est également l'une des principales raisons pour lesquelles les utilisateurs rencontrent fréquemment des échecs de transactions de pointe et des pannes.

Les protocoles DeFi sur Solana ont connu une augmentation explosive de leur TVL nominal en USD avec la hausse du prix de SOL. La tendance à la hausse de leur TVL ne s'est toujours pas arrêtée, formant une nouvelle vague de tendance haussière.

![Réexpliquer l'architecture technique de Solana : va-t-elle connaître un second printemps ?])