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

Introduction

Avec Agave 4.1, le client de validation principal de Solana poursuit son évolution régulière. Il améliore dès aujourd’hui les performances tout en préparant le terrain pour des blocs plus volumineux, des slots de 200 ms et le déploiement futur d’Alpenglow.

Principales nouveautés du cycle de publication 4.1

• Rythme de publication accéléré, avec désormais des versions majeures toutes les six semaines
• Poursuite des travaux de préparation à Alpenglow, notamment la gestion des clés publiques BLS*, les Validator Admission Tickets* et le cluster de test communautaire
• Adoption de XDP au-delà d’un seuil critique du réseau
• Réécriture d’autres programmes avec Pinocchio, notamment p-memo et p-ATA
• Réduction de l’utilisation de la RAM par les validateurs
• Préparation aux slots de 200 ms**

* Mises à niveau soumises à l’activation d’une fonctionnalité

** Prévu dans Agave 4.2

En parallèle des travaux sur le client principal, Anza et l’ensemble de l’écosystème font également progresser plusieurs initiatives majeures :

• Constellation : Constellation propose la première implémentation formelle, au niveau du protocole, de Multiple Concurrent Proposers (MCP) sur une blockchain de production à grande échelle. Au lieu d’accorder à un seul leader une grande latitude sur l’inclusion des transactions, Constellation introduit des proposants et des attestateurs qui limitent ce que le leader peut exclure d’un bloc valide.
• Renforcement face aux menaces quantiques : l’équipe de recherche d’Anza a commencé à étudier comment sécuriser Solana contre de futurs adversaires quantiques, notamment par des recherches sur les signatures post-quantiques, la migration des comptes, les signatures de consensus, la propagation des blocs et la vérification onchain des signatures.
• Évolutions économiques : une nouvelle vague de propositions tokenomiques est également en préparation. SIMD-550 propose de doubler le taux de désinflation de Solana, de -15 % à -30 %, tandis que SIMD-553: Resource and Inclusion Fee propose de scinder les frais de signature actuels en frais d’inclusion de base versés au leader et en frais de ressources détruits, calculés selon les unités de coût demandées.
• Nouveaux outils de gouvernance : la prochaine série de propositions économiques bénéficie également d’une meilleure infrastructure de gouvernance. De nouveaux outils permettent non seulement aux validateurs, mais aussi aux stakers, de participer directement à la gouvernance de Solana, élargissant ainsi le cercle des acteurs pouvant se prononcer sur les changements fondamentaux du protocole.

Il se passe énormément de choses en ce moment.

Que vous exploitiez un validateur ou développiez des applications, ce guide vous apporte les informations et éclairages 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 qui vous concernent le plus. 

À l’heure où nous écrivons ces lignes, Agave v4.1.0-rc.1 est désormais recommandé pour une utilisation générale sur le mainnet. Opérateurs de validateurs, il est temps d’effectuer la mise à niveau !

Préparation à Alpenglow

Une grande partie des fondations nécessaires à la mise à niveau du consensus vers Alpenglow arrive pendant le cycle de publication d’Agave 4.1. Ces changements préparent le réseau à passer de Tower BFT à Alpenglow, notamment grâce à la gestion des clés BLS dans le programme de vote, aux Validator Admission Tickets et aux marqueurs Fast Leader Handover.

Cluster de test communautaire

La dernière étape avant l’activation d’Alpenglow sur le mainnet repose désormais en grande partie sur des tests approfondis en conditions réelles. Depuis mai, un cluster de test communautaire composé d’environ 100 validateurs répartis géographiquement exécute la mise à niveau dans un environnement réseau réel. Il teste la transition entre le consensus actuel de Solana, fondé sur Tower BFT, et Alpenglow avant l’activation sur le mainnet.

L’objectif est de rendre le lancement aussi peu mouvementé que possible. Les validateurs du cluster alternent entre Tower BFT et Alpenglow afin de tester le parcours de migration dans les conditions réelles d’exploitation, plutôt que de s’appuyer uniquement sur des tests internes contrôlés. Les discussions ont lieu dans le canal `ag-community-cluster` du Discord Solana Tech. L’activité du cluster peut être suivie en direct sur les tableaux de bord communautaires de Valid Blocks, Staking Facilities et Noders.

Gestion des clés publiques BLS

