Solana Agave 4.2 : réduction de 90 % des frais de location et cap sur des slots de 200 ms

Trois mises à niveau activées par fonctionnalité ont commencé à s'activer sur le réseau principal de Solana la semaine du 17 août. Une réduction de 90 % du loyer de stockage sur la chaîne, une augmentation de 3,3 fois de la taille maximale des transactions, et une réduction progressive du temps de slot de 400 ms à 200 ms représentent le changement d'infrastructure le plus significatif de Solana depuis que Firedancer a atteint le réseau principal.

La feuille de route infrastructurelle de Solana en 2026 est une séquence de paris empilés les uns sur les autres. Firedancer a atteint le réseau principal en décembre 2025 et porte maintenant environ 14 % du stake du réseau principal sur plus de 20 % des validateurs actifs. Agave 4.2 change l'économie et les caractéristiques de performance du réseau que ces validateurs exécutent. Alpenglow, qui sera livré dans la prochaine version, remplace entièrement le mécanisme de consensus. Chaque couche dépend de la précédente, et chacune change ce que les développeurs peuvent construire sur Solana.

Cet article décompose les trois mises à niveau d'Agave 4.2, mesure ce que chacune change en pratique, et examine comment elles positionnent Solana par rapport à la feuille de route Hegota d'Ethereum et à la concurrence plus large pour l'attention des développeurs et des utilisateurs.

La réduction du loyer : ce que les comptes à 0,016 $ signifient pour les développeurs

Le loyer sur Solana est le solde minimum qu'un utilisateur doit déposer pour garder un compte ouvert. Le dépôt augmente avec la quantité de données stockées. Au taux précédent, un compte de jeton SPL standard nécessitait environ 0,16 $ en SOL comme dépôt exempt de loyer. Ce montant n'est pas un frais. Il est verrouillé dans le compte tant que le compte existe et est retourné lorsque le compte est fermé.

SIMD-0437 réduit la constante de lamports par octet d'un facteur 10, de 6 960 à 696. Le dépôt exempt de loyer pour le même compte de jeton tombe à environ 0,016 $. Pour un seul compte, la différence est triviale. Pour les applications qui créent des milliers ou des millions de comptes, la différence est structurelle.

Un échange décentralisé qui maintient un carnet d'ordres sur la chaîne crée des comptes pour chaque ordre ouvert. Un protocole de jeu qui suit l'état des joueurs crée des comptes pour chaque joueur actif. Une plateforme de tokenisation qui émet des actions fractionnaires crée des comptes pour chaque détenteur. Dans chaque cas, le coût de démarrage de l'application augmente linéairement avec le nombre de comptes, et SIMD-0437 réduit ce coût de 90 %.

L'effet pratique est que les catégories d'applications qui étaient non économiques sur Solana au taux de loyer précédent deviennent viables au nouveau taux. Les carnets d'ordres sur la chaîne avec des niveaux de prix granulaires, les jeux entièrement sur la chaîne avec un état persistant pour des millions de joueurs, et les plateformes de tokenisation avec des dizaines de milliers de détenteurs deviennent tous significativement moins chers à exploiter.

Le contre-argument est que le stockage moins cher augmente le gonflement de l'état. Chaque compte qui existe sur Solana occupe de l'espace que les validateurs doivent stocker et traiter. Réduire le coût de création de comptes de 90 % pourrait produire une augmentation correspondante du nombre de comptes, mettant à rude épreuve les exigences matérielles des validateurs. Anza, l'équipe de développement derrière Agave, a fait valoir que la compression d'état et les fonctionnalités de gestion du cycle de vie des comptes dans les futures versions traiteront le gonflement indépendamment du taux de loyer.

Transactions plus volumineuses : des solutions de contournement à l'exécution atomique

La limite de taille de transaction de 1 232 octets a été l'un des points de friction les plus persistants pour les développeurs sur Solana. Cette contrainte provient de la limite de taille des paquets UDP du réseau, qui a été fixée au lancement et jamais mise à jour. Les développeurs travaillant avec des opérations complexes, des preuves ZK, de grandes configurations de portefeuilles multisig et des transactions DeFi à instructions multiples ont dû répartir le travail sur plusieurs transactions ou utiliser des tables de recherche d'adresses pour compresser les références.

