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

Introduction

Avec Agave 4.2, le principal client de validation de Solana continue d’innover. Cette version majeure s’articule autour de trois mises à niveau très attendues, soumises à des feature gates : des slots de 200 ms, une réduction de 90 % des dépôts de garantie liés à l’état et des transactions de 4 096 octets grâce au nouveau format transaction v1. Elle intègre également une version complète d’Alpenglow avant son activation prévue dans la prochaine version, tandis que la transmission XDP est désormais activée par défaut.

Mises à jour notables

• Transactions 3,3× plus volumineuses avec une nouvelle norme Transaction v1 *
• Réduction de 90 % du dépôt de garantie lié à l’état (loyer) *
• Réduction de la durée des slots à 200 ms *
• Version complète d’Alpenglow
• Nouveaux outils de gouvernance (liés aux SIMD)

* Mises à niveau soumises à des feature gates

Transactions plus volumineuses (Transaction v1)

Le cycle de publication d’Agave 4.2 comprend l’activation d’un feature gate autorisant des transactions plus volumineuses, jusqu’à 4 096 octets, contre la limite historique de 1 232 octets. Formellement définie dans SIMD-0296 : taille de transaction supérieure, cette limite plus élevée représente une augmentation d’environ 3,3× et s’applique exclusivement au nouveau format transaction v1 introduit par SIMD-0385 : format Transaction V1. Les transactions legacy et v0 continuent de fonctionner sans changement et restent soumises à la limite actuelle de 1 232 octets.

Pour les développeurs, il ne s’agit pas seulement de disposer de plus d’espace pour les données d’instruction. Les preuves cryptographiques, les approbations multisignatures, les longues listes de comptes et d’autres charges utiles qui ne tenaient auparavant pas dans une seule transaction peuvent désormais être exécutées dans une opération atomique unique et native du protocole. Ce changement n’augmente pas les limites de Solana relatives au calcul, aux comptes, aux signatures ou au nombre d’instructions.

La limite initiale de 1 232 octets provenait de l’ancienne architecture réseau de Solana. Les transactions étaient transmises sous forme de datagrammes UDP individuels et devaient tenir dans l’unité de transmission maximale minimale (MTU) d’IPv6, soit 1 280 octets. Après déduction de l’en-tête IPv6 de 40 octets et de l’en-tête UDP de huit octets, il restait 1 232 octets pour la transaction elle-même. Le fait de conserver chaque transaction dans un seul paquet réduisait la fragmentation et rendait la transmission plus prévisible.

Solana a depuis longtemps abandonné UDP au profit de QUIC pour l’ingestion des transactions. Les flux QUIC ne sont pas limités à la charge utile d’un seul datagramme réseau. L’ancien plafond de 1 232 octets n’est donc plus nécessaire. Les clients ont toujours besoin d’une limite supérieure explicite pour le contrôle des admissions, l’allocation de mémoire et la validation du consensus, mais cette limite peut désormais être choisie en fonction des exigences du runtime et des applications plutôt que de la MTU IPv6.

Les listes de comptes consomment souvent une part importante de l’espace disponible. Chaque clé publique Ed25519 ou adresse dérivée d’un programme occupe 32 octets, et une transaction doit identifier chaque compte lu ou modifié par ses instructions. Cela imposait auparavant un plafond effectif d’environ 32 clés de compte complètes. Pour contourner cette limite, les transactions V0 ont introduit les Address Lookup Tables (ALT), qui remplacent chaque clé de 32 octets par un index de table d’un octet, permettant ainsi aux transactions d’atteindre la limite de 64 comptes du runtime.

Bien que les ALT constituent une forme de compression efficace, elles ajoutent malheureusement aussi de la complexité. Les applications doivent créer et gérer des tables de recherche onchain. Les services RPC et les indexeurs qui décodent un message v0 brut doivent reconstruire sa liste complète de comptes à l’aide des métadonnées de transaction ou de l’état de la table concernée. Cela complique l’analyse des transactions qui font référence à une ALT fermée depuis et qui n’est plus disponible onchain. 

Ce point de friction pour les développeurs disparaît avec les transactions v1, qui sont assez volumineuses pour contenir l’ensemble complet des comptes actuellement pris en charge par les ALT (64 clés publiques complètes occupant 2 048 octets). Une application migrant depuis v0 peut donc résoudre les entrées de sa table de recherche et inclure directement les adresses obtenues dans une transaction v1.

