La Solana Foundation a publié le 14 septembre un retour détaillé sur un incident passé relativement inaperçu auprès des utilisateurs du réseau.

Le 12 août à 04 h 01 UTC, TeraSwitch a subi un problème de routage sur son infrastructure de Francfort, où sont hébergés de nombreux validateurs Solana.

Près de 29 % du stake du mainnet est alors devenu indisponible.

Les blocs ont néanmoins continué à être produits et les transactions à être intégrées. La Solana Foundation indique que le fournisseur d’infrastructure avait totalement récupéré un peu plus de trente minutes plus tard.

29 % est un chiffre beaucoup plus intéressant que 30 minutes

La durée de la panne était courte. Le pourcentage de stake affecté dit davantage sur ce qui s’est réellement passé.

Le consensus actuel de Solana repose toujours sur TowerBFT. Comme d’autres systèmes byzantins fondés sur un quorum, il peut continuer à fonctionner tant qu’une proportion suffisante du stake reste capable de communiquer et de voter.

La Foundation situe la limite pratique autour de 33,33 % de stake indisponible.

En dessous de cette frontière, plus des deux tiers du stake peuvent encore participer et le réseau dispose du quorum nécessaire pour progresser.

Une coupure proche de 29 % ne constitue donc pas seulement « beaucoup de validateurs hors ligne ». Elle place le réseau à quelques points de pourcentage d’une zone où la production normale de consensus pourrait devenir impossible.

Cela ne signifie pas qu’un tiers du stake peut disparaître sans aucune conséquence

Le seuil byzantin est parfois résumé de manière trop confortable.

Dire qu’un système tolère jusqu’à environ un tiers de défaillances ne signifie pas qu’il fonctionne exactement de la même manière à 1 % et à 32 % de stake indisponible.

À mesure que le nombre de participants disponibles diminue, la marge de sécurité opérationnelle se réduit. Une deuxième panne indépendante peut faire basculer le réseau de l’autre côté du quorum.

Les leaders appartenant aux validateurs hors ligne peuvent également créer des slots manqués ou une dégradation temporaire des performances.

Ce que l’incident d’août démontre surtout est que le défaut d’un gros fournisseur n’a pas suffi, à lui seul, à interrompre le consensus.

Le risque était connu : TeraSwitch hébergeait auparavant 38 % du stake

La partie la plus importante du récit de la Foundation se situe avant la panne.

Selon Jacob Creech, vice-président de la technologie de la Solana Foundation, TeraSwitch hébergeait encore environ 38 % du stake du réseau l’année précédente.

À ce niveau, une panne généralisée du fournisseur aurait pu dépasser le seuil d’un tiers.

La Foundation dit avoir travaillé avec les opérateurs pour réduire cette concentration sous les 30 % avant l’incident d’août.

Autrement dit, le réseau n’a pas seulement eu de la chance que la panne n’affecte que 29 % du stake. La réduction préalable de la concentration chez ce fournisseur a directement modifié le risque.

La décentralisation d’un réseau ne se mesure donc pas seulement au nombre de validateurs

Mille validateurs ne donnent pas nécessairement mille points de défaillance indépendants.

Si plusieurs centaines d’entre eux utilisent le même datacenter, le même opérateur réseau, le même fournisseur cloud ou le même logiciel, ils peuvent tomber ensemble.

Dans le cas de TeraSwitch, la panne de routage n’a pas cassé individuellement des centaines de serveurs. Elle a supprimé leur capacité à communiquer avec le reste du réseau par un point d’infrastructure commun.

Le stake réellement indépendant géographiquement et opérationnellement devient donc plus important que le simple nombre de machines.

C’est précisément pourquoi la distribution par fournisseurs d’hébergement, régions et clients logiciels fait partie des métriques suivies par la Solana Foundation.

Devnet a subi un test encore plus violent

Le même incident a touché le réseau de développement de Solana beaucoup plus sévèrement.

Selon la Foundation, environ trois quarts du stake de Devnet est devenu indisponible.

Un tel niveau dépasse largement le quorum nécessaire au fonctionnement normal.

Devnet a donc cessé de progresser temporairement, mais la Foundation souligne qu’il a récupéré de lui-même lorsque les validateurs sont revenus en ligne, sans redémarrage coordonné.

Cette différence est importante.

Une blockchain peut perdre le quorum et s’arrêter sans pour autant exiger une intervention manuelle complexe pour retrouver son état normal lorsque suffisamment de validateurs réapparaissent.

Dans ce cas, la Foundation utilise le terme de self-healing : l’infrastructure est revenue et le réseau a repris sa progression à partir de son état de consensus existant.

Solana traîne encore l’histoire de ses anciennes pannes

L’intérêt de cette publication vient aussi du passé du réseau.

Solana a connu plusieurs interruptions importantes dans ses premières années, dont certaines nécessitaient un redémarrage coordonné des validateurs.

