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

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

• Optimisations approfondies des performances
• Augmentation de 20 % des limites de bloc, de 50 à 60 millions de CU
• Introduction de l’Accounts Lattice Hash (ALH)
• Vérification des signatures Secp256r1 (reportée depuis le cycle de publication d’Agave 2.1)
• Déploiement et exécution de programmes SBPFv1, v2 et v3
• Suppression de la restriction sur l’appelant CPI
• Loader-v4

Chaque section de cet article est autonome, ce qui vous permet d’explorer facilement les sujets les plus pertinents pour vous. Que vous exploitiez un validateur, développiez des applications ou utilisiez activement le réseau, ce guide complet d’Agave 2.2 vous fournit les informations essentielles pour tirer pleinement parti des dernières améliorations.

Déploiement des fonctionnalités

Au moment de la rédaction, 19,8 % du stake total exécute Agave v2.2.*, ce qui témoigne d’un fort soutien en faveur de son adoption à l’échelle du réseau. Les activations de feature gates sur le mainnet ont été temporairement suspendues pendant la période de mise à niveau et devraient reprendre prochainement selon la séquence d’activation prévue.

La plupart des fonctionnalités majeures introduites dans Agave 2.2 sont actuellement soumises à des feature gates et ne sont pas encore actives sur le mainnet. Elles seront progressivement activées tout au long du cycle de publication 2.2 au moyen du système de feature gates de Solana. Le calendrier d’activation dépend de la priorité des fonctionnalités et de leur ordre de déploiement sur les clusters testnet et devnet. Consultez le suivi des feature gates d’Agave pour connaître les dernières informations.

Augmentation des limites de bloc à 60 millions de CU

Anza s’est fixé un objectif ambitieux pour 2025 : doubler l’espace de bloc disponible sur Solana. Dans le cadre de cette initiative, SIMD-0256 : augmentation des limites de bloc à 60 millions doit être intégré à la prochaine version 2.2 de Solana, soit une hausse de 20 % par rapport à la limite de bloc actuelle.

Cette évolution fait suite à une mise à niveau précédente, qui avait relevé les limites de bloc de 48 à 50 millions d’unités de calcul (CU). Après celle-ci, les temps de bloc sont systématiquement restés inférieurs à l’objectif de 400 ms. Des données récentes montrent que les blocs atteignent régulièrement le plafond de 50 millions de CU, ce qui indique que le réseau est prêt à poursuivre sa montée en charge.

Remarque : certains blocs semblent remplis à 104 % en raison d’une constante codée en dur dans la logique de reporting du tableau de bord Firedancer.

Les autres limites du protocole restent inchangées dans cette mise à jour :

• Le budget de calcul par compte et par bloc reste fixé à 12 millions de CU.
• Le calcul maximal par transaction reste plafonné à 1,4 million de CU.
• La limite de calcul cumulée des transactions de vote par bloc reste fixée à 36 millions de CU.
• La quantité maximale de nouvelles données de compte allouées par bloc reste limitée à 100 Mo.

L’augmentation des limites de bloc améliore directement l’expérience utilisateur : un débit réseau supérieur réduit les frais de transaction médians et augmente les chances de confirmer les transactions pendant les périodes de congestion.

Difficultés liées à l’augmentation des limites de bloc

Pour accroître le débit, il est préférable de relever les limites de bloc avec prudence et progressivement, car deux difficultés majeures doivent être résolues :

1. Préparation de l’infrastructure

L’infrastructure de l’écosystème au sens large doit suivre le rythme des optimisations du client principal. Plus précisément, la couche d’écriture ne peut pas évoluer plus rapidement que la couche de lecture (par exemple, les nœuds RPC, les indexeurs et les services d’archivage) sans dégrader l’expérience utilisateur.

2. Propagation rapide des blocs

Un autre goulot d’étranglement concerne la transmission des blocs du nœud leader au reste du cluster. Des blocs nettement plus volumineux pourraient faire dépasser aux délais de distribution l’objectif de 400 ms, en particulier en cas de forte charge.