SIMD-0296 porte la limite à 4 096 octets grâce à un nouveau format de transaction v1. Ce format remplace les instructions ComputeBudgetProgram par un masque de configuration transporté directement dans l'en-tête de la transaction, libérant ainsi de l'espace pour les données d'instructions réelles. Les transactions v1 sont identifiées par un octet de version de tête de 129 et ne prennent pas en charge les tables de recherche d'adresses, mais à 4 096 octets, la liste complète des adresses peut être incluse directement dans la plupart des cas.

L'impact est surtout ressenti par trois catégories de développeurs. La vérification de preuves ZK, qui nécessite de passer les données de preuve en entrée de transaction, peut désormais être effectuée en une seule transaction atomique au lieu d'être répartie sur plusieurs appels. Les grands portefeuilles multisig avec de nombreux signataires peuvent inclure toutes les signatures dans une seule transaction. Et les schémas de signature sur chaîne comme BLS, qui nécessitent des clés plus volumineuses, peuvent être exécutés sans solutions de contournement.

Les applications existantes n'ont pas besoin de changer. Les formats de transaction v0 et hérités continuent de fonctionner exactement comme avant. Seules les applications qui souhaitent une taille plus grande doivent adopter v1. Les indexeurs et les explorateurs de blocs qui décodent les octets bruts des transactions devront reconnaître la nouvelle disposition, mais la migration est facultative plutôt que forcée.

L'augmentation de 3,3 fois peut sembler modeste par rapport aux calldata effectivement illimités d'Ethereum. La différence est que les transactions Solana s'exécutent dans un seul slot avec un ordre déterministe, tandis que les transactions Ethereum sont en concurrence pour être incluses dans un bloc avec des coûts de gaz variables. L'approche de Solana échange la flexibilité contre la vitesse : une transaction de 4 096 octets sur Solana se confirme en moins d'une seconde, tandis qu'une transaction Ethereum comparable peut attendre des minutes selon les prix du gaz et la congestion du bloc.

La route vers des slots de 200 ms

SIMD-0525 est la plus ambitieuse des trois mises à niveau et celle qui a l'impact le plus visible sur les utilisateurs. Le temps de slot actuel de Solana est de 400 ms, ce qui signifie qu'un nouveau bloc est produit environ toutes les 0,4 secondes. SIMD-0525 vise à le réduire à 200 ms, doublant ainsi le taux de production de blocs du réseau.

La réduction n'est pas instantanée. Elle se déroule en quatre baisses successives de 50 ms : de 400 ms à 350 ms, puis 300 ms, puis 250 ms, puis 200 ms. Chaque baisse est conditionnée par une activation de fonctionnalité que les validateurs doivent adopter. Le protocole inclut une sauvegarde critique : si le taux de sauts de blocs dépasse un seuil défini à n'importe quelle étape, le réseau ne passera pas à la baisse suivante tant que la stabilité n'est pas rétablie.

Le testnet a déjà démontré des slots de 300 ms, validant les deux premières baisses. Les étapes restantes vers 250 ms et 200 ms dépendront des performances des validateurs du mainnet sous charge réelle, qui diffèrent des conditions du testnet en termes de volume de trafic, de distribution géographique et de diversité matérielle.

Pour les utilisateurs, des slots plus rapides signifient des confirmations plus rapides. Un échange sur un DEX Solana se confirme actuellement en environ 400 ms. Avec des slots de 200 ms, le même échange se confirme en moitié moins de temps. Pour les teneurs de marché, des slots plus serrés signifient des spreads plus serrés, car la fenêtre pendant laquelle un prix coté peut devenir obsolète se réduit à chaque baisse. Pour les validateurs, des slots plus rapides signifient des exigences matérielles plus élevées : le budget de calcul par slot reste le même, mais le temps disponible pour le traiter est divisé par deux.

