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

Introduction

Avec Agave 4.0, le principal client validateur de Solana franchit une nouvelle étape en améliorant les principaux chemins de performance et en préparant le réseau à des blocs plus volumineux ainsi qu’à la très attendue mise à jour du consensus Alpenglow.

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

• XDP accélère considérablement la retransmission de Turbine
• Phase de replay à latence réduite
• Préparation à Alpenglow : marqueurs de transfert rapide entre leaders et validation des identifiants de blocs chaînés*
• Prise en charge cryptographique étendue : arithmétique G2 et syscalls BLS12-381*
• Sérialisation améliorée avec Wincode
• Augmentation de la délégation minimale de stake avec Stake Program v5*
• Réactivation du programme de preuve ZK ElGamal*
• Prise en charge des programmes SBPFv3*

* mises à niveau soumises à l’activation de fonctionnalités

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

À l’heure où nous écrivons ces lignes, Agave v4.0.0-rc.0 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 !

XDP prêt pour une adoption plus large

XDP, abréviation de eXpress Data Path, est le chemin réseau haute performance qu’Agave utilise pour accélérer Turbine. Il permet à Agave de charger un programme eBPF au plus près de la carte réseau, afin que le trafic de shreds contourne une grande partie du chemin standard de traitement des paquets de Linux.

C’est important, car Turbine devient le principal goulot d’étranglement à mesure que Solana évolue vers des limites de blocs plus élevées. Les leaders doivent distribuer les shreds à des centaines de pairs, et les grands validateurs peuvent déjà approcher 150 000 paquets sortants par seconde dans les conditions actuelles. Alors que le réseau progresse vers son objectif de longue date de blocs de 100 millions de CU, les performances d’envoi et de retransmission des paquets doivent évoluer au même rythme que le débit d’exécution. XDP crée cette marge de manœuvre en accélérant considérablement la propagation des blocs.

Avec Agave 4.0, XDP est désormais prêt à être adopté plus largement par les validateurs. Il a fait l’objet de tests de charge sous différentes configurations, a été davantage renforcé et a bénéficié d’améliorations supplémentaires du routage. Les résultats en production sont extrêmement encourageants, avec une retransmission Turbine plus rapide de plusieurs ordres de grandeur.

Alessandro Decina

@alessandrod

one of the largest validators turbine retransmit from 600ms to ~0.8ms agave 4.0 w/ XDP is going to be the biggest solana upgrade to date https://t.co/cKwqVnpH2g

22 avr. 2026, 5:25 AM

Pour mieux comprendre pourquoi XDP représente une amélioration aussi importante, consultez notre précédente interview de l’ingénieur d’Anza Alessandro Decina.

Une phase de replay plus rapide

Agave 4.0 accélère le replay en retirant deux étapes de vérification coûteuses du chemin critique des threads de replay. Dans la v4.0, la vérification des entrées et celle des signatures de transactions sont toutes deux exécutées de manière asynchrone, ce qui permet au replay de poursuivre son traitement pendant que des tâches en arrière-plan confirment la validité du slot.

La première modification déplace la vérification des entrées PoH en arrière-plan. Auparavant, le replay vérifiait la chaîne de hachage des entrées de manière synchrone avant de poursuivre. Une deuxième modification applique le même principe aux signatures de transactions, avec toutefois une distinction importante : Agave sépare désormais la vérification du hachage et du message de la transaction de celle de la signature Ed25519. Le chemin de hachage continue de s’exécuter en amont afin que les transactions puissent être assainies et exécutées en toute sécurité, tandis que les vérifications de signatures, plus coûteuses, s’exécutent en arrière-plan et sont synchronisées avant l’acceptation du bloc.

En pratique, la phase de replay est beaucoup moins bloquée, en particulier pendant les slots chargés, où le nombre de vérifications de signatures augmente avec celui des transactions.

Adoption accrue de Wincode

