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

Introduction

Agave v3.1, la dernière évolution du client Solana Agave, est disponible ! Cette mise à jour apporte un vaste ensemble d’améliorations qui renforcent les performances du client, l’exploitation des validateurs et l’expérience développeur. Elle comprend également l’activation de plusieurs feature gates importantes qui préparent la distribution des récompenses de bloc au sein du protocole, une réduction significative des dépôts d’état (c’est-à-dire le loyer) et, surtout, la prochaine mise à niveau du consensus Alpenglow.

Principales nouveautés d’Agave 3.1

• Réduction des E/S disque pendant le replay
• Redémarrages plus rapides du client
• Traitement des transactions 2 fois plus rapide
• Relèvement des limites d’informations de compte CPI*
• Compte de vote V4 des validateurs et mises à jour différées des commissions*
• Réduction du nombre de rounds ChaCha de Turbine*
• Nouveau pointeur vers les données d’instruction*
• Améliorations RPC

* mise à niveau contrôlée par une feature gate

Que vous exploitiez un validateur ou développiez des applications, ce guide vous fournit les informations nécessaires pour tirer pleinement parti des dernières améliorations. Chaque section de cet article est autonome, afin que vous puissiez vous concentrer sur les sujets les plus pertinents pour vous. 

Au moment de la rédaction, Agave 3.1.8 est considéré comme un candidat à la mise à niveau du mainnet (MUC), et Anza recherche des volontaires pour aider cette version à atteindre 25 % du stake. Opérateurs de validateurs : il est temps d’effectuer la mise à niveau !

Gains de performances du client

Cette version majeure d’Agave apporte de nombreux gains de performances. Nous présentons ci-dessous plusieurs des améliorations les plus importantes.

Réduction des E/S disque pendant le replay 

Agave 3.1 réduit considérablement l’activité du disque pendant le replay. L’image ci-dessous montre une fenêtre de profilage de 10 secondes pendant laquelle Agave 3.0 rejoue de véritables transactions du mainnet. Les opérations sur disque (représentées par des marqueurs rouges) dépassent 1 100 événements. Cela pose problème, car chaque accès au disque introduit un temps d’attente d’E/S, ce qui ajoute de la gigue aux opérations bancaires comme au replay. 

Avec Agave 3.1, les E/S disque pendant le replay sont considérablement réduites. Sur la même fenêtre de 10 secondes, on compte moins de 80 opérations sur disque, soit une baisse de 93 %. Cela améliore la stabilité du replay tout en réduisant l’usure des disques, ce qui contribue à prolonger leur durée de vie.

Redémarrages plus rapides du client

Les performances de redémarrage du client continuent de progresser de façon spectaculaire, principalement grâce aux optimisations apportées à AccountsDB. Avec les versions majeures d’Agave 1.*, les redémarrages prenaient couramment plus de 30 minutes. Les versions d’Agave 2.* ont ramené ce délai à moins de 10 minutes. Avec Agave 3.1, le temps de redémarrage diminue encore et passe désormais généralement sous la minute. À l’avenir, la prochaine version majeure, Agave 4.0, devrait faire passer ce délai sous les 30 secondes, améliorant davantage la disponibilité des validateurs et réduisant le temps de récupération après une maintenance ou une défaillance imprévue.

Traitement plus rapide des transactions

Agave 3.1 inclut des correctifs essentiels qui améliorent considérablement l’efficacité du traitement des transactions. Auparavant, des bugs dans le pipeline de traitement des transactions obligeaient les workers bancaires à consacrer trop de temps à la synchronisation avec la preuve d’historique plutôt qu’à l’exécution des transactions. En mode leader, le client ne planifiait donc activement aucune transaction pendant environ 61 % du temps.

Ces problèmes ayant été corrigés dans Agave 3.1, les threads des workers bancaires consacrent désormais ~91 % de leur temps au traitement des transactions. Celui-ci est donc deux fois plus rapide, ce qui améliore sensiblement le débit et l’utilisation du temps de leader.

Parmi les autres améliorations de performances à signaler, l’index des comptes est désormais entièrement conservé en mémoire par défaut. Les transitions entre époques ont également été considérablement améliorées et s’effectuent maintenant en moins de 400 ms, contre plus de deux secondes auparavant. Il en résulte beaucoup moins de slots ignorés lors des changements d’époque.

