Solana a réduit le temps de slot cible de son mainnet de 400 millisecondes à 350 millisecondes, première étape d’un plan progressif visant à terme à l’abaisser à 200 ms.
Le changement est entré en ligne vers le début de l’époque 1020, vendredi, et marque la première fois que Solana a réduit la durée cible des slots depuis le lancement du réseau. C’est un chiffre qui peut sembler petit, mais avec un chantier d’ingénierie assez conséquent derrière.
Un slot est la fenêtre pendant laquelle un validateur leader peut produire un bloc. Des slots plus courts signifient que les blocs peuvent être produits plus fréquemment, ce qui peut réduire le temps d’attente des utilisateurs et des applications pour obtenir des confirmations. Le mot clé est la latence. Cette mise à niveau n’est pas conçue pour doubler magiquement la capacité de traitement des transactions de Solana.
Le réseau emprunte l’escalier jusqu’à 200 ms
Le plan vient de SIMD-0525, une proposition d’amélioration de Solana rédigée par l’ingénieur d’Anza Brennan Watt. Au lieu de passer directement de 400 ms à 200 ms, le réseau utilise quatre étapes distinctes, chacune protégée par un « feature gate » : 350 ms, 300 ms, 250 ms puis finalement 200 ms.
La proposition officielle de Solana conserve 64 ticks par créneau, quatre créneaux par fenêtre de leader et 432 000 créneaux par époque. Le nombre de créneaux reste le même. Le temps réel représenté par ceux-ci devient plus court.
Créneaux à 400 ms : époques d’environ 48 heures et fenêtres de leader de 1,6 seconde
Créneaux à 350 ms : époques d’environ 42 heures et fenêtres de leader de 1,4 seconde
Créneaux à 300 ms : époques d’environ 36 heures et fenêtres de leader de 1,2 seconde
Créneaux à 250 ms : époques d’environ 30 heures et fenêtres de leader de 1,0 seconde
Créneaux à 200 ms : époques d’environ 24 heures et fenêtres de leader de 0,8 seconde
Le déploiement est volontairement prudent. Chaque étape dispose de son propre « feature gate », et les développeurs peuvent s’arrêter avant la prochaine réduction si les performances des validateurs ou les taux de saut de blocs commencent à évoluer dans la mauvaise direction. Réduire la latence est utile. Transformer le mainnet en test de stress involontaire l’est moins.
350 ms apparaît déjà sur le mainnet
Les premières mesures en conditions réelles suggèrent que le réseau a évolué dans le sens recherché. Le Block a comparé deux périodes de 1 000 créneaux autour de la transition. Une période avant le changement prenait environ 415 secondes, tandis qu’un échantillon ultérieur à l’époque 1020 a duré environ 368 secondes.
Ces chiffres varieront naturellement, car une cible de 350 ms ne signifie pas que chaque créneau tombe exactement à 350 ms. Cela dit, ils montrent que le changement sur le mainnet est bien plus qu’un simple fichier de configuration en attente d’effet. Le calendrier plus court se voit dans la production réelle des blocs.
Le même rapport indique que les développeurs n’ont pas encore fixé de date d’activation sur le mainnet pour la prochaine étape de 300 ms. Ils prévoient d’abord observer comment le réseau se comporte à 350 ms.
Ce n’est pas une mise à niveau gratuite en termes de débit
L’une des façons les plus simples de mal comprendre le changement consiste à supposer que des créneaux 12,5 % plus courts signifient automatiquement 12,5 % de capacité réseau en plus. SIMD-0525 réduit délibérément la quantité de travail autorisée dans chaque créneau à mesure que les créneaux deviennent plus courts.
Récemment, Solana a relevé sa limite de blocs sur le mainnet à 100 millions d’unités de calcul. Avec la proposition de créneaux plus courts, ce plafond par créneau passe à 87,5 millions d’unités de calcul à 350 ms, 75 millions à 300 ms, 62,5 millions à 250 ms et 50 millions à 200 ms.
Le but est de maintenir à peu près stable la cadence de travail « en temps réel » tout en réduisant le temps d’attente des utilisateurs entre les créneaux. Les validateurs disposent de moins de temps pour traiter chaque créneau, mais ils reçoivent aussi proportionnellement moins de travail à l’intérieur de celui-ci.
Cela fait de cette évolution principalement une amélioration de réactivité. Des changements séparés aux limites de calcul, au logiciel des validateurs et au traitement des transactions sont là où proviennent les hausses de capacité « brutes ».
Des fenêtres de leader plus courtes apportent un bénéfice pour la structure de marché
Il existe une autre raison pour laquelle les développeurs veulent des créneaux plus courts, qui a peu à voir avec la rapidité avec laquelle un portefeuille affiche « confirmé ».
Un responsable (leader) de Solana contrôle actuellement quatre créneaux consécutifs. Avec l’ancien objectif de 400 ms, cela donnait à un leader une fenêtre nominale de 1,6 seconde. À 350 ms, cela tombe à 1,4 seconde, et à l’extrémité proposée de 200 ms, ce serait 0,8 seconde.
Cela réduit le temps maximal qu’un leader unique peut mettre pour retarder, réordonner ou inclure de manière sélective des transactions avant qu’un autre validateur n’ait son tour. Pour les traders, les market makers et les applications sensibles à la latence, réduire cette fenêtre peut améliorer à la fois la structure du marché et l’expérience utilisateur.
Des créneaux plus courts rendent aussi le temps « on-chain » plus précis pour les systèmes qui mesurent la fraîcheur en nombre de créneaux, notamment les consommateurs d’oracles et les applications de market-making automatisées. La documentation de mise à niveau de Solana indique que les market makers pourraient être en mesure de publier des spreads plus serrés à mesure que la latence diminue.
La finalité est un projet distinct
Solana peut produire des créneaux toutes les quelques centaines de millisecondes sans atteindre si rapidement la finalité irréversible. La finalité complète actuelle prend encore environ 12,8 secondes.
C’est là qu’intervient Alpenglow. La refonte séparée du consensus en cours de développement vise à ramener la finalité à environ 150 ms. Si ce travail arrive sur le mainnet comme prévu, il représenterait un changement beaucoup plus important dans le temps nécessaire pour que le réseau considère un bloc comme final.
Ces deux efforts sont liés dans l’objectif général de réduire la latence, mais il ne faut pas les confondre. SIMD-0525 raccourcit les créneaux dans la progression actuelle. Alpenglow change à lui seul le système de consensus et de finalité.
Pourquoi les Traders devraient s’y intéresser
Pour les détenteurs ordinaires de SOL, une réduction de 50 ms des créneaux est peu susceptible de provoquer un moment « waouh, mon portefeuille est différent » du jour au lendemain. Le raisonnement d’investissement est plutôt cumulatif.
Solana s’est battu pendant des années sur la vitesse, les faibles frais et l’activité on-chain à haute fréquence. Raccourcir les durées de créneaux sans déstabiliser les validateurs renforcerait la position du réseau dans le trading, les paiements et les applications là où la latence compte. Atteindre 200 ms réduirait de moitié la durée cible du créneau par rapport au réglage initial du réseau de 400 ms.
Le risque d’ingénierie augmente aussi à mesure que le timing devient plus serré, c’est pourquoi le déploiement par étapes compte. Les prochaines étapes ne sont pas garanties simplement parce que les 350 ms sont passées en ligne. Les développeurs ont l’intention de passer à 300 ms, puis 250 ms et 200 ms uniquement si les performances du réseau restent saines.
Pour l’instant, Solana a terminé la première vraie étape sur le mainnet. C’est plus rapide, le changement est mesurable, et la route vers 200 ms n’est plus seulement une proposition posée sur GitHub. Le test le plus intéressant commence maintenant : savoir si les validateurs peuvent continuer à raccourcir l’horloge sans perdre de la fiabilité en échange.
---------------
Auteur : Sebastian Marrow Rédaction européenne Nouvelles cryptos Breaking Crypto News
Abonnez-vous à GCP via un lecteur