Solana vise aujourd'hui un slot de 400 millisecondes, soit l'intervalle pendant lequel un validateur désigné produit un bloc. La proposition SIMD-0525, ouverte en pull request le 1er mai 2026 par le contributeur bw-solana, veut ramener cette cible à 200 millisecondes. La bascule ne serait pas immédiate. Le texte décrit quatre paliers successifs, chacun activé par une feature gate, un interrupteur logiciel synchronisé entre validateurs : 350 ms, puis 300, 250 et 200 ms. Le débat a été ouvert le 20 février 2026 dans la section discussions du dépôt des SIMD. Une implémentation exploratoire a été menée en parallèle sur Agave, l'un des clients du réseau, pour mesurer l'ampleur réelle des modifications nécessaires.
Quels paramètres du réseau changent ?
Diviser par deux la durée d'un slot suppose de diviser par deux le travail admis dans un bloc. Les valeurs mises sur la table lors de la discussion technique :
| Limite par bloc | Valeur actuelle | Valeur proposée |
|---|---|---|
| Unités de calcul totales | 60 M | 30 M |
| Unités de calcul sur un même compte | 24 M | 12 M |
| Coût alloué aux votes | 36 M | 18 M |
| Données allouées | 100 Mo | 50 Mo |
| Shreds | 32 000 | 16 000 |
Le nombre de comptes de staking écrits par bloc pendant la distribution des récompenses passerait de 4 000 à 2 000. La durée de validité d'une transaction, elle, serait doublée en nombre de slots pour rester identique en temps réel. Trois valeurs ne bougent pas : 64 ticks par slot, 4 slots par fenêtre de leader et 432 000 slots par epoch. Comme les slots raccourcissent, une epoch durerait environ un jour au lieu de deux.
Pourquoi la fenêtre du leader compte
Un leader garde la main sur quatre slots consécutifs. À 400 ms, il contrôle l'ordre d'exécution des transactions pendant 1,6 seconde. À 200 ms, cette fenêtre tombe à 800 millisecondes. C'est l'argument central du document : réduire la durée maximale pendant laquelle un même producteur de blocs peut retarder, réordonner ou filtrer des transactions. L'analyse publiée par Solana le 19 août 2026 relève que le comportement d'inclusion diffère déjà d'un client à l'autre, certains plaçant les transactions en début de slot, d'autres vers la fin. Le même document note que des slots plus courts réduisent, dans les modèles, l'arbitrage sur prix périmé face aux marchés de référence externes. L'effet sur les attaques de type sandwich n'est pas tranché : la fenêtre de réaction se réduit, mais une moindre concurrence à l'intérieur d'un slot peut laisser davantage de marge aux acteurs les plus rapides. Les applications qui raisonnent en nombre de slots, dont les consommateurs d'oracles, y gagneraient un signal temporel plus fin.
Ce que ça change pour les validateurs
À 200 ms, un validateur vote environ deux fois plus souvent par unité de temps réel. L'analyse de Solana indique que les seuils attendus de récupération des frais de vote restent proches, mais que les petits validateurs supportent un coût de vote absolu plus élevé. En contrepartie, les occasions de produire un bloc deviennent plus fréquentes, ce qui réduit la variance des récompenses. La baisse est plus marquée sur l'incertitude à la baisse que sur les gains extrêmes. Le point non résolu est la marge de latence. Le transfert entre deux leaders coûte environ 60 millisecondes en moyenne sur le mainnet selon les mesures citées dans la discussion, une part importante d'un slot de 200 ms. L'effet sur les récompenses liées à la latence des votes reste, de l'aveu du document, une question empirique.
Où en est la proposition ?
Elle n'est pas adoptée. Le processus impose l'approbation d'au moins un membre de l'équipe Anza et d'un membre de l'équipe Firedancer avant toute fusion. Les retours publiés sur la pull request sont réservés. Un relecteur d'Anza s'est dit d'accord avec la direction mais opposé au calendrier, estimant qu'aucune urgence ne justifie de contourner la dette technique existante et demandant un nettoyage du code au préalable. Un relecteur de Firedancer a réclamé que les vecteurs de test soient fournis avec la spécification plutôt qu'une simple obligation de tester. Une expérimentation à 200 ms a été menée sur le réseau principal de Solana. D'après l'auteur de la proposition, les blocs y contenaient en moyenne plus de la moitié du nombre habituel de transactions hors votes, avec des latences de vote dégradées par rapport au reste du réseau.