La préoccupation matérielle des validateurs n'est pas théorique. ETHNews a rapporté que la mise à niveau Agave 4.2 « rend son utilisation moins chère, mais son exécution plus difficile ». La réduction du loyer réduit les coûts pour les développeurs. La réduction du temps de slot augmente les coûts pour les validateurs. Que le compromis soit net positif dépend de si des coûts de développement moins élevés attirent suffisamment de nouvelles activités pour justifier les coûts d'infrastructure plus élevés que les validateurs doivent absorber.

Le rôle de Firedancer dans la mise à niveau

Les exigences de performance d'Agave 4.2 seraient plus difficiles à satisfaire sans la présence de Firedancer sur le mainnet. Le client validateur en C et C++ de Jump Crypto, qui a atteint le mainnet en décembre 2025, fournit une référence de performance que le client Agave original ne pouvait pas garantir à lui seul.

Les données des opérateurs de la période de déploiement 2025 à 2026 montrent que les validateurs Firedancer ont obtenu une amélioration de 18 à 28 points de base dans la réduction du taux de saut, 15 % de crédits de vote manqués en moins, une latence de vote d'environ 1,002 slots, et des blocs plus pleins avec une moyenne de 47 millions contre 44,8 millions d'unités de calcul sous Agave. Ces marges comptent lorsque les temps de slot sont réduits de moitié, car la tolérance aux retards de traitement diminue à chaque décrément.

Firedancer détient maintenant environ 14 % du stake du mainnet sur plus de 20 % des validateurs actifs. La diversité des clients est également une caractéristique de résilience : un bug qui fait planter Agave n'affectera pas nécessairement Firedancer, et vice versa. Pour un réseau qui se prépare à réduire de moitié son temps de slot puis à remplacer entièrement son mécanisme de consensus, avoir deux clients indépendants n'est pas un luxe mais une exigence de sécurité.

Alpenglow : la réécriture du consensus attendue dans la prochaine version

Agave 4.2 inclut l'intégralité du codebase d'Alpenglow mais ne l'active pas sur le mainnet. Cette activation est réservée à Agave 4.3, prévue pour octobre 2026. Lorsqu'il sera déployé, Alpenglow remplacera à la fois Proof of History et TowerBFT, les deux systèmes que Solana utilise depuis son lancement en 2020.

Le remplaçant est Votor, un algorithme de vote qui vise une finalité d'environ 150 ms contre 12,8 secondes actuellement pour TowerBFT. Votor élimine entièrement les transactions de vote sur la chaîne. Sous TowerBFT, les validateurs soumettent des votes comme des transactions régulières qui consomment de l'espace de bloc et des unités de calcul. Sous Votor, les validateurs échangent directement les votes via un canal séparé, libérant ainsi la capacité des blocs pour les transactions des utilisateurs.

Le modèle de sécurité tolère que 20 % du stake soit hors ligne et 20 % du stake soit adversarial simultanément. Anza a publié un programme de bug bounty de 50 000 SOL pour Alpenglow, avec des soumissions ouvertes à partir du 5 août, indiquant une confiance dans le codebase tout en reconnaissant qu'un remplacement de consensus de cette ampleur nécessite une revue de sécurité externe.

La séquence est importante. Agave 4.2 réduit le loyer, augmente la taille des transactions et commence à réduire les temps de slot. Agave 4.3 remplace le mécanisme de consensus. Chaque mise à niveau est conçue pour être utile indépendamment, mais la vision complète, des slots de 200 ms avec une finalité de 150 ms sur un protocole de consensus qui ne consomme pas d'espace de bloc pour le vote, nécessite que toutes soient déployées avec succès.

Comparaison avec la feuille de route Hegota d'Ethereum

Solana et Ethereum poursuivent des chemins différents vers la même destination : des coûts plus bas, un débit plus élevé et une finalité plus rapide. Le contraste entre Agave 4.2 et le plan de mise à niveau Hegota d'Ethereum illustre les différences architecturales.

