Solana réduit son slot time pour la première fois depuis son lancement. Sa capacité par seconde ne bouge pas d'une unité

Un réseau qui tient un registre partagé entre des milliers de machines doit s'accorder sur un rythme : à quelle cadence il ouvre une nouvelle page d'écriture. Ce rythme n'est pas une performance affichée, c'est une convention que tous les opérateurs tiennent à la même seconde, et celui qui décroche envoie son travail dans une page déjà refermée, où il est perdu. Un tel réglage se pose donc au démarrage, et ensuite il se défend plutôt qu'il ne se change. L'un des réseaux les plus utilisés du secteur a passé six ans sans jamais déplacer cet intervalle de quatre cents millisecondes. Il est pourtant intervenu sur l'horloge interne qui cadence ces pages, six fois, dont cinq relèvements de sa difficulté groupés sur trois semaines au printemps 2024 : la calibration bougeait, la cible ne bougeait pas. Le 21 août 2026, ce réglage a bougé pour la première fois : Solana est passé à 350 millisecondes.

Ce qui a bougé, et ce qui n'a pas bougé

La chaîne écrit plus souvent. Elle n'écrit pas davantage.

C'est le point que la couverture a manqué, et il est spécifié noir sur blanc. SIMD-0525, le texte qui organise la réduction, abaisse les plafonds de travail par bloc dans la même proportion que la durée du bloc. À 400 millisecondes, un bloc pouvait consommer 100 millions d'unités de calcul. À 350, il en consomme 87,5 millions. Le rapport ne bouge pas : 250 millions d'unités par seconde avant, 250 millions après, et la même valeur à chacun des paliers suivants. Le texte dit pourquoi dans sa section sécurité : ces réductions proportionnelles sont requises pour éviter d'augmenter par accident les budgets par seconde en exécution, en écriture, en allocation et en fragments diffusés. Le plafond de fragments par slot suit la même règle, de 32 768 à 28 672.

La hausse de capacité que certains rattachent à l'événement a bien eu lieu, mais ailleurs et avant. Le passage de la limite de bloc de 60 à 100 millions d'unités tourne sur le réseau principal depuis l'epoch 1009, soit onze epochs avant le changement de tempo. C'est ce geste-là qui a porté le plafond de 150 à 250 millions d'unités par seconde. Le chiffre de quadruplement du débit à court terme, qui circule depuis un propos relayé par la presse, ne se réconcilie avec aucun document : la réduction du slot time n'ajoute aucune capacité, et la hausse de la limite de bloc qui en avait ajouté était déjà en production onze epochs plus tôt.

Ce qui baisse est la latence de confirmation. Et une seconde chose, plus intéressante : la fenêtre pendant laquelle un producteur de blocs garde la main. Elle passe de 1,6 à 1,4 seconde, et tombera à 0,8 au bout de la trajectoire. La proposition en fait un argument explicite de structure de marché, puisque c'est le temps maximal dont dispose un leader pour retarder, réordonner ou inclure sélectivement des transactions avant que le suivant ne prenne le relais.

L'effet que personne ne commente : l'epoch se contracte

Solana compte ses cycles en slots, pas en heures. Une epoch fait 432 000 slots, et ce nombre ne change pas. Raccourcir le slot raccourcit donc l'epoch elle-même. Les valeurs spécifiées par le texte sont sans ambiguïté : 48 heures à 400 millisecondes, 42 heures à 350, puis 36, 30, et 24 heures au dernier palier. Le réseau finira avec des cycles deux fois plus courts qu'à son lancement.

Tout ce qui se compte en epochs suit. La distribution des récompenses, l'activation et le refroidissement d'une délégation de stake, l'admission des validateurs sous le futur mécanisme Alpenglow, dont le ticket d'entrée est d'ailleurs réduit palier par palier pour tenir un coût journalier constant. Et, en bout de chaîne, l'activation des crans suivants eux-mêmes, chaque changement de paramètre prenant effet une epoch après avoir été inscrit.

C'est la conséquence la moins visible et la plus lourde. Solana ne devient pas plus gros, il devient plus rapide à se modifier lui-même.

Qui déplace le réglage, et qu'est-ce qui arrête le prochain cran

Le texte a été déposé le 1er mai 2026 et fusionné au dépôt le 14. Le premier palier est entré en production le 21 août. Cent douze jours, quatre clés d'activation prévues, une par cran, dont une seule créée à ce jour, et un délai obligatoire d'une epoch entre l'inscription du changement et sa prise d'effet, pour que les opérateurs aient le temps de suivre.

Il n'y a pas de scrutin dans ce mécanisme d'activation. SIMD-0089, qui a doté Solana d'un programme dédié à ces interrupteurs, précise en note que ce programme ajoute la capacité de révoquer une activation en attente et ne modifie en rien la façon dont les contributeurs cœur activent une fonctionnalité. Le frein documenté n'est pas un bulletin, c'est une métrique : la page officielle des mises à niveau écrit que l'accord issu de la discussion entre validateurs est que le réseau ne passera pas à la réduction suivante si le taux de slots manqués monte trop. Un accord de discussion, pas un scrutin, et pas davantage une décision unilatérale.