Wincode est une bibliothèque de sérialisation et de désérialisation développée par Anza, conçue pour l’initialisation sur place et l’écriture directe en mémoire afin de réduire au minimum les tampons intermédiaires. Elle offre des performances de premier plan parmi les sérialiseurs Rust, tout en restant entièrement compatible avec bincode, plus répandu.

Dans Agave 4.0, davantage de chemins de sérialisation critiques pour les performances passent de bincode à wincode. Comme presque toutes les données écrites sur disque ou envoyées sur le réseau dans Solana reposent sur bincode, l’optimisation de ces chemins a un impact considérable.

Augmentation de la délégation minimale de stake (Stake Program v5)

Une mise à jour importante de Stake Program arrive avec Agave 4.0. Cette modification soumise à l’activation d’une fonctionnalité, décrite dans SIMD-0490, prépare l’initiative plus large de Solana visant à réduire les cautions de stake, aussi appelées loyers.

La modification la plus notable est que la délégation minimale de stake passe de 1 lamport à 1 SOL. Cela empêche le coût de création et de maintenance des comptes de stake de devenir trop faible à mesure que les exigences de loyer diminuent, ce qui pourrait créer un vecteur d’attaque. Bien que de nombreux petits comptes de stake se situent sous ce seuil, ils ne représentent que 0,02 % du stake actif total et bénéficieront d’une clause d’antériorité lorsque la mise à jour sera déployée.

La mise à niveau simplifie également plusieurs aspects de la gestion des comptes de stake. Elle utilise désormais la sysvar Rent pour calculer le loyer, au lieu de s’appuyer sur la valeur rent_exempt_reserve stockée dans chaque compte. Elle rend également facultatives les entrées de comptes sysvar pour les opérations de Stake Program et réécrit l’implémentation de Split afin de corriger des cas limites de longue date.

La communauté des opérateurs de validateurs s’est montrée favorable au nouveau minimum de 1 SOL. Les outils et les dapps qui interagissent avec Stake Program devront vérifier leur logique afin de prendre en compte ce nouveau minimum.

Prise en charge cryptographique améliorée

Plusieurs activations de fonctionnalités au cours du cycle de publication d’Agave 4.0 visent à étendre les capacités cryptographiques natives de Solana afin de mieux prendre en charge les cas d’usage modernes, notamment les preuves ZK et les signatures BLS.

Réactivation du programme de preuve ZK ElGamal

Le programme de preuve ZK ElGamal est un programme Solana natif qui vérifie les preuves à divulgation nulle de connaissance utilisées dans les transferts confidentiels de Token-2022. Il permet de valider les soldes et transactions chiffrés sans révéler les données sous-jacentes. Il sert de vérificateur générique pour les preuves cryptographiques fondées sur ElGamal et constitue un composant essentiel des fonctionnalités de jetons respectueuses de la confidentialité de Solana.

Le programme a été désactivé sur le mainnet à la suite d’un incident de sécurité survenu en juin 2025. Une faille dans la logique de vérification des preuves, plus précisément l’absence d’un élément dans le hachage de la transcription Fiat-Shamir, permettait de créer des preuves falsifiées capables de réussir la vérification. Bien qu’aucune exploitation n’ait été observée dans la nature, l’impact potentiel a conduit à désactiver le programme par une fonctionnalité conditionnelle et à suspendre les transferts confidentiels pendant la mise en œuvre des correctifs et la réalisation des audits. Les problèmes ayant été résolus et l’implémentation renforcée, la réactivation du programme sur le mainnet est désormais planifiée.

Arithmétique G2 pour alt_bn128

SIMD-0302 : ajout de syscalls G2 pour alt_bn128 étend les syscalls cryptographiques BN254 (alt_bn128) existants de Solana pour prendre en charge les opérations natives sur les points de la courbe G2, notamment l’addition, la soustraction et la multiplication scalaire. G1 et G2 sont les deux groupes de courbes elliptiques utilisés dans la cryptographie fondée sur les couplages, G2 étant défini sur un corps d’extension plus grand.

