Un article révèle le roi de la vitesse dans la blockchain : Solana

Un rapport de performance

Le rapport "Fastest Chains" publié par CoinGecko le 17 mai a montré que Solana est la plus rapide parmi les grandes blockchains, avec le TPS réel quotidien moyen le plus élevé atteignant 1 504 (les transactions de vote ont été supprimées), Sui est le deuxième plus rapide. blockchain, avec le TPS réel moyen quotidien le plus élevé atteignant 854. BSC se classe troisième, mais le TPS réel atteint est inférieur à la moitié de Sui.

Il ressort de ce rapport que les Solana et Sui les plus performantes sont toutes deux des blockchains non compatibles EVM. De plus, le TPS réel moyen des 8 blockchains non compatibles EVM est de 284 et 17 EVM. les blockchains compatibles et Ethereum Layer 2 ne sont que de 74, et les performances des blockchains non compatibles EVM sont environ 4 fois supérieures à celles des blockchains compatibles EVM.

Cet article explorera les goulots d'étranglement en termes de performances des blockchains compatibles EVM et révélera la méthode de performance de Solana.

Gloutons d'étranglement des performances des blockchains compatibles EVM

Tout d'abord, nous généralisons la blockchain EVM aux blockchains générales. De manière générale, si la blockchain veut améliorer le TPS, il existe généralement les méthodes suivantes :

• Amélioration des performances du nœud : Améliorer les performances du nœud en empilant les ressources matérielles Les exigences matérielles du nœud affecteront le degré de décentralisation, comme la configuration recommandée. d'Ethereum, CPU 4 cœurs, 16 Go de mémoire et bande passante réseau de 25 Mbps, ce qui peut être obtenu avec un équipement ordinaire au niveau de l'utilisateur, avec un degré élevé de centralisation ; Solana recommande une configuration relativement plus élevée de 32 cœurs de processeur, 128 Go de mémoire et une bande passante réseau ; de 1 Gbps, qui ne peut être atteint que par des équipements de niveau professionnel, avec un haut degré de centralisation Général
• Améliorer les protocoles sous-jacents : y compris les protocoles réseau, la cryptographie, le stockage, etc. L'amélioration des protocoles sous-jacents de la blockchain ne change pas ; Les propriétés de la blockchain elle-même n'affectent pas non plus les règles de fonctionnement de la blockchain. Cela peut améliorer directement les performances de la blockchain, mais la technologie sous-jacente a reçu peu d'attention et il n'y a actuellement aucune avancée majeure dans le domaine de la recherche.
• Agrandir le bloc : l'augmentation de la taille du bloc peut inclure plus de transactions, améliorant ainsi le débit des transactions de la blockchain, comme Bitcoin Cash (BCH) ) a augmenté la taille du bloc de 1 Mo à 8 Mo, puis à 32 Mo. . Cependant, l'extension du bloc augmentera également le délai de propagation et entraînera des menaces de sécurité, telles que l'augmentation du risque de forks et d'attaques DDoS.
• Protocole de consensus : le protocole de consensus garantit que chaque nœud de la blockchain parvient à un accord sur la mise à jour du statut de ; la blockchain est la porte de sécurité la plus importante de la blockchain. Les mécanismes de consensus qui ont été utilisés dans la blockchain incluent PoW, PoS, PBFT, etc. Afin de répondre aux besoins d'évolutivité, les chaînes publiques généralement performantes amélioreront le protocole de consensus et le combineront avec leurs propres mécanismes spéciaux, tels que le mécanisme de consensus basé sur PoH de Solana et le mécanisme de consensus basé sur les avalanches d'Avalanche
• Exécution des transactions : L'exécution des transactions ne se soucie que du nombre de transactions ou de tâches informatiques traitées dans le bloc. Les blockchains telles que Ethereum utilisent une méthode série pour exécuter les transactions de contrats intelligents en blocs, le goulot d'étranglement des performances du processeur est très évident. limite sérieusement l’efficacité du débit de la blockchain. Généralement, les chaînes publiques performantes adopteront l’exécution parallèle, et certaines proposeront des modèles de langage plus propices au parallélisme pour construire des contrats intelligents, comme Sui Move.

Pour la blockchain EVM, le plus grand défi réside dans l'exécution des transactions en raison des limitations de la machine virtuelle, c'est-à-dire de l'environnement d'exécution des transactions. EVM présente deux principaux problèmes de performances :

