Tout savoir sur la mise à jour v1.18 de Solana

Introduction

L’adoption à la supermajorité de la mise à jour 1.18 de Solana constitue une étape importante. Elle apporte de nombreuses améliorations et nouvelles fonctionnalités destinées à renforcer les performances, la fiabilité et l’efficacité du réseau. L’un des changements les plus notables est l’introduction d’un planificateur central. Ce nouveau planificateur vise à simplifier le traitement des transactions et à garantir des calculs de priorité plus précis et efficaces. D’autres améliorations apportées à l’environnement d’exécution et au déploiement des programmes permettent, par exemple, d’assurer des performances plus fiables, même lors des pics de charge du réseau.

Cet article présente les mises à jour et améliorations apportées par la version 1.18. Nous examinerons les motivations derrière ces changements, les spécificités de ces nouvelles fonctionnalités et leur impact attendu sur le réseau. Que vous exploitiez un validateur, développiez des applications ou utilisiez simplement Solana, cette présentation complète de la mise à jour 1.18 vous fournira les informations nécessaires pour comprendre et exploiter les avantages de ces nouvelles améliorations.

Nous devons d’abord présenter Anza, une société de développement récemment créée qui pilote ces changements, ainsi que son rôle dans le développement continu de Solana.

Qu’est-ce qu’Anza ?

Anza est une société de développement logiciel récemment créée par d’anciens dirigeants et ingénieurs principaux de Solana Labs. Sa création représente une initiative stratégique visant à renforcer l’écosystème Solana en améliorant sa fiabilité, sa décentralisation et la robustesse de son réseau. Anza a été fondée pour développer l’écosystème Solana en créant des infrastructures critiques, en contribuant à des protocoles essentiels et en favorisant l’innovation autour de nouveaux outils.

L’équipe fondatrice comprend Jeff Washington, Stephen Akridge, Jed Halfon, Amber Christiansen, Pankaj Garg, Jon Cinque, ainsi que plusieurs ingénieurs principaux de Solana Labs.

Anza se concentre sur le développement et l’amélioration des clients de validation de Solana avec la création d’Agave, un fork du client de validation de Solana Labs. Les ambitions d’Anza vont au-delà du développement de son client de validation et englobent des améliorations à l’échelle de tout l’écosystème. Cela inclut le développement des Token Extensions et d’une chaîne d’outils Rust / Clang personnalisée. En favorisant une approche collaborative et ouverte du développement, Anza s’engage à accélérer et à améliorer l’écosystème Solana.

Qu’est-ce qu’Agave ?

Comme brièvement indiqué dans la section précédente, Agave est un fork du client de validation de Solana Labs piloté par Anza. Dans ce contexte, le terme « fork » signifie que l’équipe de développement d’Anza reprend le code existant du dépôt Solana Labs pour créer une nouvelle branche de développement distincte du code source d’origine. Anza peut ainsi apporter ses propres améliorations, fonctionnalités et optimisations au client Solana Labs.

Le processus de migration

La migration du client vers l’organisation GitHub d’Anza a commencé le 1er mars. Dans un premier temps, Agave reproduira le dépôt Solana Labs afin de laisser à la communauté le temps de s’adapter. Pendant cette période, Anza se chargera de clôturer les pull requests (PR) et de migrer les issues pertinentes vers le dépôt d’Agave. Agave et les versions 1.17 et 1.18 du client Solana Labs seront fonctionnellement identiques. Anza prévoit de publier Agave v2.0 cet été, ce qui implique d’archiver le client Solana Labs et de recommander à l’ensemble du réseau de migrer vers le nouveau client Agave.

Le processus de migration est suivi publiquement sur GitHub, de Solana Labs vers Agave.

L’environnement d’exécution Agave

L’environnement d’exécution Agave hérite son architecture fondamentale de la Solana Virtual Machine (SVM) et constitue l’ossature permettant d’exécuter les fonctionnalités principales définies par l’environnement d’exécution Sealevel. 

Le protocole Solana définit l’environnement d’exécution comme un composant essentiel chargé de traiter les transactions et de mettre à jour l’état dans la base de données des comptes. Cette spécification a été adoptée et perfectionnée par les clients Agave et Firedancer. La SVM se distingue principalement par sa capacité à exécuter tous les programmes Solana et à modifier en parallèle l’état des comptes.

