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

Résumé d’Agave 2.0

La sortie de la version 2.0 du client de validation Agave marque une étape importante dans l’évolution de Solana vers un écosystème multiclient plus robuste. Cette mise à jour apporte plusieurs améliorations essentielles afin d’accroître les performances, la fiabilité et l’efficacité du réseau. Ses principales nouveautés sont les suivantes :

• Refactorisations et optimisations approfondies de la base de code
• Récompenses d’époque partitionnées
• Attribution de l’intégralité des frais de priorité aux validateurs
• Activation par défaut du nouveau planificateur central
• Le programme ZK ElGamal Proof
• Appel système Get-Sysvar
• Appel système GetEpochStake
• MoveStake et MoveLamports
• Suppression des méthodes RPC obsolètes
• Renommage de crates

Que vous exploitiez un validateur, développiez sur la plateforme ou utilisiez activement Solana, cette présentation complète de la mise à jour Agave 2.0 vous donnera les clés nécessaires pour comprendre et exploiter ces dernières innovations.

Pourquoi Agave 2.0 est-elle une mise à jour majeure ?

Il n’existe désormais plus un seul et unique « validateur Solana ». Agave 2.0 adopte le nouvel environnement multiclient de Solana et marque une rupture nette avec l’ancien dépôt GitHub de Solana Labs. Le dépôt Solana Labs sera archivé et n’acceptera plus de nouvelles pull requests ni de nouveaux tickets. Auparavant, ce dépôt reflétait l’activité du dépôt Agave. Si ce n’est pas encore fait, les développeurs doivent transférer toutes leurs activités vers le dépôt GitHub Anza Agave. Le processus de migration de Solana Labs vers Agave a débuté le 1er mars et son suivi est public sur leur GitHub.

À mesure que l’écosystème évolue, les opérateurs doivent s’adapter à l’exécution d’un ou de plusieurs clients. Dans le cadre de cette transition, plusieurs crates sont renommées afin de libérer l’espace de noms pour prendre en charge plusieurs clients, notamment Firedancer, géré par des équipes de développement indépendantes. Les crates maintenues par Anza porteront désormais le préfixe « agave », ce qui permettra de les identifier facilement comme des dépendances propres à Anza dans l’environnement multiclient.

‍Les crates concernées sont : 

• solana-validator
• solana-ledger-tool
• solana-watchtower
• solana-install
• solana-geyser-plugin-interface
• solana-cargo-registry

Comme l’explique notre précédent guide de transition, la mise à jour 2.0 introduit plusieurs changements incompatibles, notamment la suppression de plusieurs endpoints obsolètes et dépréciés. Tous les développeurs Solana devraient désormais connaître ces changements majeurs. Les détails complets des modifications apportées aux RPC figurent à la fin de cet article.

Déploiement des fonctionnalités

Au moment de la rédaction de cet article, ~20,7 % des validateurs exécutent la version 2.0.14. Les activations par feature gate sur le mainnet sont temporairement suspendues afin que l’adoption de la v2.0 s’aligne davantage sur les activations du testnet et du devnet. Une fois la v2.0 largement adoptée par le cluster mainnet, les activations par feature gate devraient reprendre selon l’ordre d’activation prévu. 

Les nouvelles fonctionnalités complètes présentées dans les sections suivantes ne sont pas encore actives. Elles seront progressivement déployées au cours du cycle de vie de la version 2.0 à l’aide d’un système de feature gates. Les fonctionnalités sont activées à certaines époques selon leur priorité relative et l’ordre dans lequel elles ont été activées sur les clusters testnet et devnet.

Attribution de l’intégralité des frais de priorité aux validateurs

Cette mise à jour économique très attendue et largement débattue est désormais mise en œuvre à la suite de la proposition SIMD-0096, soumise en mai au vote de gouvernance des validateurs. Le vote s’est achevé à la fin de l’époque 620, avec une participation représentant 51,17 % du stake et 77,77 % de votes favorables. Cette mise à jour protégée par une feature gate modifiera fondamentalement la gestion des frais de priorité par le réseau. Au lieu du modèle actuel, dans lequel 50 % des frais sont brûlés et 50 % sont attribués aux validateurs, le nouveau modèle versera directement 100 % des frais de priorité aux validateurs.

Bien que les frais de priorité soient techniquement facultatifs, ils sont devenus courants avec l’augmentation de l’activité économique sur Solana. Ces frais sont calculés en microlamports (millionièmes de lamport) par unité de calcul selon la formule suivante :

‍frais de priorité = prix de l’unité de calcul (microlamports) x limite d’unités de calcul

À l’avenir, tous les frais de priorité seront attribués aux producteurs de blocs. Cela permet de mieux aligner les incitations et réduit le risque que les validateurs concluent des accords hors protocole pour inclure des transactions, un problème déjà rencontré par le passé.

