Solana a fixé au 9 septembre l’activation de Transaction V1, une mise à niveau qui augmentera fortement la taille maximale des transactions et ouvrira la voie à des opérations plus complexes. Jacob Creech, vice-président de la technologie de la Solana Foundation, a détaillé le 30 août plusieurs changements prévus pour les prochaines semaines, notamment une première réduction du rent, de nouvelles diminutions de la durée des slots et la poursuite du développement d’Alpenglow. Ces évolutions s’inscrivent dans une feuille de route plus large visant à améliorer la capacité, la rapidité et l’efficacité du réseau, mais elles ne seront pas déployées simultanément. Transaction V1, les réductions de rent, les slots plus rapides et Alpenglow disposent chacun de leur propre processus d’activation.
La date du 9 septembre concerne donc spécifiquement Transaction V1. Contrairement à certaines interprétations possibles, cette activation n’entraînera pas automatiquement une réduction supplémentaire de la durée des slots et ne déclenchera pas non plus Alpenglow. Cette distinction est importante, car Solana cherche à faire évoluer plusieurs éléments de son infrastructure tout en conservant un déploiement progressif qui permet aux validateurs et développeurs d’évaluer chaque changement séparément.
Transaction V1 porte la taille maximale à 4 096 octets
Le changement le plus direct de Transaction V1 concerne la quantité de données pouvant être intégrée dans une transaction. La limite actuelle de 1 232 octets passera à 4 096 octets, soit une augmentation d’environ 3,3 fois. Cette évolution doit permettre au réseau de prendre en charge des opérations plus lourdes sans dépendre des mêmes contraintes techniques que les formats actuels.
Selon la feuille de route officielle, le format plus large pourrait être particulièrement utile pour les transactions contenant des preuves zero-knowledge, des instructions multisignatures complexes ou d’autres opérations nécessitant davantage de données. La proposition SIMD-0296 mentionne également les signatures BLS et certaines opérations cross-chain parmi les usages potentiels. Pour les applications plus sophistiquées, la possibilité d’intégrer davantage d’informations dans une transaction unique pourrait simplifier certaines architectures et réduire la nécessité de répartir une opération sur plusieurs transactions distinctes.
L’augmentation de capacité ne signifie toutefois pas que tous les utilisateurs devront immédiatement adopter le nouveau format. Les développeurs devront choisir volontairement Transaction V1. Les transactions legacy et version-zero resteront compatibles, ce qui permet aux applications existantes de continuer à fonctionner sans migration forcée.
Le nouveau format apporte davantage de capacité mais aussi des contraintes techniques
Transaction V1 ne prendra pas en charge les address lookup tables. Les applications devront donc déterminer quel format correspond le mieux à chaque cas d’utilisation. Dans certaines situations, la taille supplémentaire offerte par V1 sera plus importante. Dans d’autres, les avantages des formats existants resteront plus adaptés.
Cette flexibilité réduit le risque d’imposer un modèle unique à l’ensemble de l’écosystème, mais elle ajoute aussi une nouvelle décision technique pour les développeurs. Wallets, API et autres infrastructures devront également être capables de traiter des payloads plus importants. À mesure que les transactions deviennent plus volumineuses, la pression sur la bande passante et sur la propagation des données à travers le réseau peut augmenter.
La proposition reconnaît explicitement des risques liés à la bande passante et à la fragmentation du réseau. Cela explique pourquoi la coordination des tests reste importante avant une adoption plus large. Solana cherche donc à gagner en capacité sans traiter l’augmentation de taille comme un simple changement sans conséquence pour l’infrastructure.
La réduction du rent commencera dès la semaine du 31 août
En parallèle de Transaction V1, Solana prévoit de lancer la première étape d’une réduction progressive du rent. Le changement ne permettra pas immédiatement d’atteindre l’objectif final de 90 %. Le réseau prévoit cinq étapes qui doivent à terme faire passer le calcul du rent de 6 960 lamports par octet à 696 lamports par octet.
Le mécanisme de rent de Solana fonctionne principalement comme un système destiné à limiter une croissance incontrôlée de l’état du réseau. Lorsqu’une application crée des comptes qui stockent des données onchain, elle doit immobiliser une certaine quantité de SOL afin que ces comptes deviennent rent-exempt. Cette somme est généralement récupérable lorsque le compte est fermé, ce qui signifie que le mécanisme ressemble davantage à un dépôt de capital qu’à une taxe périodique classique.
Une baisse des exigences réduirait donc la quantité de SOL que les développeurs doivent immobiliser lors de la création de comptes de tokens, de programmes ou d’autres formes d’état onchain. L’impact pourrait être particulièrement visible pour les applications qui gèrent un grand nombre de comptes utilisateurs, car l’accumulation de ces dépôts peut représenter un coût d’entrée significatif.
Une réduction de 90 % pourrait améliorer l’efficacité du capital des applications
L’objectif final de 696 lamports par octet représenterait une diminution très importante du capital immobilisé. Cela ne signifie pas nécessairement une baisse directe des frais de transaction pour tous les utilisateurs, car le rent et les frais courants répondent à des logiques différentes. En revanche, les projets qui créent et maintiennent beaucoup de comptes pourraient avoir besoin de bloquer moins de SOL pour fonctionner.
Cette évolution peut améliorer l’efficacité du capital des applications et réduire certaines barrières opérationnelles. Elle pourrait également rendre plus simple le lancement de produits nécessitant une grande quantité d’état onchain. Le changement doit toutefois rester compatible avec l’objectif original du rent, qui consiste à éviter que le réseau accumule trop facilement des données permanentes sans coût économique.
Le code nécessaire à cette réduction est déjà présent dans Agave 4.2, mais Solana l’a placé derrière des feature gates indépendants. Cela permet aux validateurs d’activer les changements liés au rent séparément de Transaction V1 ou des modifications de durée des slots.
Les slots sont déjà passés de 400 à 350 millisecondes
La feuille de route de performance avance aussi sur la vitesse de production des blocs. Solana a déjà réduit sa durée cible de slot de 400 à 350 millisecondes. D’autres étapes sont prévues à 300, 250 puis 200 millisecondes, mais Creech n’a pas communiqué de dates pour ces prochains seuils.
Chaque réduction doit être activée séparément. Cette approche permet aux développeurs du réseau d’observer la performance des validateurs après chaque modification avant de poursuivre. Des slots plus courts peuvent augmenter la fréquence de production des blocs et réduire le temps nécessaire pour voir une transaction progresser dans le réseau.
Mais cette vitesse supplémentaire impose aussi des contraintes plus élevées. Les validateurs disposent de moins de temps pour produire et propager les blocs, ce qui renforce les exigences en matière de réseau, de timing et de ressources. Solana prévoit d’ajuster les limites de ressources de manière proportionnelle au cours du déploiement.
Alpenglow reste ciblé pour octobre, sans date garantie
Le changement le plus ambitieux reste Alpenglow, la refonte proposée du consensus de Solana. Le réseau vise une finalité d’environ 150 millisecondes après une éventuelle activation sur le mainnet, contre un processus de confirmation actuellement plus long.
La feuille de route officielle classe toujours Alpenglow comme étant « en développement ». Agave 4.3 est attendu en octobre, et les déclarations de Creech confirment octobre comme objectif actuel. Cependant, ni la feuille de route ni son message ne garantissent une activation mainnet à une date précise.
Avant cela, Solana doit commencer la première étape de réduction du rent, activer Transaction V1 le 9 septembre et poursuivre les tests liés aux prochaines réductions de slots. Alpenglow devra lui aussi terminer ses phases de test et obtenir le niveau de soutien nécessaire auprès du réseau.
La stratégie repose sur des améliorations séparées plutôt qu’un seul grand upgrade
L’un des éléments les plus importants de cette feuille de route est la manière dont les changements sont déployés. Solana ne prévoit pas une mise à niveau unique qui modifie simultanément tous les composants critiques. Les différentes améliorations sont séparées derrière leurs propres mécanismes d’activation.
Cette structure donne davantage de contrôle au réseau. Si une modification rencontre un problème, elle peut être retardée sans empêcher les autres d’avancer. Cela permet aussi d’identifier plus clairement l’impact de chaque amélioration sur les validateurs, les applications et les performances générales.
Transaction V1 augmente la capacité des transactions. La réduction du rent améliore l’efficacité du capital. Les slots plus courts cherchent à accélérer la production des blocs. Alpenglow vise une refonte plus profonde de la finalité. Ces objectifs sont complémentaires, mais techniquement distincts.
Conclusion
Solana entrera dans une nouvelle phase de sa feuille de route avec l’activation prévue de Transaction V1 le 9 septembre. Le format augmentera la taille maximale des transactions de 1 232 à 4 096 octets tout en laissant les développeurs choisir s’ils souhaitent l’utiliser. En parallèle, le réseau doit commencer une réduction progressive du rent pouvant atteindre 90 %, poursuivre la diminution de la durée des slots et continuer les travaux sur Alpenglow.
Aucun mouvement vérifié du prix de SOL n’avait été directement attribué à ces annonces au moment de leur publication. Pour l’instant, leur importance est donc principalement technique.
Point clé final
Le calendrier de Solana ne repose pas sur un seul événement, mais sur une succession de changements indépendants. Transaction V1 constitue la prochaine date clairement annoncée, tandis que le rent, les slots et Alpenglow avanceront selon leurs propres tests et activations. Le véritable enjeu sera de savoir si Solana peut obtenir davantage de capacité, réduire le capital immobilisé et accélérer la finalité sans créer de nouvelles contraintes qui compromettent la stabilité du réseau.