Par ailleurs, la taille de 1 232 octets est particulièrement contraignante pour les fonctions cryptographiques telles que les preuves à divulgation nulle de connaissance et les implémentations BLS dépourvues de précompilations natives. Ces charges de travail peuvent contenir des centaines ou des milliers d’octets de données de preuve ou de signature. Un plafond de 4 096 octets couvre bon nombre de ces cas d’usage cryptographiques courants. 

Spécification de Transaction V1

Une transaction v1 sérialisée commence par l’octet de version 0x81. Il est suivi d’un en-tête de message de trois octets au format legacy, d’un masque de configuration de transaction de 32 bits, d’un spécificateur de durée de vie de 32 octets, des nombres d’instructions et d’adresses, du tableau complet d’adresses de 32 octets, des valeurs de configuration, des en-têtes d’instruction de taille fixe, des charges utiles d’instruction contiguës et, enfin, des signatures. 

VersionByte (u8)
LegacyHeader (u8, u8, u8) 
TransactionConfigMask (u32) -- Bitmask of which config requests are present.
LifetimeSpecifier [u8; 32]
NumInstructions (u8)
NumAddresses (u8)
Addresses [[u8; 32]] -- Length matches NumAddresses
ConfigValues [[u8; 4]] -- Length equal to the popcount (number of set bits)
  of TransactionConfigMask. See section TransactionConfigMask for details.
InstructionHeaders [(u8, u8, u16)] -- Length of NumInstructions. Values are
  (ProgramAccountIndex, NumInstructionAccounts, NumInstructionDataBytes)
InstructionPayloads [InstructionPayload] -- Length = NumInstructions.
  Each InstructionPayload is the concatenation of the following byte arrays:
    InstructionAccountIndexes [u8] -- Length = NumInstructionAccounts from the
    corresponding InstructionHeader
    InstructionData [u8] -- Length = NumInstructionDataBytes from the
    corresponding InstructionHeader
Signatures [[u8; 64]]

Les en-têtes d’instruction identifient explicitement l’index du compte de programme, le nombre de comptes d’instruction et la longueur des données d’instruction. Les limites des messages sont ainsi disponibles sans avoir à interpréter la charge utile de chaque instruction.

Les transactions V1 restent limitées à 12 signatures, 64 adresses de compte, 64 instructions et 255 index de compte par instruction. Les transactions volumineuses doivent toujours respecter la limite d’unités de calcul demandée, la limite de données de comptes chargées, les règles de verrouillage des comptes et la capacité d’exécution disponible du bloc.

Les analyseurs existants ne peuvent pas traiter v1 comme v0 avec une longueur maximale supérieure. Les indexeurs, RPC, SDK et infrastructures de signature qui inspectent des transactions sérialisées doivent reconnaître le préfixe 0x81 et implémenter le nouvel ordre des champs. Point particulièrement notable : les signatures v1 apparaissent à la fin de la transaction, et non avant le message comme dans les transactions legacy et v0.

Transaction v1 remplace les instructions de configuration du programme Compute Budget par des champs dans l’en-tête de la transaction. Le `TransactionConfigMask` initial peut déclarer les éléments suivants pour la transaction :

• frais de priorité totaux en lamports
• limite d’unités de calcul
• limite de taille des données de comptes chargées
• taille de tas demandée

Chaque bit défini identifie une valeur de configuration associée de quatre octets, les frais de priorité de 64 bits occupant deux positions dans le masque. Le masque est conçu pour être extensible dans les futures versions de transaction.

Réduction du dépôt de garantie lié à l’état (loyer)

Les exigences élevées en matière de dépôt de garantie lié à l’état, généralement appelées « loyer », restent l’une des principales sources de friction de Solana pour les applications qui utilisent beaucoup de comptes. Ce nom est quelque peu trompeur, car le loyer n’est pas un coût de stockage récurrent, mais un dépôt remboursable qu’un compte doit conserver tant que son état reste onchain. Les lamports peuvent normalement être récupérés à la fermeture du compte. D’ici là, ils constituent toutefois un capital qu’un développeur ou un utilisateur doit avancer et laisser immobilisé.