• 256 bits : EVM est conçu comme une machine virtuelle de 256 bits afin de faciliter le traitement de l'algorithme de hachage d'Ethereum, qui produira explicitement une sortie de 256 bits. Cependant, l'ordinateur exécutant réellement EVM doit mapper des octets de 256 bits à l'architecture locale pour l'exécution. Un opcode EVM correspondra à plusieurs opcodes locaux, ce qui rendra l'ensemble du système très inefficace et peu pratique.
• Bibliothèque standard manquante : il n'y a pas de norme ; bibliothèque dans Solidity, et vous devez l'implémenter vous-même avec le code Solidity. Bien qu'OpenZeppelin ait amélioré cette situation dans une certaine mesure, ils fournissent une bibliothèque standard pour l'implémentation de Solidity (en incluant le code dans le contrat ou en l'appelant sous la forme d'appel délégué). ), mais la vitesse d'exécution du bytecode EVM est bien inférieure à celle de la bibliothèque standard précompilée.

Du point de vue de l'optimisation de l'exécution, EVM présente encore deux défauts majeurs :

• Difficile de faire une analyse statique : l'exécution parallèle dans la blockchain signifie traiter des transactions non liées en même temps, en traitant les transactions non liées comme des événements qui ne s'affectent pas les uns les autres. Le principal défi pour réaliser une exécution parallèle est de déterminer quelles transactions ne sont pas pertinentes et lesquelles sont indépendantes. Actuellement, certaines chaînes publiques hautes performances effectuent à l'avance une analyse statique des transactions. Le mécanisme de sauts dynamiques d'EVM rend difficile l'analyse statique du code. ;
• Le compilateur JIT est immature : le compilateur JIT (Just In Time Compiler) est une méthode d'optimisation couramment utilisée dans les machines virtuelles modernes. L'objectif principal de JIT est de transformer l'exécution de l'interprétation en exécution compilée. Au moment de l'exécution, la machine virtuelle compile le code chaud en code machine lié à la plate-forme locale et effectue différents niveaux d'optimisation. Bien qu’il existe actuellement des projets EVM JIT, ils sont encore au stade expérimental et pas assez matures.

Ainsi, en termes de sélection de machines virtuelles, les chaînes publiques hautes performances utilisent plus souvent des machines virtuelles basées sur WASM, le bytecode eBPF ou le bytecode Move au lieu d'EVM. Solana, par exemple, utilise sa propre machine virtuelle unique SVM et le bytecode SBF basé sur eBPF.

Chaînes les plus rapides : Solana

Solana est célèbre pour son mécanisme PoH (Proof of History), sa faible latence et son débit élevé. C'est l'un des « tueurs d'Ethereum » les plus connus.

À la base, PoH est un simple algorithme de hachage similaire à la fonction de retard vérifiable (VDF). Solana est implémenté à l'aide d'une fonction de hachage résistante aux pré-images de séquence (SHA-256) qui s'exécute en continu, en utilisant la sortie d'une itération comme entrée pour la suivante. Ce calcul est exécuté sur un seul cœur par validateur.

Bien que la génération de séquences soit séquentielle et monothread, la vérification peut être effectuée en parallèle, permettant une vérification efficace sur les systèmes multicœurs. Bien qu'il existe une limite supérieure à la vitesse de hachage, les améliorations matérielles peuvent apporter des gains de performances supplémentaires. Le mécanisme PoH du

Solana Consensus Process

sert de source de temps fiable et sans confiance, créant un enregistrement vérifiable et ordonné des événements au sein du réseau. Le timing basé sur PoH permet au réseau Solana de faire tourner les dirigeants de manière planifiée et transparente. Cette rotation se produit à intervalles fixes de 4 slots, chaque slot étant actuellement réglé à 400 millisecondes. ⁠Ce mécanisme de rotation des dirigeants garantit que chaque validateur participant a une chance équitable de devenir le leader et constitue un mécanisme important permettant au réseau Solana de maintenir la décentralisation et la sécurité, empêchant un validateur unique d'acquérir trop de pouvoir sur le réseau.

Par période de créneau, le leader propose un nouveau bloc contenant les transactions reçues des utilisateurs. Le leader valide ces transactions, les regroupe dans un bloc, puis diffuse le bloc aux validateurs restants du réseau. Ce processus de proposition et de diffusion de blocs est appelé production de blocs, et les autres validateurs du réseau doivent voter sur la validité du bloc. Les validateurs vérifient le contenu des blocs pour garantir que les transactions sont valides et conformes aux règles du réseau. Un bloc est considéré comme confirmé s’il reçoit un vote majoritaire du poids de la mise. Ce processus de confirmation est essentiel pour maintenir la sécurité du réseau Solana et éviter les doubles dépenses.

