Analyse de l'architecture technique et du développement de l'écosystème de Solana
Solana est une plateforme blockchain haute performance qui adopte une architecture technologique unique pour réaliser un haut débit et une faible latence. Ses technologies de base comprennent l'algorithme Proof of History (POH) qui garantit 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 production des blocs. Le mécanisme Turbine optimise la propagation de 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. Ce sont tous des éléments de la conception architecturale de Solana pour réaliser 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.
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, en particulier dans les domaines de la DeFi, des infrastructures, du GameFi/NFT, du DePin/IA et des applications grand public. Le haut 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 de nombreuses opportunités aux entrepreneurs et aux développeurs. En ce qui concerne les applications grand public, Solana dé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écialement pour les applications grand public, Solana s'engage à intégrer la technologie blockchain dans les applications quotidiennes, augmentant ainsi l'acceptation et la commodité pour les utilisateurs.
Bien que Solana ait acquis une part de marché significative dans le secteur 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 blockchains. Base, en tant que concurrent potentiel dans l'écosystème EVM, voit rapidement le nombre d'adresses actives sur sa chaîne augmenter. Parallèlement, bien que le volume total des actifs verrouillés dans le secteur DeFi de Solana ait atteint un niveau record de (TVL), des concurrents comme Base s'accaparent rapidement des 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 progrès en matière 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 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 connu pour son algorithme POH, son mécanisme de consensus Tower BFT, ainsi que pour le réseau de transmission de données Trubine et la machine virtuelle SVM, qui offrent un TPS élevé et une finalité rapide. Comment chaque composant fonctionne, 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, 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 un Y complètement différent.
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 garantit également l'intégrité des transactions qu'elle contient. Par exemple, si nous regroupons les transactions en un bloc et générons la valeur de hachage sha256 correspondante, alors les transactions dans ce bloc sont confirmées, toute modification entraînerait un changement de la valeur de hachage. Ensuite, cette valeur de hachage de bloc servira de partie de X pour la prochaine fonction sha256, puis en ajoutant la valeur de hachage du prochain bloc, les blocs précédent et suivant sont tous confirmés, toute modification entraînera une nouvelle valeur Y différente.
C'est la signification centrale de sa technologie Proof of History, le hash du bloc précédent sera utilisé comme une partie de la fonction sha256 suivante, semblable à une chaîne, le dernier Y inclut toujours la preuve de l'histoire.
Dans le diagramme de flux de transaction 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 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, avant de créer un bloc qui est 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 époques, chaque époque contenant 432 000 créneaux(, chaque créneau durant 400 ms. Dans chaque créneau, le système de rotation attribue un nœud Leader pour chaque créneau. Le nœud Leader doit publier un bloc)400ms( dans le temps imparti du créneau, sinon, il sautera ce créneau et réélira le nœud Leader pour le prochain créneau.
En résumé, 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 les blocs dans un slot. Les utilisateurs envoient des transactions au Leader via le nœud RPC, le nœud Leader empaquette et ordonne les transactions, puis exécute la génération de blocs, les blocs sont propagés aux autres validateurs, qui doivent parvenir à un consensus sur les transactions dans le bloc et leur ordre, 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 en est une mise en œuvre technique concrète. Cet algorithme est toujours lié à l'algorithme POH. Lors du vote sur un bloc, 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 des validateurs.
![Une nouvelle interprétation de l'architecture technique de Solana : va-t-elle connaître un deuxième printemps ?]###https://img-cdn.gateio.im/webp-social/moments-c210b4025cb64385890634a405838d05.webp(
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é. 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 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 plusieurs fois le même bloc.
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 des blocs sont particulièrement élevées. Lors de la propagation de grands blocs, cela exerce également 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 shards par un processus appelé Sharding, dont la taille spécifiée est de MTU###, la quantité maximale de données pouvant être envoyée d'un nœud à l'autre sans avoir besoin d'être divisée en unités plus petites est de (. Ensuite, l'intégrité et la disponibilité des données sont garanties en utilisant le schéma de codes d'effacement de Reed-Solomon.
En divisant le bloc en quatre Data Shreds, puis pour éviter la perte et les dommages des données lors du transfert, on utilise le codage Reed-Solomon 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 sous-jacent, on considère généralement l'utilisation des protocoles UDP/TCP. Étant donné que Solana tolère un taux de perte de paquets relativement élevé, 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 transmission plus rapide. En revanche, le protocole TCP retransmet plusieurs fois en cas de perte, ce qui réduit considérablement la vitesse de transmission et le débit. Avec Reed-Solomon, ce système peut augmenter significativement le débit de Solana, pouvant atteindre une augmentation de 9 fois dans un environnement réel.
![Revisiter l'architecture technique de Solana : va-t-elle connaître un second printemps ?])https://img-cdn.gateio.im/webp-social/moments-224796bc8e080649730bb8736334abba.webp(
Après que Turbine a fragmenté les données, il utilise un mécanisme de propagation multicouche pour transmettre les informations. Le nœud Leader remettra le bloc à n'importe quel validateurs 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 activera ensuite la propagation Turbine. Tout d'abord, il faut propager vers le nœud racine, puis ce nœud racine déterminera quels validateurs se trouvent à quel niveau. Le processus est comme suit :
Créer une liste de nœuds : le nœud racine regroupe tous les validateurs actifs dans une liste, puis trie chaque validateur en fonction de ses avoirs dans le réseau ), c'est-à-dire le montant de SOL staké (, ceux avec un poids plus élevé étant en première couche, 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 : en divisant les nœuds en couches depuis le sommet de la liste, en déterminant deux valeurs, la profondeur et la largeur, on peut 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 proportion élevée de droits, 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à, il est possible de restaurer le bloc complet, tandis que les nœuds des niveaux inférieurs, en raison des pertes de transmission, verront leurs chances d'obtenir des shreds complets diminuer. Si ces shreds ne suffisent pas à construire des fragments complets, le Leader demandera une retransmission directe. À ce moment-là, la transmission des données se fera vers l'intérieur de l'arbre, et les nœuds du premier niveau auront déjà construit la confirmation complète du bloc. Plus le temps nécessaire 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 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 un 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 propagation des données Turbine. Cependant, en tant que machine virtuelle pour la transition d'état, si le nœud Leader ralentit la vitesse de traitement de SVM lors de l'exécution des transactions, cela réduira le débit global 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.
![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 SVM, une instruction est composée de 4 parties, incluant 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 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 également l'une des raisons pour lesquelles les exigences pour les validateurs de Solana sont élevées, car il est demandé que les GPU/CPU des validateurs puissent supporter SIMD) instruction unique, plusieurs données( ainsi que la capacité d'extension vectorielle avancée AVX.
Développement écologique
Dans le contexte actuel du développement de l'écosystème Solana, il y a une tendance croissante vers l'utilité réelle, comme Blinks, Actions et même Solana Mobile. La direction de développement des applications soutenues par les officiels est également plus orientée vers les applications pour les consommateurs, plutôt que vers une compétition sans fin sur l'infrastructure. Avec les performances suffisantes de Solana, la variété des applications est plus riche. En ce qui concerne Ethereum, en raison de son TPS relativement bas, l'écosystème Ethereum reste principalement axé sur l'infrastructure et les technologies d'extension. Lorsque l'infrastructure ne peut pas supporter les applications, il devient impossible de construire des applications pour les consommateurs, ce qui entraîne un déséquilibre où trop de fonds sont investis dans l'infrastructure, mais trop peu dans les applications.
) DeFi
Dans les protocoles DeFi sur Solana, il existe de nombreux projets non émis, y compris Kamino### Premier Lending(, Marginfi) Lending + Restaking(, SoLayer) Restaking(, Meteora, etc. En raison de l'atmosphère d'unité de l'écosystème Solana, un projet évite généralement de lancer ses jetons lorsque d'autres projets prévoient de le faire, afin d'attirer suffisamment l'attention du marché.
La concurrence est intense dans l'ensemble du DEX, et son leader a également connu plusieurs migrations, passant de Raydium, Orca à un certain DEX qui détient actuellement la position dominante.
Il est à noter qu'environ 50 % des transactions DEX sont effectuées par des bots MEV.
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.
19 J'aime
Récompense
19
6
Partager
Commentaire
0/400
staking_gramps
· 07-16 11:08
les performances de sol sont vraiment bonnes
Voir l'originalRépondre0
0xSunnyDay
· 07-15 15:18
Le roi du temps d'arrêt parle encore de performance ?
Voir l'originalRépondre0
CoconutWaterBoy
· 07-14 03:35
Encore en train de parler de sol?
Voir l'originalRépondre0
SandwichTrader
· 07-14 03:21
Il vaut mieux dégager que de bloquer. Rien que d'y penser, ça fait planter.
Analyse de l'architecture technique de Solana et état actuel du développement de l'écosystème
Analyse de l'architecture technique et du développement de l'écosystème de Solana
Solana est une plateforme blockchain haute performance qui adopte une architecture technologique unique pour réaliser un haut débit et une faible latence. Ses technologies de base comprennent l'algorithme Proof of History (POH) qui garantit 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 production des blocs. Le mécanisme Turbine optimise la propagation de 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. Ce sont tous des éléments de la conception architecturale de Solana pour réaliser 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.
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, en particulier dans les domaines de la DeFi, des infrastructures, du GameFi/NFT, du DePin/IA et des applications grand public. Le haut 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 de nombreuses opportunités aux entrepreneurs et aux développeurs. En ce qui concerne les applications grand public, Solana dé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écialement pour les applications grand public, Solana s'engage à intégrer la technologie blockchain dans les applications quotidiennes, augmentant ainsi l'acceptation et la commodité pour les utilisateurs.
Bien que Solana ait acquis une part de marché significative dans le secteur 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 blockchains. Base, en tant que concurrent potentiel dans l'écosystème EVM, voit rapidement le nombre d'adresses actives sur sa chaîne augmenter. Parallèlement, bien que le volume total des actifs verrouillés dans le secteur DeFi de Solana ait atteint un niveau record de (TVL), des concurrents comme Base s'accaparent rapidement des 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 progrès en matière 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 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 connu pour son algorithme POH, son mécanisme de consensus Tower BFT, ainsi que pour le réseau de transmission de données Trubine et la machine virtuelle SVM, qui offrent un TPS élevé et une finalité rapide. Comment chaque composant fonctionne, 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, 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 un Y complètement différent.
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 garantit également l'intégrité des transactions qu'elle contient. Par exemple, si nous regroupons les transactions en un bloc et générons la valeur de hachage sha256 correspondante, alors les transactions dans ce bloc sont confirmées, toute modification entraînerait un changement de la valeur de hachage. Ensuite, cette valeur de hachage de bloc servira de partie de X pour la prochaine fonction sha256, puis en ajoutant la valeur de hachage du prochain bloc, les blocs précédent et suivant sont tous confirmés, toute modification entraînera une nouvelle valeur Y différente.
C'est la signification centrale de sa technologie Proof of History, le hash du bloc précédent sera utilisé comme une partie de la fonction sha256 suivante, semblable à une chaîne, le dernier Y inclut toujours la preuve de l'histoire.
Dans le diagramme de flux de transaction 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 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, avant de créer un bloc qui est 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 époques, chaque époque contenant 432 000 créneaux(, chaque créneau durant 400 ms. Dans chaque créneau, le système de rotation attribue un nœud Leader pour chaque créneau. Le nœud Leader doit publier un bloc)400ms( dans le temps imparti du créneau, sinon, il sautera ce créneau et réélira le nœud Leader pour le prochain créneau.
En résumé, 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 les blocs dans un slot. Les utilisateurs envoient des transactions au Leader via le nœud RPC, le nœud Leader empaquette et ordonne les transactions, puis exécute la génération de blocs, les blocs sont propagés aux autres validateurs, qui doivent parvenir à un consensus sur les transactions dans le bloc et leur ordre, 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 en est une mise en œuvre technique concrète. Cet algorithme est toujours lié à l'algorithme POH. Lors du vote sur un bloc, 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 des validateurs.
![Une nouvelle interprétation de l'architecture technique de Solana : va-t-elle connaître un deuxième printemps ?]###https://img-cdn.gateio.im/webp-social/moments-c210b4025cb64385890634a405838d05.webp(
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é. 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 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 plusieurs fois le même bloc.
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 des blocs sont particulièrement élevées. Lors de la propagation de grands blocs, cela exerce également 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 shards par un processus appelé Sharding, dont la taille spécifiée est de MTU###, la quantité maximale de données pouvant être envoyée d'un nœud à l'autre sans avoir besoin d'être divisée en unités plus petites est de (. Ensuite, l'intégrité et la disponibilité des données sont garanties en utilisant le schéma de codes d'effacement de Reed-Solomon.
En divisant le bloc en quatre Data Shreds, puis pour éviter la perte et les dommages des données lors du transfert, on utilise le codage Reed-Solomon 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 sous-jacent, on considère généralement l'utilisation des protocoles UDP/TCP. Étant donné que Solana tolère un taux de perte de paquets relativement élevé, 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 transmission plus rapide. En revanche, le protocole TCP retransmet plusieurs fois en cas de perte, ce qui réduit considérablement la vitesse de transmission et le débit. Avec Reed-Solomon, ce système peut augmenter significativement le débit de Solana, pouvant atteindre une augmentation de 9 fois dans un environnement réel.
![Revisiter l'architecture technique de Solana : va-t-elle connaître un second printemps ?])https://img-cdn.gateio.im/webp-social/moments-224796bc8e080649730bb8736334abba.webp(
Après que Turbine a fragmenté les données, il utilise un mécanisme de propagation multicouche pour transmettre les informations. Le nœud Leader remettra le bloc à n'importe quel validateurs 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 activera ensuite la propagation Turbine. Tout d'abord, il faut propager vers le nœud racine, puis ce nœud racine déterminera quels validateurs se trouvent à quel niveau. Le processus est comme suit :
Créer une liste de nœuds : le nœud racine regroupe tous les validateurs actifs dans une liste, puis trie chaque validateur en fonction de ses avoirs dans le réseau ), c'est-à-dire le montant de SOL staké (, ceux avec un poids plus élevé étant en première couche, 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 : en divisant les nœuds en couches depuis le sommet de la liste, en déterminant deux valeurs, la profondeur et la largeur, on peut 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 proportion élevée de droits, 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à, il est possible de restaurer le bloc complet, tandis que les nœuds des niveaux inférieurs, en raison des pertes de transmission, verront leurs chances d'obtenir des shreds complets diminuer. Si ces shreds ne suffisent pas à construire des fragments complets, le Leader demandera une retransmission directe. À ce moment-là, la transmission des données se fera vers l'intérieur de l'arbre, et les nœuds du premier niveau auront déjà construit la confirmation complète du bloc. Plus le temps nécessaire 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 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 un 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 propagation des données Turbine. Cependant, en tant que machine virtuelle pour la transition d'état, si le nœud Leader ralentit la vitesse de traitement de SVM lors de l'exécution des transactions, cela réduira le débit global 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.
![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 SVM, une instruction est composée de 4 parties, incluant 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 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 également l'une des raisons pour lesquelles les exigences pour les validateurs de Solana sont élevées, car il est demandé que les GPU/CPU des validateurs puissent supporter SIMD) instruction unique, plusieurs données( ainsi que la capacité d'extension vectorielle avancée AVX.
Développement écologique
Dans le contexte actuel du développement de l'écosystème Solana, il y a une tendance croissante vers l'utilité réelle, comme Blinks, Actions et même Solana Mobile. La direction de développement des applications soutenues par les officiels est également plus orientée vers les applications pour les consommateurs, plutôt que vers une compétition sans fin sur l'infrastructure. Avec les performances suffisantes de Solana, la variété des applications est plus riche. En ce qui concerne Ethereum, en raison de son TPS relativement bas, l'écosystème Ethereum reste principalement axé sur l'infrastructure et les technologies d'extension. Lorsque l'infrastructure ne peut pas supporter les applications, il devient impossible de construire des applications pour les consommateurs, ce qui entraîne un déséquilibre où trop de fonds sont investis dans l'infrastructure, mais trop peu dans les applications.
) DeFi
Dans les protocoles DeFi sur Solana, il existe de nombreux projets non émis, y compris Kamino### Premier Lending(, Marginfi) Lending + Restaking(, SoLayer) Restaking(, Meteora, etc. En raison de l'atmosphère d'unité de l'écosystème Solana, un projet évite généralement de lancer ses jetons lorsque d'autres projets prévoient de le faire, afin d'attirer suffisamment l'attention du marché.
La concurrence est intense dans l'ensemble du DEX, et son leader a également connu plusieurs migrations, passant de Raydium, Orca à un certain DEX qui détient actuellement la position dominante.
Il est à noter qu'environ 50 % des transactions DEX sont effectuées par des bots MEV.