L’étape de retransmission de la Transaction Validation Unit (TVU), par laquelle les shreds sont distribués dans le cluster, constitue un défi urgent. Les grands validateurs approchent les 150 000 paquets sortants par seconde (PPS) en raison du facteur de fan-out élevé de 200 de Turbine (chaque nœud doit ainsi relayer les shreds à 200 autres nœuds). Une gestion inefficace peut entraîner une accumulation de shreds, des transitions de leader irrégulières et des vues incohérentes de l’état du réseau.

Pour résoudre ce problème, les ingénieurs d’Anza remanient actuellement le pipeline de distribution des blocs. L’équipe travaille actuellement à la transition vers XDP (eXpress Data Path), qui permet de contourner le noyau en exposant directement la gestion des paquets à l’espace utilisateur. Cette approche élimine les coûteuses copies intermédiaires et permet au logiciel du validateur de communiquer directement avec la carte d’interface réseau (NIC).

Accounts Lattice Hash (ALH)

Pour prendre en charge des milliards de comptes, Solana a besoin d’une méthode plus évolutive pour hacher l’état global des comptes. Le nouvel Accounts Lattice Hash (ALH) remplacera les anciens hachages de comptes fondés sur des arbres de Merkle par une solution plus efficace et évolutive reposant sur le hachage homomorphe. Celui-ci permet de créer un nouveau hachage à partir de hachages existants sans devoir tout recalculer.

Solana gère actuellement deux hachages de l’état des comptes :

• Epoch Accounts Hash (EAH) : racine de Merkle de l’ensemble de l’état des comptes, calculée une fois par époque.
• Accounts Delta Hash (ADH) : racine de Merkle des comptes modifiés au sein d’un même bloc, recalculée à chaque bloc.

Tous deux reposent sur le tri des comptes par clé publique et sur la construction d’arbres de Merkle, ce qui pose des problèmes de performances et d’évolutivité, en particulier à mesure que le nombre de comptes augmente. Le modèle à double hachage est apparu comme un compromis : l’EAH était précis, car il incluait l’ensemble de l’état des comptes, mais peu fréquent, tandis que l’ADH était fréquent, mais partiel, car il ne couvrait que les comptes modifiés. Dans l’idéal, chaque bloc contiendrait un hachage complet et à jour de l’ensemble de l’état des comptes, sans le coût du recalcul d’un arbre de Merkle.

Fonctionnement de l’Accounts Lattice Hash

L’ALH atteint cet objectif grâce à une fonction de hachage homomorphe permettant des mises à jour incrémentales. Au lieu de reconstruire un arbre de Merkle à chaque fois, l’ALH ajoute ou soustrait simplement les hachages de chaque compte (LtHashes) au fil des écritures dans les comptes. Le résultat est un hachage unique de 2 048 octets qui résume l’état de tous les comptes. Surtout, il peut être mis à jour bloc par bloc sans devoir être entièrement recalculé.

Cette approche offre une complexité O(n), ce qui représente une amélioration significative par rapport à la complexité O(n log n) des arbres de Merkle. Elle permet à chaque bloc d’inclure un hachage de l’ensemble de l’état des comptes sans recalcul coûteux.

Intégration et retrait des anciens hachages

Le déploiement couvre trois SIMD distincts, chacun associé à une activation indépendante par feature gate au cours du cycle de publication d’Agave 2.2.

• SIMD-0215 : Accounts Lattice Hash
• SIMD-0220 : utilisation de l’Accounts Lattice Hash par les snapshots
• SIMD-0223 : suppression de l’Accounts Delta Hash

Avec ces changements, l’Accounts Lattice Hash remplace à la fois l’ADH et l’EAH. L’ALH sera intégré au hachage de bank de chaque bloc, ce qui permettra de hacher l’état complet à la fréquence des blocs plutôt qu’à celle des époques.

Performances et compromis