Le concept de banque est essentiel pour comprendre le traitement des transactions et les changements apportés par la version 1.18. Une banque est à la fois un élément de logique et une représentation de l’état du registre à un instant donné. Elle agit comme un contrôleur sophistiqué qui gère la base de données des comptes, supervise le suivi des comptes clients, gère l’exécution des programmes et préserve l’intégrité et la progression du registre de Solana. Une banque encapsule l’état résultant des transactions incluses dans un bloc donné et sert ainsi d’instantané du registre à cet instant.

Chaque banque dispose des caches et références nécessaires à l’exécution des transactions, ce qui permet de l’initialiser à partir d’un instantané précédent ou du bloc de genèse. Pendant la Banking Stage, au cours de laquelle le validateur traite les transactions, les banques servent à assembler les blocs, puis à vérifier leur intégrité. Ce cycle de vie comprend le chargement des comptes, le traitement des transactions, le gel de la banque pour finaliser l’état et, enfin, son enracinement pour garantir sa permanence.

De manière générale, le moteur de traitement des transactions de l’environnement d’exécution Agave est chargé de charger, compiler et exécuter les programmes. Il utilise la compilation à la volée (JIT) et met en cache les programmes compilés afin d’optimiser l’efficacité de l’exécution et d’éviter les recompilations inutiles. Les programmes sont compilés au format eBPF avant leur déploiement. L’environnement d’exécution utilise ensuite la boîte à outils rBPF pour créer une machine virtuelle eBPF. Celle-ci effectue une compilation JIT du format eBPF vers des instructions de code machine x86_64 et exploite pleinement le matériel disponible. Cela garantit une exécution efficace des programmes.

La mise à jour 1.18 introduit un planificateur central de transactions, étroitement lié aux gains d’efficacité opérationnelle apportés par l’environnement d’exécution Agave. En améliorant la façon dont les transactions sont compilées, exécutées et gérées au moyen des banques, la mise à jour 1.18 permet une planification plus simple et plus efficace. Le traitement des transactions s’en trouve accéléré et le débit amélioré. Le nouvel environnement d’exécution Agave et son client constituent le socle de ces améliorations. Il est donc essentiel d’en avoir une compréhension générale avant d’examiner les subtilités du nouveau planificateur. 

Pour en savoir plus sur l’environnement d’exécution Agave, je vous recommande de lire l’article de Joe Caulfield à ce sujet. Il présente le sujet en détail et fournit de nombreux extraits de code utiles.

Un planificateur de transactions plus efficace

L’implémentation actuelle

Dans le pipeline de traitement des transactions, les paquets de transactions entrent d’abord dans le système par le point d’entrée. Leur signature est ensuite vérifiée pendant l’étape SigVerify. Cette étape garantit que chaque transaction est valide et autorisée par l’expéditeur.

Après la vérification des signatures, les transactions sont envoyées à la Banking Stage. Celle-ci compte six threads : deux sont consacrés au traitement des transactions de vote provenant de la Transaction Processing Unit (TPU) ou de Gossip, et quatre aux transactions sans vote. Chaque thread est indépendant et reçoit les paquets depuis un canal partagé. Autrement dit, SigVerify envoie des lots de paquets, puis chaque thread extrait les transactions de ce canal partagé et les stocke dans un tampon local. 

Le tampon local reçoit les transactions, détermine leur priorité et les trie en conséquence. Cette file d’attente est dynamique et se met constamment à jour pour refléter en temps réel l’évolution du statut des transactions et les besoins du réseau. À mesure que des transactions sont ajoutées à la file, leur ordre est réévalué afin que celles ayant la priorité la plus élevée soient traitées en premier.

Ce processus se déroule en continu. Le sort de ces paquets de transactions dépend de la position du validateur dans le calendrier des leaders. Si le validateur ne doit pas devenir leader prochainement, il transmet les paquets au futur leader, puis les abandonne. Lorsque le validateur se rapproche du créneau où il doit devenir leader (à environ ~20 créneaux), il continue à transmettre les paquets, mais ne les abandonne plus. Cela permet de les inclure dans l’un de ses propres blocs si les autres leaders ne les traitent pas. Lorsqu’un validateur se trouve à deux créneaux de devenir leader, il commence à conserver les paquets : il les accepte sans rien faire afin de pouvoir les traiter une fois devenu leader.

Pendant la production d’un bloc, chaque thread prend les 128 premières transactions de sa file d’attente locale, tente d’acquérir les verrous, puis vérifie, charge, exécute, enregistre et valide les transactions. Si l’acquisition d’un verrou échoue, la transaction est réessayée ultérieurement. Examinons chaque étape :

