Un grand merci à 0xIchigo et Brian Wong pour avoir examiné les versions antérieures de ce travail.

Introduction

La version majeure Agave v3.0 marque une autre étape pour Solana, introduisant une série de mises à jour visant à améliorer les performances du réseau, les opérations des validateurs et l'expérience des développeurs.

Mises à jour notables d'Agave 3.0

• Refonte du cache : livraison d'un traitement des transactions 30 à 40 % plus rapide

• Limite de calcul pour un seul compte plus élevée : augmente la limite d'un seul compte à 40 % des unités de calcul d'un bloc

• Nouvelle structure de transaction Scheduler TransactionView : amélioration de l'efficacité de la planification

• Chemin de données eXpress (XDP) pour Turbine : une condition préalable pour des blocs de 100 millions de CUs

• Augmentation de la profondeur d'imbrication CPI : élève la limite d'imbrication CPI de 4 à 8

• Assouplir les contraintes d'entrée : simplifie la logique de planification et est nécessaire pour l'exécution asynchrone

• Temps de démarrage plus rapides : les nœuds reviennent maintenant en ligne plus rapidement

• Spécification de la taille des données de transaction chargées : standardise la manière dont les données de transaction chargées sont calculées

• Améliorations RPC : mises à jour en temps réel plus rapides et plus fiables pour les dApps utilisant PubSub WebSockets

Chaque section de cet article est autonome, permettant aux lecteurs de se concentrer sur les sujets les plus pertinents pour eux. Que vous soyez un opérateur de validateur, un développeur ou un membre actif de la communauté, ce guide sur Agave v3.0 vous offre les mises à jour clés et les informations nécessaires pour tirer le meilleur parti des dernières améliorations.

Tendances liées aux clients

Avant d'explorer les détails des nouvelles fonctionnalités d'Agave v3.0, regardons comment les données récentes mettent en évidence les progrès réalisés par le réseau Solana et le client Agave, mettant en avant des cycles de sortie plus rapides, une adoption client plus large et des performances robustes sous pression.

Cadence de sortie d'Agave

Anza a notablement accéléré son rythme de sortie cette année, réduisant l'écart entre les versions mineures d'Agave à moins de trois mois. La série Agave 2.2.* est restée la version supermajoritaire pendant seulement 11 semaines, avec Agave 2.3 suivant une chronologie similaire.

Réseau multi-clients

L'adoption de Firedancer sur le mainnet a considérablement progressé ces derniers mois. Actuellement, 21,6 % de la mise est exécutée par le client Jito-Frankendancer, un chiffre qui a lentement et régulièrement augmenté tout au long de l'année (voir le graphique ci-dessous). L'adoption devrait rester autour du seuil de 20 % jusqu'à ce que le client Firedancer complet soit prêt pour le déploiement sur mainnet.

Cela marque une étape significative pour la stratégie multi-clients de Solana, un objectif de longue date visant à améliorer la sécurité, la vivacité et la résilience du réseau. Une plus grande diversité de clients offre un plus grand choix aux opérateurs de validateurs, favorise une compétition saine parmi les équipes de clients et attire plus d'attention sur les bases de code des clients. Cela atténue également le risque qu'un seul bug critique déclenche une panne à l'échelle du réseau.

Il est également notable que la mise en jeu utilisant le client Agave vanille, c'est-à-dire Agave sans modifications MEV tierces comme Jito, a diminué d'environ 6 % au début de l'année à environ 2 % aujourd'hui. Pendant ce temps, l'adoption de Paladin-Agave a augmenté ces derniers mois, représentant maintenant environ 6 % de la mise totale.

Test de stress du réseau

Le 10 octobre, le marché crypto a connu le plus grand événement de liquidation de son histoire, déclenchant une volatilité extrême à travers toutes les principales blockchains. Malgré le pic d'activité réseau battant des records, le réseau Solana et le client validateur Agave ont montré une résilience et une stabilité remarquables sous pression.

Pendant le pic, Solana a soutenu six fois ses niveaux de trafic normaux avec des leaders ingérant environ 100 000 paquets de transactions par seconde, tout en produisant des blocs complets à la limite de 60 millions de CUs.

Même dans ces conditions, Solana a montré les dynamiques de frais les plus stables de tous les principaux réseaux tout en traitant un débit d'un ordre de grandeur supérieur. Le véritable TPS (transactions non-votantes) a dépassé 3 200 au pic d'activité.