Le passage à l’ALH améliore considérablement les performances des validateurs en éliminant le hachage fondé sur les arbres de Merkle à chaque bloc. Cela simplifiera le consensus et la génération de snapshots. Par exemple, les validateurs n’auront plus besoin de trier les comptes ni de reconstruire des arbres lors de la finalisation des blocs ou de la création de snapshots : les mises à jour de l’ALH sont de simples opérations additives.

Cependant, contrairement aux arbres de Merkle ou de Verkle, cette approche ne prend pas en charge les preuves d’inclusion ou d’exclusion. Cela affecte certains cas d’usage de vérification cryptographique, tels que les clients légers et la Simple Payment Verification (SPV), mais ce compromis est jugé pertinent compte tenu des gains d’efficacité considérables. Vous trouverez ici une discussion sur les méthodes alternatives de preuve d’inclusion.

Intégration aux snapshots

Comme le calcul initial de l’Accounts Lattice Hash est coûteux, la valeur de l’ALH est désormais conservée dans les snapshots des validateurs et restaurée au démarrage lorsqu’elle est disponible. Les snapshots utiliseront le nouveau format ALH plutôt que des Snapshot Hashes fondés sur des arbres de Merkle, ce qui harmonisera davantage le modèle de stockage et de hachage de Solana avec cette nouvelle architecture.

Vérification native des signatures Secp256r1

Solana ajoute une prise en charge native de la vérification des signatures de courbe elliptique secp256r1, une mise à niveau essentielle qui permet une compatibilité on-chain avec les Passkeys, la norme WebAuthn et les modèles avancés d’abstraction de compte, notamment l’authentification à deux facteurs (2FA). Cette mise à jour introduit dans le Web3 l’authentification sans mot de passe, déjà omniprésente dans le Web2, et améliore ainsi la sécurité et la facilité d’utilisation des applications on-chain.

Initialement prévue pour Agave 2.1, cette fonctionnalité a été reportée à la version 2.2. Pour en savoir plus, consultez notre analyse complète de la vérification des signatures Secp256r1 dans la mise à jour Agave 2.1.

Bug d’alignement des précompilations

Peu après le déploiement initial d’Agave 2.2, un bug critique a été découvert dans l’implémentation des programmes précompilés Secp256r1 et Ed25519. Le bug se déclenchait avec le nouvel indicateur de vue `--transaction-structure`, qui expose les structures brutes des transactions sans garantir leur alignement. Les précompilations supposaient à tort un alignement sur 2 octets des données d’instruction, ce qui entraînait des résultats d’exécution incohérents entre les producteurs de blocs et les validateurs. Cela provoquait des divergences de hachage de bank, obligeant les leaders à abandonner et entraînant une perte de disponibilité. Le problème, signalé pour la première fois le 9 avril, a été rapidement corrigé le 11 avril. Le bug n’a eu aucun impact sur les fonds des utilisateurs. Vous trouverez plus d’informations dans l’analyse des causes profondes publiée peu après.

Déploiement et exécution de programmes SBPFv1, v2 et v3

Le Solana Berkeley Packet Filter (SBPF) est une machine virtuelle personnalisée conçue pour exécuter les programmes Solana de manière efficace et sécurisée. Il s’agit d’un fork en Rust de l’extended Berkeley Packet Filter (eBPF), initialement conçu pour Linux. 

Les mises à niveau du Solana Berkeley Packet Filter (SBPF) sont essentielles pour améliorer les performances, renforcer la sécurité et offrir de nouvelles possibilités aux développeurs d’applications. Agave 2.2 pose les bases d’une maintenance à long terme et de futures améliorations des performances en introduisant un système formel de gestion des versions de la machine virtuelle SBPF, présenté pour la première fois dans SIMD-0161. Ce changement permet le déploiement et l’exécution de programmes SBPFv1 (SIMD-0166), SBPFv2 (SIMD-0173, SIMD-0174) et SBPFv3 (SIMD-0178, SIMD-0179, SIMD-0189). Il établit ainsi un cadre durable pour faire évoluer progressivement l’environnement d’exécution des programmes sans nécessiter de redéploiement à l’échelle du réseau.

