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.
Le soir du 18 avril, le cluster mainnet-beta de Solana a franchi le seuil de participation pour le client v1.18.15 sans grand bruit ni article d’annonce. Dès le matin suivant, les validateurs exécutant Jito-Solana signalait des temps de confirmation optimiste médians autour de 240 ms, en baisse de la bande 460–500 ms qui avait défini Solana pendant la majeure partie de 2025. Ce changement résulte de la fusion cumulative de trois propositions : SIMD-0123 sur la distribution des récompenses de bloc, SIMD-0096 sur le traitement des frais de priorité, et un ensemble plus discret de correctifs relatifs à la comptabilité des crédits de vote TowerBFT, déployés sous une seule porte de fonctionnalité. 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 de moitié de la fenêtre de confirmation optimiste modifie l’économie du market-making. Pour les portefeuilles, cela change la promesse UX. Et pour l’économie des validateurs, cela redéfinit qui gagne quoi pendant les périodes de congestion. Le chiffre clé, 240 ms, 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
Avant v1.18, les clients Solana exposaient 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).
La ligne v1.18 n’a pas modifié l’architecture de ces chemins. Elle a changé la contention autour de eux. Les transactions de vote sur Solana partagent le même planificateur que les transactions utilisateurs, et sur un bloc congestionné, le leader a historiquement dû faire des choix difficiles quant aux votes à inclure. Des votes tardifs entraînent une confirmation optimiste retardée. Les modifications SIMD-0123, fusionnées dans le comportement du cluster au slot 261 498 112, font passer l’inclusion des votes avant les transactions de frais de priorité dans la file du planificateur et réservent une part fixe de calcul de bloc pour elles. L’effet, observable sur les tableaux Dune dans 48 heures, fut que la variance de la latence de confirmation optimiste s’est écrasée.
Les chiffres, avant et après
| Métrique | v1.17.31 (mars 2026) | v1.18.15 (mai 2026) | Changement |
|---|---|---|---|
| Confirmation optimiste, p50 | 478 ms | 241 ms | −49,6% |
| Confirmation optimiste, p99 | 1 840 ms | 612 ms | −66,7% |
| Ancrée (finalisée), p50 | 12,8 s | 12,6 s | stable |
| Taux d’inclusion vote-tx par slot | 71% | 96% | +25 pp |
| Taux de slots ignorés, 7 jours | 4,8% | 3,1% | −1,7 pp |
Les deux chiffres qui comptent sont l’écrasement du p99 et la finalité stable. Le chiffre p99 indique ce que les 1 % d’utilisateurs les moins bien servis expérimentent — le trader ayant cliqué sur « confirmer » exactement au moment où un lancement Pump.fun a saturé la file du leader. Réduire ce délai de 1,8 seconde à moins de 700 ms élimine la catégorie la plus grave de défaillance UX sur le réseau. Le chiffre de finalité stable est la rassurance : rien n’a changé dans le modèle de sécurité. La confirmation ancrée reste toujours conditionnée par la même discipline de lockout de 32 slots utilisée par TowerBFT depuis 2020. Solana est devenu plus rapide en surface et est resté identique au cœur.
SIMD-0123 et la réécriture du planificateur
SIMD-0123 a été rédigé par des ingénieurs principaux d’Anza, le team qui s’est forké de Solana Labs en 2024, avec l’examen du team Jito. La proposition figure dans le répertoire solana-improvement-documents comme une spécification de 14 pages et contient deux idées structurellement distinctes. La première est une priorité déterministe pour les votes de consensus dans le planificateur de la phase bancaire. Les votes sont étiquetés avec un type de transaction distinct et routés via un pipeline parallèle ; les transactions utilisateurs ne peuvent plus les évincer. La seconde est une redistribution des récompenses : une partie des frais de priorité qui auparavant s’accumulaient exclusivement au leader du bloc est maintenant redistribuée à l’ensemble actif des votes, pondérée par le retard évité par chaque validateur.
Cette seconde partie est la plus politiquement intéressante. Les validateurs Solana ont débattu pendant deux ans de la capture de MEV et du rôle du client d’enchère de Jito, qui opère désormais sur environ 92 % du stake. SIMD-0123 n’abolit pas l’enchère. Il modifie l’incitation : les leaders qui retardent l’inclusion des votes pour maximiser leur propre prise de frais de priorité perdent désormais une part de ces frais au profit des validateurs ayant voté à temps. En effet, Solana a introduit une pénalité douce pour un leadership égoïste sans toucher aux règles de consensus. 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, il s’est agi d’une porte de fonctionnalité activée un jeudi.
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 participé à cet upgrade. Son déploiement complet sur mainnet reste prévu pour la fin de 2026 avec Frankendancer — un client hybride exécutant le stack réseau de Firedancer sur l’exécuteur Rust — vivant sur environ 4 % 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 planificateur 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éécriture du planificateur de votes déployée dans 1.18.15 s’inspire directement de l’architecture de la phase bancaire de Firedancer, où les pipelines de transactions votes et utilisateurs n’ont jamais été couplés dès le départ. Anza a essentiellement réimporté le design plus propre dans le client Rust, a pris le gain de latence 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 de moitié la latence de confirmation optimiste 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 réduire la marge de sécurité requise sur ces impressions d’oracles. Le team n’a pas encore publié un modèle de risque actualisé, mais le répertoire Drift-protocol pertinent montre des commits dans les deux dernières semaines réduisant le seuil de vétusté d’oracle par défaut de 25 slots à 12. 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 deux fois plus souvent sans perdre de certitude positionnelle.
- UX portefeuille : Phantom et Solflare affichent désormais « confirmé » dans environ 250 ms après la soumission pour la transaction médiane.
- Économie des ponts : le set de gardiens de Wormhole interroge les slots finalisés, pas les confirmations optimistes, donc la finalité cross-chain reste inchangée à ~14 s.
- 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.
- Infrastructure des bots de trading : les searchers exécutant les flux gRPC Helius ou Triton voient désormais une distribution de latence plus plate, réduisant la valeur des machines co-localisées.
La partie que les supports marketing laisseront hors
Il y a un coût. Réserver du calcul de bloc pour les votes signifie qu’il y en a moins disponible pour tout le reste sous charge de pointe. Lors du lancement du token FORM le 22 avril — le premier événement majeur de congestion après l’arrivée de l’upgrade — les taux de mise en place des transactions utilisateurs ont chuté à environ 38 % pendant les 90 premières secondes du lancement, contre un chiffre historique comparable de 52 % lors du lancement GOAT à la fin de 2025. La priorité déterministe des votes fonctionne exactement comme prévu : lorsque le réseau est saturé, les votes passent et les transactions utilisateurs attendent. Ce compromis était le point implicite de SIMD-0123, et il n’est pas unanimement bon pour tout le monde.
La autre conséquence discrète concerne le classement des récompenses des validateurs. La clause de redistribution a déplacé environ 0,4 % des revenus de frais hebdomadaires des leaders du décile supérieur (largement alignés sur Jito, largement exécutant des forks optimisés de la phase bancaire) vers le validateur médian. C’est un petit nombre en termes absolus et un nombre structurel en termes relatifs : c’est la première fois que le protocole Solana utilise son propre mécanisme de récompense pour pénaliser un comportement qui était auparavant simplement désapprouvé. Nous prévoyons que la prochaine série de SIMDs — la liste publique des drafts contient maintenant onze propositions en discussion active — prolongera ce schéma. 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 deux prochains epochs. Le premier est de savoir si v1.18.15 maintient ses chiffres de latence face à un événement de congestion soutenu de plus de deux heures ; le lancement FORM était un pic bref, pas un test de stress. Le second est le draft SIMD-0156, qui propose d’étendre l’idée de priorité du planificateur de votes aux transactions de mise à jour d’oracle provenant des programmes Pyth et Switchboard — une dérogation beaucoup plus grande et politiquement chargée. 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.