Renforcement du réseau

Anza investit massivement dans la résilience du client Agave grâce à des tests de charge continus, des exercices de red teaming et une surveillance de la situation en temps réel. Bien que les détails de ce travail soient restés confidentiels jusqu’à présent, le programme a suffisamment mûri pour que ces efforts importants puissent désormais être rendus publics. Une équipe dédiée d’invalidation chez Anza attaque activement le testnet public de Solana avec une nouvelle série de tests toutes les heures. 

Les tests se répartissent en deux grandes catégories. La première porte sur des scénarios de déni de service au niveau du réseau, en testant intensivement la gestion de la contre-pression et le délestage sous des conditions extrêmes. La seconde consiste à produire des blocs spécialement conçus contenant des transactions inhabituelles et hostiles afin de pousser la VM Solana dans ses retranchements.

Anza élabore systématiquement des scénarios d’attaque et développe les défenses correspondantes. Ce travail s’appuie sur des modèles de menace réalistes, fondés sur ce qu’un validateur malveillant, bien informé et disposant d’un stake raisonnable pourrait faire, ainsi que sur ce qu’un développeur externe sophistiqué et doté de moyens financiers importants pourrait tenter.

Ce niveau de préparation a été confirmé en décembre, lorsque Solana a résisté à une attaque DDoS majeure qui a duré plusieurs semaines et aurait atteint un pic de près de 6 Tbit/s, ce qui en fait l’une des plus grandes attaques jamais enregistrées contre un système distribué. Malgré son ampleur considérable, le réseau n’a subi que peu d’effets mesurables, avec des confirmations en moins d’une seconde et une latence de slot stable pendant toute la durée de l’attaque.

Relèvement des limites d’informations de compte CPI

L’activation de SIMD-0339 : augmentation de la limite d’informations de compte CPI sur le mainnet est prévue pendant le cycle de publication d’Agave 3.1. Cette modification multiplie presque par quatre la limite d’informations de compte pour les appels inter-programmes (CPI), qui passe de 64 à 255. Elle résout ainsi un problème de longue date pour les développeurs de programmes qui doivent transmettre de longues listes de comptes via des CPI. Les informations de compte sont les métadonnées de compte sérialisées transmises aux appels système CPI, ce qui permet au programme appelé de lire les comptes fournis par l’appelant.

Auparavant, les CPI étaient limités à seulement 64 informations de compte par appel système. Cette contrainte oblige les programmes à dédupliquer et à reconstruire les listes de comptes avant les appels CPI, ce qui ajoute de la complexité et une surcharge. En pratique, de nombreux programmes réels dépassent régulièrement ce seuil, par exemple les wrappers d’agrégateurs DEX comme DFlow ou Jupiter.

Outre le relèvement de la limite, cette feature gate introduit des modifications des coûts en unités de calcul, qui évoluent selon le nombre d’informations de compte et de comptes d’instruction transmis à un CPI. Les programmes restent ainsi incités à limiter leur utilisation des comptes. 

Comme seule la limite est relevée, cette modification est entièrement rétrocompatible et n’affecte pas le comportement des programmes existants.

Compte de vote V4 des validateurs et mises à jour différées des commissions

Deux mises à jour contrôlées par des feature gates et dont l’activation est prévue pendant le cycle de publication d’Agave 3.1 sont particulièrement importantes pour les opérateurs de validateurs. La première est SIMD-0185 : compte de vote V4, qui introduit une nouvelle version de l’état du compte de vote afin de prendre en charge les prochaines mises à niveau du protocole, notamment Alpenglow, la distribution des revenus de bloc et l’amélioration des commissions.

Aujourd’hui, les comptes de vote ne stockent qu’un seul taux de commission. Toutefois, avec la future possibilité de distribuer les revenus de bloc au sein du protocole, décrite dans SIMD-0123 : partage des revenus de bloc, les validateurs devront pouvoir définir des taux de commission distincts pour différentes sources de revenus.

En outre, tous les revenus issus des frais de bloc, y compris les frais de base et de priorité, sont actuellement déposés sur le compte d’identité du validateur. Cela peut soulever des problèmes opérationnels et de sécurité, car ce compte ne peut pas être un portefeuille froid : il doit fréquemment signer des messages pour des protocoles réseau essentiels tels que Turbine et Gossip.