Agave 4.2 introduit l’implémentation soumise à des feature gates de SIMD-0437 : réduction progressive de lamports_per_byte à 696, qui réduit la constante `lamports_per_byte` de 6 960 à 696. Cela représente une réduction de 90 % du loyer (ou, plus exactement, du minimum d’exemption de loyer), déployée par l’intermédiaire de cinq feature gates indépendants : 6 960 → 6 333 → 5 080 → 2 575 → 1 322 → 696. 

Lorsqu’un de ces gates est activé, Agave met à jour la configuration du loyer de la Bank et publie la nouvelle valeur par l’intermédiaire de la sysvar Rent. Ce déploiement progressif permet au réseau d’observer la réaction des applications à chaque niveau de prix et de s’arrêter avant la réduction suivante si la croissance de l’état ou l’utilisation des ressources des validateurs devient préoccupante.

Le minimum d’exemption de loyer d’un compte est calculé à partir de la taille de données qui lui est allouée, à laquelle s’ajoute une surcharge de stockage fixe de 128 octets :

minimum_balance = (128 + account_data_size) × lamports_per_byte

Avec ce changement, le mécanisme de loyer lui-même reste inchangé : les comptes doivent toujours disposer d’un solde minimal, qui reste récupérable à la fermeture du compte. Seule la quantité de SOL devant être immobilisée change.

Un compte SPL Token standard occupe 165 octets. En incluant la surcharge de 128 octets, sa taille effective est donc de 293 octets. La réduction de 90 % du loyer fait passer le montant de SOL requis pour un tel compte d’environ ~0,16 $ à moins de 2 centimes. 

Cela entraîne des conséquences particulièrement importantes pour les paiements en stablecoins, les distributions de tokens, les systèmes de fidélité et les airdrops directs. Un portefeuille ne détient pas directement les tokens SPL ; il lui faut normalement un Associated Token Account (ATA) pour chaque mint. Lorsqu’un destinataire ne dispose pas encore de l’ATA requis, l’expéditeur peut le créer en même temps que le transfert, mais il doit également financer le solde d’exemption de loyer du destinataire. Il s’agit généralement d’un coût d’intégration unique pour chaque paire portefeuille-mint, plutôt que d’un coût payé lors de chaque paiement ultérieur. Néanmoins, à grande échelle, ce montant peut être assez élevé pour déterminer si une entreprise subventionne l’intégration ou répercute le coût sur les utilisateurs.

Croissance de l’état de Solana

La réduction progressive est importante, car diminuer le dépôt de garantie lié à l’état réduit également le montant qu’un attaquant doit immobiliser pour créer et conserver un état indésirable. L’état de Solana est répliqué, indexé, inclus dans les snapshots et maintenu par chaque validateur. Sa croissance persistante finit donc par affecter les besoins en espace disque, les opérations d’AccountsDB et, à terme, les coûts d’exploitation.

Selon l’analyse récente de Solana Foundation, les fichiers de stockage d’AccountsDB occupent environ 495 Go sur une allocation recommandée de 1 To. Après la réduction de loyer prévue, l’épuisement de cette capacité disponible obligerait un attaquant à engager environ 17,2 millions de dollars en SOL. Porter l’allocation de stockage recommandée pour les validateurs à 2 To ferait passer le capital requis pour l’attaquant à 51 millions de dollars.

Après prise en compte de la création de nouveaux comptes et de la fermeture d’anciens comptes, il a été constaté que l’état augmentait d’environ 0,3 Go par jour.

Un snapshot de l’état pris à l’époque 997 montre que la consommation de l’état est très concentrée. Les comptes SPL Token constituaient la catégorie la plus importante, tandis que les comptes OpenBook et Serum occupaient environ 30 % de l’état actif, ce qui reflète l’architecture complexe des carnets d’ordres onchain. L’analyse estimait également qu’environ 30 % de l’espace SPL Token était associé à des actifs de type plateforme de lancement de tokens Pump.fun.

Mesures de sécurité

Pour réduire les dépôts de garantie liés à l’état en toute sécurité, il faut disposer d’un mécanisme viable dans l’autre sens. Sans modifications supplémentaires du runtime, une augmentation ultérieure du minimum d’exemption de loyer placerait instantanément les comptes existants sous le nouveau seuil. Les transactions qui verrouillent ces comptes en écriture pourraient échouer même si elles n’allouaient aucun état supplémentaire, ce qui entraînerait d’importantes perturbations.