Des vagues de transactions automatisées avaient notamment exposé les limites du traitement du trafic entrant. D’autres incidents avaient révélé des problèmes dans le scheduler ou dans certains composants du logiciel validateur.

Ces épisodes ont durablement attaché l’image de Solana à la question de l’uptime.

La Foundation insiste désormais sur les modifications réalisées depuis : augmentation des connexions disponibles pour les validateurs, Stake-Weighted Quality of Service et redesign du scheduler pour réduire l’intérêt de soumettre plusieurs fois la même transaction.

100 % d’uptime depuis février 2024, selon la Foundation

Solana affirme maintenant avoir maintenu son mainnet disponible sans interruption depuis février 2024.

La page de statut officielle indique également 100 % de disponibilité du cluster mainnet sur les 90 derniers jours au moment de cette publication.

Ce chiffre doit néanmoins être interprété selon la définition de l’uptime utilisée par l’opérateur.

Un réseau peut continuer à produire des blocs tout en connaissant des dégradations de performances, des services RPC perturbés ou des problèmes touchant une partie des utilisateurs.

L’incident TeraSwitch entre précisément dans cette nuance : une partie énorme de l’infrastructure était indisponible, mais le consensus lui-même n’a pas cessé.

La véritable disponibilité d’une blockchain existe sur plusieurs étages

Pour un utilisateur, « Solana fonctionne » semble être une réponse binaire.

Techniquement, plusieurs couches peuvent échouer indépendamment.

Le consensus peut continuer pendant qu’un grand fournisseur RPC tombe. Un explorateur peut être hors service alors que les validateurs progressent normalement. Une région réseau peut être inaccessible pendant que d’autres continuent à produire des blocs.

Inversement, tous les sites web et endpoints RPC peuvent répondre alors que le consensus ne parvient plus à finaliser de nouveaux blocs.

Mesurer la résilience impose donc de séparer la disponibilité de la chaîne, celle des validateurs, des RPC, des indexeurs, des portefeuilles et des applications.

Le problème des infrastructures communes ne disparaît pas avec la blockchain

Un réseau décentralisé fonctionne toujours sur des infrastructures très centralisées par endroits.

Les validateurs utilisent des datacenters, des opérateurs de transit IP, des fournisseurs bare-metal, du DNS, des systèmes de monitoring et différents services cloud.

Une blockchain peut donc répartir le consensus entre de nombreux opérateurs tout en conservant des dépendances communes cachées en dessous.

L'incident TeraSwitch est un exemple presque pédagogique de ce phénomène.

La blockchain n’a pas été attaquée au niveau du protocole. Une couche Internet conventionnelle a cessé de router correctement du trafic et près de trois validateurs pondérés par stake sur dix ont disparu du point de vue du réseau.

Le stake pondéré rend certaines pannes bien plus importantes que d’autres

Tous les validateurs ne possèdent pas le même poids dans Solana.

Le consensus tient compte du stake délégué à chacun d’eux. Perdre dix validateurs possédant chacun très peu de stake peut être presque insignifiant ; perdre quelques gros validateurs peut au contraire déplacer brutalement le quorum.

Voilà pourquoi la statistique pertinente dans cet incident est 29 % du stake plutôt que le nombre exact de serveurs affectés.

La topologie économique du réseau devient une partie de sa topologie technique.

Le choix des délégateurs détermine indirectement quels opérateurs, logiciels et fournisseurs d’infrastructure deviennent critiques.

La prochaine évolution du consensus arrive justement en parallèle

Solana prépare actuellement la migration vers Alpenglow, son futur mécanisme de consensus.

Les prérequis cryptographiques ont déjà commencé à être activés sur le mainnet : les validateurs doivent enregistrer une clé BLS et le Validator Admission Ticket est actif depuis juillet.

La bascule complète vers Alpenglow doit arriver séparément avec Agave 4.3, actuellement attendu au quatrième trimestre 2026.

Le nouveau système remplacera TowerBFT et vise notamment une finalité d’environ 150 ms.

Cela ne supprime pas le problème révélé par TeraSwitch. Quel que soit le consensus, si trop de poids de vote dépend du même fournisseur réseau, une panne commune reste une menace.

La résilience est donc autant une politique d’hébergement qu’un algorithme

L’algorithme de consensus a fait exactement ce qu’il devait pendant l’incident du 12 août : continuer tant qu’un quorum suffisant restait disponible.

Mais cette réussite dépendait d’une décision prise bien avant la panne : réduire le stake concentré chez TeraSwitch de 38 % à moins de 30 %.

C’est peut-être la leçon la plus utile de l’événement.

La tolérance aux pannes ne se résume pas à écrire un protocole capable de survivre à un tiers de nœuds défaillants.

Il faut également éviter qu’un seul câble, opérateur, datacenter, fournisseur cloud ou client logiciel représente précisément ce tiers.

Le 12 août, Solana est resté du bon côté de cette frontière.

Avec près de 29 % du stake hors ligne, il ne lui restait simplement plus énormément de marge pour découvrir simultanément un deuxième problème.