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

Introduction

Avec Agave 4.4, le principal client validateur de Solana poursuit le déploiement d’Alpenglow, en simplifiant la validation des blocs, en rationalisant le calcul des récompenses de staking et en réduisant la quantité de SOL nécessaire au stockage des programmes et des données de compte. Ces changements améliorent l’efficacité au quotidien tout en préparant davantage l’exécution asynchrone. La récente réduction à 200 ms de la durée cible des slots ramène les époques à environ une journée, ce qui permet d’accélérer encore le rythme d’activation des fonctionnalités.

Principales nouveautés du cycle de publication d’Agave 4.4

• Autorisation des payeurs de frais non valides : une étape clé vers l’exécution asynchrone
• Redimensionnement automatique des programmes : rembourse le surplus de loyer lors des mises à niveau de programmes
• Standardisation des shreds : le protocole impose désormais des ensembles FEC de 32 shreds de données et 32 shreds de codage
• Nettoyage du stake inactif : exclut le stake inactif du calcul des récompenses
• Réduction du loyer : les trois dernières étapes prévues de la réduction de 90 % des dépôts de garantie liés à l’état

Autoriser les payeurs de frais non valides

L’activation de la fonctionnalité SIMD-0290 : assouplir la contrainte relative au payeur de frais devrait intervenir pendant le cycle de publication d’Agave 4.4. Elle modifie le comportement lorsqu’un bloc contient une transaction dont le payeur de frais échoue à la validation, par exemple parce qu’il ne dispose pas d’assez de SOL. Auparavant, l’inclusion d’une telle transaction invalidait l’intégralité du bloc. Selon les nouvelles règles de consensus, la transaction reste dans le bloc et les validateurs ignorent son exécution, sans modifier l’état des comptes.

Le solde d’un payeur de frais peut changer à mesure que les transactions précédentes sont exécutées. Exiger que chaque transaction ait un payeur de frais valide signifie donc que les validateurs doivent exécuter certaines transactions antérieures avant de pouvoir déterminer si un bloc est valide. Traiter les échecs liés au payeur de frais comme des transactions ignorées supprime cette dépendance particulière.

Ce changement prépare l’exécution asynchrone, dans laquelle les validateurs peuvent s’accorder sur les blocs et l’ordre des transactions avant la fin de l’exécution. Celle-ci se déroule séparément et applique à l’état des comptes les transactions convenues. Solana évolue vers cette architecture afin de permettre de futures améliorations, comme des temps de bloc plus courts et de multiples proposeurs de blocs simultanés.

Agave représente ces transactions ignorées comme des opérations nulles : elles n’exécutent aucune instruction et ne paient aucuns frais. Elles consomment néanmoins de la capacité dans le bloc en fonction de l’intégralité de leurs budgets de ressources demandés ou par défaut, ce qui limite le nombre qu’un leader peut inclure. L’implémentation permet également au leader de continuer à les filtrer pendant la production des blocs, même si les validateurs peuvent les accepter lors de la réexécution d’un bloc.

SIMD-0290 s’applique spécifiquement aux transactions qui utilisent un blockhash récent comme paramètre de durée de validité. Les transactions à nonce durable nécessitent un traitement supplémentaire, abordé séparément par SIMD-0297 : assouplir la contrainte relative aux transactions à nonce non valides. Ce changement est entièrement rétrocompatible : toutes les transactions et tous les blocs auparavant valides le restent.

Redimensionnement automatique des programmes lors d’une mise à niveau

Agave 4.4 inclura l’activation d’une fonctionnalité pour SIMD-0433 : Loader V3 : définir les données du programme selon la longueur ELF, qui permet aux mises à niveau de programmes de redimensionner automatiquement le compte stockant le code compilé du programme.

Loader v3 (c’est-à-dire le loader actuellement utilisé par défaut pour déployer et mettre à niveau les programmes Solana) stocke le binaire ELF compilé d’un programme dans un compte ProgramData, avec des métadonnées telles que son autorité de mise à niveau. Auparavant, les développeurs pouvaient uniquement agrandir ce compte, jamais le réduire. Le passage à un binaire plus petit laissait donc de l’espace inutilisé, et les SOL nécessaires pour maintenir cet espace exempt de loyer restaient bloqués sur le compte.

Avec ce changement, l’instruction Upgrade redimensionne le compte en fonction de l’en-tête des métadonnées et de la longueur du nouvel ELF. Un binaire plus petit transfère les lamports excédentaires vers le compte de récupération de la mise à niveau, le destinataire désigné des fonds restants. Un binaire plus volumineux agrandit automatiquement le compte, supprimant l’étape d’extension distincte lors des mises à niveau ordinaires. Le compte ProgramData et les comptes tampons doivent déjà contenir suffisamment de lamports pour satisfaire la nouvelle exigence de loyer ; sinon, la mise à niveau échoue.

Les développeurs qui adoptent des binaires plus petits peuvent ainsi récupérer des SOL lors de leur prochaine mise à niveau. Toute capacité supplémentaire précédemment réservée est également supprimée. Pour les mises à niveau invoquées via CPI, la limite de croissance des comptes de 10 Kio reste applicable : les augmentations plus importantes nécessitent une extension préalable ou une instruction de mise à niveau de premier niveau. Avant la mise à niveau, les développeurs doivent vérifier la destination de leur compte de récupération afin de s’assurer que les remboursements parviennent au destinataire prévu.