Cette évolution comble une lacune majeure de l’ensemble actuel de syscalls, qui se concentre principalement sur les opérations G1. Elle permet une prise en charge plus complète de la cryptographie fondée sur les couplages directement on-chain, en particulier pour des cas d’usage comme la vérification des signatures BLS et les systèmes avancés de preuves ZK.

En l’absence de prise en charge native de G2, certains projets se sont appuyés sur des implémentations personnalisées comme solana-alt-bn128-bls, une bibliothèque complète de signatures BLS créée par Dean Little de Blueshift à partir des syscalls existants. L’activation des opérations G2 au niveau des syscalls éliminerait ces solutions de contournement et faciliterait la création de protocoles cryptographiques prêts pour la production, nativement sur Solana.

Prise en charge du petit-boutisme pour alt_bn128

SIMD-0284 : ajout de la compatibilité petit-boutiste pour alt_bn128 étend les syscalls cryptographiques alt_bn128 existants de Solana pour prendre en charge les formats d’entrée et de sortie petit-boutistes. Auparavant, ces syscalls n’acceptaient que l’encodage gros-boutiste, ce qui compliquait le travail des développeurs utilisant des outils et bibliothèques, notamment ceux de l’écosystème Ethereum. En effet, la plupart des équipes ZK sur Solana utilisent ark-bn254, qui fonctionne en petit-boutiste. Cette modification est rétrocompatible et élargit la prise en charge des cas d’usage existants impliquant des opérations sur courbes elliptiques avec alt_bn128.

Syscalls BLS12-381

Enfin, SIMD-0388 : syscalls BLS12-381 introduit la prise en charge native des opérations cryptographiques sur la courbe elliptique BLS12-381, offrant aux programmes Solana une courbe moderne, adaptée aux couplages et sécurisée sur 128 bits. Jusqu’à présent, Solana s’appuyait sur BN254 (alt_bn128) pour la cryptographie fondée sur les couplages, qui n’atteint pas ce niveau de sécurité et limite la compatibilité avec d’autres écosystèmes largement adoptés comme Ethereum.

Plutôt que d’introduire une toute nouvelle interface de syscall, cette mise à niveau étend les syscalls de courbe existants avec de nouveaux identifiants pour les opérations G1 et G2 de BLS12-381. Les développeurs peuvent ainsi effectuer des opérations arithmétiques de groupe, valider et décompresser des points, ainsi que vérifier des couplages par lots à l’aide d’une interface familière, tout en bénéficiant de capacités cryptographiques nettement plus étendues.

Au-delà des améliorations générales apportées aux preuves à divulgation nulle de connaissance et à la vérification des signatures BLS, ce travail est aussi un élément essentiel à l’activation du consensus Alpenglow. Il permet notamment aux validateurs de vérifier on-chain les preuves de possession BLS, ce qui empêche les attaques par clé malveillante. Cela nous amène à la section suivante.

Préparation à Alpenglow

Les syscalls BLS12-381 ne sont qu’une des nombreuses activations de fonctionnalités du cycle de publication d’Agave 4.0 qui posent les bases de la mise à niveau du consensus Alpenglow. Voici d’autres activations qui contribuent à son déploiement, actuellement prévu sur le mainnet au troisième trimestre 2026, parallèlement à Agave 4.1.

Validation des identifiants de blocs chaînés

SIMD-0340 : validation des identifiants de blocs chaînés définit la manière dont les validateurs doivent vérifier l’ascendance des blocs afin de garantir une chaîne canonique cohérente avec les consensus TowerBFT et Alpenglow. Comme les numéros de slots ne suffisent pas à identifier les blocs de manière unique, notamment en cas d’équivoque lorsque plusieurs blocs peuvent être produits pour le même slot, les clients ne peuvent pas s’appuyer sur l’ordre des slots pour déterminer la bonne relation parent-enfant.

