Environ 90 validateurs Solana détenant près de 29 % du SOL misé ont perdu leur connectivité lors de l'incident du 12 août, et les blocs ont mis jusqu'à environ 30 minutes à être finalisés, contre 13 secondes habituellement, selon l'analyse de l'incident par Metrika.

Pourtant, Solana n'est jamais tombé en panne. Les blocs ont continué d'être produits, et un graphique d'uptime pour cette journée aurait montré une session ordinaire. Mercredi 21 octobre, le réseau doit activer Alpenglow, une mise à niveau qui vise une finalité d'environ 150 millisecondes — mais rien dans celle-ci ne s'attaque au problème d'hébergement à l'origine de cette quasi-faute. Un rapport de recherche publié le 16 octobre par l'unité FCAT de Fidelity, The State of Solana: Network Health and Resilience, évalue le plus grand réseau d'hébergement à environ 29 % de la mise, proche de la part que Metrika a vue se déconnecter.

Que s'est-il passé le 12 août

Solana ne peut finaliser un bloc — le point à partir duquel une transaction devient irréversible — que tant que plus des deux tiers du SOL misé votent, un processus qui prend normalement environ 13 secondes. Le 12 août, avec environ 71 % de la mise encore en ligne, le réseau est resté au-dessus de cette ligne, mais de justesse. Metrika évalue la part hors ligne à 28,83 %, contre un seuil de 33,34 % auquel la finalisation s'arrête à l'échelle de la chaîne.

Graphique : part du SOL misé hors ligne le 12 août, comparée à la ligne d'arrêt de la finalité. Source : Metrika.

Selon Metrika, quatre à cinq points de pourcentage de mise supplémentaires sur les itinéraires touchés auraient signifié un arrêt à l'échelle du réseau nécessitant une récupération coordonnée. La panne a commencé dans l'installation de TeraSwitch à Miami et s'est propagée aux infrastructures de validateurs à Londres, Amsterdam, Francfort, Singapour et Tokyo, et dans la plupart des cas, les systèmes de secours des validateurs touchés ne se sont jamais activés.

TeraSwitch a corrigé la panne environ dix minutes après l'avoir diagnostiquée, et le trafic a repris à 04h16 UTC, 33 minutes après son début. Les validateurs se sont rétablis au cours des 40 minutes suivantes. Durant cette période, la part des emplacements planifiés ne produisant aucun bloc a bondi au-dessus de 32 %, contre moins de 1 %. Les transactions hors vote par seconde sont tombées d'environ 1 100–1 300 à moins de 300. Pendant environ une demi-heure, aucun bloc n'a été finalisé, et l'arrière a ensuite été résorbé en une rafale d'une durée moyenne d'environ 1 600 secondes entre la production et la finalité.

Le seul chiffre qui n'a pas bougé était l'uptime, resté à 100 % parce que la chaîne n'a jamais cessé de produire des blocs. Mais pendant environ une demi-heure, personne ne pouvait dire quand un paiement deviendrait irréversible. Metrika, qui vend une plateforme de gestion risques pour actifs numériques et s'appuie ici sur ses propres indicateurs, considère le retard de finalité — et non l'indisponibilité — comme l'événement qui compte pour quiconque règle des fonds sur Solana.

Ce qu'un arrêt de la chaîne signifierait — et ne signifierait pas

Le risque décrit par FCAT est une finalité bloquée et une possible censure. Une coalition détenant plus d'un tiers de la mise pourrait empêcher le reste d'atteindre les deux tiers nécessaires à la finalisation, indique le rapport, mais elle n'obtiendrait pas un contrôle illimité sur les actifs des utilisateurs ni la capacité de réécrire des transactions finalisées. Une panne d'hébergement éliminant la même part de mise arrêterait la finalité sans qu'aucune attaque n'ait lieu.

