Solana Active Transaction V1 Dès Le 9 Septembre

Et si la prochaine étape de Solana ne tenait pas à un seul « grand soir » technologique, mais à une série de leviers actionnés à quelques jours d’intervalle ? Le 30 août 2026, Jacob Creech, vice-président technologie de la Solana Foundation, a précisé un calendrier que beaucoup d’équipes attendaient sans oser le dater trop fort. Transaction V1 est prévue pour le 9 septembre. La première étape d’une baisse de loyer réseau doit commencer dès la semaine du 31 août. Les créneaux plus courts et Alpenglow restent, eux, sur des rails distincts. L’annonce paraît technique. Elle touche pourtant le coût de création d’un compte, la taille d’une instruction, la vitesse de confirmation et, in fine, la manière dont une application peut grandir sans se heurter au plafond actuel.

Ce Que Change Vraiment Le Calendrier De Septembre

Le message de Creech a le mérite d’être clair : plusieurs chantiers majeurs avancent en même temps, mais ils ne s’activent pas d’un seul geste. La première descente de loyer arrive « la semaine prochaine » par rapport à la prise de parole du 29-30 août. Transaction V1 suit le 9 septembre. Les temps de slot doivent encore diminuer. Alpenglow reste visé pour octobre. Puis la communauté se retrouvera à Scale or Die en novembre. Cette séquence n’est pas un slogan marketing. Elle décrit une méthode : chaque fonctionnalité passe par une porte indépendante, testée, puis ouverte par les validateurs.

Cette méthode évite un basculement unique trop risqué. Elle impose aussi de la pédagogie. Beaucoup de lecteurs ont déjà vu des titres qui amalgamaient le 9 septembre, les slots plus rapides et Alpenglow. Or Creech n’a pas dit que tout basculerait le même jour. Transaction V1 n’accélère pas automatiquement le réseau. Elle n’active pas non plus le nouveau consensus. Comprendre cette distinction, c’est déjà éviter une mauvaise surprise opérationnelle.

Pourquoi Cette Séquence Arrive Maintenant

Solana a déjà réduit sa cible de slot à 350 millisecondes, contre 400 millisecondes auparavant. Le code nécessaire à d’autres évolutions circule dans Agave 4.2, mais une partie reste derrière des feature gates. Autrement dit, le logiciel peut être déployé sans que la fonction soit allumée. Les validateurs décident ensuite, après tests, d’ouvrir la porte. Cette architecture explique le calendrier étalé : on n’attend plus « une seule mise à jour miracle », on orchestre des activations séparées.

Le contexte produit est aussi plus mature. Les applications veulent des transactions plus denses : preuves à connaissance nulle, instructions multi-signatures complexes, opérations inter-chaînes. Le plafond historique de 1 232 octets devient un corset. En parallèle, le loyer — en réalité un dépôt récupérable — pèse sur les projets qui multiplient les comptes utilisateurs. Réduire ce dépôt par étapes, plutôt qu’en une seule coupe de 90 %, limite le choc sur l’économie interne du réseau et sur le comportement des opérateurs.

Transaction V1 : 4 096 Octets Et Un Choix D’Opt-In

Le cœur de l’annonce de septembre, c’est un chiffre simple à retenir et difficile à sous-estimer. Transaction V1 porte la taille maximale d’une transaction sérialisée de 1 232 octets à 4 096 octets. L’augmentation est d’environ 3,3 fois la limite actuelle, selon la feuille de route officielle. Ce n’est pas un détail cosmétique. C’est un nouveau volume utile pour ce que l’on peut glisser dans une seule unité de travail réseau.

Jusqu’ici, certaines opérations « lourdes » devaient être découpées, reportées, ou tout simplement abandonnées on-chain. Une preuve volumineuse, un schéma de signatures plus riche, un paquet d’instructions trop dense : le plafond coupait court. Le format V1 rouvre ces pistes. La proposition associée, SIMD-0296, cite notamment les signatures BLS et les opérations inter-chaînes parmi les usages possibles. Elle évoque aussi les preuves à connaissance nulle. Autant de familles d’outils qui aiment les octets.

There are a lot of major changes happening soon– Next week: First step down in rent reduction– Sept 9: Transaction V1 goes live– Dropping slot time even further– October: Alpenglow Then we all meetup at Scale or Die in November Solana development will never be the same