Le compte de vote V4 lève ces contraintes en ajoutant de nouveaux champs à l’état de vote (voir le bloc de code ci-dessous). Ceux-ci permettent aux validateurs de configurer à la fois le taux de commission et le compte collecteur pour les récompenses d’inflation et les revenus de bloc. La mise à jour supprime également l’ancien champ prior_voters.

pub struct VoteStateV4 {
    pub node_pubkey: Pubkey,
    pub authorized_withdrawer: Pubkey,

    /// REMOVED
    /// commission: u8,

    /// NEW: the collector accounts for validator income
    pub inflation_rewards_collector: Pubkey,
    pub block_revenue_collector: Pubkey,

    /// NEW: basis points (0-10,000) that represent how much of each income
    /// source should be given to this VoteAccount
    pub inflation_rewards_commission_bps: u16,
    pub block_revenue_commission_bps: u16,

    /// NEW: reward amount pending distribution to stake delegators
    pub pending_delegator_rewards: u64,

    /// NEW: compressed bls pubkey for alpenglow
    pub bls_pubkey_compressed: Option<[u8; 48]>

    pub votes: VecDeque<LandedVote>,
    pub root_slot: Option<Slot>,

    /// UPDATED: serialization structure of the AuthorizedVoters map is
    /// unchanged but will now contain entries for the previous epoch.
    pub authorized_voters: AuthorizedVoters,

    /// REMOVED
    /// prior_voters: CircBuf<(Pubkey, Epoch, Epoch)>,

    pub epoch_credits: Vec<(Epoch, u64, u64)>,
    pub last_timestamp: BlockTimestamp,
}

Dans le cadre de cette mise à jour, les valeurs de commission seront stockées en points de base. Toutefois, l’instruction UpdateCommission existante du Vote Program ne prend en charge que des valeurs de commission exprimées en pourcentages entiers. Jusqu’à l’adoption de SIMD-0291 : taux de commission en points de base, les taux de commission resteront limités à des pourcentages entiers. Pour l’instant, les calculs de commission doivent donc continuer à utiliser des valeurs de pourcentage entières.

Les outils et programmes existants qui lisent l’état de vote, y compris le programme de stake, seront mis à jour pour prendre en charge la nouvelle version du compte de vote.

Mises à jour différées des commissions

La deuxième mise à jour contrôlée par une feature gate qui est importante pour les opérateurs de validateurs est SIMD-0249 : report des mises à jour des commissions. Cette modification permet aux validateurs de soumettre des mises à jour de commission à tout moment, tout en garantissant qu’elles ne prennent effet qu’après au moins une époque complète.

Le programme de vote sera modifié afin de supprimer la restriction actuelle qui empêche d’augmenter les commissions pendant la première moitié d’une époque. Au lieu de limiter le moment où une modification de commission peut être soumise, le protocole impose un délai avant son entrée en vigueur. Les validateurs pourront donc ajuster librement leurs taux de commission, mais devront attendre au moins une époque complète avant que le nouveau taux ne s’applique.

Ce délai profite également aux délégateurs de stake en leur accordant une époque complète pour réagir aux prochaines modifications de commission. Surtout, il met fin au « commission rugging », une pratique par laquelle des validateurs malveillants augmentent temporairement leurs commissions à 100 % peu avant la fin d’une époque afin de capter les récompenses, puis les ramènent rapidement à leur niveau normal peu après.

Réduction du dépôt d’état (loyer)

Les exigences élevées en matière de dépôt d’état, couramment appelées « loyer », restent l’une des principales contraintes pesant sur l’évolutivité à long terme pour les développeurs Solana. Aujourd’hui, les dépôts d’état sur le mainnet sont coûteux : le stockage revient à environ 1 million de dollars par gigaoctet. Par exemple, la création d’un seul nouveau compte de token (ATA) nécessite un peu plus de 0,002 SOL, soit environ 0,25 $ aux prix actuels. Cela rend les airdrops directs de tokens à grande échelle prohibitifs et crée des obstacles pour les micropaiements et les applications de paiement en stablecoins, qui doivent soit subventionner la création des comptes de tokens, soit répercuter ce coût sur les utilisateurs finaux.

