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

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

• Optimisations approfondies des performances
• Augmentation des limites de bloc
• Introduction de l’ordonnanceur glouton (expérimental)
• Prise en charge native de la vérification des signatures Secp256r1 (mise à jour : reportée à Agave 2.2)
• Désactivation de la collecte des frais de loyer et des réécritures liées au loyer
• Assouplissement des contraintes en cas d’échec du chargement des transactions
• Migration des programmes de configuration et de tables de recherche d’adresses vers le BPF principal

Chaque section de cet article est conçue pour être consultée indépendamment. Vous pouvez ainsi naviguer librement et vous concentrer sur les sujets qui vous intéressent le plus. Que vous exploitiez un validateur, développiez des applications ou utilisiez activement le réseau, cette présentation détaillée d’Agave 2.1 vous donnera les informations nécessaires pour tirer pleinement parti de ces avancées.

Déploiement des fonctionnalités

Au moment de la rédaction, 88 % du stake exécute désormais Agave 2.1.11. Les activations de fonctionnalités sur le mainnet ont été temporairement suspendues afin de favoriser une adoption plus large de la v2.1 et devraient reprendre prochainement selon l’ordre d’activation prévu. 

La plupart des nouvelles fonctionnalités complètes abordées dans les sections suivantes ne sont pas encore actives. Leur déploiement est prévu au cours du cycle de publication 2.1 au moyen du système d’activation des fonctionnalités. 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.

Améliorations des performances

Les validateurs et les opérateurs RPC ont constaté des gains notables en matière de stabilité et de performances avec Agave 2.1. Au cours de l’année écoulée, Anza s’est attachée à éliminer les goulots d’étranglement, à optimiser l’utilisation des ressources et à améliorer les performances globales. Les nouvelles versions du client visent autant à perfectionner les fondamentaux — augmenter la bande passante, réduire la latence — qu’à introduire de nouvelles fonctionnalités. Avant d’entrer dans les détails de la mise à jour 2.1, prenons un peu de recul pour quantifier les importantes améliorations de performances obtenues au fil des dernières mises à jour du client.

Temps de bloc

L’accélération des temps de bloc sur Solana fait passer la durée moyenne des slots sous les 400 ms. Les époques récentes sont en passe de s’achever en un peu moins de deux jours, un record dans l’histoire du réseau. Les deux clients sont prêts à prendre en charge des temps de bloc plus courts. Cette accélération ne se limite pas à une hausse du débit des transactions. Les récompenses de staking étant liées aux émissions dues à l’inflation, calculées en « années d’époque » plutôt qu’en années civiles, les validateurs et les participants au staking devraient en bénéficier. Une année d’époque suppose 182,5 époques par an, sur la base d’une durée standard de deux jours par époque. Lorsque les époques raccourcissent, elles sont plus nombreuses sur une même période, ce qui augmente de fait la fréquence de distribution des récompenses de staking.

Disponibilité

Solana a affiché une fiabilité presque parfaite tout au long de 2024 et au début de 2025, avec une disponibilité de 100 % pendant plus d’un an. La dernière interruption enregistrée s’est produite le 6 février 2024, lorsqu’un bug connu a temporairement perturbé la finalisation des blocs sur le Mainnet. Le problème a été rapidement identifié et corrigé. Depuis, Solana produit des blocs sans interruption, même pendant les périodes d’activité intense du réseau — comme la récente hausse provoquée par le lancement des tokens de la famille Trump — démontrant ainsi sa résilience sous forte charge.

Taux de slots ignorés

Le taux de slots ignorés mesure la fréquence à laquelle un validateur désigné comme leader pour un slot donné ne parvient pas à produire un bloc dans le délai imparti. Depuis environ l’époque 700, en novembre 2024, ce taux a fortement diminué. Après avoir fluctué entre 2 % et 5 % pendant plusieurs années, il est désormais proche de zéro pour la plupart des validateurs correctement optimisés.  

L’un des facteurs ayant contribué à cette amélioration est l’introduction des récompenses d’époque partitionnées sur le mainnet à l’époque 707. En répartissant les récompenses de stake sur plusieurs blocs, cette modification réduit les goulots d’étranglement provoqués par leur concentration dans le premier bloc de chaque nouvelle époque. Le fonctionnement du réseau devient ainsi plus fluide.