Jacob Creech, 29 août 2026

Le point le plus important pour les équipes produit n’est pas seulement la taille. C’est le caractère optionnel du nouveau format. Les développeurs doivent choisir V1. Les transactions héritées et les transactions version zéro restent valides. Il n’y a pas d’obligation de tout migrer le 9 septembre au matin. Cette compatibilité est précieuse. Elle évite de casser d’un coup les portefeuilles, les routeurs et les programmes qui n’ont pas encore besoin de 4 096 octets.

En contrepartie, V1 ne prendra pas en charge les tables de recherche d’adresses. Une application devra donc arbitrer : rester sur un format qui connaît ces tables, ou passer à un format plus spacieux sans ce mécanisme. Ce n’est pas un détail de bas niveau réservé aux experts du runtime. C’est une décision d’architecture. Selon le type d’instruction, selon le nombre de comptes touchés, selon la stratégie de compression des adresses, le bon format ne sera pas le même.

Ce Que Les Preuves Et Les Signatures Gagnent En Espace

Une preuve à connaissance nulle n’est pas un simple booléen. Elle transporte un objet cryptographique. Plus la preuve est expressive, plus elle occupe de place. Dans un monde où la transaction doit tenir dans 1 232 octets, une partie du travail bascule hors chaîne, ou se fragmente en plusieurs allers-retours. Avec 4 096 octets, certaines preuves peuvent voyager plus intactes. Cela ne rend pas la vérification gratuite. Cela rend le transport moins acrobatique.

Les signatures BLS suivent une logique voisine. Elles intéressent les schémas où l’on agrège, où l’on compacte, où l’on veut prouver un quorum sans aligner une file interminable de signatures individuelles. Encore faut-il que le contenant tienne. V1 agrandit le contenant. Il ne remplace pas le travail de conception cryptographique. Il retire une contrainte de tuyauterie qui, trop souvent, décidait à la place des concepteurs.

Les opérations inter-chaînes aiment aussi les métadonnées. Un message relais, un état attesté, une preuve d’inclusion : tout cela pèse. Quand le réseau d’origine et le réseau d’arrivée ne parlent pas le même langage, on compense par des données. Un plafond trop bas force à simplifier le pont, parfois jusqu’à le rendre moins sûr ou moins général. Un plafond plus haut n’élimine pas le risque de pont. Il élargit la palette de ce qu’un protocole peut tenter sans bricolage excessif.

Infrastructures, Portefeuilles Et Charge Utile Plus Lourde

Une transaction plus grande n’existe vraiment que si toute la chaîne d’outils la transporte. Portefeuilles, interfaces de programmation, indexeurs, relais, simulateurs, explorateurs : chacun doit accepter une charge utile plus volumineuse. Le 9 septembre n’est donc pas seulement une date de protocole. C’est une date de coordination industrielle. Si un maillon refuse le nouveau format, l’utilisateur verra une erreur là où le validateur, lui, serait prêt.

La proposition le reconnaît : il existe des risques de bande passante et de fragmentation réseau. Tous les opérateurs n’ont pas la même capacité. Tous les liens n’ont pas la même qualité. Si une minorité d’acteurs se met à envoyer des transactions très lourdes pendant que d’autres restent sur l’ancien format, le trafic n’est plus homogène. D’où l’insistance sur des tests coordonnés avant une adoption large. Activer V1 ne signifie pas inonder le réseau de paquets de 4 096 octets dès la première heure.

Les équipes prudentes feront probablement l’inverse. Elles activeront le format sur un sous-ensemble d’opérations, mesureront la latence, observeront les échecs de propagation, puis élargiront. C’est moins spectaculaire qu’un « tout le monde passe à V1 ». C’est plus fidèle à la réalité d’un réseau public où la diversité des nœuds n’est pas un slogan, mais une contrainte physique.

Le Loyer Solana N’Est Pas Un Loyer Comme Les Autres

Le mot rent prête à confusion. Sur Solana, le mécanisme vise surtout à freiner la croissance incontrôlée de l’état. Quand une application crée un compte qui stocke des données, elle verrouille du SOL. Ce SOL est en général récupérable à la fermeture du compte. On est plus proche d’un dépôt remboursable que d’une facture mensuelle invisible. Pourtant, pour un projet qui ouvre des milliers de comptes token ou de comptes programme, le dépôt initial reste un vrai coût d’entrée.