Le pouvoir des validateurs existe pourtant, et il est réel. Il s'exerce ailleurs : sur la version du client qu'ils font tourner. Un palier activé sur un réseau qui ne le supporterait pas casserait le consensus, ce qui rend l'adoption logicielle contraignante en permanence. C'est un contrôle continu et informel, pas une approbation cran par cran.

Le contraste avec les deux autres grands réseaux est frappant, et il n'a pas de bon côté évident. Chez Bitcoin, un correctif prêt pour quatre failles connues attend qu'on puisse l'activer, faute de mécanisme praticable. Chez Ethereum, un nombre figé depuis 2015 se dégèle au terme d'un fork planifié, de plusieurs testnets et de mois de coordination publique. Chez Solana, le même geste tient en quatre interrupteurs et une discipline d'annonce. Coût de modification très bas d'un côté, concentration de la décision de l'autre : c'est le même fait, et il se lit dans les deux sens.

Ce que le réseau tient réellement

La cible est à 350 millisecondes. Mesuré le 22 août sur le réseau principal, l'intervalle moyen entre deux slots ressort à 366 millisecondes, contre 415 avant le changement. Le gain réel est donc de 49 millisecondes, pour un objectif de 50. L'écart au-dessus de la cible, lui, est passé de 3,8 à 4,6 %, ce qui allonge l'epoch en cours à environ 44 heures au lieu des 42 spécifiées.

Le taux de slots manqués, seul indicateur qui commande officiellement la suite, ne permet encore de conclure à rien. Il ressort à 0,160 % depuis le changement, contre 0,020 % deux epochs plus tôt. Mais il était déjà à 0,140 % pendant l'epoch intermédiaire, qui tournait encore à 400 millisecondes. La hausse précède le changement de tempo, et lui attribuer la dégradation serait une erreur de lecture.

Les réseaux de test, eux, ont pris beaucoup d'avance. Le testnet a parcouru les quatre paliers en dix jours, du 5 au 15 août, en tenant chaque cran entre 64 et 88 heures ; il écrit à 200 millisecondes depuis le 16. Le devnet écrit à 250 depuis le 19 août, l'interrupteur ayant été posé la veille. Sur le réseau principal, l'interrupteur du palier à 300 millisecondes n'existe pas encore, et la seule indication officielle est que les quatre paliers sont visés dans la version que le réseau exécute déjà, sur un calendrier qu'Anza qualifie lui-même de provisoire.

Ce qui se surveille tient donc en deux points, et aucun ne concerne la vitesse. Le premier est le moment où l'interrupteur du palier à 300 millisecondes sera créé, parce qu'il dira à quel rythme la nouvelle variable se pilote. Le second est le taux de slots manqués sur une epoch pleine, seul juge de la tenue de la trajectoire, et le seul frein que le texte se soit donné.

Questions fréquentes

La réduction du slot time rend-elle Solana capable de traiter plus de transactions ?
Non, et ce n'est pas un effet secondaire, c'est la spécification. SIMD-0525 abaisse les plafonds par bloc dans la même proportion que la durée du bloc, de 100 à 87,5 millions d'unités de calcul, ce qui maintient le plafond à 250 millions d'unités par seconde avant comme après, et à chacun des paliers suivants. Le texte écrit que ces réductions proportionnelles sont requises pour éviter d'augmenter par accident les budgets par seconde. Ce qui baisse est la latence de confirmation, pas la capacité.

Combien de temps dure une epoch Solana après le passage à 350 millisecondes ?
Le nombre de slots par epoch ne change pas, il reste à 432 000, donc la durée en temps réel se contracte. Les valeurs spécifiées sont 48 heures à 400 millisecondes, 42 heures à 350, 36 à 300, 30 à 250 et 24 à 200. Sur le réseau réel, l'intervalle constaté au 22 août 2026 étant de 366 millisecondes et non de 350, l'epoch en cours tourne plutôt autour de 44 heures.

Les validateurs votent-ils chaque palier ?
Il n'existe pas de scrutin dans ce mécanisme d'activation. Chaque palier a son propre interrupteur, et SIMD-0089 précise que le programme qui les gère ajoute la possibilité de révoquer une activation en attente sans changer la façon dont les contributeurs cœur activent une fonctionnalité. Le frein documenté par la page officielle est un accord issu de la discussion entre validateurs : le réseau ne passera pas au palier suivant si le taux de slots manqués monte trop. Le pouvoir des validateurs est réel mais d'une autre nature : il s'exerce sur la version du client qu'ils exécutent, en continu, et non par une approbation cran par cran.

Quand les paliers suivants arriveront-ils sur le réseau principal ?
Aucune date n'est annoncée. La page officielle des mises à niveau indique seulement que les quatre paliers sont visés dans la version Agave 4.2, celle que le réseau principal exécute déjà, et précise que ce calendrier est provisoire et susceptible de changer. Au 22 août 2026, l'interrupteur du palier à 300 millisecondes n'a pas encore été créé. Le testnet, lui, a parcouru les quatre paliers en dix jours, du 5 au 15 août, en tenant chaque cran entre 64 et 88 heures, et le devnet écrit à 250 millisecondes depuis le 19 août, l'interrupteur ayant été posé la veille.