SIMD-0387: BLS Pubkey Management in Vote Account sera activé pendant le cycle de publication d’Agave 4.1. Cette mise à niveau ajoute au programme de vote l’infrastructure nécessaire pour que les validateurs enregistrent leurs clés publiques BLS dans leurs comptes de vote avant Alpenglow. Alpenglow utilise des signatures BLS agrégées pour réduire le coût d’agrégation et de vérification des votes, mais les clés publiques BLS sont distinctes des clés d’autorité de vote Ed25519 utilisées aujourd’hui. 

Les validateurs peuvent ajouter des clés publiques BLS à leurs comptes de vote tout en continuant à fonctionner avec leurs clés d’autorité de vote Ed25519 existantes. Une fois Alpenglow activé, les comptes de vote sans clé publique BLS enregistrée ne pourront pas participer au nouveau processus de vote.

Alpenglow Validator Admission Tickets (VAT)

Le cycle de publication d’Agave 4.1 inclura également l’activation sur le mainnet de SIMD-0357, qui implémente les Validator Admission Tickets (VAT). Les VAT visent à préserver une structure de coûts similaire pour les validateurs lorsque Solana abandonnera le modèle actuel de transactions de vote de Tower BFT.

Aujourd’hui, les validateurs paient continuellement des frais de transaction de vote à mesure qu’ils votent, soit un total de ~2,1 SOL par époque pour ceux qui votent régulièrement. Avec Alpenglow, ces transactions de vote sont remplacées par une nouvelle architecture de consensus. SIMD-0357 introduit donc à la place un coût d’admission payé une fois par époque. Chaque validateur autorisé à participer au vote Alpenglow paie un VAT de 1,6 SOL par époque. Cela maintient une barrière économique comparable tout en réduisant le risque d’une expansion immédiate et incontrôlée de l’ensemble des validateurs après le lancement d’Alpenglow.

L’implémentation intervient à la limite de l’époque. Lors du passage à une nouvelle époque, le runtime calcule l’ensemble des validateurs pour l’époque suivante, filtre les comptes de vote qui disposent à la fois d’une clé publique BLS enregistrée et de suffisamment de lamports pour couvrir le VAT et le loyer, puis déduit le VAT des comptes de vote des validateurs acceptés. Ces lamports sont envoyés directement au compte incinérateur. Si plus de 2 000 validateurs remplissent les conditions, l’ensemble des votants est plafonné selon le poids du stake et les principaux validateurs admissibles sont sélectionnés.

Sur le plan opérationnel, cela change l’endroit où les opérateurs de validateurs doivent conserver leurs fonds. Les frais de transaction de vote sont actuellement payés depuis le compte d’identité du validateur, qui doit utiliser une paire de clés active pour le fonctionnement normal du validateur. Avec les VAT, le coût d’admission est déduit du compte de vote à la place.

Marqueurs Fast Leader Handover

Enfin, l’activation de SIMD-0337: Markers for Alpenglow Fast Leader Handover ajoutera de nouveaux marqueurs de bloc permettant à un leader Alpenglow de déclarer le parent d’un bloc au début de celui-ci et, si nécessaire, de mettre à jour ce parent pendant la diffusion du bloc. Ces marqueurs prennent en charge Fast Leader Handover, conçu pour réduire les délais de synchronisation entre les leaders.

Adoption accrue de XDP et trajectoire vers 100 millions de CU

XDP (eXpress Data Path) est le chemin réseau haute performance utilisé par Agave pour accélérer Turbine. Il permet à Agave de charger un programme eBPF à proximité de la carte d’interface réseau, afin que le trafic de shreds contourne une grande partie du chemin standard de traitement des paquets Linux. L’adoption de XDP est indispensable pour que le réseau atteigne son objectif de longue date : des blocs de 100 millions de CU. 

L’adoption a désormais franchi un seuil important. Au début du mois, le réseau a connu le « basculement » : les leaders exécutant XDP sont devenus majoritaires. Actuellement, plus des deux tiers du réseau ont activé XDP. Agave 4.1 reflète cette maturité en retirant la mention expérimentale de la prise en charge de XDP et en remplaçant les anciens indicateurs `--experimental-retransmit-xdp-*` par `--xdp-interface`, `--xdp-cpu-cores` et `--xdp-zero-copy`. Dans Agave 4.2, XDP devrait être activé par défaut.

Pour les opérateurs de validateurs qui n’ont toujours pas effectué la transition, la page de mise à niveau de Solana Foundation et le guide de configuration d’Anza fournissent une liste de vérification pratique couvrant la prise en charge du noyau, le matériel réseau, les capacités du validateur, les indicateurs de démarrage et les étapes de vérification. Vous trouverez ci-dessous un guide utile sur la compatibilité des pilotes et des cartes réseau.