Aujourd’hui, le calcul de référence s’établit à 6 960 lamports par octet. L’objectif à terme est de descendre à 696 lamports par octet, soit une réduction d’environ 90 %. Mais cette cible ne bascule pas d’un seul coup. Cinq étapes sont prévues. La première arrive dès la semaine commençant le 31 août 2026. Elle n’apporte donc pas l’économie maximale. Elle ouvre le chemin. Les suivantes suivront selon le rythme d’activation et la capacité du réseau à digérer un état potentiellement plus facile à créer.

Agave 4.2 embarque déjà le code utile à cette baisse. Comme pour V1, le basculement dépend de portes de fonctionnalités indépendantes. Les validateurs peuvent donc allumer le loyer, la taille de transaction et le temps de slot séparément, après avoir vérifié que leur machine, leur lien et leur configuration tiennent la charge. Cette séparation est une forme d’hygiène. Elle empêche qu’un incident sur un levier n’oblige à reculer sur les trois.

Qui Gagne À La Première Baisse De Dépôt

Les premiers bénéficiaires ne sont pas forcément les protocoles les plus médiatiques. Ce sont souvent les applications qui gèrent beaucoup de petits états : comptes token individuels, profils utilisateurs, positions, coffres, identifiants on-chain. Chaque compte supplémentaire impose aujourd’hui de immobiliser du SOL. Moins le dépôt est élevé, plus le coût d’acquisition d’un utilisateur technique diminue. Cela peut changer le calcul d’un lancement, d’une campagne de mint, ou d’un outil grand public qui refuse de faire payer d’avance un « droit d’exister » on-chain.

Il faut toutefois raison garder. Une baisse de loyer rend la création d’état moins chère. Elle n’efface pas le besoin de gouverner cet état. Si tout le monde crée davantage de comptes parce que c’est moins coûteux, l’état global grossit. Le mécanisme de dépôt existe précisément pour éviter que le registre ne devienne une décharge. D’où le choix d’un escalier à cinq marches plutôt qu’une bascule brutale à 90 %. Le réseau teste sa propre capacité à rester habitable.

Pour un développeur, la question concrète devient : faut-il attendre la cinquième étape pour lancer un flux gourmand en comptes, ou commencer dès la première ? La réponse dépend du modèle. Un produit qui crée peu de comptes peut ignorer le sujet. Un produit qui en crée des dizaines de milliers a intérêt à suivre chaque palier, à recalculer ses trésoreries de dépôt, et à expliquer à ses utilisateurs pourquoi une partie du SOL reste verrouillée jusqu’à la fermeture du compte.

Des Slots Plus Courts, Mais Pas Le 9 Septembre

Le temps de slot est l’un des rythmes profonds de Solana. Plus le slot est court, plus les validateurs produisent des blocs souvent, plus la confirmation perçue peut s’accélérer. Le réseau a déjà quitté la cible de 400 millisecondes pour viser 350. La suite dessine trois autres paliers : 300, 250, puis 200 millisecondes. Creech n’a pas daté ces paliers restants. Chaque réduction exigera une activation séparée. Les équipes réseau pourront observer les performances des validateurs avant de descendre d’un cran.

Accélérer le métronome n’est pas gratuit. Un slot plus court augmente les exigences de timing et de réseau. Un validateur trop lent, mal placé, ou mal connecté rate davantage. Solana prévoit d’ajuster les limites de ressources de façon proportionnelle pendant le déploiement. C’est une manière de dire que l’on ne se contente pas de presser le chronomètre : on recalibre aussi ce que chaque bloc a le droit de contenir, pour que la cadence nouvelle ne devienne pas un piège.

C’est ici que la pédagogie publique compte. Relier le 9 septembre à la fois à V1 et à la baisse des slots reviendrait à surinterpréter l’annonce. Les deux sujets appartiennent à la même feuille de route de performance. Ils restent techniquement distincts. Une application peut bénéficier de transactions plus grandes sans voir encore le slot tomber à 200 millisecondes. Un validateur peut affronter un slot plus court sans que ses clients n’utilisent V1. Mélanger les deux dates, c’est fabriquer une attente que le protocole n’a pas promise.