Au cours de la fenêtre de pic d'environ deux heures, les frais de transaction médians (P50) de Solana n'ont augmenté qu'à 0,007 $, soit moins d'un centime. Les frais moyens ont brièvement atteint 0,10 $, et le top 1 % des transactions (P99) a culminé juste au-dessus de 1,00 $. Ce schéma démontre l'efficacité des marchés de frais locaux, qui ont confiné les frais élevés uniquement à ces transactions interagissant avec des comptes chauds contestés, tandis que les utilisateurs ordinaires effectuant des transferts simples (par exemple, paiements en stablecoin) n'étaient pas affectés.

Pour comparaison, le mainnet Ethereum et Arbitrum ont vu les frais médians brièvement atteindre plus de 100 $ par transaction pendant la même période. La L2 Base exploitée par Coinbase a également connu des pics de frais avec des frais médians atteignant plus de 3 $. Ces réseaux manquent de marchés de frais locaux, appliquant des ajustements de frais globaux qui augmentent uniformément les coûts pour tous les utilisateurs pendant le stress réseau.

Croissance de l'état

Solana a récemment franchi une étape majeure dans la croissance de l'état on-chain, dépassant 1 milliard de comptes totaux. Près de 67 % de ces comptes sont détenus par le programme Token, dont 89,45 % sont des comptes de jetons associés et 10,55 % des comptes de frappe de jetons.

Cette expansion constante de l'état a des implications à long terme pour les clients Solana et les fournisseurs d'infrastructure. À mesure que le nombre de comptes augmente, la demande sur le stockage, la taille des instantanés et l'indexation des comptes augmente également, ce qui peut avoir un impact sur les performances et les exigences matérielles. Des solutions telles que la compression ZK offrent une voie prometteuse à long terme pour réduire le gonflement de l'état.

Mises à jour du cycle de sortie d'Agave

Révision du cache

Agave 3.0 réduit considérablement les opérations redondantes à l'exécution. Un réaménagement complet du cache de programmes élimine des centaines de recherches de comptes superflues par lot de transaction, résultant en environ 30-40 % de traitement des transactions plus rapide dans les benchmarks internes.

Augmenter la limite de compte à 40 % de CU de bloc

Dans le cadre du cycle de sortie d'Agave 3.0, Solana activera SIMD-0306 : Augmenter les limites de CU des comptes. Cela augmente la limite de CU par compte d'une constante fixe statique de 12 millions à 40 % de la limite de CU de bloc. Actuellement, chaque compte peut consommer jusqu'à 12 millions de CUs par bloc. Comme le montre le graphique ci-dessous d'Anza, les comptes les plus contestés atteignent souvent ce plafond.

Avec ce changement, la limite par compte augmentera initialement de 12 millions à 24 millions de CUs, et finalement à 40 millions de CUs une fois SIMD-0286 (blocs de 100M CU) activé. Combinée à des mises à jour comme l'introduction du programme P-token, cette mise à niveau augmentera considérablement le débit pour les comptes chauds qui sont fréquemment accessibles dans chaque bloc.

D'autres contraintes resteront inchangées, y compris :

• Max Vote Units : le plafond sur le total des CUs de transactions de vote par bloc, à 36 millions de CUs

• Max Block Accounts Data Size Delta : la limite sur les changements totaux de données de compte par bloc, à 100 mégaoctets.

Bien qu'augmenter le plafond des CUs par compte améliore le débit pour l'état chaud, cela peut également augmenter le temps d'exécution sérialisé dans le pire des cas, allongeant potentiellement la vérification des blocs ou la durée des slots dans des scénarios à forte charge.

Enfin, il convient de noter la récente proposition SIMD-0370 : Supprimer la limite de bloc d'unités de calcul, qui explore l'élimination complète des limites de bloc basées sur CU, une direction qui sera probablement révisée après la mise à niveau Alpenglow.

Chemin de données eXpress (XDP) pour Turbine

Le chemin de données eXpress (XDP) est une technologie du noyau Linux conçue pour le réseau haute performance. Elle permet aux applications de contourner une grande partie du chemin standard de traitement des paquets du noyau, réduisant à la fois les copies de données intermédiaires et les changements de contexte entre l'espace utilisateur et l'espace noyau. En traitant les paquets directement avec la carte d'interface réseau (NIC) dans l'espace utilisateur, XDP réduit considérablement le coût par paquet.