Même si la suppression de la destruction des frais augmente légèrement le taux d’inflation net de SOL, l’émission de nouveaux tokens par l’intermédiaire des récompenses de staking a un impact bien plus important. Pour une analyse plus détaillée de cette dynamique, consultez notre précédent article du blog Helius consacré au calendrier d’émission et d’inflation de Solana.

Récompenses d’époque partitionnées

Les récompenses d’époque partitionnées visent à répartir les récompenses de stake sur plusieurs blocs afin d’atténuer les problèmes de performance liés à la concentration de leur distribution dans le premier bloc de chaque nouvelle époque. Le principal goulot d’étranglement de ce processus réside dans l’obligation de réécrire les mises à jour dans le nombre croissant de comptes de stake actifs sur le réseau, qui s’élève désormais à environ 1,4 million.

Avec cette nouvelle approche, le calcul et la distribution des récompenses de stake à la limite d’une époque seront divisés en deux phases distinctes :

• Phase de calcul des récompenses : durant cette phase, les récompenses d’époque de tous les comptes de stake actifs sont calculées et leur distribution est divisée en lots planifiés.
• Phase de distribution des récompenses : les récompenses d’époque précalculées des comptes de stake actifs sont distribuées en conséquence.

Pour faciliter et surveiller le processus, un compte Sysvar, EpochRewards, suivra et vérifiera les distributions de récompenses tout au long de la phase de distribution. La Sysvar EpochRewards indique si la phase de distribution des récompenses est en cours et conserve les informations nécessaires pour reprendre la distribution lors d’un démarrage à partir d’un snapshot. 

Calcul des récompenses

Les récompenses seront calculées au premier bloc de l’époque. Une fois calculées, elles seront réparties en lots de distribution stockés dans la banque, puis distribués pendant la phase de distribution des récompenses.

Afin de réduire au minimum l’impact sur le temps de traitement des blocs pendant la phase de distribution des récompenses et de garantir que chaque bloc distribue un sous-ensemble des récompenses de manière déterministe, l’objectif est de distribuer 4 096 récompenses de stake par bloc. Pour se prémunir contre une croissance spectaculaire du nombre de comptes de stake, le nombre de blocs est plafonné à 10 % du nombre total de slots d’une époque. Le nombre de comptes par partition ne peut dépasser l’objectif de 4 096 que si ce plafond de blocs est atteint.

Distribution des récompenses

La distribution des récompenses commence immédiatement après la phase de calcul, à partir du deuxième bloc de l’époque. Les récompenses sont distribuées au début du bloc, avant le traitement normal des transactions.

Les utilisateurs peuvent donc voir les récompenses créditées sur leurs comptes de stake quelques blocs plus tard qu’auparavant. L’expérience globale reste toutefois similaire, car la durée prolongée du premier bloc à la limite de l’époque retardait déjà l’accès des utilisateurs à leurs comptes de stake. Cette approche présente un autre avantage : les transactions sans staking peuvent continuer à être traitées normalement, alors qu’elles étaient auparavant bloquées pendant la distribution des récompenses.‍

En raison du nombre relativement faible de comptes de vote, environ 1 500, le mécanisme actuel de distribution des récompenses de vote au premier bloc de la limite d’époque restera inchangé. Seules les récompenses de stake seront distribuées sur plusieurs blocs.

Le planificateur central est désormais activé par défaut

Introduit pour la première fois en tant que fonctionnalité dans la mise à jour v1.18, le planificateur central, auparavant appelé « le planificateur », n’était pas activé par défaut. Les opérateurs devaient l’activer à l’aide du flag --block-production-method central-scheduler lors du démarrage d’un validateur. Il est désormais activé par défaut. L’implémentation précédente du planificateur présentait plusieurs problèmes susceptibles de nuire aux performances. Les goulots d’étranglement du traitement des transactions entraînaient souvent des variations ou des incohérences dans leur ordonnancement et leur priorisation.

La nouvelle implémentation remplace l’ancien modèle composé de quatre threads bancaires indépendants, chacun gérant la priorisation et le traitement de ses propres transactions. Dans cette nouvelle structure, le planificateur central est le seul destinataire des transactions provenant de l’étape SigVerify de la TPU. Il crée une file d’attente prioritaire et déploie un graphe de dépendances, appelé prio-graph, afin de mieux gérer le traitement et la priorisation des transactions conflictuelles. Cette nouvelle conception améliore l’évolutivité et la flexibilité, en permettant d’augmenter le nombre de threads sans les risques antérieurs de multiplication des conflits de verrouillage. Le déploiement initial du planificateur central a généré de meilleures récompenses, augmentant ainsi les revenus de nombreux opérateurs. Notre précédent article Helius sur la mise à jour Solana v1.18 explique en détail le fonctionnement du planificateur central.