Cette part n'est pas difficile à atteindre. FCAT compte environ 20 identités de validateurs (18 dans un autre passage) détenant plus d'un tiers de la mise, et indique que ce tiers se situe dans deux pays, sur deux réseaux d'hébergement et deux implémentations de clients de base. Ce sont des comptes de vote, pas des organisations indépendantes : Figment, entre autres, exploite deux des cinq premiers validateurs de ce groupe. Le verdict global de FCAT est positif, citant plus de deux ans sans interruption majeure du mainnet, un taux de réussite des votes d'environ 99,7 % en 2026 et une pile logicielle qui se diversifie lentement. Il cite la concentration comme le point à continuer de surveiller. FCAT est l'unité de recherche en technologies appliquées de Fidelity et exploite son propre petit validateur Solana.

Deux mois plus tard, la part est toujours d'environ 29 %

Le cliché d'octobre de FCAT évalue le plus grand réseau d'hébergement à environ 29 % de la mise. Les deux chiffres mesurent des choses différentes — la mise hors ligne lors d'une panne et la part d'un réseau sur l'ensemble de la mise — mais ils convergent. FCAT indique que la Solana Foundation travaillait déjà à réduire la dominance de TeraSwitch. Voici comment ses chiffres se décomposent, des opérateurs de validateurs au code qu'ils exécutent :

• 18–20 opérateurs — identités de validateurs détenant plus d'un tiers de la mise. Ce sont des comptes de vote, pas des organisations indépendantes ; Figment exploite deux des cinq premiers du groupe.
• ~40 % localisation — part de la mise à Francfort et Amsterdam. Il s'agit d'une estimation par géolocalisation IP que FCAT juge potentiellement inexacte ; environ 59 % se situe en Allemagne, aux Pays-Bas et aux États-Unis.
• ~29 % fournisseur réseau — part de la mise sur un seul réseau d'hébergement, selon le cliché d'octobre. Des validateurs de villes différentes peuvent partager un fournisseur, et des validateurs d'une même ville peuvent en utiliser de différents.
• ~63 % logiciel — part de la mise exécutant un logiciel basé sur Jito au T3, contre 26 % sur Harmonic. La plupart des configurations partagent toujours le code Agave en dessous, si bien qu'un bug pourrait les toucher simultanément.

Source : FCAT, The State of Solana: Network Health and Resilience (octobre 2026).

Les validateurs se regroupent pour une raison. La latence récompense la proximité des autres nœuds, note FCAT, et des hébergeurs spécialisés comme TeraSwitch et Latitude conçoivent du matériel pour la charge de travail de Solana. Les opérateurs disposent de protections : bascules de secours, alimentation de secours et réseaux privés comme DoubleZero qui réduisent la dépendance à l'internet public. La Foundation a également mis en place un réseau de réponse aux incidents, SIRN, début 2026. Mais le 12 août, la plupart des solutions de secours ne se sont jamais activées.

La limite de la Foundation ne couvre qu'environ 4 % de la mise

Le me de délégation de la Solana Foundation fixe la règle principale. Depuis le 1er mai 2026, les validateurs souhaitant recevoir de la mise de la Foundation doivent se trouver sur un réseau d'hébergement sous un plafond de 25 % et dans un centre de données sous 15 %. Un validateur qui échoue perd sa délégation de la Foundation jusqu'à ce qu'il se conforme à nouveau.

Ces limites sont entrées en vigueur trois mois avant la panne d'août, et au cliché d'octobre de FCAT, le plus grand réseau était toujours au-dessus du plafond. La portée du programme est l'autre moitié du problème. Au T3, il déléguait à environ 51 % des validateurs, mais ces délégations représentaient environ 4 % de la mise active. La règle donne aux validateurs une raison de se diversifier, mais elle ne régit pas le reste de la mise.

Les données d'octobre de FCAT placent le plus grand réseau d'hébergement à environ 29 % de la mise — au-dessus du plafond de 25 % de la Foundation — tandis que le programme de la Foundation a délégué environ 4 % de la mise active au T3.

Ce qu'Alpenglow corrige — et ce qu'il ne corrige pas