De plus, les Timely Vote Credits (TVC), introduits en novembre 2024, incitent les validateurs à voter rapidement tout en décourageant les votes tardifs. En réduisant le nombre de validateurs qui retardent volontairement leurs votes, les TVC améliorent la convergence du cluster, ce qui accélère la confirmation et la finalité. Ce mécanisme contribue à limiter les forks et à réduire leur durée. Comme le score TVC influence désormais le classement des pools de stake, les opérateurs ont réagi en mettant à niveau leur matériel et en optimisant la configuration de leurs validateurs afin d’améliorer leurs performances.

Transactions par seconde (TPS)

Un nombre plus élevé de transactions par seconde (TPS) indique un débit accru de la chaîne. Les TPS hors votes de Solana, également appelés « True TPS », suivent une progression constante depuis fin 2023. Les données les plus récentes, portant sur la première semaine de février 2025, montrent que le réseau a enregistré une moyenne de 1 228 TPS au 50e centile, tandis que les performances maximales au 99e centile ont atteint 2 520 TPS.  

Le record absolu de TPS a été observé pendant la semaine de l’airdrop du token PENGU, qui s’est achevée le 23 décembre 2024. La moyenne au 50e centile s’élevait alors à 1 260 TPS, tandis que le 99e centile culminait à 3 252 TPS. Cette croissance soutenue souligne la progression continue de l’évolutivité de Solana et de l’efficacité du traitement des transactions.

Frais de priorité

Enfin, une comparaison des frais de priorité collectés par Agave 2.1 et la version précédente 2.0, du 27 janvier au 4 février 2025, montre qu’Agave 2.1 collecte systématiquement des frais de priorité légèrement plus élevés.

Augmentation des limites de bloc

Une augmentation des limites de bloc, proposée dans SIMD-0207 : augmenter la limite de bloc à 50 M, est prévue pour le cycle de publication 2.1 de Solana. Actuellement, le protocole limite à 48 millions d’unités de calcul (CU) le total des ressources de calcul par bloc. Les limites de bloc permettent aux nœuds de suivre le rythme du réseau en restreignant la quantité de travail qu’un leader peut intégrer dans un bloc. L’équipe fondatrice a fixé la limite actuelle de manière empirique, selon la quantité de données que les validateurs peuvent raisonnablement traiter pour atteindre des temps de bloc de 400 millisecondes. 

Cependant, l’activité actuelle du mainnet n’est pas limitée par les temps d’exécution. Les blocs pourraient donc accueillir davantage de transactions sans dépasser l’objectif de 400 ms. Cette mise à jour introduit une hausse modeste de 4 % afin d’augmenter progressivement la capacité du réseau, en faisant passer la limite de calcul par bloc de 48 M à 50 M de CU. Une augmentation plus ambitieuse, comme un doublement de la limite, pourrait être envisageable, mais elle a été jugée trop risquée pour une première modification. L’augmentation des limites de bloc n’affecte pas seulement les validateurs, mais aussi des infrastructures critiques telles que les nœuds RPC, les indexeurs et les services d’archivage, qui doivent adapter leur capacité en conséquence.

Les autres limites du protocole restent inchangées :

• La limite de calcul par compte et par bloc reste fixée à 12 M de CU.
• Le calcul maximal par transaction reste fixé à 1,4 M de CU.

D’autres augmentations des limites de bloc sont prévues et devraient suivre le processus formel SIMD.

Ordonnanceur glouton

Contexte : l’ordonnanceur central

La dernière mise à jour majeure de l’ordonnanceur — l’ordonnanceur central — a été introduite dans Agave 1.18 en mai dernier. Cet ordonnanceur construit un graphe de dépendances à partir des N transactions ayant la priorité la plus élevée, N étant actuellement fixé à 256. Il tente ensuite de planifier les transactions par ordre de priorité, en veillant à traiter d’abord celles qui ne sont pas en conflit. Une fois planifiées, ces transactions sont retirées du graphe, ce qui permet de donner la priorité aux transactions qui étaient auparavant en conflit. L’ordonnanceur remplit ensuite de nouveau le graphe afin de maintenir une file de N transactions.

Cette approche a principalement été conçue pour optimiser le traitement de grands lots et améliorer le débit global des transactions. Elle présente toutefois un inconvénient majeur : la construction du graphe de dépendances et le tri des transactions prennent beaucoup de temps, ce qui crée un goulot d’étranglement. 

Consultez notre précédent article du blog Helius pour une présentation plus détaillée d’Agave 1.18 et de l’implémentation de l’ordonnanceur central.

Le nouvel ordonnanceur glouton

Contrairement à l’ordonnanceur central, l’ordonnanceur glouton ne construit pas de graphe de dépendances. Il suit plutôt une approche plus directe :