Alpenglow, Objectif Octobre Et Finalité Plus Serrée

Alpenglow désigne le projet de refonte du consensus. L’ambition affichée est de ramener la finalité des transactions autour de 150 millisecondes, contre un processus de confirmation plus long dans le système actuel. Sur le papier, c’est le geste le plus spectaculaire du semestre. Dans les faits, la feuille de route officielle le range encore « en développement ». Agave 4.3 est attendu en octobre. Le message de Creech conforte octobre comme cible, sans transformer cette cible en date garantie d’activation mainnet.

La nuance vaut d’être répétée. Une cible de feuille de route n’est pas un créneau d’échange. Avant d’allumer Alpenglow en production, le réseau doit terminer les tests et rassembler le soutien nécessaire. Entre-temps, la première baisse de loyer et Transaction V1 peuvent déjà modifier le quotidien des équipes. Les réductions de slot suivantes dépendront d’activations distinctes. Empiler ces chantiers dans une seule phrase donne l’impression d’une révolution simultanée. Les calendriers disent autre chose : une succession d’examens.

Pour l’utilisateur final, la finalité à 150 millisecondes, si elle se concrétise, changerait surtout le ressenti. Un échange, un mint, une interaction de jeu ou un règlement de marché perpétuel gagne en naturel quand l’attente disparaît presque. Pour le validateur, le sujet est plus rude : nouveau protocole, nouvelles hypothèses, nouvelle surface d’erreur. C’est précisément pourquoi octobre reste un horizon, pas un tampon « livré ».

Compatibilité : L’Ancien Monde Ne Disparaît Pas

L’un des choix les plus sages de V1 est de ne pas jeter l’existant. Les formats hérités et version zéro continuent de fonctionner. Les applications choisissent quand elles ont réellement besoin de l’espace supplémentaire. Cette coexistence limite le risque d’une journée « tout est cassé ». Elle crée aussi une période hybride, où deux philosophies de transaction circulent. Les outils d’analyse devront afficher clairement le format utilisé. Les tableaux de bord devront distinguer les files. Les documentations devront cesser de parler « de la transaction Solana » au singulier.

L’absence de tables de recherche d’adresses dans V1 force un arbitrage honnête. Ces tables existent pour alléger certaines transactions en évitant de répéter de longues adresses. V1 offre plus d’espace brut, mais retire cet outil. Selon les cas, l’espace supplémentaire compensera largement. Selon d’autres, l’ancienne recette restera plus élégante. Il n’y a pas de vainqueur universel. Il y a des profils d’instructions. Les équipes sérieuses dresseront une matrice : type d’opération, nombre de comptes, besoin de preuve, besoin de table, puis elles choisiront le format case par case.

Cette matrice prendra du temps. C’est normal. Un réseau public n’adopte pas un nouveau contenant comme on change de police de caractères. Il l’adopte comme on change de gabarit de camion : il faut vérifier les ponts, les quais, les entrepôts. Les semaines qui suivent le 9 septembre diront si l’opt-in reste anecdotique ou s’il devient le chemin par défaut des applications les plus ambitieuses.

Ce Que Les Équipes Produit Devraient Faire Cette Semaine

La première tâche n’est pas d’écrire un fil d’annonce. C’est d’inventorier. Quelles transactions approchent déjà le plafond de 1 232 octets ? Quelles créations de comptes pèsent sur la trésorerie de dépôt ? Quels fournisseurs d’infrastructure ont confirmé le support de charges plus lourdes ? Quels simulateurs comprennent V1 ? Sans cet inventaire, on parle d’une mise à jour générale alors que l’on a surtout un problème local, ou l’inverse.

La deuxième tâche consiste à séparer les risques. Un échec d’encodage V1 n’est pas un échec de loyer. Un slot plus exigeant n’est pas une preuve mal formée. En isolant les surfaces, on prépare des plans de repli lisibles. On peut reporter une fonction gourmande en octets sans geler tout le produit. On peut attendre un palier de loyer sans bloquer une campagne. On peut observer un validateur sous 300 millisecondes sans conclure que « Solana est instable ».

