Mise à jour Agave v2.3 : tout ce que vous devez savoir

Introduction

La version v2.3 du client de validation Agave marque une nouvelle avancée majeure pour Solana. Comme les mises à jour précédentes, cette nouvelle version apporte des améliorations essentielles visant à renforcer les performances du réseau et l’expérience des développeurs.

Principales nouveautés d’Agave 2.3 

• Nouveau client TPU tpu-client-next
• Optimisations d’AccountsDB réduisant les opérations d’E/S disque
• Calendrier des leaders désormais indexé par les comptes de vote des validateurs
• Vérification des événements passibles de pénalisation
• Planificateur glouton activé par défaut
• Améliorations des snapshots
• Mises à niveau du gossip
• Transitions d’époque plus rapides

Chaque section de cet article est indépendante, ce qui vous permet d’accéder facilement aux sujets les plus pertinents pour vous. Que vous soyez opérateur de validateur, développeur ou utilisateur actif, ce guide complet sur Agave 2.3 devrait vous fournir les informations essentielles pour tirer pleinement parti des dernières améliorations.

Anza accélère le rythme des versions d’Agave. Moins de trois mois après la version 2.2, la version 2.3 est déjà en production, et 13 % du stake total exécute actuellement des versions du nouveau client. Son adoption devrait progresser rapidement dans les semaines à venir. Entre-temps, les activations des feature gates sur le mainnet ont été temporairement suspendues pendant le déploiement. Elles reprendront bientôt dans le cadre de la séquence d’activation prévue.

Nouveau client TPU

Agave 2.3 introduit une nouvelle implémentation du client Transaction Processing Unit (TPU), qui remplace l’ancien ConnectionCache. Ce client TPU est chargé d’envoyer les transactions sérialisées aux validateurs sur le réseau à l’aide du protocole QUIC. La nouvelle conception, appelée tpu-client-next, est une refonte complète destinée à améliorer considérablement les performances, à réduire l’utilisation des ressources et à simplifier l’architecture globale.

Le client TPU est utilisé dans deux scénarios principaux : dans le ForwardingStage, où les validateurs transmettent les transactions au prochain leader, et dans le SendTransactionService, utilisé par les RPC pour relayer les transactions au leader.

L’ancienne implémentation, ConnectionCache, était conçue pour prendre en charge les protocoles UDP et QUIC, ce qui la rendait inutilement complexe. ConnectionCache s’appuyait sur une file d’attente asynchrone interne pour stocker les transactions plutôt que sur un canal explicite, et comprenait une logique de préchauffage du cache qui envoyait des paquets vides. Elle rencontrait également des problèmes persistants liés à la gestion des endpoints Quinn (c’est-à-dire une implémentation de QUIC en Rust).

Le nouveau tpu-client-next résout ces problèmes grâce à une conception asynchrone et simplifiée. En interne, il suit un modèle à base d’agents dans lequel des tâches worker individuelles gèrent chaque connexion QUIC. Ces workers communiquent avec un ConnectionWorkersScheduler centralisé au moyen de canaux asynchrones. 

Lorsque le planificateur reçoit un lot de transactions, celui-ci est diffusé à l’ensemble approprié de workers selon la stratégie configurée. Cette architecture élimine entièrement le multistreaming, réduisant ainsi la fragmentation du trafic. Les connexions sont également préétablies, ce qui supprime la latence liée à l’ouverture de nouveaux streams au moment de l’envoi.

tpu-client-next affiche des gains de performances évidents. 

• Lors d’expériences RPC sur le testnet, l’ancien et le nouveau client ont atteint un TPS moyen similaire sous charge. Cependant, tpu-client-next a affiché une gigue nettement plus faible. 
• Dans les cas d’utilisation des validateurs, ForwardingStage a augmenté de 10 % le volume de transactions transmises, avec des schémas de trafic plus stables et une réduction de 30 % de l’utilisation du CPU.
• L’outil propriétaire de test de charge d’Anza, transaction-bench, est conçu avec le client le plus récent. Il génère deux fois plus de transactions par seconde que l’ancien outil de test de performances, bench-tps.

tpu-client-next est entièrement rétrocompatible et constitue désormais l’implémentation par défaut des nœuds Agave. En cas de problème, les opérateurs peuvent revenir au comportement précédent en lançant leur nœud avec le flag --use-connection-cache afin de restaurer l’ancienne implémentation.

En résumé, tpu-client-next offre :

• Une architecture à base d’agents adaptée au traitement asynchrone
• Un trafic régulier avec une gigue réduite
• Une utilisation réduite du CPU et de la mémoire
• Des politiques configurables de planification et de mise en file d’attente
• Une intégration simplifiée et une surface d’API plus claire

