Mise à jour Agave 3.0 : tout ce que vous devez savoir

Introduction

La version majeure Agave v3.0 marque une nouvelle étape pour Solana. Elle introduit plusieurs améliorations visant à optimiser les performances du réseau, l’exploitation des validateurs et l’expérience développeur.

Principales nouveautés d’Agave 3.0 

• Refonte du cache : accélère le traitement des transactions de 30 à 40 %
• Limite de calcul par compte plus élevée : porte la limite d’un compte unique à 40 % des CU d’un bloc
• Nouvelle structure TransactionView du planificateur : améliore l’efficacité de la planification
• eXpress Data Path (XDP) pour Turbine : un prérequis pour les blocs de 100 millions de CU
• Profondeur d’imbrication CPI accrue : fait passer la limite d’imbrication CPI de 4 à 8
• Assouplissement des contraintes d’entrée : simplifie la logique de planification et permet l’exécution asynchrone
• Démarrage plus rapide : les nœuds se remettent désormais en ligne plus rapidement
• Spécification de la taille des données de transaction chargées : standardise le calcul des données de transaction chargées
• Améliorations RPC : mises à jour en temps réel plus rapides et plus fiables pour les dApps utilisant les WebSockets PubSub

Chaque section de cet article est autonome, ce qui vous permet de vous concentrer sur les sujets les plus pertinents pour vous. Que vous exploitiez un validateur, développiez des applications ou participiez activement à la communauté, ce guide d’Agave v3.0 vous présente les principales nouveautés et informations nécessaires pour tirer pleinement parti des dernières améliorations.

Tendances liées aux clients

Avant d’examiner en détail les nouvelles fonctionnalités d’Agave v3.0, voyons comment les données récentes mettent en évidence les progrès du réseau Solana et du client Agave : cycles de publication plus rapides, adoption plus large des clients et performances solides sous pression.

Rythme de publication d’Agave

Anza a nettement accéléré son rythme de publication cette année, réduisant à moins de trois mois l’intervalle entre les versions mineures d’Agave. La série Agave 2.2.* n’est restée la version à supermajorité que pendant 11 semaines, et Agave 2.3 suit un calendrier similaire.

Réseau multiclient

L’adoption de Firedancer sur le mainnet a considérablement progressé ces derniers mois. Actuellement, 21,6 % du stake utilise le client Jito-Frankendancer, une part qui a augmenté lentement mais régulièrement tout au long de l’année (voir le graphique ci-dessous). L’adoption devrait se maintenir autour du seuil de 20 % jusqu’à ce que le client Firedancer complet soit prêt pour un déploiement en production sur le mainnet.

Il s’agit d’une étape majeure pour la stratégie multiclient de Solana, un objectif de longue date visant à améliorer la sécurité, la disponibilité et la résilience du réseau. Une plus grande diversité de clients offre davantage de choix aux opérateurs de validateurs, favorise une concurrence saine entre les équipes chargées des clients et multiplie les regards portés sur leurs bases de code. Elle réduit également le risque qu’un seul bug critique provoque une panne à l’échelle du réseau.

Il convient également de noter que le stake utilisant le client Agave standard, c’est-à-dire Agave sans modifications MEV tierces comme Jito, est passé d’environ 6 % au début de l’année à près de 2 % aujourd’hui. Dans le même temps, l’adoption de Paladin-Agave a progressé ces derniers mois et représente désormais environ 6 % du stake total.

Test de résistance du réseau

Le 10 octobre, le marché des cryptomonnaies a connu le plus important événement de liquidation de son histoire, provoquant une volatilité extrême sur toutes les principales blockchains. Malgré une hausse record de l’activité du réseau, le réseau Solana et le client de validation Agave ont fait preuve d’une résilience et d’une stabilité remarquables sous pression.

Au plus fort de l’activité, Solana a supporté un trafic six fois supérieur à la normale, tandis que les leaders recevaient environ 100 000 paquets de transactions par seconde, tout en produisant des blocs complets à la limite de 60 millions de CU.

Même dans ces conditions, Solana a affiché la dynamique de frais la plus stable parmi les principaux réseaux, tout en traitant un débit supérieur d’un ordre de grandeur. Le TPS réel (transactions hors vote) a dépassé 3 200 au pic d’activité.

