Qu'est-ce qui change exactement ?
Solana raccourcit la durée cible de production d'un bloc (slot time) sur le mainnet, de 400 millisecondes à 350 millisecondes. Selon le reportage de CryptoSlate, ce changement a été activé au début de l'époque 1019, mais en raison de ce qu'on appelle le décalage d'une époque (one-epoch delay), le réseau conserve les paramètres existants et la nouvelle cible de 350 ms n'entrera réellement en vigueur qu'à partir de l'époque 1020.
Juste pour préciser les termes : le slot time est l'intervalle cible dans lequel un bloc doit être produit. L'époque est une fenêtre temporelle plus longue composée de nombreux slots, à l'issue de laquelle certaines modifications de paramètres sont appliquées. Les compute units (unités de calcul) sont une mesure de la quantité de calcul qu'un bloc peut contenir.
Pourquoi la limite de calcul par bloc est-elle réduite en même temps ?
C'est le cœur de toute l'histoire. Selon CryptoSlate, les blocs reçoivent un intervalle cible de production plus court, mais ne reçoivent pas un volume de calcul autorisé plus élevé par seconde. En pratique, cela signifie que lorsque les blocs sont produits plus fréquemment, chaque bloc individuel doit être plus "léger", afin que la charge totale sur le réseau et les validateurs par unité de temps reste à peu près constante.
La logique est simple : accélérer les blocs sans ajuster la limite de calcul reviendrait à traiter davantage de calcul par seconde, ce qui pourrait surcharger les validateurs et menacer la stabilité du réseau. La réduction de la limite par bloc est donc une garantie, pas un effet secondaire.
Où en sont les réseaux de test ?
Selon CryptoSlate, le déploiement est plus avancé ailleurs que sur le mainnet :
| Réseau | État de la durée cible du bloc |
|---|---|
| Mainnet | passage de 400 ms à 350 ms (effectif à partir de l'époque 1020) |
| Testnet | cible effective de 200 ms |
| Devnet | cible de 300 ms, seuil de 250 ms activé, mais pas encore effectif |
Le Testnet et le Devnet servent donc d'étape préalable, où des valeurs plus agressives sont testées avant d'arriver sur le mainnet.
D'où vient ce changement ?
CryptoSlate renvoie au changelog de Solana du 6 août, où ces paramètres sont décrits. Le raccourcissement progressif de la durée d'un bloc s'inscrit dans un effort plus large et de long terme de Solana pour réduire la latence du réseau.
Qu'est-ce qui n'est pas encore clair ?
La source disponible n'indique pas la date exacte au calendrier à laquelle l'époque 1020 aura lieu, ni la valeur numérique précise de la réduction de la limite de calcul par bloc. De même, cette source ne documente pas l'impact réel qu'aura le changement sur la latence des transactions, les frais ou la stabilité du réseau pour les utilisateurs finaux. Cela ne se manifestera qu'à travers le comportement du mainnet après l'époque 1020.
À quoi faut-il faire attention avec ce type de changement ?
Pour les ajustements de paramètres d'une blockchain au niveau du protocole, il est utile de surveiller trois choses : si le changement s'active réellement à l'époque annoncée, s'il n'y a pas de pannes imprévues ou de ralentissement de la production de blocs, et si le débit (nombre de transactions par seconde) évolue réellement ou reste stable. Justement parce que Solana maintient ici délibérément le calcul par seconde constant, la principale métrique à vérifier est plutôt la latence et la stabilité que le débit brut.
charliedesk note ce changement afin de pouvoir le comparer plus tard avec ce qui se passera réellement sur le réseau après l'époque 1020.