• Verrouillage : cette étape détermine les transactions pour lesquelles le thread peut acquérir des verrous. Chacune de ces transactions lit et écrit dans un certain nombre de comptes. Le validateur doit donc s’assurer qu’il n’existe aucun conflit
• Vérifications : cette étape vérifie si la transaction est trop ancienne ou a déjà été traitée. Notez que les banques disposent d’un cache d’état qui conserve les transactions des 150 à 300 derniers créneaux
• Chargement : cette étape charge les comptes nécessaires à l’exécution d’une transaction donnée. Elle vérifie également si le payeur des frais peut effectivement les régler et si le programme invoqué est valide. En résumé, cette étape charge les comptes et effectue une partie de la configuration initiale
• Exécution : cette étape exécute chaque transaction
• Enregistrement : les résultats des transactions exécutées sont envoyés au service Proof of History pour être hachés. C’est à ce stade que la signature de la transaction est envoyée
• Validation : si l’étape d’enregistrement réussit, les transactions sont validées. Cette étape propage également les modifications au système de comptes afin que les futures transactions de ce créneau ou des suivants disposent d’une vue actualisée de chaque compte‍
• Déverrouillage : les verrous appliqués à chaque compte lors de la première étape sont levés

La Banking Stage utilise une approche à plusieurs itérateurs pour créer ces lots de transactions. Un multi-itérateur est un modèle de programmation qui permet de parcourir simultanément un jeu de données selon plusieurs séquences. Imaginez plusieurs lecteurs parcourant un même livre, chacun commençant à un chapitre différent et se coordonnant pour ne pas lire la même page au même moment si leur compréhension du contenu risque d’interférer. Dans la Banking Stage, ces « lecteurs » sont des itérateurs et le « livre » est l’ensemble des transactions en attente de traitement. L’objectif du multi-itérateur est de parcourir efficacement les transactions pour les regrouper en lots pouvant être traités sans conflit de verrouillage.

Initialement, les transactions sont sérialisées dans un vecteur en fonction de leur priorité. Le multi-itérateur dispose ainsi d’une séquence structurée qu’il peut segmenter en lots sans conflit. Il commence au début du vecteur sérialisé et place des itérateurs aux jonctions où les transactions n’entrent pas en conflit. Il crée ainsi des lots de 128 transactions sans aucun conflit lecture-écriture ou écriture-écriture. Si une transaction entre en conflit avec le lot en cours de formation, elle est ignorée et reste non marquée, ce qui lui permet d’être incluse dans un lot ultérieur où le conflit n’existe plus. Ce processus itératif s’ajuste dynamiquement à mesure que les transactions sont traitées. 

Une fois le lot formé, les transactions sont exécutées. Si l’exécution réussit, elles sont enregistrées dans le service Proof of History et diffusées sur le réseau.

Les problèmes de l’implémentation actuelle

L’implémentation actuelle présente plusieurs aspects susceptibles de nuire aux performances, d’entraîner des goulets d’étranglement dans le traitement des transactions et de rendre leur priorisation incohérente. Ces difficultés découlent principalement de l’architecture de la Banking Stage et de la façon dont le système traite les transactions.

L’un des problèmes fondamentaux est que les quatre threads indépendants qui traitent les transactions sans vote ont chacun leur propre vision de la priorité des transactions. Cette divergence peut entraîner des variations ou des incohérences dans l’ordre des transactions. Ces écarts deviennent plus prononcés lorsque toutes les transactions hautement prioritaires entrent en conflit. Comme chaque thread extrait les paquets de manière essentiellement aléatoire depuis le canal partagé de SigVerify, chacun dispose d’un ensemble aléatoire de toutes les transactions. Lors d’événements très concurrentiels, comme le mint d’une collection NFT populaire, de nombreuses transactions hautement prioritaires sont susceptibles de se trouver dans plusieurs threads de la Banking Stage. Cette situation est problématique, car elle peut entraîner des conflits de verrouillage entre les threads. Comme ils utilisent des ensembles de priorités différents, les threads peuvent entrer en concurrence pour traiter ces transactions hautement prioritaires, ce qui gaspille involontairement du temps de traitement en raison de tentatives de verrouillage infructueuses.