Le support de XDP dans Turbine a été introduit pour la première fois dans Agave v2.3.8 et sera activé par défaut à partir d'Agave 3.1. Turbine est le principal goulot d'étranglement de scalabilité alors que les limites de bloc augmentent à 100M CUs. Les leaders relaient leurs fragments à 200 pairs, générant une lourde charge réseau. Les grands validateurs avec plus de slots de leader peuvent approcher 150 000 paquets sortants par seconde dans les conditions actuelles. XDP s'attaque directement à ce goulot d'étranglement, rendant l'envoi de paquets jusqu'à 100 fois plus rapide, permettant aux validateurs de propager des blocs plus grands beaucoup plus efficacement.

Les lecteurs intéressés par un examen plus approfondi de l'implémentation de XDP dans Agave peuvent se référer au guide de configuration des validateurs et à notre précédente interview avec l'ingénieur d'Anza, Alessandro Decina, qui a dirigé l'intégration de XDP dans le client Agave.

Spécification de la taille des données de transaction chargées

Dans le cadre des efforts continus pour simplifier et standardiser le modèle d'exécution de Solana, SIMD-0186 : Spécification de la taille des données de transaction chargées, est prévu pour activation sur le mainnet lors du cycle de sortie d'Agave 3.0.

Cela introduit une méthode sécurisée par consensus pour calculer les données totales des comptes chargés par chaque transaction. L'objectif est de garantir que tous les clients validateurs calculent des tailles de données de transaction identiques, éliminant ainsi les incohérences subtiles qui pourraient autrement provoquer une divergence de consensus.

Actuellement, la logique de dimensionnement des données de transaction de Solana est trop complexe. L'implémentation existante est idiosyncratique dans la manière dont elle gère les programmes LoaderV3 et BPF Upgradeable Loader, qui sous-estiment souvent la taille réelle des données de programme chargées. Ces divergences ont rendu difficile pour les équipes de clients indépendants de mettre en œuvre une logique compatible.

Sous SIMD-0186, les règles de dimensionnement sont désormais explicites et faciles à comprendre :

• Chaque compte chargé est compté exactement une fois

• Les programmes utilisant le BPF Upgradeable Loader incluent leurs données de programme associées

• La taille de chaque compte chargé est définie comme la longueur en octets de ses données avant l'exécution de la transaction, avec 64 octets supplémentaires pour les métadonnées

• Les tables de recherche d'adresses (ALTs) ajoutent chacune 8 248 octets

Cette spécification standardise le dimensionnement des transactions à travers tous les clients et rend le comportement des transactions plus prévisible pour les développeurs.

La limite de taille des données chargées sert un rôle similaire à la limite de CU par transaction, fournissant un comptage de ressources prévisible pour les nœuds validateurs. Par défaut, chaque transaction peut charger jusqu'à 64 Mo de données de compte, consommant huit unités de calcul (CUs) par 32 Ko chargés, équivalent à un coût de base de 16 000 CUs, même si moins de données sont effectivement chargées. Les développeurs peuvent abaisser cette limite via l'instruction setLoadedAccountsDataSizeLimit pour réduire le coût de calcul et améliorer l'efficacité de la planification.

Puisque la nouvelle méthode de dimensionnement peut produire des valeurs variables en fonction de la structure de la transaction, les développeurs peuvent avoir besoin d'ajuster la limite de taille des données de compte chargées spécifiée dans leurs instructions de budget de calcul.

Structure TransactionView du planificateur

Avec Agave 3.0, le planificateur introduit une nouvelle structure de données légère appelée TransactionView, conçue pour rationaliser la façon dont les transactions sont analysées et traitées. Contrairement aux anciens types de transactions SDK, qui nécessitaient une désérialisation et plusieurs allocations de mémoire, TransactionView fournit une vue directe sur une transaction sérialisée. Elle analyse et met en cache des métadonnées sur la disposition de la transaction sans réellement la désérialiser.

Temps de démarrage plus rapides

Les performances de démarrage des clients continuent de s'améliorer avec la version Agave v3.0, marquant une mise à niveau notable de la qualité de vie pour les opérateurs de validateurs et de RPC. Que ce soit après un crash, une mise à niveau ou une maintenance programmée, les nœuds peuvent désormais revenir en ligne de manière significativement plus rapide.

En partant d'une archive d'instantané, les temps de démarrage ont été réduits à moins de trois minutes et demie, moins de la moitié de la durée requise sous Agave v2.2 (voir le graphique ci-dessous). Cette amélioration représente un gain de performance critique, car un démarrage plus rapide améliore directement la résilience du réseau et le temps de disponibilité des validateurs en réduisant le temps nécessaire pour que les nœuds rejoignent à nouveau le consensus.