Pendant la période de pointe d’environ deux heures, les frais de transaction médians (P50) de Solana n’ont atteint que 0,007 $, soit moins d’un centime. Les frais moyens ont brièvement atteint 0,10 $, tandis que les 1 % de transactions les plus coûteuses (P99) ont culminé juste au-dessus de 1,00 $. Ce comportement démontre l’efficacité des marchés de frais locaux, qui ont limité les frais élevés aux seules transactions interagissant avec des comptes très sollicités, sans affecter les utilisateurs ordinaires effectuant de simples transferts, tels que des paiements en stablecoins.

À titre de comparaison, les frais médians sur le mainnet Ethereum et Arbitrum ont brièvement dépassé 100 $ par transaction pendant la même période. Base, la L2 exploitée par Coinbase, a également connu une envolée des frais, avec une médiane culminant à plus de 3 $. Ces réseaux ne disposent pas de marchés de frais locaux et appliquent des ajustements globaux qui augmentent uniformément les coûts pour tous les utilisateurs lorsque le réseau est sous tension.

Croissance de l’état

Solana a récemment franchi une étape majeure dans la croissance de son état on-chain, en dépassant un milliard de comptes au total. Près de 67 % de ces comptes appartiennent au Token Program, dont 89,45 % sont des comptes de jetons associés et 10,55 % des comptes d’émission de jetons.

Cette croissance continue de l’état a des conséquences à long terme pour les clients Solana et les fournisseurs d’infrastructure. À mesure que le nombre de comptes augmente, les besoins en stockage, la taille des snapshots et les exigences d’indexation des comptes progressent également, ce qui peut affecter les performances et les besoins matériels. Des solutions comme ZK Compression offrent une voie prometteuse à long terme pour réduire l’accumulation excessive de données d’état.

Nouveautés du cycle de publication d’Agave 3.0

Refonte du cache

Agave 3.0 réduit considérablement les opérations redondantes à l’exécution. Une refonte complète du cache des programmes élimine des centaines de recherches de comptes superflues par lot de transactions. Les benchmarks internes montrent ainsi un traitement des transactions environ 30 à 40 % plus rapide.

Augmentation de la limite par compte à 40 % des CU du bloc

Dans le cadre du cycle de publication d’Agave 3.0, Solana activera SIMD-0306 : augmentation des limites de CU par compte. La limite de CU par compte passera d’une constante fixe de 12 millions à 40 % de la limite de CU du bloc. Actuellement, chaque compte peut consommer jusqu’à 12 millions de CU par bloc. Comme le montre le graphique d’Anza ci-dessous, les comptes les plus sollicités atteignent souvent ce plafond.

Avec ce changement, la limite par compte passera d’abord de 12 à 24 millions de CU, puis à 40 millions de CU après l’activation de SIMD-0286 (blocs de 100 millions de CU). Associée à des nouveautés comme l’introduction du programme P-token, cette mise à niveau augmentera considérablement le débit des comptes très sollicités auxquels chaque bloc accède fréquemment.

Les autres contraintes resteront inchangées, notamment :

• Nombre maximal d’unités de vote : plafond du total de CU des transactions de vote par bloc, fixé à 36 millions de CU
• Variation maximale de la taille des données de comptes par bloc : limite du volume total de modifications des données de comptes par bloc, fixée à 100 mégaoctets.

Si l’augmentation du plafond de CU par compte améliore le débit pour les états très sollicités, elle peut également accroître le temps d’exécution séquentielle dans le pire des cas, et donc potentiellement allonger la vérification des blocs ou la durée des slots en période de forte charge.

Enfin, il convient de mentionner la récente proposition SIMD-0370 : suppression de la limite d’unités de calcul par bloc, qui envisage de supprimer entièrement les limites de bloc basées sur les CU. Cette orientation sera probablement réexaminée après la mise à niveau Alpenglow.

eXpress Data Path (XDP) pour Turbine

eXpress Data Path (XDP) est une technologie du noyau Linux conçue pour les réseaux hautes performances. Elle permet aux applications de contourner une grande partie du chemin standard de traitement des paquets du noyau, réduisant à la fois les copies de données intermédiaires et les changements de contexte entre les espaces utilisateur et noyau. En traitant directement les paquets avec la carte d’interface réseau (NIC) dans l’espace utilisateur, XDP réduit considérablement la surcharge par paquet.