Davantage de réécritures de programmes avec Pinocchio

Le lancement réussi de p-token a récemment démontré que des réécritures ciblées des programmes les plus utilisés de Solana peuvent générer d’importantes économies de calcul à l’échelle du réseau. En tant que remplacement direct du programme SPL Token, p-token réduit la consommation d’unités de calcul (CU) d’environ 95 %, soit une efficacité multipliée par ~19 pour les transactions de tokens standard. Les instructions du programme de tokens représentaient auparavant environ 10 % de l’utilisation des CU à l’échelle d’un bloc. En ramenant le coût de ces instructions à environ 5 % de son niveau antérieur, p-token a libéré près de 9,5 % de la capacité totale des blocs.

Le « p » de p-token signifie Pinocchio, une bibliothèque optimisée, performante et sans dépendance, développée par Anza pour écrire des programmes Solana. Pinocchio remplace le crate solana-program standard, qui utilise largement des types zero-copy pour traiter les données d’instruction et de compte.

Anza réécrit désormais d’autres programmes fondamentaux avec Pinocchio. L’objectif n’est pas d’introduire de nouvelles normes ni d’imposer des migrations au niveau des applications, mais de réduire considérablement le coût d’exécution de programmes existants et largement utilisés.

Programme p-memo

Le premier exemple est p-memo, une réimplémentation du programme SPL Memo avec Pinocchio, déjà active sur le mainnet. Le programme Memo est petit, mais les gains d’efficacité restent remarquables. Sans signataire, p-memo consomme 287 CU, contre 2 022 CU pour le programme Memo actuel, soit environ 14 % du coût existant. Avec des signataires, l’écart devient encore plus marqué : avec un signataire, p-memo utilise 513 CU contre 13 525 CU ; avec deux signataires, 628 CU contre 25 111 CU ; et avec trois signataires, 743 CU contre 36 406 CU. Ainsi, lorsqu’il y a beaucoup de signataires, p-memo ramène la consommation de calcul à seulement 2 à 4 % du coût du programme actuel.

Programme p-ATA

Les travaux progressent également sur p-ATA, une réimplémentation avec Pinocchio de l’Associated Token Account program. Le programme ATA définit la correspondance standard entre un wallet, l’émission d’un token et le compte de tokens utilisé pour détenir les tokens émis. Il offre un moyen déterministe de dériver le compte de tokens associé d’un utilisateur et permet à quiconque de créer ce compte pour un destinataire s’il n’existe pas encore. 

Le programme ATA est le cinquième programme le plus invoqué sur le réseau. Selon les estimations de l’équipe Anza, il apparaît dans ~11,9 % de toutes les transactions et représente ~13,3 % de la consommation totale de CU. Cette réécriture pourrait réduire de 80,9 % l’utilisation moyenne pondérée des CU, avec des économies supplémentaires attendues grâce aux nouvelles instructions ajoutées avec p-ATA. Au niveau actuel d’utilisation du réseau, cela représenterait environ 10 % d’économies globales de CU sur le mainnet. Dans l’échantillon d’Anza, p-ATA a libéré plus de 2,78 millions de CU par bloc.

P-token, p-memo et p-ATA ne marqueront probablement pas la fin de ces travaux. Le programme Token-2022 est un autre programme très demandé. Plus généralement, les efforts d’Anza visant à rendre les programmes fondamentaux `no_std` préparent la réécriture d’un plus grand nombre de programmes essentiels de Solana avec moins de dépendances et des coûts de calcul inférieurs.

Réduction de la surcharge du point d’entrée des programmes

Un changement connexe dont l’activation est prévue pendant le cycle de publication d’Agave 4.1 est SIMD-0449: Direct Account Pointers in Program Input, qui optimise le point d’entrée des programmes. Aujourd’hui, les programmes sBPF ABIv1 doivent analyser la section sérialisée des comptes dans l’entrée du programme afin d’identifier les limites des comptes et de construire la tranche de comptes transmise au programme. SIMD-0449 change cette approche : la VM ajoute à l’entrée du programme une tranche de pointeurs directs vers les comptes, en utilisant les informations de limites qu’elle connaît déjà lors de la préparation de l’invocation.