Le calendrier Hegota d'Ethereum prévoit une date limite de préférence en septembre, la mise à niveau elle-même étant ciblée pour 2027. Le périmètre est encore en cours de définition : 66 propositions ont été soumises, et la communauté doit en éliminer la plupart avant de finaliser la mise à niveau. Les candidats clés incluent EIP-8182 pour la confidentialité native, FOCIL pour la résistance à la censure, et l'augmentation du débit des blobs pour l'évolutivité des rollups. Le devnet Glamsterdam a glissé, repoussant encore le calendrier.

L'approche de Solana est plus rapide et plus centralisée dans sa prise de décision. Anza définit le calendrier d'activation des fonctionnalités, les validateurs l'adoptent, et la mise à niveau se poursuit. Il n'existe pas d'équivalent du processus EIP pluriannuel d'Ethereum avec une gouvernance communautaire sur les propositions retenues. Le compromis est que Solana peut livrer trois mises à niveau majeures en une seule version tandis qu'Ethereum prend 12 à 18 mois pour finaliser une portée comparable de changements.

L'écart de performance après Agave 4.2 est frappant. Solana avec des slots de 200 ms et une finalité Alpenglow de 150 ms confirmerait les transactions en moins de 400 ms. La finalité actuelle d'Ethereum est d'environ 13 minutes, et les améliorations de Hegota, si elles sont livrées, visent une finalité en un seul slot qui se mesurerait encore en secondes plutôt qu'en millisecondes.

L'écart de coût se creuse également. La réduction des frais de location de Solana rend le stockage en chaîne d'un ordre de grandeur moins cher. Le L1 d'Ethereum reste cher pour le stockage, les rollups absorbant la plupart des réductions de coûts via les données blob. Pour les développeurs qui choisissent où construire de nouvelles applications, l'économie de l'infrastructure favorise de plus en plus Solana pour les cas d'utilisation nécessitant un débit élevé, un faible coût et une finalité rapide.

Le contre-argument est que le processus plus lent d'Ethereum produit des mises à niveau plus robustes et éprouvées au combat, avec un consensus communautaire plus large. L'avantage de vitesse de Solana se fait au prix d'une pression de centralisation des validateurs et d'une marge de sécurité plus mince lors des transitions majeures de l'infrastructure. Le marché jugera en fin de compte les deux approches par l'adoption des développeurs et l'activité des utilisateurs, plutôt que par les seules spécifications techniques.

Le signal de migration des développeurs

Les mises à niveau de l'infrastructure ne comptent que si les développeurs répondent en construisant des applications qui les utilisent. L'indicateur avancé n'est pas le prix de SOL ou la TVL, mais le taux de nouveaux déploiements de programmes et le volume d'adoption des transactions v1 dans les semaines suivant l'activation.

L'écosystème de développeurs de Solana a connu une croissance régulière tout au long de 2026, la Fondation Solana signalant plus de 2 500 développeurs mensuels actifs dans son rapport d'écosystème le plus récent. La réduction des frais de location devrait accélérer le développement de jeux en chaîne, de protocoles sociaux décentralisés et de plateformes de tokenisation qui étaient auparavant contraints par les coûts de création de comptes.

La dynamique concurrentielle est également pertinente. Les développeurs qui attendaient une infrastructure Solana moins chère l'ont maintenant. Les développeurs qui envisageaient les rollups Ethereum pour des raisons de coût doivent peser la complexité supplémentaire du pontage L2 et de la liquidité fragmentée par rapport à l'expérience L1 intégrée de Solana à des coûts similaires ou inférieurs.

Le cas opposé : pourquoi ces mises à niveau comportent des risques

Le scénario haussier pour Agave 4.2 est qu'il rend Solana moins cher, plus rapide et plus performant. Le scénario baissier est qu'il rend Solana plus difficile à exécuter, augmentant la pression de centralisation sur les validateurs tout en introduisant trois changements simultanés sur un réseau qui traite des milliards de dollars de volume quotidien.

