Voir la table des matières Ne plus voir la table des matières
- Cinquante millisecondes de moins, et tout le calendrier se décale
- Quatre marches jusqu’aux 200 millisecondes
- Un réseau plus rapide n’est pas un réseau plus gros
- Ce que la fenêtre du leader change pour l’ordre des transactions
- Ce que la mise à jour coûte aux validateurs
- Une course à la latence dont le prix reste à établir
Vendredi matin, sans annonce spectaculaire ni interruption de service, Solana a raccourci le battement de cœur de sa blockchain. Le réseau vise désormais 350 millisecondes pour produire chaque slot, contre 400 auparavant. Un slot, c’est la courte fenêtre pendant laquelle un validateur désigné a le droit de fabriquer un bloc de transactions. Cinquante millisecondes de moins, cela paraît anecdotique, et pourtant le calendrier interne du réseau s’en trouve entièrement décalé.
La manœuvre n’a rien d’improvisé. Elle applique la première des quatre marches prévues par la proposition SIMD-0525, un document technique validé par les développeurs du réseau au printemps, qui trace une route vers 200 millisecondes par slot, soit la moitié de la valeur historique. Sur un marché où la vitesse d’exécution sert d’argument commercial autant que technique, chaque milliseconde gagnée se transforme en argument de vente. Reste à savoir ce qu’un porteur de jetons y gagne réellement ?
Cinquante millisecondes de moins, et tout le calendrier se décale
La mécanique tient à une contrainte que les développeurs ont refusé de toucher : une époque compte toujours 432 000 slots. Raccourcir le slot raccourcit donc l’époque. Le cycle qui durait environ 48 heures tombe à 42 heures, et descendra jusqu’à 24 heures une fois les 200 millisecondes atteintes. Les récompenses, les changements de jeu de validateurs et les activations de fonctionnalités suivent ce rythme.
Un validateur conserve la main sur quatre slots consécutifs. Sa fenêtre de contrôle passe donc de 1,6 à 1,4 seconde, et tombera à 800 millisecondes au terme du déploiement. Le relais entre producteurs de blocs s’accélère d’autant.
La mesure prise par The Block au moment de la bascule donne l’ordre de grandeur : une série de 1 000 slots demandait 415 secondes juste avant la mise à jour, contre 368 secondes un peu plus tard dans l’époque 1020. L’écart de 47 secondes correspond très exactement à la théorie, ce qui n’était pas gagné d’avance sur un réseau de cette taille. Le reste du chemin est déjà cartographié.
Quatre marches jusqu’aux 200 millisecondes
Le déploiement se fait par paliers séparés, chacun activé par sa propre barrière logicielle, et chacun réversible si trop de validateurs manquent leur tour. Voici la trajectoire prévue par la proposition :
- 350 millisecondes, activées sur le réseau principal le 21 août 2026 ;
- 300 millisecondes, prochain palier annoncé, sans date d’activation fixée ;
- 250 millisecondes, troisième étape, conditionnée à la bonne tenue des deux précédentes ;
- 200 millisecondes, cible finale, qui divisera par deux la valeur en vigueur depuis les débuts du réseau.
Chaque barrière ne devient effective qu’une époque après son activation, le temps que les validateurs ajustent leurs filtres de propagation. Ce délai d’une époque est une précaution de sécurité, pas une lenteur administrative : sans lui, des fragments de blocs parfaitement valides seraient rejetés avant même d’être exécutés.
Les développeurs observeront le comportement du réseau à 350 millisecondes avant d’enclencher la suite. Ce séquencement prudent tranche avec l’image d’un écosystème qui avance vite quitte à casser, et il mérite d’être porté au crédit de l’équipe. Encore faut-il comprendre ce que cette accélération ne fait pas.
Un réseau plus rapide n’est pas un réseau plus gros
La confusion est tentante et le document technique prend soin de la dissiper. Les limites de travail par slot sont réduites dans la même proportion que la durée du slot : le plafond de calcul d’un bloc passe de 100 à 87,5 millions d’unités, et les fragments de données maximaux de 32 768 à 28 672. Le débit exprimé en travail par seconde reste donc inchangé.
Ce qui change, c’est la latence ressentie. Une confirmation arrive plus tôt, un oracle publie un prix plus frais, une application qui raisonne en nombre de slots gagne en précision temporelle. La rapidité perçue par l’utilisateur ne se confond pas avec la capacité du réseau, et cette distinction sépare les annonces sérieuses des effets d’affiche. La fenêtre du leader, elle, produit un effet plus discret mais plus structurant.
Ce que la fenêtre du leader change pour l’ordre des transactions
Pendant qu’il tient la main, un validateur décide de l’ordre des transactions qu’il inclut. Il peut retarder, réordonner, choisir. Réduire sa fenêtre de 1,6 à 1,4 seconde, puis à 800 millisecondes, réduit mécaniquement la durée pendant laquelle un seul acteur contrôle le flux. Les auteurs de la proposition présentent explicitement cet effet comme une amélioration de la structure de marché.
L’argument parle directement à quiconque exécute des ordres de taille sur une place décentralisée, mais il vaut aussi pour un porteur ordinaire, qui subit ces réordonnancements sans les voir.
Des slots plus courts réduisent la latence de confirmation et de finalisation pour les utilisateurs. Tout seuil de consensus ou d’engagement mesuré en slots demande moins de temps réel à mesure que la durée du slot diminue.
Brennan Watt, ingénieur chez Anza, auteur de la proposition SIMD-0525 déposée le 1er mai 2026
La finalité complète, c’est-à-dire le moment où un bloc devient irréversible, reste un autre chantier. Elle demande encore près de 12,8 secondes, et c’est le chantier de refonte engagé au printemps qui vise à la ramener autour de 150 millisecondes. Deux horloges distinctes avancent en parallèle, et les confondre revient à surestimer ce que la mise à jour du 21 août apporte aujourd’hui.
Ce que la mise à jour coûte aux validateurs
Raccourcir l’époque aurait renchéri le ticket d’entrée des validateurs, facturé par époque et non par jour. La proposition corrige ce biais en faisant baisser le ticket au même rythme que la durée du cycle, pour maintenir un coût d’environ 0,8 SOL par jour tout au long du déploiement.
| Durée de slot | Durée d’une époque | Fenêtre du leader | Ticket d’admission |
|---|---|---|---|
| 400 ms | 48 h | 1,6 s | 1,6 SOL |
| 350 ms | 42 h | 1,4 s | 1,4 SOL |
| 300 ms | 36 h | 1,2 s | 1,2 SOL |
| 250 ms | 30 h | 1,0 s | 1,0 SOL |
| 200 ms | 24 h | 0,8 s | 0,8 SOL |
La compensation ne couvre pas tout. Les frais de vote classiques, eux, ne sont pas ajustés : un validateur paiera deux fois plus de frais de vote par heure une fois les 200 millisecondes atteintes, et le trafic de propagation double également. La robustesse acquise avec l’arrivée d’un second client de validation trouvera là un terrain d’épreuve.
Une course à la latence dont le prix reste à établir
Solana joue une partition cohérente depuis dix-huit mois : plafond de calcul relevé à 100 millions d’unités l’été dernier, diversité logicielle renforcée, et maintenant la durée de slot. Chaque brique prise isolément semble modeste, l’ensemble dessine une infrastructure qui vise le règlement en temps quasi réel plutôt que la performance de démonstration.
Le pari n’est pas sans contrepartie pour ceux qui font tourner le réseau. Des fenêtres plus courtes laissent moins de temps pour recevoir, rejouer et bâtir sur le bloc précédent, et les outils tiers qui convertissent encore les slots en secondes sur la base de 400 millisecondes vont se désynchroniser. Le record d’usage établi en juillet montre que la demande suit ; la question porte désormais sur la marge de sécurité des opérateurs.
Un investisseur qui regarde Solana au-delà du cours du jour trouvera là un indicateur utile. La qualité d’exécution d’une feuille de route technique, palier après palier, en dit plus long sur la solidité d’un réseau que la volatilité de son jeton. Les trois marches restantes se joueront sans filet médiatique, et c’est précisément à ce moment que la robustesse se mesure.
