Le temps de slot cible du mainnet de Solana devrait passer de 400 millisecondes à 350 millisecondes à l'epoch 1020, après un délai d'un epoch consécutif à l'activation de la fonctionnalité au début de l'epoch 1019. Le changement effectif est prévu pour l'epoch 1020.

Le changelog d'ingénierie du 6 août de Solana confirme que le feature gate visant à réduire les temps de slot de 400 ms à 350 ms était actif sur Devnet et Testnet. Le changelog renvoie également à un prochain calendrier des feature gates et répertorie les versions ainsi que les travaux d'ingénierie dans l'écosystème Solana.

Le timing cible n'est pas la même chose que la production de blocs observée, la latence de confirmation des transactions ou la finalité économique. Le changement réduit l'intervalle cible de production sans augmenter l'allocation de calcul par seconde.

EXPLORE: Best Memecoins Presales to Watch in 2026

Ce que change l'objectif de 350 ms

Réduire l'intervalle cible de 400 ms à 350 ms le raccourcit de 50 millisecondes. L'augmentation théorique de la fréquence de planification est d'environ 14,3 %, calculée comme 400 divisé par 350 moins 1. Ce calcul décrit uniquement le rythme cible ; il ne s'agit pas d'une prévision du débit des transactions ni de la vitesse de confirmation.

La réduction progressive est liée à la proposition de brouillon SIMD-0525. Selon la description de la proposition dans le rapport, le compte de fonctionnalité du mainnet a été activé à l'epoch 1019, tandis que l'objectif effectif de 350 ms est repoussé à l'epoch 1020.

nous activons la première réduction du temps de slot sur le mainnet

pour aider à s'assurer que les développeurs sont prêts, car la période de transition est délicate…

1. Nous n'avons PAS mis à jour certaines constantes du SDK comme DEFAULT_MS_PER_SLOT pour refléter les nouvelles valeurs. Note : nous publierons une version avec des valeurs mises à jour après l'activation… — Brennan Watt (@bw_solana) August 18, 2026

Le même rapport indique qu'à mesure que les slots cibles deviennent plus courts, le budget maximal de calcul par bloc diminue dans l'exemple. Il mentionne 100 millions d'unités de calcul pour un objectif de 400 ms et 87,5 millions d'unités de calcul pour 350 ms. Ces deux chiffres correspondent à un maximum théorique d'environ 250 millions d'unités de calcul par seconde : 100 millions divisé par 0,4 seconde et 87,5 millions divisé par 0,35 seconde.

Ce plafond théorique n'est pas une prévision du débit des transactions. L'activité réelle dépend de la charge de travail et des conditions du réseau, et une limite maximale de calcul par bloc ne signifie pas que chaque bloc contient cette quantité de travail.

Solana continuerait d'attribuer quatre slots consécutifs à chaque leader. À un objectif de 400 ms, cela correspond à une fenêtre nominale de leader de 1,6 seconde ; à 350 ms, cela correspond à 1,4 seconde. La période plus courte laisse moins de temps aux validateurs pour recevoir un bloc précédent, le rejouer, construire dessus et enregistrer leurs votes avant que le réseau ne passe au slot suivant.

EXPLORE: Best Memecoins Presales to Watch in 2026

La trajectoire par étapes vers 200 ms

La séquence proposée de réductions du slot cible va de 400 ms à 350 ms, puis à 300 ms, 250 ms et 200 ms. Le rapport de presse Solana indique que Testnet fonctionnait avec un objectif effectif de 200 ms, tandis que Devnet était à 300 ms et avait activé un gate de 250 ms qui n'était pas encore effectif.

Le changement à 350 ms sur le mainnet doit donc être considéré comme une étape d'une séquence plus large proposée, et non comme la confirmation que chaque objectif ultérieur prendra effet selon le même calendrier. SIMD-0525 reste un brouillon, et l'activation d'une fonctionnalité sur un cluster ne fait pas du design complet à 200 ms une norme finale acceptée.

La première fonctionnalité de réduction du temps de slot est désormais active sur Solana testnet. SIMD-0525 est actif sur testnet, réduisant le temps de slot de 400 ms à 350 ms comme première des quatre étapes sous feature gate vers un temps de slot de 200 ms. pic.twitter.com/8XnTu4Byqs — Solana Developers (@solana_devs) August 5, 2026

Le changelog du 6 août apporte également un contexte supplémentaire sur le travail des clients validateurs. Il répertorie les versions d'Agave et de Firedancer, décrit des travaux de conformité supplémentaires sur Agave et indique que Mithril se tient à jour sur la suite de conformité d'Agave. Le changelog précise que Mithril est une nouvelle implémentation de validateur écrite en Go qui participera bientôt au consensus, et que son travail avec la suite de conformité vise à l'aider à suivre Agave.

Le changelog décrit aussi des améliorations du cache de diffusion Turbine du leader d'Agave et de la reconstruction de la table de routage. Selon le changelog, les leaders créent des blocs à partir des transactions envoyées par le réseau, découpent les blocs en shards et les distribuent aux validateurs via Turbine.

EXPLORE: Best Crypto Presales to Watch in 2026