Cette modification introduit des règles explicites de validation de la chaîne afin de garantir que chaque bloc référence correctement son parent, ce qui évite les divergences et aide le réseau à converger vers un historique unique. Avec TowerBFT, cette règle impose aux ensembles FEC de référencer la racine de Merkle de leur parent, à la fois au sein d’un même slot et entre différents slots. Alpenglow utilise une construction à double racine de Merkle couvrant tous les ensembles FEC d’un slot. Si ces vérifications échouent, le bloc, ou le slot, est marqué comme mort. L’application de ces règles renforce la sécurité du consensus et permet aux validateurs de se rétablir après la réception de blocs incorrects ou contradictoires.

Marqueurs de transfert rapide entre leaders

SIMD-0337 : marqueurs pour le transfert rapide entre leaders d’Alpenglow définit des règles de signalement explicites permettant aux validateurs de déterminer quand un slot parent est entièrement terminé et peut servir de base en toute sécurité, condition indispensable aux transitions rapides entre leaders. Cette modification introduit des exigences de placement plus strictes pour DATA_COMPLETE_SHRED ainsi qu’un nouveau marqueur « parent prêt », afin que l’exhaustivité d’un bloc puisse être détectée sans ambiguïté à partir du flux de shreds lui-même.

Aujourd’hui, l’incertitude quant à la transmission complète d’un slot peut retarder le leader suivant, car il peut devoir attendre des shreds supplémentaires ou risquer de construire à partir de données incomplètes. En normalisant la manière dont la fin de transmission est signalée, cette modification permet au leader suivant de commencer plus tôt à produire des blocs en toute confiance, sans coordination supplémentaire ni approximation.

Il s’agit d’un élément essentiel de la conception du transfert rapide entre leaders d’Alpenglow, dans laquelle la réduction de l’intervalle entre les leaders améliore directement le débit du réseau.

Mise à jour du modèle de coût des transactions de vote

SIMD-0458 : fin du coût statique des transactions SimpleVote supprime l’utilisation d’un coût fixe en CU pour les transactions de vote et les aligne sur le modèle standard de coût des transactions utilisé pour les transactions hors vote.

Aujourd’hui, les transactions de vote simples se voient facturer un coût constant de 3 428 CU, fondé sur d’anciennes hypothèses concernant le coût d’exécution déterministe. Avec le nouveau modèle, les transactions de vote seront mesurées dynamiquement comme toutes les autres transactions, ce qui rendra la comptabilisation des coûts plus cohérente et éliminera la nécessité d’une limite de CU distincte pour les votes.

Bien que la consommation réelle de CU à l’exécution reste identique pour les transactions de vote, leur comptabilisation lors de l’assemblage des blocs change. Les votes incluront désormais environ ~16 000 CU estimées supplémentaires, notamment les coûts de chargement des données de comptes, ce qui entraînera des réservations initiales de CU plus élevées lorsque les leaders construiront les blocs.

Cette modification fait suite à SIMD-0387 (gestion des clés publiques BLS dans le compte de vote), qui a supprimé l’hypothèse selon laquelle le programme Vote possède un profil d’exécution statique.

Autres mises à niveau notables

Parmi les autres nouveautés du cycle de publication d’Agave 4.0 figurent la prise en charge des programmes SBPFv3, la possibilité de créer des comptes préfinancés et les entrées-sorties directes pour la décompression des snapshots.

Prise en charge des programmes SBPFv3

Le cycle de publication d’Agave 4.0 comprend une fonctionnalité conditionnelle qui permet de déployer et d’exécuter des programmes SBPFv3. Solana Berkeley Packet Filter (SBPF) est le fork d’eBPF fondé sur Rust de Solana : il s’agit du format de bytecode de bas niveau et de la machine virtuelle vers lesquels les programmes on-chain sont compilés avant leur exécution. Cette mise à jour regroupe les travaux décrits dans trois SIMD : SIMD-0178, SIMD-0189 et SIMD-0377.