Cette évolution est particulièrement pertinente pour les programmes de type Pinocchio, car l’analyse des comptes représente une grande partie du coût du point d’entrée. Grâce aux pointeurs directs vers les comptes, le point d’entrée peut accéder aux comptes sans parcourir toute la section correspondante. Le coût de calcul du point d’entrée devient ainsi pratiquement constant, quel que soit le nombre de comptes. 

Dans les benchmarks mis à jour, le coût d’un point d’entrée Pinocchio comprenant 64 comptes passe de 504 CU à environ 7 CU, tandis que les ensembles de comptes plus petits convergent également vers ce faible coût de 7 CU.

Réduction du temps des slots à 200 ms

L’une des améliorations de performances les plus attendues consiste à réduire le temps cible des slots de Solana de 400 ms à 200 ms. Elle ne sera probablement pas déployée pendant le cycle de publication d’Agave 4.1 et devrait plutôt arriver sur le mainnet avec Agave 4.2. Cependant, la dynamique s’accélère pour déployer cette importante mise à niveau sur le mainnet dès que possible.

SIMD-0525: Reduce Slot Times propose un déploiement progressif : les slots passeraient de 400 ms à 350 ms, puis à 300 ms et 250 ms, avant d’atteindre finalement 200 ms. Chaque étape est soumise à l’activation d’une fonctionnalité, ce qui permet aux équipes chargées des clients et aux opérateurs d’observer le réseau avec des slots plus courts avant de passer à l’étape suivante. Anza teste en interne les slots de 200 ms depuis plusieurs mois et l’équipe estime que le réseau est prêt pour une réduction ambitieuse de leur durée. Les améliorations apportées à l’étape de replay ont rendu ce changement plus réaliste : le replay d’un slot complet de 400 ms prend désormais environ 40 ms.

La motivation est simple. Des slots plus courts réduisent la latence de confirmation et de finalisation pour les utilisateurs. Ils raccourcissent également la fenêtre de chaque leader. Aujourd’hui, la période d’un leader Solana couvre quatre slots consécutifs, soit une fenêtre de 1,6 seconde avec des slots de 400 ms. Avec des slots de 200 ms, cette fenêtre tombe à 800 ms. Cela améliore la structure du marché en réduisant, dans le pire des cas, la durée pendant laquelle un leader malveillant peut retarder, réordonner ou inclure sélectivement des transactions avant que le leader suivant puisse produire un bloc.

Des slots plus courts offrent également aux applications une vision plus précise du temps onchain. C’est important pour les systèmes qui évaluent la fraîcheur des slots, notamment les consommateurs d’oracles et les teneurs de marché propriétaires de type AMM.

La proposition est soigneusement conçue pour ne pas modifier l’économie de Solana. `slots_per_year` est augmenté selon le ratio inverse, ce qui préserve le calendrier d’inflation de SOL. Avec Alpenglow, le coût des Validator Admission Tickets (VAT) évolue également selon l’étape de réduction du temps des slots, maintenant le coût d’admission proche de la cible de ~0,8 SOL par jour. De plus, les limites de travail par slot sont réduites proportionnellement au raccourcissement du temps cible des slots, de sorte que la quantité de travail que le réseau peut traiter par seconde reste pratiquement inchangée. 

Plusieurs hypothèses fondamentales restent inchangées. Les périodes des leaders couvrent toujours quatre slots, les époques restent fixées à 432 000 slots et chaque slot compte toujours 64 ticks. Comme les époques conservent un nombre fixe de slots, des slots de 200 ms réduisent la durée d’une époque d’environ deux jours à un jour.

L’un des points de désaccord concerne l’impact sur les coûts de vote des validateurs si des slots plus courts sont activés avant Alpenglow. Des slots plus rapides entraînent davantage de votes par jour et donc une hausse des coûts de vote quotidiens pour les validateurs. Les transactions de vote représentent leur principale dépense. Leur prix uniforme est de 0,000005 SOL et leur coût quotidien s’élève à ~1,086 SOL. Avec des slots de 200 ms, ces coûts doubleraient approximativement.

Autres nouveautés importantes

Plusieurs améliorations plus modestes mais notables doivent être activées pendant le cycle de publication d’Agave 4.1. Elles vont de taux de commission des validateurs plus précis à de nouvelles primitives cryptographiques, en passant par la suppression d’un vecteur d’attaque par déni de service dans le loader évolutif.

Précision accrue des taux de commission des validateurs