Une première étape vers la réduction de cette charge est SIMD-0194 : dépréciation du seuil d’exemption de loyer, dont l’activation est prévue pendant le cycle de publication d’Agave 3.1. Elle marque le début d’un effort plus large visant à réduire sensiblement et à simplifier les coûts de stockage, afin de permettre aux applications de servir des millions d’utilisateurs sans exigences de capital prohibitives liées à l’état. En outre, trois autres SIMD sont actuellement en préparation pour s’attaquer directement au coût des dépôts d’état et réduire davantage le loyer.

SIMD-0194 simplifie les futures mises à jour du loyer. Aujourd’hui, déterminer si un compte est exempté de loyer est relativement coûteux pour les programmes on-chain. Le calcul actuel de `Rent::minimum_balance` utilise des opérations en virgule flottante (f64) et consomme environ 256 unités de calcul par appel. Avec SIMD-0194, ce coût tombe à seulement 8 CU grâce à la suppression des opérations en virgule flottante de la logique d’exemption de loyer.

Pour cela, le champ exempt_threshold (f64) est déprécié, ce qui évite aux programmes d’effectuer des calculs en virgule flottante pour déterminer le statut d’exemption de loyer.

Dans le cadre de cette modification, lamports_per_byte_year est renommé lamports_per_byte, et sa valeur par défaut double, passant de 3480 à 6960. Cela reflète le fait que l’exemption de loyer a toujours été définie comme la détention de l’équivalent de deux années de loyer. Point important : cette mise à jour ne modifie pas le montant requis pour qu’un compte soit exempté de loyer ; elle simplifie et standardise uniquement la représentation et le calcul de cette valeur.

La mise à jour est entièrement rétrocompatible et n’aura aucun impact sur les programmes déjà déployés.

Perspectives : SIMD-0437

Parmi les autres SIMD liés au loyer attendus plus tard cette année, le plus important est SIMD-0437 : réduction progressive de `lamports_per_byte` à 696. Cette proposition définit un calendrier structuré visant à réduire le coût à long terme des dépôts d’état en abaissant progressivement `lamports_per_byte` de 6960 à 696, soit une réduction par 10.

SIMD-0437 remplace l’ancienne proposition SIMD-0436, qui prévoyait une réduction unique de 50 %. SIMD-0437 instaure à la place un calendrier de réduction plus granulaire en cinq étapes : 6333 → 5080 → 2575 → 1322 → 696.

La répartition de cette modification en plusieurs phases permet au réseau d’observer et d’évaluer la croissance de l’état au fil du temps, tout en isolant les réductions les plus controversées dans des étapes distinctes afin de faciliter les discussions et la gouvernance.

Autres nouveautés notables du cycle de publication d’Agave 3.1

Application stricte de 32 shreds de données et 32 shreds de codage

Aujourd’hui, Turbine accepte un nombre variable de shreds par ensemble FEC. Ce comportement ajoute une complexité inutile sans apporter d’avantages significatifs. La validation des indices de shreds devient plus difficile, car les récepteurs ont besoin des shreds de codage pour déterminer les limites des indices. La prochaine activation de la feature gate pour SIMD-0317 : imposer 32 shreds de données + 32 shreds de codage standardise ce comportement en exigeant exactement 32 shreds de données et 32 shreds de codage par ensemble FEC. Cette modification renforce également la détection des équivoques, qui servira ultérieurement aux mécanismes d’application tels que les pénalités de slashing.

Limites statiques des instructions

Aujourd’hui, les transactions comportant plus de 64 instructions de premier niveau passent les contrôles initiaux d’assainissement, mais échouent au moment de l’exécution. Cela impose un travail inutile au planificateur, car des transactions vouées à l’échec peuvent entrer dans le pipeline et consommer ses ressources.

La prochaine activation de la feature gate pour SIMD-0160 : limite statique des instructions résout ce problème en appliquant la limite de 64 instructions pendant l’assainissement des transactions. Après cette modification, toute transaction dépassant 64 instructions de premier niveau (y compris les appels CPI) échouera à l’assainissement et sera immédiatement rejetée.

Réduction du nombre de rounds ChaCha de Turbine

SIMD-0332 : réduction du nombre de rounds ChaCha de Turbine de 20 à 8 apporte une amélioration modeste mais significative des performances de propagation des données de bloc par Turbine. Aujourd’hui, Turbine utilise ChaCha20 pour mélanger de manière déterministe les validateurs pondérés selon leur stake lors de la construction des arbres de propagation des blocs. Cet ordre aléatoire est important pour prévenir les attaques par censure, mais il entraîne une charge de calcul supplémentaire.

