Solana a entamé la réduction de la durée de ses slots, de 400 à 200 millisecondes. Le changement passe par la proposition SIMD-0525, déposée le 1er mai 2026 sur le dépôt des Solana Improvement Documents et depuis approuvée. Selon Decrypt, la première baisse, de 400 à 350 ms, a été activée sur le réseau principal cette semaine par les validateurs faisant tourner le client Agave v4.2. C'est la première modification de cette durée depuis le lancement de la chaîne. Un slot est la fenêtre de temps pendant laquelle un validateur désigné, le leader, produit un bloc. Pendant ce laps, les autres validateurs rejouent les transactions du bloc et votent sur sa validité, tandis que le leader suivant reçoit déjà des transactions. Raccourcir le slot raccourcit donc tout ce qui se compte en slots, à commencer par le délai avant qu'une transaction devienne irréversible. Le fonctionnement de cette chaîne à haut débit repose sur cette horloge interne, la proof of history, dont le nombre de ticks par slot reste inchangé.
Comment se déroule la baisse ?
La réduction est découpée en quatre paliers de 50 ms, chacun doté de son propre feature gate. Il s'agit d'un interrupteur intégré au code des clients, qui déclenche le changement des règles du protocole à une époque donnée. Une époque correspond à 432 000 slots, soit deux à trois jours selon Decrypt, et ce nombre ne bouge pas.
| Palier | Durée du slot | État |
|---|---|---|
| 1 | 400 ms vers 350 ms | activé sur mainnet selon Decrypt |
| 2 | 350 ms vers 300 ms | à venir |
| 3 | 300 ms vers 250 ms | à venir |
| 4 | 250 ms vers 200 ms | à venir |
Anza vise l'activation des quatre étapes dans la version Agave v4.2, une par une, chacune à une époque postérieure à la précédente. La fondation précise que ce calendrier reste indicatif et peut changer. L'accord issu de la discussion entre validateurs prévoit que le réseau ne passe pas au palier suivant si le taux de blocs sautés monte trop. Rien ne garantit donc que les quatre baisses soient toutes appliquées. La fondation classe par ailleurs la modification comme cassante, et laisse en suspens la question des adaptations nécessaires côté indexation des données.
Pourquoi parler de résistance à la censure ?
Le leader garde la main sur quatre slots consécutifs. À 400 ms, cela lui donne une fenêtre nominale de 1,6 seconde pendant laquelle il est seul à décider quelles transactions entrent dans les blocs, dans quel ordre, et lesquelles attendent. À 200 ms, cette fenêtre tombe à 800 millisecondes. La proposition en fait un argument central : le pire délai qu'un leader peut imposer avant que la main passe est divisé par deux. Une seconde proposition, distincte, vise à réduire le nombre de slots consécutifs attribués à un même leader. La fondation avance aussi que les époques deviendront plus courtes, ce qui rapprochera le versement des récompenses aux validateurs, et que les teneurs de marché pourront resserrer leurs écarts de cotation. Ces effets relèvent pour l'instant de sa communication, pas d'une mesure sur le réseau.
Que reprochent certains développeurs à la proposition ?
La revue publique de SIMD-0525 n'a pas été unanime. Le contributeur t-nelson, membre de l'équipe Anza habilitée à approuver la proposition, s'est dit d'accord sur la direction mais opposé à la méthode, estimant qu'aucune urgence ne justifie de prendre des raccourcis liés à la dette technique d'Agave et demandant un nettoyage du code au préalable. Son autre réserve porte sur la fenêtre du leader, maintenue à quatre slots plutôt qu'à une durée fixe. Les incidents imprévus surviennent selon lui aux slots de frontière entre deux leaders, et une fenêtre plus longue en offre davantage à sacrifier. L'auteur de la proposition, bw-solana, a répondu en s'appuyant sur une expérimentation à 200 ms menée sur le réseau principal : le nombre de transactions hors vote par slot y dépasse la moitié du volume habituel, avec des latences de vote correctes mais moins bonnes que sur le reste du réseau. Un développeur de l'équipe Firedancer, ripatel-fd, a de son côté demandé que la proposition livre directement les vecteurs de test et les fixtures, plutôt qu'une section listant les comportements à vérifier. La discussion sur ce point était encore ouverte début mai.