Programme ZK ElGamal Proof

Le programme ZK Token Proof, dont l’intégration était initialement prévue dans la version 1.17, est désormais déprécié. Il sera remplacé par un programme ZK ElGamal Proof plus polyvalent et indépendant des applications. Le nouveau programme ZK ElGamal Proof conserve les parties du programme ZK Token Proof qui s’appliquent à un large éventail d’applications, comme la vérification de la validité d’une clé publique ou de la plage de valeurs chiffrées dans un texte chiffré ElGamal. Il exclut toutefois les éléments propres à certaines applications, comme la validation de preuve à divulgation nulle de connaissance requise pour les instructions de transfert SPL Token. Le nouveau programme ZK ElGamal Proof sera ajouté à la liste des programmes intégrés à l’adresse ZkE1Gama1Proof11111111111111111111111111111

Pour en savoir plus sur le programme ZK Token Proof, consultez notre article d’origine sur le blog Helius.

Appel système Get-Sysvar

Les Syscalls, ou appels système, demandent des services au noyau du système d’exploitation. Dans le contexte de Solana, un appel système permet aux programmes exécutés dans la Solana Virtual Machine (SVM) d’interagir avec des ressources et des services externes. 

Les Sysvars exposent des informations sur l’état du cluster, comme le hash de bloc récent et les récompenses d’époque. Ces comptes sont renseignés à des adresses connues. Les programmes peuvent accéder aux Sysvars via un compte Sysvar ou les interroger par l’intermédiaire d’un appel système. Les programmes on-chain utilisent de nombreuses Sysvars pour un large éventail de cas d’usage, et certaines sont indispensables au fonctionnement du réseau.

L’appel système Get-Sysvar, initialement proposé dans la SIMD-127 par Joe Caulfield, ingénieur chez Anza, introduit une interface d’appel système unifiée pour accéder aux données Sysvar. Cette mise à niveau permet de récupérer des données Sysvar auparavant inaccessibles, notamment SlotHashes et StakeHistory. Grâce à cette nouvelle interface, les développeurs peuvent accéder à des fragments précis de données Sysvar, par exemple en appelant SlotHashes::get_slot(slot) et StakeHistory::get_entry(epoch), sans avoir à dupliquer des structures de données entières.

La mise à jour réduit également la surcharge liée à la modification de la structure des données Sysvar ou à l’ajout de nouvelles Sysvars. Auparavant, chaque nouvelle Sysvar nécessitait l’ajout d’un appel système correspondant. Ce couplage étroit alourdissait progressivement l’interface d’appel système et compliquait sa maintenance. Désormais, un seul appel système sol_get_Sysvar desservira toutes les interfaces Sysvar, permettant de récupérer les données de n’importe quelle Sysvar de manière cohérente et efficace.

L’introduction du nouvel appel système simplifie la modification et l’ajout de Sysvars. Elle réduit considérablement la complexité et les besoins de maintenance de l’interface d’appel système. Cette mise à jour ouvre également la voie à un accès élargi des programmes BPF aux données Sysvar, ce qui permettra aux programmes on-chain de lire davantage d’informations Sysvar sans augmenter la taille des transactions.

Appel système GetEpochStake

Le nouvel appel système GetEpochStake apportera une fonctionnalité très demandée pour récupérer le stake délégué à un compte de vote pendant l’époque en cours. Il offrira ainsi une méthode on-chain plus efficace et directe pour obtenir cette information.

À l’heure actuelle, les programmes ne peuvent pas accéder aux données en temps réel sur le stake délégué à des comptes de vote précis pendant l’époque en cours. Cela constitue un obstacle pour des cas d’usage comme la gouvernance des validateurs et les mécanismes de consensus secondaires. La possibilité d’interroger ces données on-chain débloquera ces applications et ouvrira la voie à de futurs cas d’usage.

Avec GetEpochStake, les développeurs fournissent l’adresse d’un compte de vote sur 32 octets, et l’appel système renvoie un entier u64 représentant le stake actif total actuellement délégué à ce compte de vote. Si l’adresse fournie ne correspond pas à un compte de vote valide ou n’existe pas, l’appel système renvoie simplement 0.

MoveStake et MoveLamports

Deux nouvelles instructions du programme de stake, MoveStake et MoveLamports, sont introduites afin de faciliter les transferts de valeur entre comptes de stake. Proposées pour la première fois dans la SIMD-0148, ces instructions permettent aux développeurs de transférer des fonds entre des comptes dont les autorités correspondent, sans contrôle de l’autorité de retrait.