Imaginez la Banking Stage comme un orchestre dont chaque thread représente une section différente : cordes, cuivres, bois et percussions. Dans l’idéal, un chef d’orchestre coordonnerait ces sections pour garantir une interprétation harmonieuse. Cependant, le système actuel ressemble à un orchestre qui tenterait d’interpréter une œuvre complexe sans chef. Chaque section joue sa propre mélodie et entre régulièrement en conflit avec les autres. Les transactions hautement prioritaires sont les parties solistes que toutes les sections tentent de jouer simultanément, ce qui crée de la confusion. Ce manque de coordination souligne la nécessité d’un « chef » centralisé pour garantir l’efficacité et l’harmonie du traitement des transactions de Solana, à l’image d’un chef dirigeant un orchestre.

Le nouveau planificateur de transactions

La mise à jour 1.18 introduit un thread de planification central qui remplace le modèle précédent, dans lequel quatre threads bancaires indépendants géraient chacun la priorisation et le traitement de leurs propres transactions. Dans cette nouvelle architecture, le planificateur central est le seul destinataire des transactions provenant de l’étape SigVerify. Il crée une file d’attente prioritaire et utilise un graphe de dépendances pour gérer la priorisation et le traitement des transactions.

Ce graphe de dépendances est appelé prio-graph. Il s’agit d’un graphe orienté acyclique qui est évalué de manière paresseuse à mesure que de nouvelles transactions sont ajoutées. Les transactions sont insérées dans le graphe pour créer des chaînes d’exécution, puis extraites par ordre chronologique de priorité. En cas de transactions conflictuelles, la première insérée est toujours prioritaire. Dans l’exemple ci-dessus, nous avons les transactions A à H. Notez que les transactions A et E disposent de la priorité la plus élevée dans leurs chaînes respectives et n’entrent pas en conflit. Le planificateur progresse de gauche à droite et traite les transactions par lots :

Les transactions A et E sont traitées dans le premier lot, puis B et F, ensuite C, D et G, et enfin H dans le dernier lot. Comme vous pouvez le constater, les transactions les plus prioritaires se trouvent en haut du graphe, c’est-à-dire tout à gauche. Lorsque le planificateur examine les transactions par ordre décroissant, il détecte les conflits. Si une transaction entre en conflit avec une transaction plus prioritaire, une arête est créée dans le graphe pour représenter cette dépendance. Par exemple, C et D entrent en conflit avec B.

Le nouveau modèle de planificateur résout plusieurs problèmes majeurs inhérents à l’approche à plusieurs itérateurs :

• Cohérence de la gestion des priorités : le nouveau système centralise la réception et la planification des transactions afin de garantir qu’elles soient toutes traitées selon un ordre de priorité cohérent. Cela élimine les variations auparavant causées par les différentes visions de la priorité des transactions entre les threads
• Réduction des délais de traitement : le prio-graph garantit que les lots préparés pour l’exécution ont de fortes chances de réussir sans conflit de verrouillage, ce qui réduit le temps de traitement et les délais causés par la contention des verrous. Notez l’emploi de l’expression « ont de fortes chances de réussir » : il n’est pas tout à fait exact d’affirmer que le prio-graph crée des lots ne pouvant pas échouer à acquérir les verrous, puisqu’ils peuvent entrer en conflit avec les threads de vote, même si ce cas limite est très rare
• Évolutivité et flexibilité : la conception de ce nouveau planificateur permet d’augmenter le nombre de threads sans rencontrer les problèmes antérieurs d’accroissement des conflits de verrouillage. Cela est rendu possible par la vue centralisée des verrous et par une distribution plus contrôlée des transactions entre les workers 

L’introduction du planificateur central dans la version 1.18 devrait considérablement améliorer le traitement des transactions et réduire la complexité ainsi que la surcharge associées au système précédent. Elle devrait accélérer le traitement des transactions, augmenter le débit et renforcer la stabilité du réseau. En raison des retards pris par la publication de la version 1.18, le planificateur a été amélioré depuis sa création. Par exemple, la vérification de la précompilation des transactions a été déplacée vers les threads workers pour améliorer l’efficacité. En outre, les limites de CU sont désormais plus raisonnables, avec des ratios estimé/réel nettement inférieurs à ceux de l’ancien planificateur. Le nouveau planificateur peut désormais utiliser les CU pour limiter les files de tâches planifiées, ce qui évite la mise en file d’un volume excessif de tâches en raison de conflits entre comptes.