La troisième tâche est pédagogique, en direction des utilisateurs. Beaucoup entendront « transactions plus grandes » et comprendront « frais plus bas » ou « réseau plus rapide ». Or V1 ne promet ni l’un ni l’autre à elle seule. La baisse de loyer réduit un dépôt, pas nécessairement chaque commission de calcul. Les slots plus courts et Alpenglow relèvent d’autres activations. Expliquer cela maintenant évite la déception de septembre, qui est souvent plus coûteuse qu’un retard technique.

Risques De Bande Passante Et Tentation Du « Plus Gros Possible »

Dès qu’un plafond monte, une partie de l’écosystème teste le nouveau plafond pour le plaisir. C’est humain. C’est aussi dangereux. Une transaction de 4 096 octets n’est pas « quatre fois mieux ». Elle est plus lourde à propager, plus coûteuse à stocker temporairement, plus exposée aux liens faibles. Si les usages les plus bruyants saturent les chemins d’abord, les usages modestes en pâtiront. Le réseau n’a pas besoin d’une démonstration de force. Il a besoin d’une adoption proportionnée aux vrais besoins.

La fragmentation est l’autre risque nommé. Imaginez un sous-ensemble de validateurs et de relais parfaitement à l’aise avec V1, et un autre sous-ensemble qui traite encore surtout l’ancien monde. Les transactions lourdes circuleront moins bien vers certaines zones. Des confirmations sembleront capricieuses. Des utilisateurs accuseront « le réseau » alors que le vrai écart sera d’outillage. D’où l’importance des tests communs, des jeux d’essai publics, des seuils d’alerte partagés. La coordination n’est pas un luxe de communication. C’est une condition de propagation.

Il existe enfin un risque de récit. Présenter septembre comme le mois où Solana « change de dimension » peut être vrai à l’échelle de plusieurs trimestres, et faux à l’échelle d’une semaine. La première baisse de loyer est un palier. V1 est un format optionnel. Les slots restants n’ont pas de date. Alpenglow n’est pas certifié pour une heure H. Un récit trop compact fabrique de la volatilité émotionnelle. Un récit exact fabrique de la préparation.

Marché : Aucun Mouvement Vérifié Attribué À L’Annonce

Au moment de la publication initiale de cette actualité, aucun mouvement de marché vérifié n’était directement attribué à la prise de parole de Creech. Cette phrase mérite de rester visible. Trop souvent, une feuille de route technique est immédiatement traduite en thèse d’achat ou de vente. Or un format de transaction, un palier de dépôt et une cible de consensus ne se transforment pas en prix en quelques heures, sauf récit spéculatif. Le travail réel se joue dans les dépôts de code, les versions de clients, les seuils d’activation et les tests de charge.

Cela n’interdit pas d’anticiper des effets de second tour. Si V1 débloque des produits impossibles aujourd’hui, l’activité on-chain peut changer de composition. Si le loyer baisse vraiment sur cinq étapes, le coût de l’état diminue et certains modèles économiques redeviennent tenables. Si Alpenglow tient sa promesse de finalité, l’expérience utilisateur se rapproche d’un service web classique. Ces « si » sont cohérents. Ils ne sont pas des garanties. Les traiter comme des garanties, c’est confondre une carte et le territoire.

Les observateurs les plus utiles, dans les semaines qui viennent, ne seront pas ceux qui commenteront le cours à la minute. Ce seront ceux qui mesureront le taux d’opt-in V1, la taille médiane des transactions, le volume de comptes créés après le premier palier de loyer, la stabilité des validateurs à chaque tentative de slot plus court, et l’état réel des tests Alpenglow. Ces indicateurs sont moins chatoyants. Ils disent pourtant si le calendrier de Creech est en train de tenir.

Scale Or Die En Novembre, Point De Rendez-Vous Plus Que Slogan

Creech clôt sa séquence par un rendez-vous : se retrouver à Scale or Die en novembre. La formule « Solana development will never be the same » sonne comme une punchline. Elle s’appuie pourtant sur une accumulation concrète. Entre fin août et novembre, le réseau est censé avoir entamé la baisse de loyer, activé un format de transaction nettement plus spacieux, progressé sur les slots, et, si tout se tient, approché ou entamé le chapitre Alpenglow. Un événement de novembre devient alors un lieu d’après-coup : que s’est-il vraiment allumé, que reste-t-il derrière une porte, qu’ont appris les validateurs ?