Calendrier des leaders indexé par les comptes de vote

Dans le cadre du cycle de publication d’Agave 2.3, Solana activera SIMD-0180: Use Vote Account Address To Key Leader Schedule. Cette modification change la façon dont le réseau détermine quels validateurs doivent produire des blocs : le calendrier des leaders utilisera désormais les adresses des comptes de vote comme clé principale, au lieu des adresses d’identité des validateurs.

Cette migration résout une ambiguïté de longue date dans le protocole Solana : l’impossibilité d’associer de façon fiable un validateur producteur de blocs à un stake précis. Dans la conception actuelle, le calendrier des leaders est indexé par les adresses d’identité des validateurs. Cependant, plusieurs comptes de vote peuvent déléguer à la même identité de validateur, ce qui complique l’association de la production du bloc d’un slot donné à un ensemble précis de stakes délégués.

En indexant plutôt le calendrier des leaders par les adresses des comptes de vote, cette modification établit un lien clair et direct entre le stake délégué et le rôle de leader du validateur. Ce changement en apparence mineur ouvre la voie à plusieurs fonctionnalités importantes.

Tout d’abord, il fournit la base nécessaire à la distribution des récompenses de bloc, comme indiqué dans SIMD-0123, qui a fait l’objet d’un vote formel de gouvernance en mars. Les validateurs peuvent ainsi définir un taux de commission sur les frais de bloc et distribuer les revenus restants proportionnellement entre les délégants. Ce système reprend le modèle de partage des récompenses déjà utilisé pour les récompenses inflationnistes de staking, ce qui harmonise davantage les incitations économiques des validateurs et de leurs stakers.

Ensuite, l’utilisation des adresses des comptes de vote pour indexer le calendrier des leaders est essentielle à l’activation de la pénalisation programmatique, qui sanctionne les validateurs enfreignant les règles du réseau en soumettant des blocs en double ou en votant sur plusieurs forks. Cela nous amène naturellement à la prochaine mise à jour.

Vérification des événements passibles de pénalisation

Le slashing est un mécanisme qui sanctionne les validateurs malveillants en vérifiant leur comportement fautif on-chain et en brûlant une partie du stake qui leur est délégué. Il constitue un moyen de dissuasion essentiel contre les comportements qui menacent la sécurité ou la stabilité du réseau.

Il existe deux principaux modèles de slashing :

Slashing social (système actuel sur Solana)

Solana repose actuellement sur une approche de consensus manuelle pilotée par la communauté, appelée slashing social. Selon ce modèle, si un validateur agit de manière malveillante, par exemple en compromettant la disponibilité ou la sécurité du réseau, les participants honnêtes peuvent se coordonner off-chain pour lancer un hard fork, redémarrer le réseau et réduire le stake du contrevenant. Si cette méthode permet une appréciation flexible au cas par cas, elle implique une importante charge de coordination et reste intrinsèquement réactive.

Slashing programmatique (slashing intégré au protocole)

À l’inverse, le slashing programmatique est entièrement appliqué on-chain. Si un validateur enfreint les règles du protocole, une preuve cryptographique de l’infraction peut être soumise à un programme dédié, qui déclenche alors automatiquement le slashing. Ce modèle réduit la dépendance à la coordination humaine et permet de sanctionner les infractions mineures sans perturber le fonctionnement du réseau, ouvrant la voie à une responsabilisation décentralisée et évolutive.

Le slashing comprend deux étapes clés :

• Détection et attribution des fautes : identifier le comportement fautif et le validateur responsable.
• Application de la sanction : sanctionner économiquement le contrevenant en réduisant son stake et en le tenant responsable.

Dans le cadre du cycle de publication d’Agave 2.3, Solana prévoit d’activer une feature gate pour le Slashing Program, comme indiqué dans la SIMD : SIMD-0204: Slashable Event Verification. Il s’agit de la première étape vers l’activation du slashing programmatique sur Solana, avec un accent mis sur la détection et l’attribution des fautes. Cette mise à jour introduit un programme on-chain qui permet à chacun de signaler et de consigner les comportements passibles de slashing, préparant ainsi le terrain pour une application automatisée à l’avenir.

Ce programme ne modifie ni les stakes ni les récompenses ; il se contente de vérifier et de consigner les infractions, constituant ainsi un registre on-chain des comportements fautifs des validateurs. Un premier prototype du programme a été déployé sur le Testnet (par exemple, un exemple de transaction DuplicateBlockProof). 

