{"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-06-25T13:46:13","modified_gmt":"2026-06-25T13:46:13","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":"\r\n

Le soir du 18 avril, le cluster mainnet-beta de Solana a franchi le seuil de participation pour le client v1.18.15<\/a> sans grand bruit ni article d’annonce. D\u00e8s le matin suivant, les validateurs ex\u00e9cutant Jito-Solana<\/a> signalait des temps de confirmation optimiste m\u00e9dians autour de 240 ms, en baisse de la bande 460\u2013500 ms qui avait d\u00e9fini Solana pendant la majeure partie de 2025. Ce changement r\u00e9sulte de la fusion cumulative de trois propositions : SIMD-0123 sur la distribution des r\u00e9compenses de bloc, SIMD-0096 sur le traitement des frais de priorit\u00e9, et un ensemble plus discret de correctifs relatifs \u00e0 la comptabilit\u00e9 des cr\u00e9dits de vote TowerBFT, d\u00e9ploy\u00e9s sous une seule porte de fonctionnalit\u00e9. Aucun \u00e9v\u00e9nement de lancement n’a \u00e9t\u00e9 organis\u00e9. Le cluster est simplement devenu plus rapide.<\/p>\r\n\r\n\r\n\r\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 de moiti\u00e9 de la fen\u00eatre de confirmation optimiste modifie l’\u00e9conomie du market-making. Pour les portefeuilles, cela change la promesse UX. Et pour l’\u00e9conomie des validateurs, cela red\u00e9finit qui gagne quoi pendant les p\u00e9riodes de congestion. Le chiffre cl\u00e9, 240 ms, 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>\r\n\r\n\r\n\r\n

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

Avant v1.18, les clients Solana exposaient 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>\r\n\r\n\r\n\r\n

La ligne v1.18 n’a pas modifi\u00e9 l’architecture de ces chemins. Elle a chang\u00e9 la contention autour de eux. Les transactions de vote sur Solana partagent le m\u00eame planificateur que les transactions utilisateurs, et sur un bloc congestionn\u00e9, le leader a historiquement d\u00fb faire des choix difficiles quant aux votes \u00e0 inclure. Des votes tardifs entra\u00eenent une confirmation optimiste retard\u00e9e. Les modifications SIMD-0123, fusionn\u00e9es dans le comportement du cluster au slot 261 498 112, font passer l’inclusion des votes avant les transactions de frais de priorit\u00e9 dans la file du planificateur et r\u00e9servent une part fixe de calcul de bloc pour elles. L’effet, observable sur les tableaux Dune<\/a> dans 48 heures, fut que la variance de la latence de confirmation optimiste s’est \u00e9cras\u00e9e.<\/p>\r\n\r\n\r\n\r\n

Les chiffres, avant et apr\u00e8s<\/h2>\r\n\r\n\r\n\r\n
M\u00e9trique<\/th>v1.17.31 (mars 2026)<\/th>v1.18.15 (mai 2026)<\/th>Changement<\/th><\/tr><\/thead>
Confirmation optimiste, p50<\/td>478 ms<\/td>241 ms<\/td>−49,6%<\/td><\/tr>
Confirmation optimiste, p99<\/td>1 840 ms<\/td>612 ms<\/td>−66,7%<\/td><\/tr>
Ancr\u00e9e (finalis\u00e9e), p50<\/td>12,8 s<\/td>12,6 s<\/td>stable<\/td><\/tr>
Taux d’inclusion vote-tx par slot<\/td>71%<\/td>96%<\/td>+25 pp<\/td><\/tr>
Taux de slots ignor\u00e9s, 7 jours<\/td>4,8%<\/td>3,1%<\/td>−1,7 pp<\/td><\/tr><\/tbody><\/table>
Mesures m\u00e9dianes sur un \u00e9chantillon de 200 validateurs mainnet-beta, fen\u00eatres hebdomadaires. Sources : m\u00e9triques de cluster solana.com, t\u00e9l\u00e9m\u00e9trie jito.network.<\/figcaption><\/figure>\r\n\r\n\r\n\r\n

Les deux chiffres qui comptent sont l’\u00e9crasement du p99 et la finalit\u00e9 stable. Le chiffre p99 indique ce que les 1 % d’utilisateurs les moins bien servis exp\u00e9rimentent \u2014 le trader ayant cliqu\u00e9 sur \u00ab confirmer \u00bb exactement au moment o\u00f9 un lancement Pump.fun a satur\u00e9 la file du leader. R\u00e9duire ce d\u00e9lai de 1,8 seconde \u00e0 moins de 700 ms \u00e9limine la cat\u00e9gorie la plus grave de d\u00e9faillance UX sur le r\u00e9seau. Le chiffre de finalit\u00e9 stable est la rassurance : rien n’a chang\u00e9 dans le mod\u00e8le de s\u00e9curit\u00e9. La confirmation ancr\u00e9e reste toujours conditionn\u00e9e par la m\u00eame discipline de lockout de 32 slots utilis\u00e9e par TowerBFT depuis 2020. Solana est devenu plus rapide en surface et est rest\u00e9 identique au c\u0153ur.<\/p>\r\n\r\n\r\n\r\n

SIMD-0123 et la r\u00e9\u00e9criture du planificateur<\/h2>\r\n\r\n\r\n\r\n

SIMD-0123 a \u00e9t\u00e9 r\u00e9dig\u00e9 par des ing\u00e9nieurs principaux d’Anza, le team qui s’est fork\u00e9 de Solana Labs en 2024, avec l’examen du team Jito. La proposition figure dans le r\u00e9pertoire solana-improvement-documents<\/a> comme une sp\u00e9cification de 14 pages et contient deux id\u00e9es structurellement distinctes. La premi\u00e8re est une priorit\u00e9 d\u00e9terministe pour les votes de consensus dans le planificateur de la phase bancaire. Les votes sont \u00e9tiquet\u00e9s avec un type de transaction distinct et rout\u00e9s via un pipeline parall\u00e8le ; les transactions utilisateurs ne peuvent plus les \u00e9vincer. La seconde est une redistribution des r\u00e9compenses : une partie des frais de priorit\u00e9 qui auparavant s’accumulaient exclusivement au leader du bloc est maintenant redistribu\u00e9e \u00e0 l’ensemble actif des votes, pond\u00e9r\u00e9e par le retard \u00e9vit\u00e9 par chaque validateur.<\/p>\r\n\r\n\r\n\r\n

Cette seconde partie est la plus politiquement int\u00e9ressante. Les validateurs Solana ont d\u00e9battu pendant deux ans de la capture de MEV et du r\u00f4le du client d’ench\u00e8re de Jito<\/a>, qui op\u00e8re d\u00e9sormais sur environ 92 % du stake. SIMD-0123 n’abolit pas l’ench\u00e8re. Il modifie l’incitation : les leaders qui retardent l’inclusion des votes pour maximiser leur propre prise de frais de priorit\u00e9 perdent d\u00e9sormais une part de ces frais au profit des validateurs ayant vot\u00e9 \u00e0 temps. En effet, Solana a introduit une p\u00e9nalit\u00e9 douce pour un leadership \u00e9go\u00efste sans toucher aux r\u00e8gles de consensus. 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, il s’est agi d’une porte de fonctionnalit\u00e9 activ\u00e9e un jeudi.<\/p>\r\n\r\n\r\n\r\n

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

Firedancer, la r\u00e9\u00e9criture C++ de Jump Crypto du client validateur, n’a pas particip\u00e9 \u00e0 cet upgrade. Son d\u00e9ploiement complet sur mainnet reste pr\u00e9vu pour la fin de 2026 avec Frankendancer \u2014 un client hybride ex\u00e9cutant le stack r\u00e9seau de Firedancer sur l’ex\u00e9cuteur Rust \u2014 vivant sur environ 4 % 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 planificateur 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>\r\n\r\n\r\n\r\n

La r\u00e9\u00e9criture du planificateur de votes d\u00e9ploy\u00e9e dans 1.18.15 s’inspire directement de l’architecture de la phase bancaire de Firedancer, o\u00f9 les pipelines de transactions votes et utilisateurs n’ont jamais \u00e9t\u00e9 coupl\u00e9s d\u00e8s le d\u00e9part. Anza a essentiellement r\u00e9import\u00e9 le design plus propre dans le client Rust, a pris le gain de latence 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>\r\n\r\n\r\n\r\n

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

R\u00e9duire de moiti\u00e9 la latence de confirmation optimiste 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 r\u00e9duire la marge de s\u00e9curit\u00e9 requise sur ces impressions d’oracles. Le team n’a pas encore publi\u00e9 un mod\u00e8le de risque actualis\u00e9, mais le r\u00e9pertoire Drift-protocol<\/a> pertinent montre des commits dans les deux derni\u00e8res semaines r\u00e9duisant le seuil de v\u00e9tust\u00e9 d’oracle par d\u00e9faut de 25 slots \u00e0 12. 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 deux fois plus souvent sans perdre de certitude positionnelle.<\/p>\r\n\r\n\r\n\r\n