Lorsque la période du leader actuel se termine, le réseau ne s'arrêtera pas et n'attendra pas la confirmation du blocage, mais passera à la période suivante, offrant aux dirigeants suivants la possibilité de produire des blocs, et l'ensemble du processus recommence. Cette approche garantit que le réseau Solana maintient un débit élevé et reste résilient, même si certains validateurs rencontrent des problèmes techniques ou se déconnectent.

Conseils de performances Solana

Étant donné que le réseau Solana peut confirmer les dirigeants à l'avance, Solana n'a pas besoin d'un pool de mémoire publique pour enregistrer les transactions des utilisateurs. Lorsqu'un utilisateur soumet une transaction, le serveur RPC la convertit en paquet QUIC et la transmet immédiatement au validateur du leader. Cette approche s'appelle Gulf Stream et permet un changement rapide de leader et une pré-exécution des transactions, réduisant ainsi la charge de mémoire sur les autres validateurs.

Les données de bloc de Solana sont introduites dans l'espace du noyau, puis transmises au GPU pour une vérification parallèle de la signature. Une fois la signature vérifiée sur le GPU, les données seront transmises au CPU pour l'exécution de la transaction, et enfin renvoyées au noyau. espace pour la persistance des données. Ce processus de traitement multiple consistant à diviser les données en différents composants matériels, appelé technologie de pipeline, peut maximiser l'utilisation du matériel et accélérer la vérification et la transmission des blocs.

Étant donné que les transactions de Solana spécifient explicitement quels comptes sont accessibles, le planificateur de transactions de Solana peut utiliser le mécanisme de verrouillage en lecture-écriture pour exécuter des transactions en parallèle. Chaque thread du planificateur de transactions Solana possède sa propre file d'attente gérée, traite les transactions de manière séquentielle et indépendante, tente de verrouiller (verrouillage en lecture-écriture) le compte de la transaction et d'exécuter la transaction. Les transactions avec des conflits de compte seront exécutées ultérieurement. Cette technique d'exécution parallèle multithread s'appelle Sealevel.

Le processus de propagation des blocs par le leader, divisant les paquets QUIC (éventuellement en utilisant un codage d'effacement) en paquets plus petits et en les distribuant aux validateurs avec une structure hiérarchique. Cette technique, appelée Turbine, réduit essentiellement l'utilisation de la bande passante du leader.

Pendant le processus de vote, les validateurs utilisent un mécanisme de consensus pour le vote fork. Les validateurs n'ont pas besoin d'attendre les votes pour procéder à la production de blocs ; au lieu de cela, les producteurs de blocs surveillent en permanence les nouveaux votes valides et les incluent dans le bloc actuel en temps réel. Ce mécanisme de consensus s'appelle TowerBFT, et en fusionnant les votes fork en temps réel, Solana garantit un processus de consensus plus efficace et rationalisé, améliorant ainsi les performances globales.

Pour le processus de persistance des blocs, Solana a développé la base de données Cloudbreak pour maximiser l'efficacité du SSD en partitionnant la structure des données du compte de manière spécifique pour bénéficier de la vitesse des opérations séquentielles et en utilisant des fichiers mappés en mémoire.

Pour réduire la charge des validateurs, Solana transfère le stockage des données des validateurs vers un réseau de nœuds appelé Archiver. L’historique du statut des transactions est divisé en plusieurs fragments et une technologie de codage d’effacement est utilisée. L'archiveur est utilisé pour stocker des fragments d'état, mais ne participe pas au consensus.

Résumé

La vision de Solana est d'être une blockchain dont le logiciel évolue à la vitesse du matériel, donc Solana tire pleinement parti de toutes les capacités CPU, GPU et bande passante disponibles dans les ordinateurs d'aujourd'hui pour maximiser les performances et la vitesse maximale théorique qu'il peut atteindre 65 000 TPS.

C'est précisément grâce aux hautes performances et à l'évolutivité de Solana que Solana est devenue la plate-forme blockchain préférée pour gérer les transactions à haute fréquence et les contrats intelligents complexes, qu'il s'agisse de la piste DePIN/AI du début de l'année ou du récent Meme. piste, Solana Tous montrent un grand potentiel.

Après le lancement de l'ETF Ethereum, Solana est également devenue la crypto-monnaie avec le plus d'appels pour le prochain ETF. Bien que la SEC répertorie toujours Solana comme titre, d'autres ETF de crypto-monnaie ne seront pas approuvés à court terme. Mais sur le marché de la cryptographie, le consensus a de la valeur, et le consensus de Solana pourrait devenir aussi indestructible que Bitcoin et Ethereum.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!