En regardant vers l'avenir, Agave v3.1 rationalisera encore ce processus en éliminant la vérification des comptes en arrière-plan, permettant aux validateurs de commencer à voter immédiatement après le début de la rediffusion.

Augmenter la limite d'imbrication CPI

SIMD-0268 : Augmenter la limite d'imbrication CPI augmente la profondeur maximale des appels d'invocation croisée de programme (CPI) de 4 à 8. Cela double effectivement le nombre de fois qu'un programme Solana peut invoquer d'autres programmes dans une seule transaction.

Le CPI est le mécanisme par lequel un programme Solana appelle un autre. C'est une fonctionnalité fondamentale de l'exécution de Solana qui permet aux programmes de s'appuyer sur la logique des autres.

Des protocoles on-chain complexes tels que les swaps perpétuels, les portefeuilles intelligents et les systèmes de marge croisée s'appuient souvent sur plusieurs couches d'interactions entre programmes pour gérer les positions, les liquidations et le risque. La précédente limite CPI de 4 niveaux a contraint ces conceptions, dans certains cas forçant les développeurs à diviser la logique sur plusieurs transactions.

Les applications existantes continueront de fonctionner comme auparavant (à moins qu'elles ne dépendent de l'ancienne limite dans leur logique pour échouer les transactions). Dans l'ensemble, ce changement fréquemment demandé élargit l'espace de conception pour les développeurs et renforce la composabilité de Solana.

Assouplir les contraintes d'entrée

SIMD-0083 : Assouplir les contraintes d'entrée, prévu pour activation lors d'Agave 3.0, supprime la règle selon laquelle les transactions dans une entrée de bloc ne doivent pas entrer en conflit les unes avec les autres. Auparavant, toute entrée contenant des transactions conflictuelles (c'est-à-dire celles qui écrivent toutes deux dans le même compte ou où l'une lit pendant que l'autre écrit) invaliderait tout le bloc.

Avec cette mise à jour, de tels conflits sont désormais autorisés. Lorsqu'ils se produisent, les transactions sont simplement exécutées séquentiellement dans l'ordre où elles apparaissent. Ce changement simplifie les règles de regroupement des blocs, offrant aux leaders une plus grande flexibilité dans l'ordre des transactions et la construction des blocs. C'est aussi un changement nécessaire pour que Solana mette en œuvre une exécution asynchrone.

Améliorations RPC

Agave v3.0 introduit des mises à niveau de réactivité au serveur de souscription, qui priorise désormais les messages entrants, tels que les demandes de souscription et les PING, par rapport aux notifications sortantes. Ce changement offre des mises à jour en temps réel plus rapides et plus fiables pour les dApps utilisant PubSub WebSockets.

De plus, des propriétés de slot ont été ajoutées aux données d'erreur des récompenses d'époque, améliorant le débogage et l'observabilité pour les développeurs.

Autres changements

• À partir d'Agave v3.0.0, Anza a discontinué la publication de binaires agave-validator précompilés. Les opérateurs de validateurs doivent désormais compiler les binaires à partir de la source en suivant les instructions de construction fournies.

• Avec Agave v3.0, l'intervalle d'instantané par défaut a été étendu à tous les 100 000 slots, contre 50 000 dans v2.3 et 25 000 dans v2.2. L'augmentation de l'intervalle améliore considérablement les performances du disque, réduisant les pics d'IOPS (opérations d'entrée/sortie par seconde) lors de la création d'instantanés.

• De nombreux anciens arguments et drapeaux CLI obsolètes ont été supprimés (liste complète ici).

• Actuellement, une instruction de nonce avancé dans une transaction peut spécifier n'importe quel compte dans la transaction comme le compte à avancer. Suite à l'activation de la fonctionnalité pour SIMD-0242 : Compte de nonce statique uniquement, cela restreindra l'instruction de nonce avancé à ne pouvoir avancer qu'un compte inclus statiquement.

Conclusion

Agave v3.0 est une mise à niveau substantielle du client, introduisant un traitement des transactions plus rapide, des limites de calcul plus élevées, une efficacité améliorée du planificateur et une gamme d'optimisations pour les validateurs et RPC. Ensemble, ces mises à jour renforcent les performances du réseau et l'expérience des développeurs.

Des données récentes renforcent encore cette progression : des cadences de sortie plus rapides, une diversité de clients croissante et une stabilité exceptionnelle du réseau sous une demande de pointe soulignent tous la maturation de Solana. Avec Agave 3.0 alimentant désormais le réseau, Solana continue de prouver sa capacité à évoluer.