Notez que le planificateur central n’est pas activé par défaut et doit l’être à l’aide du nouveau flag --block-production-method central-scheduler lors du démarrage d’un validateur. Son activation est actuellement facultative, mais il deviendra le planificateur par défaut dans les prochaines versions. Notez également que l’ancien planificateur peut être activé à l’aide du flag --block-production-method thread-local-multi-iterator. Celui-ci est activé par défaut, mais évitez de l’utiliser dans les prochaines versions : le planificateur central est bien plus efficace et résout les problèmes de l’ancien planificateur.

Un calcul des priorités plus efficace 

La version 1.18 affine également la méthode de détermination de la priorité des transactions, ce qui rend le processus plus équitable et efficace en matière d’utilisation des ressources et de recouvrement des coûts. Auparavant, la priorisation des transactions reposait principalement sur la priorité du budget de calcul, ce qui pouvait entraîner une tarification sous-optimale des unités de calcul. En effet, la priorisation ne tenait pas suffisamment compte des frais de base perçus, ce qui pouvait conduire à une sous-évaluation des ressources et nuire à l’efficacité opérationnelle du réseau.

La nouvelle approche ajuste le calcul de la priorité d’une transaction pour tenir compte des frais de transaction et des coûts associés à l’aide de la formule Priorité = Frais / (Coût + 1). Ici, les frais correspondent aux frais associés à une transaction donnée, tandis que le coût représente la consommation de ressources et de calcul déterminée par le modèle de coût de Solana. L’ajout de « 1 » au dénominateur est une mesure de sécurité destinée à éviter toute division par zéro. 

Nous pouvons décomposer davantage la formule pour préciser les notions de Frais et de Coût :

Le coût d’une transaction est désormais calculé de manière exhaustive, en tenant compte de tous les coûts de calcul et d’exploitation associés. Les calculs de priorité reflètent ainsi la consommation réelle de ressources d’une transaction. Par conséquent, les développeurs et les utilisateurs obtiennent une priorité plus élevée s’ils demandent moins d’unités de calcul. Cela signifie également que les transferts simples, sans frais de priorité, bénéficient d’une certaine priorité dans la file d’attente.

Amélioration du déploiement des programmes

La version 1.18 améliore également considérablement le déploiement des programmes en matière de fiabilité du déploiement et d’efficacité de l’exécution. 

La nouvelle mise à jour corrige un problème qui empêchait les programmes déployés pendant le dernier créneau d’une époque d’appliquer correctement les changements d’environnement d’exécution prévus pour l’époque suivante. Un programme déployé pendant cette période de transition utilisait donc à tort l’ancien environnement d’exécution. La version 1.18 ajuste le processus de déploiement afin que l’environnement d’exécution de tout programme déployé à la fin d’une époque corresponde à celui de l’époque suivante.

La version 1.18 corrige également l’impossibilité de définir un prix ou une limite d’unités de calcul pour les transactions de déploiement en ajoutant le flag --with-compute-unit-price aux commandes de déploiement de programmes du CLI. Ce flag peut être utilisé avec les commandes solana program deploy et solana program write-buffer. La limite d’unités de calcul est définie en simulant chaque type de transaction de déploiement, puis en lui attribuant le nombre d’unités de calcul consommées.  

Une autre amélioration importante concerne la gestion des blockhashes lors du déploiement de programmes volumineux. Avant la version 1.18, les transactions envoyées avec sign_all_messages_and_send étaient limitées à 100 TPS. Pour les programmes plus volumineux, le nombre de transactions de déploiement peut atteindre plusieurs milliers. Les transactions risquaient donc d’être retardées et d’utiliser des blockhashes expirés, car beaucoup d’entre elles pouvaient subir un délai supérieur à 10 secondes. La version 1.18 reporte la signature des transactions de déploiement avec un blockhash récent jusqu’à la fin du délai de limitation. Les blockhashes sont désormais actualisés toutes les 5 secondes. Les déploiements de plus de 500 transactions bénéficient donc d’un blockhash plus récent.

En outre, la version 1.18 améliore la façon dont le réseau gère les déploiements de programmes et vérifie les transactions. Auparavant, certains programmes étaient incorrectement marqués comme FailedVerification en raison d’erreurs dans l’identification de l’état des comptes. Des programmes n’ayant échoué à aucune vérification pouvaient ainsi recevoir une étiquette incorrecte. Ces programmes sont désormais correctement identifiés comme Closed s’ils ne sont pas censés être actifs. Ce changement garantit que seuls les programmes problématiques sont signalés pour une nouvelle vérification et permet d’éviter les revérifications inutiles.

