Une route par défaut mal configurée déconnecte 12 datacenters et frôle l’arrêt de finalité de Solana
Le 12 août 2026, une route par défaut corrompue propagée par un réflecteur chez l’hébergeur TeraSwitch a déconnecté 28,83 % du SOL staké, à 4,51 points du seuil d’arrêt de finalité de Solana. La leçon dépasse la blockchain : mesurez la concentration de vos ASN et testez réellement votre bascule.
12 août 2026. 28,83 % du SOL staké hors ligne en quelques minutes. 04:16:15 UTC, retour à la normale. Pendant une trentaine de minutes, Solana s’est approché à 86 % du seuil où plus aucune transaction n’est finalisée — non à cause d’un bug de son client, mais à cause d’une route BGP par défaut mal configurée chez son hébergeur TeraSwitch.
L’incident n’a jamais provoqué d’arrêt, et c’est précisément ce qui le rend instructif pour un RSSI ou un SRE : une seule route au format corrompu, propagée par un réflecteur, a fait tomber 12 datacenters répartis sur deux continents et mis hors ligne 94 % du stake hébergé sur un seul système autonome. La fragilité n’était pas dans la blockchain, mais dans le BGP qui la porte.
Ce qui s’est passé : une route par défaut vidée de ses attributs
La défaillance, reconstituée par le protocole de staking liquide Marinade Finance puis confirmée par un postmortem de TeraSwitch, tient en une chaîne de propagation. Une route par défaut originaire du site de Miami (MIA1) a circulé sur le backbone de l’hébergeur avec sa métrique et ses communautés BGP dépouillées, et un AS-path ne contenant que l’ASN de TeraSwitch lui-même — AS20326.
Un réflecteur de routes situé à Amsterdam (AMS2) a ensuite poussé cette route altérée vers les marchés européens et asiatiques de l’hébergeur. Les routeurs de bord, en aval, l’ont lue comme originaire localement et l’ont préférée à leur propre défaut valide, avant de l’annoncer au cœur du datacenter — qui l’a rejetée comme invalide. Résultat : sans défaut acceptable installé, les fabrics des sites concernés ont cessé de transférer le trafic vers leurs propres routeurs de bord.
Douze sites ont perdu la connectivité — LON1, AMS1, AMS2, AMS3, DUB1, DUB2, FRA2, SGP1, SGP2, TYO1, TYO2, TYO3 — tandis que les sites nord-américains restaient en ligne. Les ingénieurs ont identifié la route malformée en une dizaine de minutes et retiré MIA1 du backbone ; la restauration complète du trafic a été journalisée à 04:16:15 UTC, soit une fenêtre d’indisponibilité d’environ 30 à 33 minutes.
28,83 % de stake délinquant, à 4,51 points de l’arrêt
Le consensus de Solana compte le stake, pas les serveurs. Sur la fenêtre de l’incident, 28,83 % du SOL staké est passé en état « délinquant », contre un seuil de 33,34 % au-delà duquel le réseau cesse de finaliser les blocs. Autrement dit, Solana a atteint 86 % du chemin vers une perte de finalité, avec une marge de 4,51 points de pourcentage — environ 19,9 millions de SOL.
Par nombre de machines, l’événement paraissait plus modeste : 597 validateurs sur 699 ont continué de voter, soit 102 arrêts (environ 15 % des effectifs). Mais c’est le chiffre en stake, 28,83 %, que le consensus lit. Les blocs ont continué d’être produits et les transactions de passer, sans arrêt ni rollback. La page de statut de Solana n’a d’ailleurs journalisé aucun incident — cohérent avec une chaîne dégradée, mais jamais interrompue.
Le coût financier est resté minime : 333 SOL de récompenses de staking manquées, soit environ 25 600 dollars, absorbés par les cautions des validateurs à la fin de l’époque. Le cours du SOL est resté autour de 76,31 à 76,46 dollars pendant et après l’incident.
Personne n’a basculé : le vrai problème est opérationnel
La découverte la plus inconfortable n’est pas architecturale, mais opérationnelle. Marinade a mesuré le comportement de 74 validateurs pendant la panne : seuls 3 ont basculé proprement vers une infrastructure de secours. 59 validateurs portant 80,2 millions de SOL sont revenus dans la même fenêtre étroite, répartis entre Amsterdam, Francfort et Tokyo — la signature d’une attente passive de reconvergence BGP, pas d’une migration active.
Même Helius, l’un des plus gros opérateurs d’infrastructure de l’écosystème, est resté hors ligne pendant la totalité des 33 minutes, ses systèmes de secours n’ayant pas réussi à s’activer. La formule de Marinade résume le constat : « personne n’a basculé. Ils sont restés assis là jusqu’à ce que le routage reconverge. »
C’est la leçon numéro un pour tout opérateur : une bascule qui n’est jamais testée n’existe pas. La marge de 4,51 points qui a sauvé la finalité a été déterminée par le temps de réaction d’un tiers — TeraSwitch — et non par la redondance des acteurs qui portaient le stake.
27,34 % du stake sur un seul ASN : la concentration comme risque structurel
Le chiffre qui transforme l’incident en avertissement structurel est 27,34 % : l’ASN AS20326 de TeraSwitch porte 118 890 767 SOL, soit plus du quart du stake total. Ce chiffre dépasse déjà le plafond de 25 % par système autonome du programme de délégation de la Fondation Solana, et 94 % de ce stake est tombé hors ligne dans les mêmes minutes.
Le plus instructif : ce plafond a parfaitement fonctionné sur le périmètre qu’il contrôle. Marinade a vérifié les 82 validateurs hébergés sur AS20326 et n’a trouvé aucune délégation de la fondation — « pas un seul SOL sur 24,5 millions ». La concentration n’a pas été créée par la fondation, mais par le choix du marché : prix, latence et commodité opérationnelle ont agrégé des validateurs indépendants sur le même fabric.
Marinade a ensuite retourné la mesure contre elle-même : deux tiers du stake que distribue son modèle d’allocation reposent sur quatre systèmes autonomes, dont AS395201 à 36,94 % — un niveau supérieur à la part qui a failli stopper la finalité. Son propre constat : « personne ne devrait être à l’aise avec ça, nous y compris. »
Ce que ça apprend à un réseau qui n’a rien à voir avec la crypto
Il serait tentant de classer l’affaire comme un problème crypto. C’est l’inverse : c’est un problème BGP qui a simplement trouvé une victime très mesurable.
Premièrement, RPKI et la validation d’origine (ROV) n’auraient rien bloqué ici, comme nous l’avons détaillé dans notre guide sur RPKI et ROV. Ces mécanismes détectent les détournements d’origine — un préfixe annoncé par un ASN qui n’en est pas le titulaire légitime. Or la route fautive portait l’ASN de TeraSwitch lui-même : ce n’était pas une usurpation, mais une corruption interne propagée par un réflecteur. La parade relève de l’hygiène de configuration : ne pas ré-originer de défaut, ne pas dépouiller les attributs, et contrôler ce que vos réflecteurs propagent.
Deuxièmement, la concentration d’ASN est un risque mesurable et négligé. Un seul ASN portant 27 % de votre capacité de consensus — ou de vos charges de production — transforme une erreur de configuration isolée en incident systémique. La métrique à surveiller n’est pas « combien de fournisseurs », mais « quelle fraction de la capacité tombe si un ASN tombe ».
Troisièmement, la bascule passive ne compte pas. Une redondance qui « reviendra toute seule quand le routage reconvergera » n’est pas une redondance : c’est une dépendance déguisée à la vitesse de remédiation d’un tiers.
Verdict
Si votre disponibilité repose sur un seul hébergeur ou un seul ASN, mesurez immédiatement la fraction de capacité qu’il concentre et demandez-lui, comme TeraSwitch l’a fait, un postmortem public sur ses contrôles de propagation de routes.
Si vous opérez des services critiques, testez la bascule pour de vrai — pas un scénario sur le papier, mais un basculement réel qui prouve que vos secours s’activent sans attendre la reconvergence BGP. L’incident du 12 août montre qu’une fenêtre de 33 minutes sans finalité est un scénario plausible, et que la marge qui vous sépare de l’arrêt est souvent fixée par quelqu’un d’autre.
Pour Solana, le réseau a survécu à un test de résistance grandeur nature sans arrêt ni perte de fonds — mais la structure qui l’a mis à 4,51 points du précipice reste en place : 27 % du stake sur un seul ASN, et des validateurs qui attendent la reconvergence au lieu de basculer.