C’est là que SIMD-0392 : adaptation du runtime aux augmentations de loyer modifie la règle de solde minimal après exécution, afin que les comptes existants puissent conserver leurs conditions antérieures en cas d’augmentation du loyer. Lorsqu’un compte existe déjà, ne grossit pas et conserve le même propriétaire, son minimum autorisé devient la plus faible des deux valeurs suivantes :

1. le minimum selon le taux de loyer actuel
2. le solde du compte avant l’exécution

Les nouveaux comptes doivent toujours respecter le minimum actuel d’exemption de loyer. Il en va de même pour les comptes qui augmentent leur taille allouée ou changent de propriétaire. Un solde nul continue de représenter la fermeture du compte. L’état existant peut ainsi continuer de fonctionner avec son montant immobilisé précédent, tandis que l’état nouvellement alloué paie le tarif le plus récent.

SIMD-0438 : mesure de protection pour l’augmentation du minimum d’exemption de loyer ajoute un feature gate de protection distinct qui rétablit `lamports_per_byte` à son ancienne valeur de 6 960. Il est destiné à être activé uniquement si la réduction du loyer entraîne une croissance excessive de l’état ou un autre problème opérationnel majeur. Comme ce gate existe avant le début des réductions, les développeurs du cœur du protocole n’auraient pas à concevoir, examiner et déployer une nouvelle modification du consensus au beau milieu d’un incident émergent de croissance de l’état.

Ensemble, les cinq gates de réduction, les règles de maintien des conditions antérieures de SIMD-0392 et le mécanisme de repli de SIMD-0438 rendent le déploiement réversible au niveau du protocole. Le réseau peut réduire progressivement le dépôt, observer le comportement de l’état actif et du stockage des validateurs, suspendre le processus à une valeur intermédiaire ou rétablir l’exigence initiale sans obliger à renflouer immédiatement tous les comptes existants.

Réduction de la durée des slots à 200 ms

L’une des améliorations de performances les plus attendues de Solana consiste à réduire la durée cible des slots de 400 ms à 200 ms. Le principal avantage est une latence plus faible. Avec des slots de 200 ms, la fenêtre de leader de quatre slots de Solana passerait de 1,6 seconde à 800 ms, réduisant les délais de confirmation et limitant la durée pendant laquelle un leader malveillant peut retarder, réordonner ou inclure sélectivement des transactions. Des slots plus courts offrent également aux applications telles que les consommateurs d’oracles et les teneurs de marché une temporalité onchain plus granulaire.

La proposition vise à préserver l’économie et le débit actuels de Solana. Les paramètres d’inflation, les coûts des Validator Admission Tickets dans Alpenglow et les limites de travail par slot sont ajustés proportionnellement. Toutefois, si les slots de 200 ms arrivent avant Alpenglow, les coûts de vote des validateurs pourraient approximativement doubler, car ceux-ci devraient voter deux fois plus souvent.

Pour une analyse plus approfondie des slots de 200 ms, consultez notre précédent article dans l’analyse d’Agave 4.1.

Autres mises à jour notables

Plusieurs améliorations plus modestes, mais notables, devraient être activées pendant le cycle de publication d’Agave 4.2.

Préparation à Alpenglow

Agave 4.2 intègre une version complète d’Alpenglow, mais n’activera pas le nouveau protocole de consensus sur le mainnet. Les principales équipes d’ingénierie profitent de ce cycle de publication pour poursuivre les tests, les audits et le renforcement avant la migration du consensus, désormais prévue avec Agave 4.3. Les validateurs exécutant la version 4.2 disposent donc déjà de l’implémentation complète d’Alpenglow, notamment du moteur de vote Votor et de ses composants de vérification des certificats BLS. 

Pour élargir l’examen de la sécurité du code, Anza organise également un concours de bug bounty Alpenglow, doté d’une cagnotte pouvant atteindre 50 000 SOL et ouvert aux soumissions du 5 au 19 août. Alpenglow avait auparavant été exclu du programme de bug bounty permanent d’Agave pendant son développement, sa migration vers le monorepo et les audits internes. Ce concours marque son intégration au périmètre du bug bounty et vise à découvrir les problèmes qui auraient pu échapper aux examens précédents.

Passage du programme Stake des nombres flottants à la virgule fixe