• Il sélectionne d’abord la transaction ayant la priorité la plus élevée.
• Si la transaction n’entre pas en conflit avec un lot en cours, elle est ajoutée à l’une des quatre files de threads de travail.
• En cas de conflit, le lot actuel est finalisé et envoyé, puis la transaction est ajoutée à un nouveau lot.

Cette méthode accélère considérablement la planification des transactions, mais produit des lots plus petits, ce qui augmente la surcharge par transaction. Dans les conditions réelles du mainnet, ce compromis reste toutefois avantageux, car le temps d’exécution est principalement déterminé par le traitement BPF plutôt que par la mise en lots.

L’ordonnanceur central rencontre des difficultés lorsque la charge du réseau est élevée, principalement parce qu’il lui faut du temps pour trier les transactions et construire le graphe de dépendances. En supprimant cette surcharge, l’ordonnanceur glouton améliore la réactivité au prix d’une efficacité moindre de la mise en lots.

Prenons un scénario dans lequel les transactions appartiennent à trois groupes en conflit : A, B et C. Deux transactions entrent en conflit lorsque l’une souhaite écrire dans un compte que l’autre souhaite lire ou modifier. Les transactions du groupe A comportent des frais de priorité plus élevés que celles des groupes B ou C.

• L’ordonnanceur central planifierait ensemble les transactions sans conflit A1, B1 et C1 dans un lot : [A1, B1, C1].
• L’ordonnanceur glouton donne d’abord la priorité aux transactions dont les frais sont les plus élevés. Il planifie A1 dans un lot distinct, puis passe à A2 dans le lot suivant.

Cette priorisation accélère la planification, mais peut produire des lots plus petits que ceux de l’ordonnanceur central.

Programme natif de vérification des signatures Secp256r1

Solana introduit un nouveau programme natif pour vérifier les signatures de la courbe elliptique secp256r1, permettant la prise en charge on-chain des Passkeys, de la norme WebAuthn et de nouveaux modèles d’abstraction de compte, notamment l’authentification à deux facteurs (2FA). Cette amélioration ouvre la voie à l’utilisation de l’authentification sans mot de passe, déjà très répandue dans le Web2, comme deuxième facteur de sécurité on-chain.

La courbe elliptique secp256r1 est une courbe cryptographique normalisée par le NIST et largement prise en charge par les appareils modernes, notamment :

• WebAuthn : une norme du W3C pour l’authentification fondée sur la cryptographie à clé publique, prise en charge par tous les principaux navigateurs web.
• Secure Enclave d’Apple : un environnement d’exécution de confiance (TEE) matériel qui signe les messages et n’est accessible que par authentification biométrique.
• Android Keystore : une API permettant de gérer les clés privées et les méthodes de signature, qui s’appuie sur le TEE de l’appareil pour stocker les clés de manière sécurisée.
• Passkeys : une norme de la FIDO Alliance et du W3C qui remplace les mots de passe par des paires de clés cryptographiques et qui est compatible avec la cryptographie sur courbes elliptiques.

Plusieurs autres réseaux, dont Ethereum (EIP-7212), ont également étudié l’intégration de la prise en charge de la courbe secp256r1.

Détails du programme Secp256r1

Le nouveau programme sera déployé sous l’ID : Secp256r1SigVerify1111111111111111111111111

Structure de l’instruction :

• Un compteur u8 indique le nombre de signatures à vérifier.
• Un octet de remplissage suit.
• Pour chaque signature, la structure sérialisée suivante est utilisée :

struct Secp256r1SignatureOffsets {
    signature_offset: u16,             // offset to secp256r1 signature of 64 bytes
    signature_instruction_index: u16,  // instruction index to find signature
    public_key_offset: u16,            // offset to public key of 32 bytes
    public_key_instruction_index: u16, // instruction index to find public key
    message_data_offset: u16,          // offset to start of message data
    message_data_size: u16,            // size of message data
    message_instruction_index: u16,    // index of instruction data to get msg data
}

Cette mise à jour provient de SIMD-0048 : programme natif pour la vérification des signatures Secp256r1, proposé par l’équipe Bunkr. Le programme précompilé Secp256r1 SigVerify fonctionnera de manière similaire à la prise en charge existante de secp256k1 par Solana et à celle des signatures ed25519.

Désactivation de la collecte des frais de loyer et des réécritures liées au loyer