Les rounds ChaCha agissent comme un brouilleur déterministe : chaque round applique des transformations qui rendent la sortie encore plus aléatoire. Un nombre plus élevé de rounds renforce la sécurité cryptographique, mais augmente également le coût de calcul.

Depuis la transition d’Agave vers XDP, les envois de retransmission sont devenus presque instantanés, ce qui signifie que l’étape de mélange pondéré domine désormais le temps d’exécution. Avec environ ~1 microseconde par shred, le passage de ChaCha20 à ChaCha8 maintient un niveau d’aléa suffisant pour résister à la censure, tout en évitant que le processus ne devienne un goulot d’étranglement.

Nouveau pointeur vers les données d’instruction

Aujourd’hui, les programmes sBPF doivent analyser la section des comptes de la région d’entrée sérialisée pour localiser les données d’instruction. Comme le format de sérialisation place les comptes avant les données d’instruction, les programmes doivent parcourir chaque entrée de compte avant d’atteindre le segment des données d’instruction. Cela impose un travail inutile aux programmes qui opèrent principalement, voire exclusivement, sur ces données.

La prochaine activation de la feature gate pour SIMD-0321 : pointeur vers les données d’instruction dans le registre 2 de la VM améliore ce fonctionnement en fournissant un pointeur 64 bits vers les données d’instruction dans le registre r2 de la VM au point d’entrée du programme. Ce pointeur référence directement le début de la section des données d’instruction dans la région d’entrée, ce qui permet aux programmes d’y accéder immédiatement sans devoir d’abord analyser la section des comptes. La suppression de cette surcharge d’analyse réduit la consommation d’unités de calcul.

Remarque sur la compatibilité : cette fonctionnalité n’est rétrocompatible qu’avec les programmes qui ne lisent pas actuellement r2 au point d’entrée. Tout programme qui dépend à tort de la valeur non initialisée ou indéterminée auparavant présente dans r2 au point d’entrée cessera de fonctionner après l’activation de cette fonctionnalité.

Améliorations RPC

L’endpoint RPC getProgramAccounts renvoie désormais les erreurs JSON-RPC appropriées lorsque les filtres fournis sont mal formés. Auparavant, les filtres non valides étaient ignorés silencieusement, ce qui transformait l’appel RPC en requête non filtrée. Cela déclenchait souvent des requêtes d’un coût inattendu et une charge inutile sur les nœuds RPC. Grâce à cette amélioration, les filtres incorrects renvoient désormais une erreur claire, ce qui évite les requêtes accidentellement gourmandes en ressources et facilite considérablement le débogage.

En outre, les échecs de vérification de signature dans simulateTransaction() et pendant l’étape de prévalidation de sendTransaction() seront désormais renvoyés sous la forme d’une erreur TransactionError::SignatureFailure dans le champ err du résultat de simulation, au lieu de déclencher une erreur API JSON-RPC (-32003).

Par conséquent, les applications qui s’appuyaient auparavant sur l’interception des exceptions JSON-RPC pour les échecs de vérification de signature doivent désormais s’attendre à voir ces erreurs apparaître directement dans la réponse de simulation. Les applications qui matérialisent et traitent déjà les valeurs TransactionError dans les résultats de simulation peuvent désormais s’attendre à recevoir TransactionError::SignatureFailure à ces points de vérification.

Conclusion

Agave v3.1 est une mise à niveau majeure du client qui apporte de nombreux gains de performances et optimisations, notamment une réduction des E/S disque, un traitement plus rapide des transactions et une meilleure gestion des erreurs RPC. Agave a réalisé des progrès notables dans le renforcement du réseau et offre désormais une meilleure résilience face aux conditions hostiles. Cette version marque également la première étape vers une réduction significative des dépôts d’état.

Anza continue de se démarquer comme la seule équipe de développement cœur de l’industrie à proposer des améliorations sur l’ensemble de la stack, notamment en soumettant des correctifs au noyau Linux. Alors qu’Agave 3.1 s’apprête à propulser le réseau, Solana continue de démontrer sa capacité à passer à l’échelle.

La prochaine étape sera Agave 4.0 et le lancement d’Alpenglow sur le testnet, actuellement prévu pour début mai.

Ressources complémentaires

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