Les conférences techniques servent souvent de théâtre. Celle-ci peut servir de bilan. Les équipes y compareront leurs matrices de formats, leurs incidents de propagation, leurs économies de dépôt, leurs métriques de confirmation. Le public y cherchera des dates plus nettes pour 200 millisecondes et pour Alpenglow. L’écart entre les deux attentes — opérationnelle d’un côté, narrative de l’autre — dira si la communication de fin août a été bien lue.

En attendant, le plus utile n’est pas de répéter que « plus rien ne sera comme avant ». C’est de traiter chaque activation comme un chapitre mesurable. Le 9 septembre, on saura si V1 s’allume comme prévu. Dans les jours suivants, on saura qui l’utilise vraiment. Sur le loyer, on saura si le premier palier change les habitudes de création de comptes ou s’il reste symbolique. Sur les slots, on saura si la prudence l’emporte sur la précipitation. Sur Alpenglow, on saura si octobre reste un cap ou s’il recule d’un cran, comme cela arrive aux refontes de consensus.

Une Lecture Plus Large : Performance Par Couches, Pas Par Miracle

Ce calendrier raconte une philosophie. Solana n’essaie pas, ici, de tout résoudre avec un unique levier. Elle pousse la taille utile, le coût d’état, la fréquence des slots et, plus tard, la finalité. Chaque couche a son ennemi : le plafond d’octets, le dépôt trop lourd, l’horloge trop lente, le consensus trop long. Traiter ces ennemis séparément rend le progrès moins photogénique. Cela le rend plus gouvernable. On peut échouer sur une couche sans annuler les autres.

Cette approche contraste avec le fantasme d’une bascule unique, si répandu dans les récits de protocoles. Une bascule unique est facile à raconter. Elle est difficile à opérer sans casse. Les portes de fonctionnalités, les activations par les validateurs, les paliers de loyer et l’opt-in de V1 dessinent plutôt un réseau qui accepte de vieillir par étapes. Ce n’est pas moins ambitieux. C’est plus adulte.

Pour les créateurs d’applications, la leçon pratique est la même. Il ne s’agit pas d’attendre « le » jour où tout sera parfait. Il s’agit d’accrocher chaque amélioration à un usage réel. Un module de preuve peut basculer sur V1. Un flux d’onboarding peut recalculer ses dépôts dès le premier palier. Un marché peut se préparer à des confirmations plus fréquentes sans parier encore sur 150 millisecondes de finalité. Le calendrier devient alors une liste de travaux, pas une légende.

Ce Qu’Il Faut Retenir Avant Le 9 Septembre

Transaction V1 est datée : le 9 septembre 2026. Elle triple largement l’espace utile d’une transaction sérialisée, sur option, sans tuer les formats anciens, et sans tables de recherche d’adresses. La baisse de loyer commence plus tôt, dès la semaine du 31 août, mais seulement pour la première des cinq étapes vers 696 lamports par octet. Les slots iront vers 300, 250 et 200 millisecondes selon d’autres activations, après le passage déjà effectué à 350. Alpenglow vise octobre et environ 150 millisecondes de finalité, sans date d’allumage mainnet garantie. Rien dans l’annonce n’autorise à fusionner ces dates en une seule fête technique.

Le reste appartient au travail invisible. Mettre à niveau les outils. Choisir le bon format pour chaque instruction. Recalculer les dépôts. Surveiller la propagation. Refuser le récit trop compact. Mesurer. Ajuster. C’est moins flamboyant qu’une révolution annoncée. C’est exactement la matière dont sont faites les mises à jour qui tiennent.

Alors, le développement de Solana ne sera plus le même, comme le laisse entendre Creech ? Peut-être, si l’on regarde la somme des couches à l’horizon novembre. Certainement pas si l’on attend du 9 septembre qu’il règle à lui seul la taille, le loyer, l’horloge et le consensus. La seule manière honnête de lire les prochaines semaines, c’est de les prendre une porte après l’autre — et de vérifier, à chaque ouverture, ce qui passe vraiment de l’autre côté.