Le processus de mise à jour de l’état des programmes a également été amélioré. Les programmes peuvent désormais passer d’un état Closed à un état actif dans le même créneau que celui de leur déploiement. Ils deviennent ainsi opérationnels plus rapidement et de manière plus fiable, ce qui est crucial pendant les périodes de forte demande. Il est toutefois important de noter que cette amélioration reste soumise au délai d’un créneau entre l’annulation, le redéploiement ou le déploiement, ainsi qu’au délai de visibilité d’un créneau. Par conséquent, même si ces ajustements aident à mieux gérer la charge du réseau et à prévenir certains types de congestion, ils ne modifient pas sensiblement le workflow des développeurs de dApps.

« Le correctif contre la congestion » — Mieux gérer la congestion

La version 1.18.11 de Testnet, présentée comme « le correctif contre la congestion », proposait des changements destinés à résoudre les récents problèmes de congestion de Solana. Notez que cette version n’est pas propre à la 1.18 et qu’elle a été rétroportée vers la version 1.17.31. Il est néanmoins essentiel d’en parler.

Le changement majeur est que QUIC traite désormais les pairs disposant d’un stake extrêmement faible comme des pairs sans stake dans le cadre de la qualité de service pondérée par le stake (SWQoS). Ce changement répond au problème des nœuds disposant d’un stake très faible, qui pouvaient abuser du système pour obtenir une bande passante disproportionnée. De plus, les métriques existantes ne permettaient pas de déterminer les proportions de paquets transmis et limités provenant respectivement des nœuds avec et sans stake. Ces métriques ont donc été ajoutées pour améliorer la visibilité. La gestion des segments de paquets a également été optimisée en remplaçant les instances de vec par smallvec afin d’économiser une allocation par paquet. Cela est possible, car les streams ont la taille d’un paquet et sont donc censés être peu nombreux. 

Auparavant, pendant la Banking Stage, tous les paquets étaient transmis au nœud suivant. Cependant, la version 1.18 change ce comportement afin que seuls les paquets provenant de nœuds avec stake soient transmis. Cette mise à jour rend les connexions avec stake plus importantes que jamais, car elles pèsent davantage dans le calcul de la priorité et la transmission des transactions.

Amélioration de la documentation

La mise à jour 1.18 améliore également considérablement la prise en charge des traductions dans la documentation officielle de Solana afin de la rendre plus accessible à l’échelle mondiale. Ces changements comprennent la mise à niveau du CLI et de la configuration de Crowdin, qui simplifie la synchronisation des documents entre les langues, ainsi que l’introduction d’une nouvelle commande serve pour faciliter les tests locaux avec Docusaurus. La documentation améliore également la gestion du contenu statique en reliant directement les fichiers PDF aux blobs GitHub afin d’éviter les problèmes de chemins relatifs dans les builds traduits.

Pour les développeurs, le processus de contribution aux traductions est clarifié par un README actualisé qui explique comment résoudre les problèmes courants, notamment ceux liés aux variables d’environnement nécessaires et aux erreurs de build habituelles. Ces changements sont complétés par des améliorations apportées au flux d’intégration continue, qui n’inclut désormais les traductions que dans les builds du canal stable. Ainsi, seuls des documents vérifiés et stables sont proposés aux utilisateurs finaux. Ces changements visent à simplifier les contributions, à améliorer la qualité de la documentation officielle et à donner à tous les utilisateurs accès à des informations fiables et précises.

Conclusion

Pilotée par Anza, la mise à jour 1.18 améliore considérablement le traitement des transactions, les calculs de priorité, le déploiement des programmes, la documentation officielle et les performances globales du réseau. Grâce à l’introduction d’un planificateur central et aux différents correctifs visant à résoudre les récents problèmes de congestion, Solana est mieux armée pour gérer les pics de charge et garantir un fonctionnement efficace et fiable du réseau. Solana représente la meilleure chance de disposer d’une blockchain évolutive, et cette mise à jour confirme son potentiel.

Si vous avez lu jusqu’ici, merci, anon ! Pensez à saisir votre adresse e-mail ci-dessous pour ne manquer aucune actualité de Solana. Vous souhaitez approfondir le sujet ? Découvrez les derniers articles du blog Helius et poursuivez dès aujourd’hui votre découverte de Solana.

Ressources supplémentaires

• Client Agave
• Calendrier de transition vers Agave
• Anza
• Crate Prio-graph
• Banking Stage et planificateur de Solana
• À la une : le planificateur de Solana