La prise en charge de XDP dans Turbine a été introduite pour la première fois dans Agave v2.3.8 et sera activée par défaut à partir d’Agave 3.1. Turbine constitue le principal goulot d’étranglement en matière de scalabilité à mesure que les limites de bloc passent à 100 millions de CU. Les leaders relaient leurs shreds à 200 pairs, ce qui génère une forte charge réseau. Dans les conditions actuelles, les grands validateurs disposant de davantage de slots de leader peuvent approcher les 150 000 paquets sortants par seconde. XDP s’attaque directement à ce goulot d’étranglement en accélérant jusqu’à 100 fois l’envoi des paquets, ce qui permet aux validateurs de propager des blocs plus volumineux avec une efficacité nettement supérieure. 

Pour approfondir l’implémentation de XDP dans Agave, consultez le guide de configuration des validateurs ainsi que notre précédent entretien avec Alessandro Decina, ingénieur chez Anza, qui a dirigé l’intégration de XDP au client Agave.

Spécification de la taille des données de transaction chargées

Dans le cadre des efforts continus visant à simplifier et à standardiser le modèle d’exécution de Solana, SIMD-0186 : spécification de la taille des données de transaction chargées doit être activée sur le mainnet pendant le cycle de publication d’Agave 3.0.

Cette proposition introduit une méthode compatible avec le consensus pour calculer le volume total de données de comptes chargé par chaque transaction. L’objectif est de garantir que tous les clients de validation calculent des tailles de données de transaction identiques, afin d’éliminer les incohérences subtiles susceptibles d’entraîner une divergence du consensus.

Actuellement, la logique de calcul de la taille des données de transaction de Solana est excessivement complexe. L’implémentation existante traite de manière particulière les programmes LoaderV3 et BPF Upgradeable Loader, qui sous-estiment souvent la taille réelle des données de programme chargées. Ces écarts compliquaient l’implémentation d’une logique compatible par les équipes de clients indépendants.

Avec SIMD-0186, les règles de calcul de la taille sont désormais explicites et faciles à comprendre :

• Chaque compte chargé est comptabilisé exactement une fois
• Les programmes utilisant BPF Upgradeable Loader incluent les données de programme associées
• La taille de chaque compte chargé correspond à la longueur en octets de ses données avant l’exécution de la transaction, à laquelle s’ajoutent 64 octets de métadonnées
• Chaque table de recherche d’adresses (ALT) ajoute un montant fixe de 8 248 octets

Cette spécification standardise le calcul de la taille des transactions entre tous les clients et rend le comportement des transactions plus prévisible pour les développeurs.

La limite de taille des données chargées remplit un rôle similaire à la limite de CU par transaction, en assurant une comptabilisation prévisible des ressources pour les nœuds de validation. Par défaut, chaque transaction peut charger jusqu’à 64 Mo de données de comptes et consomme huit unités de calcul (CU) par tranche de 32 Ko chargée, soit un coût de base de 16 000 CU, même si le volume réellement chargé est inférieur. Les développeurs peuvent réduire cette limite à l’aide de l’instruction setLoadedAccountsDataSizeLimit afin de diminuer le coût de calcul et d’améliorer l’efficacité de la planification.

Comme la nouvelle méthode de calcul de la taille peut produire des valeurs différentes selon la structure de la transaction, les développeurs devront peut-être ajuster la limite de taille des données de comptes chargées indiquée dans leurs instructions de budget de calcul.

Structure TransactionView du planificateur

Avec Agave 3.0, le planificateur introduit une nouvelle structure de données légère appelée TransactionView, conçue pour simplifier l’analyse et le traitement des transactions. Contrairement aux anciens types de transactions du SDK, qui nécessitaient une désérialisation et plusieurs allocations de mémoire, TransactionView fournit une vue directe d’une transaction sérialisée. Cette structure analyse et met en cache les métadonnées relatives à l’organisation de la transaction sans réellement la désérialiser.

Démarrage plus rapide

Les performances de démarrage du client continuent de progresser avec Agave v3.0, ce qui améliore nettement le quotidien des opérateurs de validateurs et de RPC. Qu’ils redémarrent après un plantage, une mise à niveau ou une opération de maintenance planifiée, les nœuds peuvent désormais se remettre en ligne beaucoup plus rapidement.

Lors d’un démarrage à partir d’une archive de snapshot, le délai a été réduit à moins de trois minutes et demie, soit moins de la moitié du temps nécessaire avec Agave v2.2 (voir le graphique ci-dessous). Cette amélioration représente un gain de performances essentiel : un démarrage plus rapide renforce directement la résilience du réseau et la disponibilité des validateurs en réduisant le temps nécessaire aux nœuds pour rejoindre le consensus.

À l’avenir, Agave v3.1 simplifiera davantage ce processus en supprimant la vérification des comptes en arrière-plan, ce qui permettra aux validateurs de commencer à voter dès le début de la relecture.