Jusqu’à présent, toutes les mises à niveau de SBPF devaient être introduites au moyen de feature gates globales, ce qui compliquait l’évolution du runtime et rendait presque impossible la coordination des déploiements. La gestion des versions résout ce problème en dissociant le comportement du programme du runtime global et en le liant plutôt à une balise de version propre au programme, encodée dans le champ e_flags de l’en-tête du fichier Executable and Linkable Format (ELF). Cette approche permet ce qui suit :

Comportement explicite du runtime

Chaque programme indique l’architecture du jeu d’instructions attendue, c’est-à-dire une version de SBPF. En fonction de cette version, le runtime du programme adapte son comportement.

Déploiement contrôlé

Des feature gates activeront indépendamment le déploiement et l’exécution des nouvelles versions de SBPF, tout en supprimant progressivement les anciennes. Des ensembles complets de changements sont regroupés dans des versions SBPF distinctes, ce qui rend les mises à niveau plus claires et plus faciles à gérer.

Dépréciation progressive

La prise en charge des anciennes versions de SBPF pourra être supprimée après leur dépréciation, ce qui simplifiera la logique de la machine virtuelle. Ce processus sera lent afin de laisser aux développeurs suffisamment de temps pour migrer ou redéployer leurs programmes et les adapter aux nouvelles versions.

Discriminateur de version

Actuellement, le protocole traite toute valeur e_flags autre que 0x0020 comme SBPF v0, ce qui est valide dans le système existant. Toutefois, cette approche ne permet pas de prendre en charge plusieurs versions de SBPF et doit être mise à jour.

Une fois activée la première feature gate autorisant une nouvelle version de SBPF, le protocole modifiera son interprétation de e_flags et associera directement sa valeur au numéro de version SBPF correspondant. Dans ce système, 0x0000 représentera SBPF v0, 0x0001 représentera SBPF v1, et ainsi de suite.

Suppression de la restriction sur l’appelant CPI

Le cycle de publication d’Agave 2.2 inclut une amélioration attendue depuis longtemps, qui supprime une contrainte historique pesant sur les Cross-Program Invocations (CPI). Actuellement, tout programme appelé par CPI doit être explicitement transmis par l’appelant en tant que compte d’instruction. Cela complexifie la construction des transactions et entraîne un coût de calcul important, en particulier avec des CPI profondément imbriquées. Cette restriction est toutefois purement historique et n’est pas nécessaire au protocole actuel.

SIMD-0163 supprime cette restriction en permettant aux instructions CPI de référencer les comptes de programme directement depuis la liste de comptes de premier niveau de la transaction, au lieu d’exiger leur transmission récursive à chaque niveau d’appel. Ce changement offre les avantages suivants :

• Réduit considérablement l’utilisation des CU en évitant la sérialisation et la désérialisation redondantes des comptes de programme (à l’exception des programmes loader-v3, qui stockent leur exécutable dans un compte distinct), particulièrement coûteuses en raison de leur taille importante (binaires d’environ ~10 Mo).
• Simplifie la construction des transactions en évitant de transmettre les comptes des programmes appelés à travers les piles d’instructions.
• Améliore la composabilité et facilite la création d’architectures de programmes modulaires et profondément imbriquées.

Rétrocompatibilité

Les programmes existants ne sont pas affectés, sauf s’ils souhaitent tirer parti de ce changement. Dans ce cas, ils peuvent choisir l’une des options suivantes :

Les programmes dans lesquels le programme appelé est codé en dur de façon statique et qui ont seulement besoin qu’il figure comme n’importe quel compte d’instruction pour respecter la contrainte imposée par le runtime peuvent recevoir un espace réservé tel que NativeLoader1111111111111111111111111111111, afin de ne pas décaler les indices des autres comptes d’instruction.

Tous les autres programmes existants, qui appellent dynamiquement ce qui est transmis dans un compte d’instruction spécifique, devront être mis à jour et redéployés pour bénéficier de la suppression de cette restriction.

Cette optimisation ne compromet pas la sécurité. La fonctionnalité de « visibilité différée » garantit que les programmes ne peuvent pas en appeler d’autres qui ont été ajoutés, modifiés ou supprimés au cours de la même transaction.