Auparavant, les protocoles gérant les stakes des utilisateurs rencontraient des difficultés lorsqu’ils les répartissaient entre plusieurs validateurs et les redéléguaient régulièrement. Lorsqu’un protocole fractionne le stake d’un utilisateur en vue de sa désactivation, il doit financer les lamports nécessaires à l’exemption de loyer du nouveau compte. Le protocole ne peut pas récupérer ces lamports d’exemption de loyer lors de la fusion des comptes fractionnés.

MoveStake

MoveStake : cette instruction permet de déplacer un stake actif entre des comptes, en le transférant d’un compte actif à un autre ou d’un compte actif vers un compte inactif, réactivant ainsi ce dernier. Si l’intégralité de la délégation du compte source est déplacée, celui-ci devient inactif. Le solde exonéré de loyer reste inchangé dans tous les scénarios, et les règles de délégation minimale restent applicables aux comptes actifs.

MoveLamports

MoveLamports : déplace les lamports excédentaires d’un compte actif ou inactif vers un autre compte actif ou inactif. Les « lamports excédentaires » désignent les lamports qui ne constituent ni un stake délégué ni une somme requise pour l’exemption de loyer. MoveLamports permet d’effectuer des tâches de maintenance, comme récupérer les lamports de comptes fusionnés et regrouper les fonds inutilisés.

Afin de simplifier l’implémentation, ces changements ne permettent pas d’activer ou de désactiver des comptes et n’affectent pas les comptes de stake partiellement actifs. Ces nouvelles instructions de programme ne modifient pas les fonctionnalités existantes.

Bonus : la crate Solana-SVM

La sortie d’Agave 2.0 s’accompagne d’une toute nouvelle crate solana-svm, qui offre aux développeurs un accès direct aux composants essentiels de la SVM par l’intermédiaire d’une API simplifiée et indépendante de l’environnement complet du validateur. Elle rend le traitement haute performance des transactions de Solana accessible à des applications autres que le validateur, comme les services off-chain, les clients légers, les canaux d’état et les rollups.

En découplant l’API du reste du runtime, cette crate élimine le besoin de composants tels que les instances Bank et réduit ainsi la surcharge opérationnelle. Les développeurs peuvent désormais exploiter les mêmes composants robustes que ceux qui prennent en charge le mainnet-beta de Solana pour créer des projets SVM personnalisés, tels que des clients légers, des canaux d’état, des rollups et des services off-chain. Au cœur de cette API se trouve la structure TransactionBatchProcessor, qui permet aux applications de traiter des lots de transactions Solana assainies avec l’ensemble complet des composants Agave en aval, notamment BPF Loader, eBPF et la machine virtuelle.

Consultez l’analyse approfondie de la nouvelle API SVM d’Anza pour tout savoir sur cette évolution prometteuse.

Endpoints RPC supprimés 

Plusieurs endpoints RPC Agave v1 obsolètes et dépréciés ont été supprimés. L’équipe DevRel de Helius a contacté tous les clients qui les utilisaient. Une analyse interne nous avait permis d’identifier un petit groupe de clients utilisant activement les endpoints suivants, dont la suppression était prévue :

• getRecentBlockhash
• getConfirmedSignatureForAddresses2
• getConfirmedTransaction
• getConfirmedBlock
• getStakeActivation
• getFees

N.B. L’approche alternative pour getAccountInfo présentée dans l’image est disponible ici.

Les changements incompatibles du SDK comprennent :

• Suppression de la prise en charge de Borsh v0.9, veuillez utiliser v1 ou v0.10 (#1440)
• Le trait Copy n’est plus dérivé pour Rent et EpochSchedule ; utilisez clone()
• solana-sdk : suppression des symboles dépréciés) 
• solana-program : suppression des symboles dépréciés

Pour les opérateurs de validateurs, plusieurs arguments de validateur dépréciés seront supprimés avec la sortie d’Agave v2.0. Vous trouverez leur liste complète ici.‍

Conclusion

La mise à jour Agave 2.0 marque une avancée majeure pour Solana avec l’implémentation de nombreuses fonctionnalités et optimisations du runtime. Cette version repousse encore les limites grâce à de nouveaux appels système puissants, des fonctionnalités étendues et une maintenance complète, notamment le renommage de crates, la suppression de méthodes RPC dépréciées et la simplification des arguments de validateur. Agave 2.0 étend les capacités de Solana tout en améliorant ses performances et sa facilité d’utilisation. Que vous soyez développeur, validateur ou utilisateur actif, la mise à jour Agave 2.0 ouvre de nouvelles possibilités prometteuses pour l’ensemble de l’écosystème Solana.

Ressources supplémentaires

• Calendrier de sortie d’Agave v2.0
• Journal des modifications d’Agave v2.0
• Versions d’Agave