Deux mises à jour liées, proposées dans SIMD-0084 : désactiver la collecte des frais de loyer et SIMD-0183 : ignorer les réécritures liées au loyer, élimineront une grande partie de la surcharge héritée associée aux comptes soumis au loyer.

La collecte des frais de loyer est un composant complexe de la Bank. Sa désactivation simplifiera la base de code du client de validation et facilitera le développement de toutes les implémentations de clients de validation, qui n’auront plus à reproduire la logique de collecte du loyer. Le loyer ne sera plus déduit des comptes et les frais de loyer collectés ne seront plus distribués aux validateurs. Il n’est déjà plus possible de créer de nouveaux comptes soumis au loyer : toute tentative entraîne une erreur de transaction.

Actuellement, la collecte du loyer vérifie chaque compte au moins une fois par époque. Elle charge et stocke les comptes même lorsqu’ils restent inchangés. Tous les comptes Solana étant déjà exemptés de loyer, le maintien de ce processus représente une charge de calcul inutile.

Les réécritures de comptes liées au loyer seront supprimées, ce qui réduira le nombre de comptes stockés par slot. Les validateurs bénéficieront ainsi de meilleures performances, car moins de comptes seront inclus dans le calcul du hachage delta des comptes et du hachage incrémentiel des comptes. Cette modification réduit également la taille des instantanés incrémentiels, diminuant encore la consommation de ressources.

Assouplissement des contraintes sur les transactions : échecs de chargement

Actuellement, les transactions Solana sont soumises à des contraintes strictes qui peuvent les faire échouer avant leur inclusion dans un bloc. Ces échecs préalables à l’inclusion entraînent un gaspillage des ressources de calcul des validateurs, car des ressources sont mobilisées sans percevoir de frais de transaction. Le travail est donc effectué sans compensation.

La production de blocs est également compliquée par la nécessité de filtrer les transactions qui invoquent des programmes non valides ou dépassent la limite maximale de 64 MiB (~67,11 Mo) de données de comptes chargées. Ces restrictions augmentent la complexité de l’assemblage des blocs et rendent plus difficile la détermination de leur validité. En assouplissant ces contraintes, les transactions pourraient être incluses dans un bloc et des frais pourraient être facturés sans qu’il soit nécessaire de charger et de vérifier au préalable les données du programme. Cette évolution vise à supprimer la dépendance à l’état des comptes pour la validation des blocs.

Ces modifications, proposées dans SIMD-0191, peuvent affecter certains outils, notamment les explorateurs de blockchain, qui partent du principe que toutes les transactions tentent de s’exécuter. Les utilisateurs doivent également s’assurer que leurs transactions sont exécutables afin d’éviter des dépenses inutiles en frais.

Migration des programmes de configuration et de tables de recherche d’adresses vers le BPF principal

Dans le cadre de la transition en cours des programmes natifs intégrés vers les programmes Berkeley Packet Filter (BPF), les programmes Config et Address Lookup Table seront migrés vers des programmes BPF principaux. Cette évolution dissocie ces programmes critiques de l’environnement d’exécution du validateur, ce qui permet des mises à jour plus flexibles et une maintenance plus simple.

Les programmes BPF sont moins complexes que leurs équivalents natifs, ce qui simplifie leur développement et leur maintenance sur les différents clients de validation. Grâce à cette modification, les équipes travaillant sur Firedancer et Anza n’auront plus à suivre et à implémenter séparément les changements apportés aux programmes dans leurs environnements d’exécution. Les mises à jour seront appliquées uniformément à tous les clients. 

Les programmes réimplémentés conserveront des ABI identiques à celles de leurs versions natives, garantissant une compatibilité totale. Seule leur consommation de ressources de calcul différera.

Conclusion

La mise à jour Agave 2.1 représente une avancée majeure pour Solana, avec des améliorations essentielles des fonctionnalités et des optimisations de l’environnement d’exécution. Cette version renforce le réseau en étendant ses capacités, en améliorant ses performances et en repoussant les limites de Solana. Avec la prise en charge native de la vérification des signatures Secp256r1, l’augmentation des limites de bloc, les nombreuses améliorations de performances et l’introduction future de l’ordonnanceur glouton, Agave 2.1 améliore à la fois l’efficacité et l’évolutivité. Que vous développiez des applications, exploitiez un validateur ou utilisiez activement le réseau, cette mise à jour ouvre de nouvelles possibilités et rend Solana plus rapide, plus flexible et plus puissante que jamais.

Ressources complémentaires

• Dépôt du client Agave
• Calendrier de publication d’Agave v2.1
• Pull requests étiquetées Agave v2.1