Loader-v4

Agave 2.2 introduit la prise en charge de Loader-v4, un mécanisme de déploiement de programmes simplifié et plus flexible, conçu pour remplacer Loader-v3. Activé via SIMD-0167, Loader-v4 simplifie la gestion des comptes de programme, améliore les processus de mise à niveau et introduit des fonctionnalités de sécurité essentielles pour les programmes en production, en particulier ceux qui opèrent dans des environnements à fort enjeu tels que la DeFi.

Principales fonctionnalités de Loader-v4 :

Modèle à compte unique : Loader-v4 élimine le besoin de comptes proxy et de buffers de données de programme distincts. Un seul compte représente désormais chaque programme.

Mode maintenance

Les programmes peuvent désormais être placés dans un « mode maintenance » non exécutable sans être définitivement fermés ni redéployés. Cela préserve l’adresse d’origine du programme et permet aux développeurs de suspendre son exécution, par exemple en cas d’exploitation d’une vulnérabilité, sans renoncer à l’adresse.

Redimensionnement arbitraire

Loader-v4 permet d’agrandir ou de réduire les binaires des programmes après leur déploiement, ce qui assouplit l’allocation des ressources et permet de récupérer des fonds immobilisés.

Utilisation facultative des buffers

Contrairement à Loader-v3, qui exigeait toujours un compte buffer externe pour les redéploiements, Loader-v4 rend les buffers facultatifs. Les programmes peuvent désormais être redéployés directement dans le compte principal du programme, ce qui réduit de moitié les fonds à immobiliser pendant l’importation.

Redéploiements partiels

Loader-v3 exigeait de réimporter l’intégralité du binaire du programme à chaque mise à niveau. À l’inverse, Loader-v4 prend en charge les importations partielles, ce qui permet aux développeurs de ne corriger que certaines sections d’un programme. Cette possibilité est particulièrement utile pour les mises à jour mineures.

Migration fluide depuis Loader-v3

Les programmes déployés avec Loader-v3 peuvent migrer vers Loader-v4 sans changer d’adresse de programme. Cette opération est rendue possible par une nouvelle instruction Migrate dans Loader-v3. Elle différera la visibilité, ce qui signifie que le programme sera indisponible pendant le reste du slot en cours.

Après l’activation de Loader-v4, une feature gate distincte sera déclenchée afin de désactiver les nouveaux déploiements sur Loader-v3. Les programmes Loader-v3 existants resteront fonctionnels, mais tous les futurs déploiements devront utiliser Loader-v4.

Lors de la finalisation d’un programme loader-v4, il est possible d’indiquer l’adresse de la version suivante, afin de former éventuellement une liste chaînée. Cela offre une alternative au redéploiement des programmes et permet aux interfaces utilisateur de proposer une liste des versions finalisées parmi lesquelles choisir.

Les mécanismes de gestion des autorités et de fermeture des comptes restent inchangés dans Loader-v4. Toutes ces fonctions seront disponibles via la nouvelle sous-commande CLI program-v4.

Conclusion

Agave 2.2 représente une étape importante pour le protocole Solana. Cette version apporte des améliorations essentielles du runtime et de nouvelles capacités qui repoussent les limites techniques du réseau. Elle introduit plusieurs changements majeurs : une augmentation de 20 % de la capacité des blocs, l’intégration de l’Accounts Lattice Hash (ALH) pour un hachage évolutif de l’état, plusieurs améliorations du développement de programmes et la prise en charge de la vérification des signatures Secp256r1, essentielle pour permettre des intégrations cryptographiques grand public. Ensemble, ces améliorations augmentent le débit, optimisent l’expérience développeur et renforcent la capacité du réseau à prendre en charge un plus large éventail d’applications.

Que vous développiez des programmes, exploitiez des validateurs ou interagissiez avec le réseau, Agave 2.2 offre à Solana davantage de performances, de flexibilité et de résilience.

Ressources complémentaires

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