Dans un premier temps, le programme se concentrera sur la détection et la consignation de la production de blocs en double. La prise en charge d’autres infractions, telles que le double vote, est prévue ultérieurement. Point essentiel, le slashing programmatique se limite aux comportements fautifs pouvant être clairement prouvés. Par conséquent, l’application de sanctions pour des problèmes plus subjectifs ou systémiques, tels que la production volontairement lente de blocs ou l’extraction de MEV, est nettement plus complexe et ne sera probablement pas prise en charge par le programme de slashing.

Les preuves soumises comprennent deux shreds contradictoires pour le même slot, tous deux signés par le même validateur. Le programme de slashing vérifie la preuve en s’assurant que les shreds constituent une preuve valide de bloc en double, qu’ils appartiennent au même slot et qu’ils sont correctement signés par le validateur fautif. Cette logique reprend l’approche utilisée dans le protocole gossip de Solana pour traiter les preuves de blocs en double dans le processus de sélection des forks. 

Une fois la preuve vérifiée, les résultats sont stockés dans une Program-derived Address (PDA) pour consultation ultérieure. Il devient ainsi facile de créer des tableaux de bord présentant les données relatives au slashing en exécutant simplement getProgramAccounts sur le programme de slashing. Les validateurs peuvent l’utiliser pour vérifier s’ils ont été signalés pour des infractions et prendre les mesures correctives nécessaires.

Une prochaine SIMD traitera de l’application économique du slashing, notamment des paramètres tels que la pénalité de stake pour les différentes infractions. Comme ces décisions ont une incidence sur l’économie de l’exploitation d’un validateur Solana, toute modification proposée devra être approuvée par un vote complet de gouvernance.

Transitions d’époque plus rapides

Agave 2.3 améliore considérablement la vitesse des transitions d’époque. Les calculs des récompenses d’époque sont désormais effectués en moins de 500 millisecondes. Cela réduit le nombre de slots ignorés et rend l’inclusion des transactions plus fiable autour de la limite d’époque.

De plus, si le premier slot de leader d’une nouvelle époque est ignoré, Agave 2.3 veille à ce que les calculs de récompenses ne soient pas exécutés à nouveau. Les résultats précédemment calculés sont réutilisés, ce qui élimine les calculs redondants et facilite le démarrage de la nouvelle époque.

Optimisations d’AccountsDB

L’efficacité du stockage a été considérablement améliorée dans cette version. L’utilisation des E/S disque a diminué d’environ 75 %, tandis que le volume des demandes de réparation a baissé d’environ 85 %. Ensemble, ces optimisations assurent des performances de nœud plus régulières et fiables, en particulier pendant les périodes de forte charge du réseau.

Planificateur glouton activé par défaut

Dans Agave 2.3, le planificateur glouton est désormais activé par défaut. L’ancien planificateur central devenait souvent un goulot d’étranglement lorsque le réseau était fortement chargé, en raison du temps nécessaire au tri des transactions et à la construction d’un graphe de dépendances. La nouvelle approche gloutonne accélère considérablement la planification des transactions grâce à une logique simplifiée et à des lots plus petits.

Pour en savoir plus sur le planificateur glouton, consultez notre précédent article du blog Helius.

Version de shred du gossip

Agave 2.3 impose une correspondance plus stricte des versions de shred dans le réseau gossip. Les nœuds ne peuvent désormais établir des connexions gossip entrantes que si leur version de shred correspond à celle du cluster, ce qui permet de rejeter rapidement les nœuds mal configurés.

Auparavant, les nœuds espions pouvaient rejoindre le réseau sans utiliser la même version de shred que le cluster. Avec ce changement, tous les nœuds, y compris ceux en mode espion, doivent obtenir la bonne version de shred, soit depuis un point d’entrée du cluster, soit en la définissant explicitement via la ligne de commande.

Cette mise à jour s’inscrit dans le prolongement des efforts récents visant à réduire la surcharge du gossip. Ces derniers mois, le trafic gossip entrant a diminué d’environ 61 %, grâce à l’abandon de trois types de messages gossip et à la suppression de la diffusion des slots d’époque par les validateurs sans stake.

Les simulations RPC incluent l’utilisation des ressources

Afin d’améliorer la visibilité sur l’utilisation des ressources par les transactions, un nouveau champ a été ajouté à la méthode RPC `simulateTransaction` par défaut : `loadedAccountsDataSize`. Ce champ indique le nombre total d’octets de données de comptes chargés pendant la simulation.

Cet ajout permet aux développeurs d’estimer le coût des transactions et d’ajuster les frais de priorité avec une plus grande précision. Le chargement des données de comptes consomme des unités de calcul (CU) à raison de 8 CU par tranche de 32 Ko, selon la taille d’allocation des pages du tas de Solana. En exposant cette métrique, les développeurs peuvent mieux optimiser les coûts lors de la création et de l’envoi de transactions.

Améliorations des snapshots