SIMD-0178 introduit des syscalls statiques, ce qui permet de résoudre leurs références au moment de l’édition des liens plutôt qu’au moyen de relocalisations ELF lors de l’exécution. Aujourd’hui, ces relocalisations complexifient le chargeur de programmes. Leur suppression simplifie l’exécution et réduit les risques de sécurité.

SIMD-0189 renforce ensuite les contraintes relatives à la structure ELF autorisée pour les programmes. La structure des fichiers doit être plus stricte afin de réduire le nombre de cas limites que les validateurs doivent analyser et la quantité de données inattendues qu’ils doivent traiter. Cette modification devrait être transparente pour les développeurs, car la chaîne d’outils d’édition de liens doit produire automatiquement des binaires conformes.

Enfin, SIMD-0377 met à jour la machine virtuelle SBPF afin de mieux correspondre au jeu d’instructions eBPF moderne généré par LLVM, notamment grâce à la prise en charge d’instructions supplémentaires comme les opérations de saut sur 32 bits. L’objectif est de rendre la VM de Solana plus compatible avec les outils en amont, tout en permettant de compiler les programmes en bytecode plus efficace. Pour les développeurs, cela se traduit concrètement par un chargement plus rapide des programmes, une surface d’attaque réduite et la possibilité d’une consommation de calcul moindre sans modifier la logique applicative.

Création de comptes préfinancés

L’activation de SIMD-0312 : CreateAccountAllowPrefund sur le mainnet est prévue pendant le cycle de publication d’Agave 4.0. Cette proposition introduit dans le programme système une nouvelle instruction qui supprime l’obligation pour les comptes nouvellement créés de commencer avec un solde nul en lamports. Les comptes peuvent ainsi être préfinancés avant leur création, ce qui simplifie un flux de travail courant pour les développeurs et réduit le nombre d’instructions inutiles.

Auparavant, l’instruction CreateAccount échouait si le compte de destination détenait déjà des lamports. Les développeurs devaient donc décomposer l’initialisation du compte en plusieurs étapes : généralement un transfert, suivi d’une allocation et d’une attribution. Cela augmentait la complexité et ajoutait un coût de calcul supplémentaire. Ce schéma est particulièrement courant dans les programmes qui financent les comptes à l’avance.

La nouvelle instruction regroupe ces étapes en un seul appel en permettant d’initialiser directement les comptes préfinancés. En pratique, cela réduit la surcharge liée aux CPI et peut économiser des milliers d’unités de calcul dans les flux courants, offrant ainsi aux développeurs une solution plus claire et plus performante. Comme il s’agit d’une nouvelle instruction et non d’une modification des instructions existantes, elle reste entièrement rétrocompatible.

Entrées-sorties directes pour la décompression des snapshots

Agave 4.0 utilise par défaut les entrées-sorties directes pour décompresser les snapshots, au lieu de faire transiter leurs écritures par le cache de pages du système d’exploitation. Cela améliore le temps de démarrage et les performances de restauration des snapshots. Cette approche est particulièrement utile, car les données de snapshots sont généralement écrites en flux continu sur le disque et n’ont pas besoin d’évincer de la mémoire les données plus fréquemment utilisées par le validateur. Les opérateurs peuvent désactiver cette option avec --no-accounts-db-snapshots-direct-io si leur système de fichiers ne prend pas en charge O_DIRECT. Les entrées-sorties directes devraient être étendues à la création des snapshots dans une prochaine version.

Conclusion

Agave v4.0 est une mise à niveau majeure du client qui apporte de nombreuses améliorations de performances et optimisations de l’environnement d’exécution. Ces modifications visent à rendre le réseau plus rapide, plus sûr et plus facile à utiliser pour développer.

La prochaine étape sera Agave 4.1 et la mise à jour du consensus Apenglow.

Ressources complémentaires

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