Alpenglow sera activé sur le mainnet à l'epoch 1064, qui, selon Solana, débutera vers 15h00 UTC le mercredi 21 octobre ; Anza, l'équipe derrière le client Agave, a évoqué environ 14h50. L'ancien système de vote continue de fonctionner pendant les 5 000 premiers emplacements, environ 18 minutes, et le nouveau prend le relais à l'emplacement 459 653 000. La finalité devrait passer d'environ 12,8 secondes à environ 150 millisecondes, un chiffre que Solana présente comme une attente, pas une constante. Les portefeuilles et les applications continueront de fonctionner comme aujourd'hui.

La mise à niveau ne fait rien pour le problème d'hébergement. Un vote plus rapide raccourcit le délai de consensus, mais rien sur la page des mises à niveau de Solana ne change l'endroit où les validateurs tournent ni le fournisseur qui les connecte.

Pour l'instant, elle réduit aussi la diversité logicielle. Les validateurs doivent exécuter Agave, Jito-Solana ou Harmonic Salsa sur une version basée sur Agave 4.3.0. Firedancer et Frankendancer ne sont pas pris en charge pendant la migration, et la page de Solana ne donne aucune date pour leur prise en charge. Firedancer est la base de code indépendante que FCAT décrit comme la avancée la plus significative de Solana vers une diversité de clients indépendante. Les validateurs doivent également détenir au moins 0,8 SOL au-dessus du minimum exempté de loyer dans leur compte de vote, sinon ils ne voteront ni ne produiront de blocs à l'epoch suivant.

• Avant — dès maintenant jusqu'à environ 14h50–15h00 UTC, le 21 octobre : les opérateurs de Firedancer et Frankendancer migrent vers un client basé sur Agave, et chaque validateur votant détient 0,8 SOL au-dessus du minimum exempté de loyer dans son compte de vote.

• À la bascule — début de l'epoch 1064 : l'ancien système de vote fonctionne pendant les 5 000 premiers emplacements, environ 18 minutes, et Alpenglow prend le relais à l'emplacement 459 653 000.

• Après — ce qui change pour les données : les transactions de vote quittent les blocs, donc les compteurs de transactions baissent ; confirmé et finalisé deviennent le même état ; et les données de participation migrent vers les certificats en pied de bloc.

La supervision change aussi. L'analyse de Metrika considère les votes par bloc comme l'indicateur le plus proche de la distance entre le réseau et la ligne de finalité, car les votes sont des transactions ordinaires portées par les blocs. Alpenglow retire les votes des blocs, et les notes de migration de Solana indiquent que tout ce qui mesure la participation des validateurs en analysant les transactions de vote devra trouver une nouvelle source, car ces données migrent vers les certificats en pied de bloc. Les compteurs de transactions rapportées baisseront également sans aucune baisse d'activité réelle.

Ce qu'il faut vérifier cette semaine

Si vous misez du SOL : vérifiez où votre validateur est hébergé avant de déléguer. Validators.app, la source utilisée à la fois par FCAT et la Foundation, suit la mise par réseau d'hébergement et par centre de données. Un validateur sur le plus grand réseau partage le risque d'août.

Si vous développez sur Solana : attendez-vous à ce que les tableaux de bord de comptage de transactions et de TPS baissent mercredi sans changement d'activité réelle. Continuez de lire l'état confirmé jusqu'à l'activation d'Alpenglow, puis passez à finalisé, comme le conseillent les notes de migration de Solana. Avant l'activation, finalisé signifiera toujours une attente d'environ 12,8 secondes. Revérifiez tout délai d'attente ou logique de réessai calibré sur ce délai, et suivez le temps de finalité en plus de l'uptime.

Si vous exploitez un validateur : si vous utilisez Firedancer ou Frankendancer, passez à un client basé sur Agave avant l'epoch 1064, et vérifiez que le compte de vote détient bien les 0,8 SOL.

Après mercredi, deux chiffres méritent d'être surveillés : le moment où la part du plus grand réseau d'hébergement passera sous le plafond de 25 % de la Foundation, et celui où Firedancer sera à nouveau pris en charge. Aucun des deux n'est au programme de mercredi.

Cet article est fourni à titre informatif uniquement et ne constitue pas un conseil financier ou d'investissement.