L’upgrade du mainnet de Solana a discrètement réduit de moitié la latence de confirmation
L’upgrade du cluster v1.18.x de Solana et les modifications de récompense SIMD-0123 ont réduit la latence médiane de confirmation optimiste d’environ 480 ms à 240 ms. Voici ce qui a changé sous le capot.
Mise à jour — 8 octobre 2026. La baisse de latence décrite ici est portée par la réduction progressive du temps de slot de Solana (SIMD-0525), qui vise à faire passer le temps de slot de 400 ms à 200 ms en quatre décréments de 50 ms (400 → 350 → 300 → 250 → 200 ms). Le 27 août 2026, le journal des modifications confirmait qu’une porte de fonctionnalité ramenant le temps de slot à 300 ms avait atteint le mainnet ; le 18 septembre 2026, à l’epoch 1037, le réseau est passé à 250 ms, contre 300 ms auparavant. Les trois premières réductions sont désormais actives sur le mainnet, et la réduction finale à 200 ms est programmée pour l’epoch 1052. Le rapport de Galaxy du 6 octobre 2026 estime que ce changement devrait réduire de moitié la latence de confirmation.
Au cours de l’année 2026, le cluster mainnet-beta de Solana a réduit son temps de slot par étapes successives, sans grand bruit ni article d’annonce. Le changement est déployé sous une seule famille de portes de fonctionnalité, SIMD-0525, et procède en quatre décréments de 50 ms : 400 → 350 → 300 → 250 → 200 ms. Les validateurs exécutant Jito-Solana ont vu les temps de confirmation se resserrer à chaque étape, en baisse de la bande qui avait défini Solana pendant la majeure partie de 2025. Aucun événement de lancement n’a été organisé. Le cluster est simplement devenu plus rapide.
La question en jeu concerne la partie de Solana que la plupart des utilisateurs ressentent réellement : non pas le débit théorique, mais l’écart perçu entre le clic sur un swap sur Jupiter et sa confirmation. Pour les plateformes DeFi opérant sur le réseau — perps sur Drift, carnet d’ordres sur Phoenix, vaults de produits structurés sur Adrastea — la réduction du temps de slot modifie l’économie du market-making. Pour les portefeuilles, cela change la promesse UX. Et pour l’économie des validateurs, cela redéfinit la cadence du réseau pendant les périodes de congestion. Le chiffre clé — un temps de slot de 250 ms aujourd’hui, en route vers 200 ms à l’epoch 1052 — est l’élément le plus important de l’actualité infrastructurelle de Solana du trimestre, et presque personne, hors le Discord des validateurs, n’y a pris note.
Deux confirmations, un seul cluster : pourquoi le chemin est important
Les clients Solana exposent deux chemins de confirmation distincts. Le premier, la « confirmation optimiste », se déclenche lorsque une supermajorité de crédits de vote pondérés par le stake s’aligne sur un fork particulier dans le calendrier de lockout TowerBFT. Le second, la « confirmation ancrée » (rooted), se déclenche uniquement lorsque ce fork est d’au moins 32 slots profond et finalisé via le pipeline de consensus. La latence optimiste est celle affichée aux utilisateurs par les portefeuilles ; la latence ancrée est celle attendue par les ponts et les échanges. La documentation sur le consensus décrit les deux, mais l’asymétrie pratique — l’optimiste est rapide et probabiliste, l’ancrée est lente et finale — a toujours été le compromis UX central de Solana (avec l’AMF, Autorité des Marchés Financiers, comme contrepartie locale aux régulateurs génériques).
SIMD-0525 ne modifie pas l’architecture de ces chemins. Il change la cadence à laquelle ils se déroulent. Comme chaque confirmation dépend du nombre de slots écoulés — la confirmation optimiste suit l’alignement des votes slot après slot, l’ancrée exige 32 slots de profondeur — raccourcir le temps de slot compresse mécaniquement les deux fenêtres en temps réel. Un slot plus court signifie que les leaders se succèdent plus souvent, que les votes de consensus s’accumulent plus vite et que la même profondeur de lockout se traduit par moins de millisecondes attendues. La page des mises à niveau de Solana décrit le plan : faire passer le temps de slot de 400 ms à 200 ms par étapes, la réduction finale à 200 ms étant programmée pour l’epoch 1052. L’effet, observable sur les tableaux Dune après chaque étape, est que la latence de confirmation perçue s’est resserrée à mesure que le temps de slot descendait.
Les chiffres, avant et après
| Étape | Temps de slot cible | Statut (octobre 2026) |
|---|---|---|
| 400 → 350 ms | 350 ms | Actif sur mainnet |
| 350 → 300 ms | 300 ms | Actif sur mainnet (changelog du 27 août 2026) |
| 300 → 250 ms | 250 ms | Actif depuis le 18 septembre 2026 (epoch 1037) |
| 250 → 200 ms | 200 ms | Programmé pour l’epoch 1052 |
Les deux éléments qui comptent sont la progression régulière et la finalité inchangée. Trois des quatre réductions étagées sont désormais actives sur le mainnet, et la page d’état du déploiement indique que les utilisateurs devraient bénéficier de temps de confirmation plus rapides en conséquence. Le modèle de sécurité, lui, n’a pas bougé : la confirmation ancrée reste conditionnée par la même discipline de lockout de 32 slots utilisée par TowerBFT depuis 2020 — ce sont les millisecondes par slot qui diminuent, pas le nombre de slots requis. Solana est devenu plus rapide en surface et est resté identique au cœur. Le rapport de Galaxy du 6 octobre 2026 résume l’attendu : une fois le palier de 200 ms atteint, la latence de confirmation devrait être réduite de moitié par rapport au point de départ de 400 ms.
SIMD-0525 et la réduction progressive du temps de slot
SIMD-0525 figure dans le répertoire solana-improvement-documents et encadre une idée simple à énoncer mais délicate à livrer : raccourcir le temps de slot cible du cluster de 400 ms à 200 ms. Plutôt que de basculer le réseau d’un coup, le changement procède en quatre décréments de 50 ms, chacun activé par une porte de fonctionnalité distincte afin que les opérateurs puissent observer l’effet sur la propagation des blocs et le taux de slots ignorés avant de passer à l’étape suivante. Le journal des modifications du 27 août 2026 a confirmé que la porte ramenant le temps de slot à 300 ms avait atteint le mainnet ; la réduction à 250 ms a suivi le 18 septembre 2026 à l’epoch 1037.
La partie la plus exigeante est opérationnelle plutôt que théorique. Un temps de slot plus court impose plus de blocs par unité de temps, donc plus de bande passante de propagation, plus de messages de vote et moins de marge pour les validateurs dont le matériel ou la connectivité sont à la traîne. C’est pourquoi le déploiement est étagé : chaque décrément est un test grandeur nature de la capacité du set actif — une large majorité du stake exécutant des forks optimisés du client — à suivre la cadence sans voir grimper le taux de slots ignorés. C’est le type de changement qui aurait nécessité un hard fork sur Ethereum et un débat de six mois entre tous les développeurs principaux ; sur Solana, chaque palier s’est agi d’une porte de fonctionnalité activée epoch après epoch.
Pourquoi le team Firedancer a été important, même s’ils n’ont pas livré
Firedancer, la réécriture C++ de Jump Crypto du client validateur, n’a pas porté ce déploiement. Son déploiement complet sur mainnet reste attendu, avec Frankendancer — un client hybride exécutant le stack réseau de Firedancer sur l’exécuteur Rust — vivant sur une fraction minoritaire du stake. Mais l’existence de Firedancer a changé ce qui était politiquement possible dans le client Rust. Les ingénieurs d’Anza ont parlé lors des conférences Breakpoint de la pression qu’un second client haute performance exerce sur l’implémentation de référence : les décisions de performance qui étaient auparavant défendues comme « la seule façon que Rust peut suivre » deviennent plus difficiles à justifier quand un codebase C++ parallèle benchmark plus vite.
La réduction du temps de slot déployée sous SIMD-0525 s’appuie directement sur les gains de propagation et de pipeline que la concurrence entre clients a rendus crédibles : raccourcir le slot n’a de sens que si le stack réseau tient la cadence plus serrée, et c’est précisément le terrain sur lequel Firedancer a poussé. Anza a essentiellement pris le gain de latence au niveau du temps de slot et réduit l’écart que Firedancer devait ouvrir. Si cela retarde la proposition de valeur de Firedancer est maintenant un sujet de débat discret parmi les opérateurs de validateurs que nous avons interrogés pour cet article, aucun n’ayant voulu parler publiquement. La dynamique concurrentielle entre deux clients de production produit néanmoins un réseau plus rapide pour les utilisateurs finaux.
Ce que cela change pour les plateformes DeFi
Réduire le temps de slot ne fait pas juste mieux ressentir. Cela modifie les paramètres que les market-makers intègrent dans leurs cotes. Une plateforme de perpétuels comme Drift, qui dépend de la mise à jour des oracles dans un intervalle étroit avant le déclenchement des liquidations, peut désormais resserrer la marge de sécurité qu’elle applique sur ces impressions d’oracles, puisque la même profondeur en slots s’écoule en moins de temps. Le team n’a pas encore publié un modèle de risque actualisé, mais le répertoire Drift-protocol pertinent montre un travail en cours sur les seuils de vétusté d’oracle à mesure que le temps de slot diminue. Le CLOB de Phoenix, qui croise les ordres dans un seul slot lorsque les deux côtés arrivent dans la même phase bancaire, voit des spreads plus faibles car ses makers peuvent rafraîchir leurs cotes plus souvent sans perdre de certitude positionnelle.
- UX portefeuille : Phantom et Solflare affichent désormais « confirmé » plus rapidement qu’auparavant pour la transaction médiane, le temps de slot étant passé à 250 ms.
- Économie des ponts : le set de gardiens de Wormhole interroge les slots finalisés, pas les confirmations optimistes ; la finalité cross-chain se resserre parce que les 32 slots s’écoulent en moins de temps réel, sans changement du modèle de sécurité.
- Staking liquide : les limites d’epoch des pools de stake de Marinade et Jito voient une comptabilité de déblocage plus serrée car les crédits de vote s’accumulent plus prédictiblement à cadence plus rapide.
- Infrastructure des bots de trading : les searchers exécutant les flux gRPC Helius ou Triton voient une distribution de latence plus plate à chaque réduction de slot, réduisant la valeur des machines co-localisées.
La partie que les supports marketing laisseront hors
Il y a un coût. Doubler le nombre de blocs par seconde signifie doubler le volume de propagation, de messages de vote et de travail de planification que chaque validateur doit absorber. C’est précisément pour cette raison que la réduction est étagée en quatre paliers plutôt qu’appliquée d’un coup : chaque décrément de 50 ms est un test de résistance de la capacité du réseau à conserver un taux de slots ignorés bas lorsque le matériel le plus faible du set actif est poussé plus fort. Sous charge de pointe — un lancement de token saturant la file du leader — un temps de slot plus court laisse moins de marge d’absorption par bloc, et le risque est reporté sur les validateurs les moins performants plutôt que supprimé. Ce compromis est le point implicite de SIMD-0525, et il n’est pas unanimement bon pour tout le monde.
La autre conséquence discrète concerne la répartition des opérateurs capables de suivre. Chaque palier resserre la tolérance du réseau aux validateurs sous-dimensionnés : ceux dont la connectivité ou le CPU peinait déjà à 400 ms verront leur taux de slots ignorés grimper plus vite à 250 ms, et plus encore à 200 ms. C’est la première fois depuis longtemps que Solana utilise sa propre cadence de production de blocs comme un filtre de facto sur la qualité des opérateurs. Nous prévoyons que la prochaine série de SIMDs prolongera ce schéma, en cherchant à récupérer la marge que des slots plus courts consomment. Pour plus de contexte sur comment l’économie des validateurs évolue entre les cycles, notre tableau de marché suit la courbe de rendement pondérée par le stake chaque semaine.
À surveiller prochainement
Trois éléments valent d’être suivis sur les prochains epochs. Le premier est de savoir si le palier de 250 ms, actif depuis le 18 septembre 2026, maintient son taux de slots ignorés face à un événement de congestion soutenu de plus de deux heures, et non pas seulement lors de pics brefs. Le second est la dernière étape du déploiement — la réduction à 200 ms programmée pour l’epoch 1052 — qui doublera le nombre de blocs par seconde par rapport au point de départ de 400 ms et constituera le vrai test de résistance de SIMD-0525. Le troisième est la roadmap mainnet de Firedancer, maintenant que l’écart entre lui et le client de référence s’est réduit. La culture ingénieriale de Solana a toujours été prête à déployer rapidement des changements difficiles ; cet upgrade rappelle que la roadmap du réseau est encore définie par ce que ses teams principaux peuvent fusionner, pas par ce que son département marketing annonce. Pour les traders surveillant l’impact sur la liquidité, notre tracker de frais de priorité se actualise chaque slot, et la prochaine conférence développeur Anza est sur notre calendrier d’événements.