Ce changement incite les développeurs à adopter des bibliothèques et frameworks plus récents et plus performants, comme Pinocchio. Il réduit également l’espace occupé par les programmes dans Accounts DB.

Standardisation des shreds

Agave 4.4 renforce les règles de propagation des blocs de Solana décrites dans SIMD-0317 : imposer 32 shreds de données + 32 shreds de codage. Ce changement standardise la structure utilisée par les validateurs pour distribuer et reconstruire les données des blocs.

Solana distribue les blocs via Turbine, qui divise les données des blocs en shreds et les relaie à travers plusieurs couches de validateurs. Les shreds sont regroupés dans des ensembles de correction d’erreurs sans voie de retour (FEC), qui combinent des shreds de données et des shreds de codage contenant des informations de récupération. Avec un ensemble correctement construit de 32 shreds de données et 32 shreds de codage, un destinataire peut reconstruire les données d’origine à partir de n’importe quels 32 des 64 shreds, ce qui améliore sa tolérance à la perte de paquets.

Chaque shred contient également une preuve de Merkle qui le relie à la racine de Merkle de l’ensemble, authentifiée par la signature du leader. Pour un ensemble de 64 shreds, cette preuve comporte six entrées, correspondant aux six niveaux entre une feuille et la racine. Le contrôle de la taille des preuves d’Agave exige la taille attendue pour cette structure fixe 32:32.

Les clients produisent déjà 32 shreds de données et 32 shreds de codage par ensemble, mais les validateurs récepteurs ont historiquement accepté des configurations plus flexibles. SIMD-0317 comble cet écart en faisant de la structure fixe 32:32 une exigence du protocole. Cela simplifie la validation : un destinataire peut déterminer les limites valides des indices de shreds sans attendre qu’un shred de codage révèle les dimensions de l’ensemble.

La structure fixe simplifie également la détection de l’équivoque, lorsqu’un leader distribue des versions contradictoires des mêmes données. Deux shreds appartenant au même ensemble FEC, dotés de racines de Merkle différentes et de signatures de leader valides, constituent une preuve de ce conflit. La standardisation du format réduit donc la complexité de l’implémentation tout en facilitant l’identification des équivoques.

Exclusion du stake inactif du calcul des récompenses

Le cycle de publication d’Agave 4.4 inclura l’activation d’une fonctionnalité pour SIMD-0599 : supprimer les stakes inactifs des délégations de stake, qui simplifie la manière dont les validateurs traitent les comptes de stake inactifs lors du calcul partitionné des récompenses d’époque au début de chaque époque. Les comptes de stake inactifs peuvent détenir des SOL au-delà du minimum requis pour l’exemption de loyer, mais ne comportent aucun stake actif ou en cours d’activation. Leurs SOL ne sont pas délégués ou ont achevé leur désactivation.

Ces comptes ne génèrent aucune récompense du protocole, mais leur inclusion peut affecter le nombre de partitions de distribution des récompenses et le hachage de treillis utilisé pour suivre l’état des comptes. Chaque client validateur doit reproduire précisément ce comportement, ce qui ajoute une complexité inutile au code critique pour le consensus.

Ce changement exclut le stake qui était inactif pendant l’époque récompensée, tout en conservant les stakes en cours d’activation, actifs et en cours de désactivation. Ainsi, un compte de stake qui devient inactif au début d’une nouvelle époque reçoit tout de même les récompenses acquises pendant l’époque précédente, au cours de laquelle il était en cours de désactivation.

Nouvelle réduction du loyer

Agave 4.4 devrait apporter les trois dernières activations de la réduction progressive du loyer sur Solana. Selon le plan défini dans SIMD-0437, le solde minimum requis par octet de stockage de compte passe de 6 960 lamports à l’origine à 696 en cinq étapes, soit une réduction de 90 %.

Chaque activation possède sa propre fonctionnalité d’activation, ce qui permet au réseau d’évaluer son impact sur la création de comptes et la croissance de l’état avant de poursuivre.

La réduction de cette exigence diminue le capital que les développeurs et les utilisateurs doivent immobiliser lors de la création de comptes de tokens, de PDAs et d’autres états onchain. Elle est particulièrement utile aux applications qui financent la création de comptes pour le compte de leurs utilisateurs, comme les services de paiement à grande échelle.

Les estimations de Ghost indiquent que plus de 3 millions de SOL (~300 M$) peuvent être récupérés. Plusieurs outils ont été développés pour aider les utilisateurs à récupérer les SOL excédentaires de leurs comptes.

Conclusion

Les principales nouveautés d’Agave 4.4 s’appuient sur Alpenglow tout en faisant progresser des améliorations attendues de longue date concernant les récompenses de staking, le déploiement des programmes et les coûts des comptes. Ensemble, elles poursuivent l’évolution de Solana vers un réseau plus rapide et plus accessible. La prochaine étape sera Breakpoint London, suivie d’Agave 4.5.

Ressources complémentaires

• Calendrier de publication d’Agave 4.4
• Calendrier de suivi des activations de fonctionnalités
• Journal des modifications d’Agave 4.4
• Pull requests d’Agave 4.4