Dans le cadre du cycle de publication d’Agave 4.1, la mise à niveau SIMD-0291: Commission Rate in Basis Points, soumise à l’activation d’une fonctionnalité, sera activée sur le mainnet. Aujourd’hui, les taux de commission des validateurs ne peuvent être définis qu’en points de pourcentage entiers. Un validateur peut donc fixer sa commission à 5 % ou 6 %, mais pas à 5,5 %, 5,25 % ou 5,01 %.

Grâce à cette mise à jour, les validateurs bénéficient d’un contrôle plus précis en définissant leurs taux de commission en points de base, 100 points de base équivalant à 1 %. Le programme de vote ajoute une nouvelle instruction `UpdateCommissionBps`, qui permet au responsable des retraits autorisé d’un compte de vote de mettre à jour avec cette précision accrue la commission du validateur sur les récompenses d’inflation. Les validateurs peuvent ainsi définir leurs commissions avec davantage de flexibilité et de compétitivité.

Ce changement fait partie de plusieurs mises à jour liées au nouveau Vote Account V4. Il contribue également à préparer le réseau à l’activation attendue de SIMD-0123: Block Revenue Distribution, qui permettra de distribuer les récompenses de bloc directement dans le protocole.

Syscall SHA-512

SIMD-0512: Sha512 Syscall introduit un nouveau syscall qui donne aux programmes onchain un accès direct au hachage SHA-512 via le runtime, au moyen d’une interface semblable à celle des syscalls de hachage existants tels que `sol_sha256`, `sol_keccak256` et `sol_blake3`.

SHA-512 est une primitive fondamentale utilisée pour vérifier les signatures Ed25519. Elle existe déjà comme dépendance interne dans les clients de validation Agave et Firedancer. Jusqu’à présent, elle n’était toutefois pas exposée aux programmes onchain. Le hachage direct d’un message court onchain est coûteux et consomme des milliers de CU, contre moins de 100 CU avec un syscall.

Avec `sol_sha512`, les programmes peuvent calculer des hachages SHA-512 au coût d’un syscall et recevoir directement le condensé standard de 64 octets. Ce changement est additif et soumis à l’activation d’une fonctionnalité. Il n’affecte donc pas les programmes qui n’utilisent pas le nouveau syscall, et les syscalls de hachage existants restent inchangés.

Renforcement du loader évolutif

Le cycle de publication d’Agave 4.1 verra également le lancement, soumis à l’activation d’une fonctionnalité, de SIMD-0431: Loader V3: Minimum Extend Program Size, qui ajoute une taille d’extension minimale à l’instruction `ExtendProgram` de Loader V3. Une fois cette fonctionnalité activée, les programmes devront être étendus d’au moins 10 240 octets (10 Kio), sauf si le compte de données du programme se trouve déjà à moins de 10 Kio de la taille maximale de 10 Mio par compte.

Ce changement corrige un vecteur subtil de déni de service dans le loader évolutif actuel. `ExtendProgram` est sans permission, ce qui signifie que n’importe qui peut étendre le compte de données d’un programme évolutif, même d’un seul octet. Comme chaque extension invalide l’entrée du programme dans le cache pour le slot actuel, une extension peu coûteuse d’un octet peut temporairement perturber l’accès au programme.

Plutôt que de soumettre `ExtendProgram` à une autorisation, ce changement préserve la conception sans permission de l’instruction tout en rendant les abus économiquement peu attrayants. Avec le nouveau minimum de 10 Kio, chaque extension coûte environ 0,072 SOL en lamports exemptés de loyer.

Pour les mises à niveau légitimes de programmes, l’impact devrait rester limité. Les programmes nécessitant moins de 10 Kio d’espace supplémentaire devront être étendus du minimum complet, mais cette capacité additionnelle restera disponible pour de futures mises à niveau. Le SIMD ne modifie pas non plus les comptes des instructions, les exigences relatives aux signataires, les restrictions CPI ni les workflows multisig existants.

Conclusion

Agave 4.1 est une mise à niveau majeure du client qui réunit un large éventail d’améliorations et d’optimisations des performances. Agave 4.2 s’annonce encore plus importante, avec des transactions plus volumineuses de 4 096 octets, des slots réduits à 200 ms et, peut-être, la mise à niveau tant attendue du consensus vers Alpenglow.

Ressources complémentaires

• Calendrier de publication d’Agave 4.1
• Calendrier de suivi de l’activation des fonctionnalités
• Journal des modifications d’Agave 4.1
• Pull requests d’Agave 4.1