Solana passe à des blocs de 200 millisecondes : le temps de bloc divisé par deux depuis août

Ce qu’il faut retenir :

• Solana réduit son temps de slot cible de 250 à 200 millisecondes ce vendredi 9 octobre, à l’epoch 1053.
• Le réseau aura divisé par deux son temps de bloc en sept semaines, contre 400 millisecondes en août.
• La capacité théorique du réseau reste stable, mais les validateurs devront voter deux fois plus souvent.

Solana abaisse ce vendredi 9 octobre son temps de bloc cible à 200 millisecondes, contre 250 millisecondes jusqu’ici. Le changement doit intervenir à l’epoch 1053, vers 15 h UTC (17 h, heure de Paris), selon Anza, l’équipe qui développe Agave, le logiciel de validation le plus utilisé sur Solana (SOL). Une epoch désigne une période de fonctionnement du réseau d’environ deux jours, au terme de laquelle les paramètres peuvent changer.

Cette dernière étape conclut un chantier lancé en août. En sept semaines, la blockchain aura divisé par deux le délai entre deux blocs.

Solana : quatre réductions du temps de bloc en sept semaines

Le réseau tournait sur une cadence de 400 millisecondes jusqu’au 21 août. Les développeurs sont passés à 350 millisecondes ce jour-là, puis à 300 millisecondes le 28 août et à 250 millisecondes le 18 septembre.

À 200 millisecondes, Solana offre cinq occasions de produire un bloc chaque seconde, contre 2,5 avec la configuration d’origine. Le slot correspond à cette courte fenêtre pendant laquelle un validateur désigné peut ajouter des transactions à la blockchain.

Le débit de Solana va-t-il augmenter ?

Non. La proposition technique SIMD-0525, qui encadre ces baisses, plafonne aussi le travail que chaque bloc peut contenir. Ce travail se mesure en unités de calcul (compute units), qui comptabilisent les ressources informatiques consommées par les transactions.

Chaque bloc pourra embarquer au maximum 30 millions d’unités de calcul, contre 37,5 millions à 250 millisecondes. Les blocs arrivent plus souvent, mais chacun en porte proportionnellement moins. La capacité théorique de traitement du réseau reste donc à peu près la même : Solana gagne en réactivité, à volume constant.

L’écart entre la cible et la réalité mérite aussi l’attention. D’après les données de Solana Compass, la configuration à 250 millisecondes a produit des slots de 266 à 269 millisecondes en moyenne sur les dernières epochs, un peu plus lents que prévu.

Ce qui change pour les traders et les applications

Des slots plus courts permettent aux plateformes de trading, aux wallets et aux exchanges de recevoir des données à jour plus souvent. Une transaction soumise attend moins longtemps avant d’être traitée.

Les validateurs continuent de produire leurs blocs par séries de quatre slots consécutifs. Leur fenêtre exclusive pour ordonner les transactions passe ainsi de 1,6 seconde dans la configuration d’origine à 800 millisecondes. Ce raccourcissement laisse moins de marge pour retarder des transactions ou profiter d’un prix qui a déjà bougé sur d’autres plateformes avant que Solana ne s’aligne. Ces pratiques relèvent de la MEV (maximal extractable value), les profits qu’un producteur de blocs peut tirer de l’ordre des transactions.

Validateurs et wallets : le coût de la vitesse

L’accélération a un prix. Les validateurs qui votent à chaque slot devront le faire environ deux fois plus souvent qu’avec la configuration d’origine. Leurs frais de vote augmentent, tout comme la pression sur leurs connexions réseau.

Les wallets et les applications disposent aussi de moins de temps pour utiliser un blockhash récent. Cet identifiant de bloc, intégré à chaque transaction, empêche qu’elle soit rejouée. Une fenêtre de validité plus courte peut gêner les opérations qui demandent une approbation manuelle ou une signature hors ligne.

Et maintenant ?

Le passage à 200 millisecondes tourne déjà sur le testnet et le devnet de Solana. Pour le mainnet, les développeurs conditionnent le déploiement à l’état du réseau, en particulier au taux de slots manqués (skip rate), c’est-à-dire la part des créneaux où le validateur désigné ne produit pas son bloc.

Les prochaines epochs serviront de test grandeur nature. Deux indicateurs comptent : le temps de slot réel, qui dépassait la cible à 250 millisecondes, et le skip rate. Si l’un des deux dérape, les développeurs devront arbitrer entre vitesse et stabilité.