Le cycle de publication d’Agave 4.2 comprend également l’implémentation soumise à un feature gate de SIMD-0391 : passage du programme Stake des nombres flottants à la virgule fixe, qui remplace l’arithmétique à virgule flottante IEEE-754 dans les calculs de montée en puissance et de désactivation du programme Stake par des calculs déterministes sur des entiers à virgule fixe. La motivation principale est la compatibilité avec la chaîne d’outils eBPF standard, qui ne prend pas en charge les opérations à virgule flottante. La chaîne d’outils SBF de Solana peut les émuler au moyen de routines soft-float déterministes, mais cette approche est inefficace et bloque la migration du programme Stake vers une implémentation `no_std`.

La plupart des applications ne nécessitent aucun changement. Toutefois, les indexeurs et les outils de staking qui reproduisent indépendamment le stake effectif, en cours d’activation ou de désactivation devront implémenter les nouvelles règles de calcul sur les entiers une fois la fonctionnalité activée.

Nouveaux outils de gouvernance

Le cycle de publication d’Agave 4.2 voit également le lancement de nouveaux outils de gouvernance en préparation depuis l’année dernière. Ces outils fournissent un processus onchain permettant aux validateurs et aux stakers natifs d’indiquer leur position sur les principales décisions économiques et protocolaires. 

Son composant central, svmgov, est un programme basé sur Anchor qui gère la création des propositions, leur soutien, le vote pondéré par le stake et leur finalisation. Les poids de vote proviennent d’un snapshot du stake propre à une époque, produit par le Node Consensus Network (NCN). Des opérateurs indépendants génèrent le snapshot, parviennent à un consensus sur une racine de Merkle canonique et la publient onchain. Les validateurs prouvent ensuite leur stake actif à l’aide de preuves de Merkle. 

Les validateurs disposant d’au moins 100 000 SOL de stake actif peuvent créer des propositions, tandis qu’une proposition doit recevoir le soutien de 15 % du stake du cluster avant de passer à l’étape du vote. Le dépôt de gouvernance comprend également une CLI Rust et une interface web permettant de voter et de suivre le soutien.

Les documents complets des propositions se trouvent dans le dépôt distinct Solana Governance Proposals et sont épinglés à un commit Git précis, tandis que le compte de proposition onchain stocke le lien, l’état du cycle de vie et le décompte des votes. Les validateurs votent initialement avec l’ensemble du stake qui leur est délégué, mais chaque délégateur conserve la souveraineté sur ses SOL. Un staker peut soumettre une dérogation pour un compte de stake précis, retirant ce stake du décompte du validateur et le réaffectant selon son propre vote.

Les Solana Governance Proposals (SGP) sont destinées à compléter les SIMD, et non à les remplacer : une SGP répond à la question d’orientation consistant à déterminer si le réseau doit poursuivre un changement, tandis que la SIMD associée précise comment ce changement doit être implémenté.

Trois SGP ont déjà franchi la phase de soutien et constitueront la première série de votes de gouvernance dans le nouveau système :

• SGP-0001 : la Constitution de Solana propose de ratifier un contrat social de gouvernance canonique qui définit les rôles des développeurs, des validateurs et des stakers, et établit formellement le processus SGP.
• SGP-0002 : doublement de la désinflation demande au réseau de doubler le taux annuel de désinflation du SOL, de 15 % à 30 %, tout en maintenant le taux d’inflation terminal à 1,5 %. La durée estimée pour atteindre ce taux terminal passerait ainsi d’environ 5,7 ans à 2,8 ans. 
• SGP-0003 : frais de ressources et d’inclusion propose de remplacer la structure actuelle de frais de base fixes par des frais d’inclusion de 2 500 lamports versés au leader et des frais de ressources distincts, calculés en fonction des unités de coût de transaction demandées et entièrement brûlés, sans modifier la distribution des frais de priorité.

Conclusion

Agave 4.2 est l’une des versions les plus importantes de Solana de ces dernières années. Les slots plus rapides de 200 ms rapprochent le réseau d’une réactivité en temps réel. La réduction prévue de 90 % des dépôts de garantie liés à l’état rend la création de comptes beaucoup plus abordable. Enfin, les transactions v1 de 4 096 octets offrent nettement plus d’espace pour les instructions complexes, les preuves cryptographiques et les applications qui utilisent de nombreux comptes. Ensemble, ces changements rendent Solana plus rapide, moins coûteux et plus expressif, tant pour les développeurs que pour les utilisateurs.

Ressources complémentaires

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