{"id":41,"date":"2026-06-25T13:46:13","date_gmt":"2026-06-25T13:46:13","guid":{"rendered":"https:\/\/hoge.gg\/fr\/solanas-mainnet-upgrade-quietly-halved-confirmation-latency\/"},"modified":"2026-10-08T03:32:55","modified_gmt":"2026-10-08T03:32:55","slug":"solanas-mainnet-upgrade-quietly-halved-confirmation-latency","status":"publish","type":"post","link":"https:\/\/hoge.gg\/fr\/solanas-mainnet-upgrade-quietly-halved-confirmation-latency\/","title":{"rendered":"L\u2019upgrade du mainnet de Solana a discr\u00e8tement r\u00e9duit de moiti\u00e9 la latence de confirmation"},"content":{"rendered":"\n

Mise \u00e0 jour \u2014 8 octobre 2026.<\/strong> La baisse de latence d\u00e9crite ici est port\u00e9e par la r\u00e9duction progressive du temps de slot de Solana (SIMD-0525), qui vise \u00e0 faire passer le temps de slot de 400 ms \u00e0 200 ms en quatre d\u00e9cr\u00e9ments de 50 ms (400 \u2192 350 \u2192 300 \u2192 250 \u2192 200 ms). Le 27 ao\u00fbt 2026, le journal des modifications confirmait qu’une porte de fonctionnalit\u00e9 ramenant le temps de slot \u00e0 300 ms avait atteint le mainnet ; le 18 septembre 2026, \u00e0 l’epoch 1037, le r\u00e9seau est pass\u00e9 \u00e0 250 ms, contre 300 ms auparavant. Les trois premi\u00e8res r\u00e9ductions sont d\u00e9sormais actives sur le mainnet, et la r\u00e9duction finale \u00e0 200 ms est programm\u00e9e pour l’epoch 1052. Le rapport de Galaxy du 6 octobre 2026 estime que ce changement devrait r\u00e9duire de moiti\u00e9 la latence de confirmation.<\/p><\/blockquote>\n\n\n\n

Au cours de l’ann\u00e9e 2026, le cluster mainnet-beta de Solana a r\u00e9duit son temps de slot par \u00e9tapes successives, sans grand bruit ni article d’annonce. Le changement est d\u00e9ploy\u00e9 sous une seule famille de portes de fonctionnalit\u00e9, SIMD-0525<\/a>, et proc\u00e8de en quatre d\u00e9cr\u00e9ments de 50 ms : 400 \u2192 350 \u2192 300 \u2192 250 \u2192 200 ms. Les validateurs ex\u00e9cutant Jito-Solana<\/a> ont vu les temps de confirmation se resserrer \u00e0 chaque \u00e9tape, en baisse de la bande qui avait d\u00e9fini Solana pendant la majeure partie de 2025. Aucun \u00e9v\u00e9nement de lancement n’a \u00e9t\u00e9 organis\u00e9. Le cluster est simplement devenu plus rapide.<\/p>\n\n\n\n

La question en jeu concerne la partie de Solana que la plupart des utilisateurs ressentent r\u00e9ellement : non pas le d\u00e9bit th\u00e9orique, mais l’\u00e9cart per\u00e7u entre le clic sur un swap sur Jupiter et sa confirmation. Pour les plateformes DeFi op\u00e9rant sur le r\u00e9seau \u2014 perps sur Drift, carnet d’ordres sur Phoenix, vaults de produits structur\u00e9s sur Adrastea \u2014 la r\u00e9duction du temps de slot modifie l’\u00e9conomie du market-making. Pour les portefeuilles, cela change la promesse UX. Et pour l’\u00e9conomie des validateurs, cela red\u00e9finit la cadence du r\u00e9seau pendant les p\u00e9riodes de congestion. Le chiffre cl\u00e9 \u2014 un temps de slot de 250 ms aujourd’hui, en route vers 200 ms \u00e0 l’epoch 1052 \u2014 est l’\u00e9l\u00e9ment le plus important de l’actualit\u00e9 infrastructurelle de Solana du trimestre, et presque personne, hors le Discord des validateurs, n’y a pris note.<\/p>\n\n\n\n

Deux confirmations, un seul cluster : pourquoi le chemin est important<\/h2>\n\n\n\n

Les clients Solana exposent deux chemins de confirmation distincts. Le premier, la \u00ab confirmation optimiste \u00bb, se d\u00e9clenche lorsque une supermajorit\u00e9 de cr\u00e9dits de vote pond\u00e9r\u00e9s par le stake s’aligne sur un fork particulier dans le calendrier de lockout TowerBFT. Le second, la \u00ab confirmation ancr\u00e9e \u00bb (rooted), se d\u00e9clenche uniquement lorsque ce fork est d’au moins 32 slots profond et finalis\u00e9 via le pipeline de consensus. La latence optimiste est celle affich\u00e9e aux utilisateurs par les portefeuilles ; la latence ancr\u00e9e est celle attendue par les ponts et les \u00e9changes. La documentation sur le consensus<\/a> d\u00e9crit les deux, mais l’asym\u00e9trie pratique \u2014 l’optimiste est rapide et probabiliste, l’ancr\u00e9e est lente et finale \u2014 a toujours \u00e9t\u00e9 le compromis UX central de Solana (avec l’AMF, Autorit\u00e9 des March\u00e9s Financiers, comme contrepartie locale aux r\u00e9gulateurs g\u00e9n\u00e9riques).<\/p>\n\n\n\n

SIMD-0525 ne modifie pas l’architecture de ces chemins. Il change la cadence \u00e0 laquelle ils se d\u00e9roulent. Comme chaque confirmation d\u00e9pend du nombre de slots \u00e9coul\u00e9s \u2014 la confirmation optimiste suit l’alignement des votes slot apr\u00e8s slot, l’ancr\u00e9e exige 32 slots de profondeur \u2014 raccourcir le temps de slot compresse m\u00e9caniquement les deux fen\u00eatres en temps r\u00e9el. Un slot plus court signifie que les leaders se succ\u00e8dent plus souvent, que les votes de consensus s’accumulent plus vite et que la m\u00eame profondeur de lockout se traduit par moins de millisecondes attendues. La page des mises \u00e0 niveau de Solana<\/a> d\u00e9crit le plan : faire passer le temps de slot de 400 ms \u00e0 200 ms par \u00e9tapes, la r\u00e9duction finale \u00e0 200 ms \u00e9tant programm\u00e9e pour l’epoch 1052. L’effet, observable sur les tableaux Dune<\/a> apr\u00e8s chaque \u00e9tape, est que la latence de confirmation per\u00e7ue s’est resserr\u00e9e \u00e0 mesure que le temps de slot descendait.<\/p>\n\n\n\n

Les chiffres, avant et apr\u00e8s<\/h2>\n\n\n\n
\u00c9tape<\/th>Temps de slot cible<\/th>Statut (octobre 2026)<\/th><\/tr><\/thead>
400 \u2192 350 ms<\/td>350 ms<\/td>Actif sur mainnet<\/td><\/tr>
350 \u2192 300 ms<\/td>300 ms<\/td>Actif sur mainnet (changelog du 27 ao\u00fbt 2026)<\/td><\/tr>
300 \u2192 250 ms<\/td>250 ms<\/td>Actif depuis le 18 septembre 2026 (epoch 1037)<\/td><\/tr>
250 \u2192 200 ms<\/td>200 ms<\/td>Programm\u00e9 pour l’epoch 1052<\/td><\/tr><\/tbody><\/table>
D\u00e9ploiement progressif du temps de slot sous SIMD-0525, quatre d\u00e9cr\u00e9ments de 50 ms. Sources : page des mises \u00e0 niveau et page d’\u00e9tat du d\u00e9ploiement de solana.com, journal des modifications du client, rapport Galaxy du 6 octobre 2026.<\/figcaption><\/figure>\n\n\n\n

Les deux \u00e9l\u00e9ments qui comptent sont la progression r\u00e9guli\u00e8re et la finalit\u00e9 inchang\u00e9e. Trois des quatre r\u00e9ductions \u00e9tag\u00e9es sont d\u00e9sormais actives sur le mainnet, et la page d’\u00e9tat du d\u00e9ploiement indique que les utilisateurs devraient b\u00e9n\u00e9ficier de temps de confirmation plus rapides en cons\u00e9quence. Le mod\u00e8le de s\u00e9curit\u00e9, lui, n’a pas boug\u00e9 : la confirmation ancr\u00e9e reste conditionn\u00e9e par la m\u00eame discipline de lockout de 32 slots utilis\u00e9e par TowerBFT depuis 2020 \u2014 ce sont les millisecondes par slot qui diminuent, pas le nombre de slots requis. Solana est devenu plus rapide en surface et est rest\u00e9 identique au c\u0153ur. Le rapport de Galaxy du 6 octobre 2026 r\u00e9sume l’attendu : une fois le palier de 200 ms atteint, la latence de confirmation devrait \u00eatre r\u00e9duite de moiti\u00e9 par rapport au point de d\u00e9part de 400 ms.<\/p>\n\n\n\n

SIMD-0525 et la r\u00e9duction progressive du temps de slot<\/h2>\n\n\n\n

SIMD-0525 figure dans le r\u00e9pertoire solana-improvement-documents<\/a> et encadre une id\u00e9e simple \u00e0 \u00e9noncer mais d\u00e9licate \u00e0 livrer : raccourcir le temps de slot cible du cluster de 400 ms \u00e0 200 ms. Plut\u00f4t que de basculer le r\u00e9seau d’un coup, le changement proc\u00e8de en quatre d\u00e9cr\u00e9ments de 50 ms, chacun activ\u00e9 par une porte de fonctionnalit\u00e9 distincte afin que les op\u00e9rateurs puissent observer l’effet sur la propagation des blocs et le taux de slots ignor\u00e9s avant de passer \u00e0 l’\u00e9tape suivante. Le journal des modifications du 27 ao\u00fbt 2026 a confirm\u00e9 que la porte ramenant le temps de slot \u00e0 300 ms avait atteint le mainnet ; la r\u00e9duction \u00e0 250 ms a suivi le 18 septembre 2026 \u00e0 l’epoch 1037.<\/p>\n\n\n\n

La partie la plus exigeante est op\u00e9rationnelle plut\u00f4t que th\u00e9orique. Un temps de slot plus court impose plus de blocs par unit\u00e9 de temps, donc plus de bande passante de propagation, plus de messages de vote et moins de marge pour les validateurs dont le mat\u00e9riel ou la connectivit\u00e9 sont \u00e0 la tra\u00eene. C’est pourquoi le d\u00e9ploiement est \u00e9tag\u00e9 : chaque d\u00e9cr\u00e9ment est un test grandeur nature de la capacit\u00e9 du set actif \u2014 une large majorit\u00e9 du stake ex\u00e9cutant des forks optimis\u00e9s du client \u2014 \u00e0 suivre la cadence sans voir grimper le taux de slots ignor\u00e9s. C’est le type de changement qui aurait n\u00e9cessit\u00e9 un hard fork sur Ethereum et un d\u00e9bat de six mois entre tous les d\u00e9veloppeurs principaux ; sur Solana, chaque palier s’est agi d’une porte de fonctionnalit\u00e9 activ\u00e9e epoch apr\u00e8s epoch.<\/p>\n\n\n\n

Pourquoi le team Firedancer a \u00e9t\u00e9 important, m\u00eame s’ils n’ont pas livr\u00e9<\/h2>\n\n\n\n

Firedancer, la r\u00e9\u00e9criture C++ de Jump Crypto du client validateur, n’a pas port\u00e9 ce d\u00e9ploiement. Son d\u00e9ploiement complet sur mainnet reste attendu, avec Frankendancer \u2014 un client hybride ex\u00e9cutant le stack r\u00e9seau de Firedancer sur l’ex\u00e9cuteur Rust \u2014 vivant sur une fraction minoritaire du stake. Mais l’existence de Firedancer a chang\u00e9 ce qui \u00e9tait politiquement possible dans le client Rust. Les ing\u00e9nieurs d’Anza ont parl\u00e9 lors des conf\u00e9rences Breakpoint<\/a> de la pression qu’un second client haute performance exerce sur l’impl\u00e9mentation de r\u00e9f\u00e9rence : les d\u00e9cisions de performance qui \u00e9taient auparavant d\u00e9fendues comme \u00ab la seule fa\u00e7on que Rust peut suivre \u00bb deviennent plus difficiles \u00e0 justifier quand un codebase C++ parall\u00e8le benchmark plus vite.<\/p>\n\n\n\n

La r\u00e9duction du temps de slot d\u00e9ploy\u00e9e sous SIMD-0525 s’appuie directement sur les gains de propagation et de pipeline que la concurrence entre clients a rendus cr\u00e9dibles : raccourcir le slot n’a de sens que si le stack r\u00e9seau tient la cadence plus serr\u00e9e, et c’est pr\u00e9cis\u00e9ment le terrain sur lequel Firedancer a pouss\u00e9. Anza a essentiellement pris le gain de latence au niveau du temps de slot et r\u00e9duit l’\u00e9cart que Firedancer devait ouvrir. Si cela retarde la proposition de valeur de Firedancer est maintenant un sujet de d\u00e9bat discret parmi les op\u00e9rateurs de validateurs que nous avons interrog\u00e9s pour cet article, aucun n’ayant voulu parler publiquement. La dynamique concurrentielle entre deux clients de production produit n\u00e9anmoins un r\u00e9seau plus rapide pour les utilisateurs finaux.<\/p>\n\n\n\n

Ce que cela change pour les plateformes DeFi<\/h2>\n\n\n\n

R\u00e9duire le temps de slot ne fait pas juste mieux ressentir. Cela modifie les param\u00e8tres que les market-makers int\u00e8grent dans leurs cotes. Une plateforme de perp\u00e9tuels comme Drift, qui d\u00e9pend de la mise \u00e0 jour des oracles dans un intervalle \u00e9troit avant le d\u00e9clenchement des liquidations, peut d\u00e9sormais resserrer la marge de s\u00e9curit\u00e9 qu’elle applique sur ces impressions d’oracles, puisque la m\u00eame profondeur en slots s’\u00e9coule en moins de temps. Le team n’a pas encore publi\u00e9 un mod\u00e8le de risque actualis\u00e9, mais le r\u00e9pertoire Drift-protocol<\/a> pertinent montre un travail en cours sur les seuils de v\u00e9tust\u00e9 d’oracle \u00e0 mesure que le temps de slot diminue. Le CLOB de Phoenix, qui croise les ordres dans un seul slot lorsque les deux c\u00f4t\u00e9s arrivent dans la m\u00eame phase bancaire, voit des spreads plus faibles car ses makers peuvent rafra\u00eechir leurs cotes plus souvent sans perdre de certitude positionnelle.<\/p>\n\n\n\n