Augmentation de la limite d’imbrication CPI

SIMD-0268 : augmentation de la limite d’imbrication CPI fait passer la profondeur maximale des appels Cross-Program Invocation (CPI) de 4 à 8. Cette mesure double le nombre de fois qu’un programme Solana peut appeler d’autres programmes au sein d’une même transaction.

CPI est le mécanisme par lequel un programme Solana en appelle un autre. Cette fonctionnalité fondamentale de l’environnement d’exécution de Solana permet aux programmes de s’appuyer sur la logique les uns des autres.

Les protocoles on-chain complexes, comme les swaps perpétuels, les portefeuilles intelligents et les systèmes de marge croisée, reposent souvent sur plusieurs couches d’interactions entre programmes pour gérer les positions, les liquidations et les risques. L’ancienne limite CPI de 4 niveaux restreignait ces architectures et obligeait parfois les développeurs à répartir la logique entre plusieurs transactions.

Les applications existantes continueront de fonctionner comme auparavant, sauf si leur logique dépend de l’ancienne limite pour faire échouer des transactions. Dans l’ensemble, cette modification très demandée élargit les possibilités de conception offertes aux développeurs et renforce la composabilité de Solana.

Assouplissement des contraintes d’entrée

SIMD-0083 : assouplissement des contraintes d’entrée, dont l’activation est prévue avec Agave 3.0, supprime la règle interdisant les conflits entre les transactions d’une même entrée de bloc. Auparavant, toute entrée contenant des transactions en conflit, c’est-à-dire écrivant toutes deux sur le même compte ou dont l’une lit un compte pendant que l’autre y écrit, invalidait l’intégralité du bloc.

Avec cette mise à jour, ces conflits sont désormais autorisés. Lorsqu’ils se produisent, les transactions sont simplement exécutées l’une après l’autre, dans leur ordre d’apparition. Ce changement simplifie les règles de remplissage des blocs et offre aux leaders davantage de flexibilité pour ordonner les transactions et construire les blocs. Il est également indispensable pour permettre à Solana d’implémenter l’exécution asynchrone.

Améliorations RPC

Agave v3.0 améliore la réactivité du serveur d’abonnement, qui donne désormais la priorité aux messages entrants, tels que les demandes d’abonnement et les PINGs, par rapport aux notifications sortantes. Ce changement fournit des mises à jour en temps réel plus rapides et plus fiables aux dApps utilisant les WebSockets PubSub.

De plus, les propriétés des slots ont été ajoutées aux données d’erreur relatives aux récompenses d’époque, ce qui améliore le débogage et l’observabilité pour les développeurs.

Autres changements

• À partir d’Agave v3.0.0, Anza ne publie plus de binaires agave-validator précompilés. Les opérateurs de validateurs doivent désormais compiler les binaires à partir du code source en suivant les instructions de compilation fournies.
• Avec Agave v3.0, l’intervalle par défaut entre les snapshots a été porté à 100 000 slots, contre 50 000 dans la v2.3 et 25 000 dans la v2.2. L’augmentation de cet intervalle améliore considérablement les performances du disque en réduisant les pics d’IOPS (opérations d’entrée/sortie par seconde) lors de la création des snapshots.
• De nombreux anciens arguments et flags CLI obsolètes ont été supprimés (liste complète ici).
• Actuellement, une instruction d’avancement du nonce dans une transaction peut désigner n’importe quel compte de la transaction comme compte à avancer. Après l’activation du feature gate de SIMD-0242 : compte de nonce statique uniquement, l’instruction d’avancement du nonce ne pourra faire avancer qu’un compte inclus statiquement.

Conclusion

Agave v3.0 est une mise à niveau majeure du client. Elle accélère le traitement des transactions, augmente les limites de calcul, améliore l’efficacité du planificateur et apporte plusieurs optimisations aux validateurs et aux RPC. Ensemble, ces nouveautés renforcent les performances du réseau et l’expérience développeur.

Les données récentes confirment également ces progrès : des cycles de publication plus rapides, une diversité croissante des clients et une stabilité exceptionnelle du réseau en période de forte demande témoignent de la maturité de Solana. Maintenant qu’Agave 3.0 alimente le réseau, Solana continue de démontrer sa capacité à passer à l’échelle.

Ressources complémentaires

• Calendrier de publication d’Agave 3.0
• Calendrier de suivi des feature gates
• Journal des modifications d’Agave 3.0
• Pull requests d’Agave 3.0