Les snapshots servent de points de sauvegarde périodiques et permettent aux nœuds de restaurer leur état. Les nœuds génèrent continuellement ces snapshots et remplacent progressivement les anciennes versions par de nouvelles.

Cette version apporte plusieurs améliorations pratiques au fonctionnement des snapshots :

• Mise à jour de l’intervalle par défaut : l’intervalle par défaut entre les snapshots complets est passé de 25 000 à 50 000 slots, ce qui réduit leur fréquence de création.
• Nouveau flag pour désactiver les snapshots : un nouveau flag `--no-snapshots` permet de désactiver explicitement la génération de snapshots. L’ancienne méthode utilisant `--snapshot-interval-slots 0` est désormais obsolète.
• Amélioration du comportement de Geyser : lors d’une restauration à partir d’un snapshot, les notifications de comptes envoyées via Geyser ne sont plus dédupliquées.

L’allongement de l’intervalle entre les snapshots offre également des performances disque plus régulières en réduisant les pics d’IOPS (opérations d’entrée/sortie par seconde).

Améliorations de la chaîne d’outils SBPF

Agave 2.3 apporte plusieurs améliorations pratiques aux développeurs qui utilisent la chaîne d’outils SBPF :

• Ciblage des versions : les développeurs peuvent désormais cibler explicitement des versions précises de la VM BPF (v0 à v3) lors de la compilation des programmes, ce qui leur offre un meilleur contrôle.
• Rust uniquement pour SBPFv3 : à partir de SBPFv3, seule la chaîne d’outils basée sur Rust est prise en charge. L’ancienne chaîne d’outils C n’est plus compatible avec les versions futures.
• Nouveau flag d’optimisation : un nouveau flag de build `--optimize-size` a été ajouté afin de générer des binaires de programme plus petits pour le déploiement. Cela peut réduire les besoins en stockage, mais aussi augmenter légèrement l’utilisation des unités de calcul (CU).

Autres changements

Cette version comprend également les mises à jour suivantes :

• Récupération automatique du cluster : une nouvelle fonctionnalité de récupération du cluster, `wen-restart`, permet désormais de déclencher automatiquement le redémarrage d’un cluster en cas de plantage de la chaîne.
• Mise à jour de l’ABI de journalisation : l’ABI de journalisation `TimedTracedEvent` a été mise à jour avec de nouveaux diagnostics. Les validateurs doivent donc mettre à jour tous les outils externes de traçage ou d’analyse qui utilisent ces journaux afin de garantir leur compatibilité. Les données de trace existantes doivent être effacées après la mise à niveau pour éviter les incompatibilités de format.
• Améliorations de la CLI : ajout de withdraw-stake AVAILABLE pour simplifier le retrait de tous les lamports non stakés, et mise à jour de solana-test-validator afin de lier par défaut les services RPC à localhost (127.0.0.1) pour renforcer la sécurité.
• Démarrage plus rapide : les temps de démarrage des validateurs ont été considérablement réduits. Les nœuds mettent désormais environ 3 minutes à démarrer et à charger le registre, puis environ 5 minutes à rattraper la tête de la chaîne. Cependant, fastboot exige désormais un arrêt propre à l’aide du nouveau flag --wait-for-exit. Les opérateurs doivent laisser le processus du validateur se terminer entièrement de lui-même avant de le redémarrer, au lieu d’émettre immédiatement une commande de redémarrage.

Conclusion

Agave 2.3 marque une nouvelle étape majeure pour le protocole Solana. Parmi les principales nouveautés figurent le lancement d’un nouveau client TPU (`tpu-client-next`), une réduction significative des E/S disque grâce aux optimisations d’AccountsDB, de meilleures performances des snapshots, des améliorations du réseau gossip, ainsi que des transitions d’époque et des temps de démarrage plus rapides. Ensemble, ces mises à jour renforcent la robustesse du réseau tout en améliorant l’expérience des développeurs et des opérateurs de validateurs.

Solana continue de progresser régulièrement vers un réseau multiclient robuste, avec plus de 8 % du stake total utilisant Firedancer, et cette part ne cesse d’augmenter. Près d’un an et demi de fonctionnement sans interruption témoigne de la maturité et de la stabilité croissantes des logiciels fondamentaux du réseau. Parallèlement, le rythme des versions majeures et mineures s’accélère.

Prochaine étape : Agave 3.0 !

Ressources complémentaires

• Calendrier de publication d’Agave 2.3
• Journal des modifications d’Agave 2.3
• Pull requests d’Agave 2.3
• Notes de mise à jour d’Agave 2.3 - Blog Anza 
• Présentation de tpu-client-next - Appel de la communauté Solana Core, 20 juin 2025