La réduction des frais de location crée un risque de croissance de l'état. Si le nombre de comptes sur Solana augmente proportionnellement à la réduction des coûts, les validateurs devront stocker et traiter 10 fois plus de données d'état. La Fondation Solana n'a pas publié de projection de croissance de l'état pour l'environnement post SIMD-0437.

La réduction du temps de slot augmente les exigences matérielles à un moment où les coûts des validateurs Solana sont déjà plus élevés que ceux de la plupart des réseaux concurrents. Un validateur exécutant Solana nécessite du matériel haut de gamme avec un stockage NVMe rapide, une bande passante réseau élevée et une RAM substantielle. Réduire de moitié le temps de slot ne double pas le coût matériel, mais cela réduit la marge d'erreur et peut pousser les petits validateurs en dessous du seuil de performance nécessaire pour éviter les pénalités de saut.

L'augmentation de la taille des transactions introduit un nouveau format que les indexeurs, les portefeuilles et les SDK doivent prendre en charge. Bien que la migration soit facultative, la fragmentation de l'écosystème entre les formats de transactions v0, hérités et v1 crée une complexité supplémentaire pour les développeurs et les fournisseurs d'infrastructure.

Le calendrier introduit également un risque d'exécution. Activer trois fonctionnalités majeures simultanément sur un réseau qui traite des milliards de dollars quotidiennement signifie que tout effet d'interaction entre les mises à niveau, un scénario que le testnet peut ne pas reproduire entièrement, pourrait apparaître sous charge de production. La réduction progressive du temps de slot atténue le risque le plus important, mais la réduction des frais de location et l'augmentation de la taille des transactions s'activent sans garanties équivalentes.

Il existe également un risque concurrentiel moins discuté. Si Agave 4.2 réussit, cela valide la thèse selon laquelle une seule équipe peut livrer des changements majeurs d'infrastructure plus rapidement que le processus de gouvernance décentralisée d'Ethereum. Cette thèse attire les développeurs à court terme. À long terme, elle crée une dépendance à la compétence continue d'Anza et à son alignement avec l'écosystème. Le processus plus lent d'Ethereum répartit ce risque sur un ensemble plus large de contributeurs. Que la vitesse ou la résilience importe le plus dépend de l'horizon temporel.

Ce qui prouverait que le scénario baissier est erroné : l'activation réussie des trois fonctionnalités sans augmentation des taux de saut, aucun départ de validateurs, et une croissance mesurable de l'activité des développeurs et des comptes sur la chaîne dans les 90 jours. La fenêtre de 90 jours est importante car les changements d'infrastructure montrent souvent leurs effets progressivement plutôt qu'immédiatement.

Quoi regarder

• Taux de saut après chaque décrémentation de temps de slot. La sauvegarde dans SIMD-0525 arrête la progression si les taux de saut dépassent le seuil. Que le réseau traverse les quatre décrémentations ou s'arrête à une étape intermédiaire signalera les limites réelles de l'infrastructure de validateurs de Solana.
• Taux de création de comptes après la réduction du loyer. Une forte augmentation de nouveaux comptes valide la thèse selon laquelle le loyer était un obstacle significatif au développement. Une création de comptes stable suggérerait que la contrainte se situait ailleurs.
• Adoption des transactions v1. La rapidité avec laquelle les fournisseurs de portefeuilles, les DEX et les protocoles DeFi adoptent le format de transaction plus grand déterminera si l'augmentation de taille se traduit par de nouvelles capacités ou reste inutilisée.
• Résultats du programme de bug bounty Alpenglow. Le programme de 50 000 SOL se terminant avant la sortie d'Agave 4.3 produira des résultats de sécurité publics qui indiqueront si le changement de consensus d'octobre se déroule comme prévu.
• Trajectoire de la part de stake de Firedancer. La diversité des clients est un prérequis pour le profil de risque de ces mises à niveau. Que la part de stake de Firedancer, actuellement de 14 %, croisse vers 33 %, le seuil largement considéré comme nécessaire pour une résilience significative, importe pour la sécurité du réseau pendant la transition.

Questions fréquemment posées