TL;DR
- 28,76 % des SOL mis en jeu sont devenus en souffrance.
- Il ne restait que 19,9 millions de SOL avant le seuil.
- Un échec de routage a touché les validateurs dans plusieurs régions.
- L’incident a révélé la concentration des infrastructures partagées.
Solana est resté en ligne le 12 août, mais la marge était beaucoup plus mince que ce que suggèrent les statistiques normales de disponibilité.
Selon une reconstruction de Marinade Finance, un échec de routage affectant les validateurs liés au même fournisseur d'infrastructure a poussé 28,76 % de tous les SOL mis en jeu dans un statut de délinquant. Au pire, seuls 19,9 millions de SOL séparaient le réseau du seuil d’un tiers de participation où la finalité normale pourrait s’arrêter.
Près de 29 % des SOL misés ont arrêté de voter
Marinade Finance a reconstitué la fenêtre de panne validateur par validateur, montrant la rapidité avec laquelle les participations en souffrance se sont constituées sur le réseau le 12 août.
Le pire moment est survenu vers 03h58 UTC. Solana avait 434,93 millions de SOL activement mis en jeu à l'époque, avec 125,08 millions de SOL ne votent plus normalement, 28,76% du total. La marque d'un tiers était d'environ 144,98 millions SOLplaçant le réseau à environ 86 % du chemin.
Le « délinquant » compte ici. Les validateurs concernés n'étaient pas nécessairement éteints ou tombés en panne ; ils étaient suffisamment désynchronisés ou avaient perdu suffisamment de connectivité pour que leurs votes n'atteignent plus le cluster comme prévu.
Pour le consensus, la différence est surtout académique. Les enjeux qui ne peuvent pas voter sont des enjeux que le réseau ne peut pas utiliser.
Pourquoi le seuil d'un tiers est important
Solana s'appuie sur des votes pondérés en fonction des enjeux, et environ les deux tiers des droits de vote doivent rester disponibles pour que la chaîne continue d'atteindre sa finalité normale. Si vous perdez plus d'un tiers, le réseau n'aura plus le poids de vote nécessaire pour continuer à confirmer l'historique de la manière habituelle.
La Fondation Solana qualifie 33 % de la participation déléguée de « superminorité » car cette part est suffisante pour interférer avec la capacité du réseau à finaliser de nouveaux blocs.
Cela ne signifie pas que tous les serveurs deviennent sombres à 33,3 %. Les validateurs peuvent toujours fonctionner et des blocs peuvent encore être produits, mais le consensus perd la marge dont il a besoin pour continuer à avancer normalement.
Le 12 août a failli transformer un problème de réseau en exactement cela.
Les validateurs étaient séparés. Leur infrastructure ne l’était pas.
L'autopsie de Marinade s'éloigne du logiciel de validation de Solana et se dirige vers un échec beaucoup moins exotique : un hébergeur et une faute de routage.
Les problèmes semblent avoir commencé autour des infrastructures de Miami, mais les conséquences n'ont pas été locales. Les validateurs en Europe et en Asie ont également perdu leur connectivité, et à peu près 94 % de la participation hébergée chez le fournisseur concerné est devenu délinquant.
Les opérateurs eux-mêmes étaient des entreprises distinctes. Le goulot d’étranglement se trouvait en amont.
Différentes identités de validateurs, différentes délégations et différents opérateurs n’achètent pas beaucoup de résilience si une grande partie d’entre eux dépend toujours de la même société d’hébergement, du même fournisseur de transit ou du même itinéraire pour atteindre le reste du cluster. Une fois que cette couche partagée a échoué, ce qui semblait décentralisé sur la chaîne s'est comporté comme un domaine de défaillance unique en dessous.
C’est la partie que le validateur ordinaire compte manquer.
L'itinéraire a été fixé en quelques minutes. Les validateurs ont pris plus de temps.
Le problème de routage sous-jacent a été corrigé en 10 minutes environ, mais la participation des validateurs n’a pas repris d’un seul coup. Le graphique de Marinade montre que les mises en souffrance restent élevées après la réparation du chemin du réseau, puis chutent fortement à mesure que les machines rattrapent le cluster et reprennent le vote.
Vers 04h30 UTC, la majeure partie de la participation concernée était de retour.
Solana n'a jamais eu besoin du type de redémarrage coordonné observé lors de certaines de ses pannes précédentes. En février 2024, la production de blocs s'est arrêtée pendant environ cinq heures et les validateurs ont dû mettre à niveau leur logiciel avant de redémarrer le cluster. Rien de comparable ne s'est produit ici : une participation suffisante a continué à voter, la chaîne a continué à fonctionner et l'échec a été résolu avant que le seuil d'un tiers ne soit franchi.
La source du risque était également différente. Il ne s’agissait pas d’un bug du validateur-client ou d’un échec de consensus interne. Une dépendance en dehors du protocole a brièvement supprimé d’un seul coup une énorme partie du pouvoir de vote.
Alpenglow se dirige déjà vers le réseau principal
Le quasi-accident arrive alors que Solana est déjà en train de tester Alpenglow, sa plus grande refonte consensuelle depuis des années. Le code contient toutes les fonctionnalités d'Agave 4.2 et les validateurs l'exécutent désormais dans un cluster de test communautaire, l'activation du réseau principal étant prévue pour Agave 4.3 en octobre.
Alpenglow remplacera TowerBFT par Votor et visera une finalité d'environ 150 ms, contre environ 12,8 secondes aujourd'hui. Mais l’incident du 12 août se situe en dessous de cette couche : un consensus plus rapide ne peut pas éliminer un routage partagé ou un goulot d’étranglement au niveau du centre de données si une part trop importante dépend toujours du même fournisseur.
Le problème de décentralisation de Solana pourrait se situer sous la chaîne
L'événement du 12 août est moins intéressant en tant qu'entrée supplémentaire dans l'historique des pannes de Solana qu'en tant qu'avertissement sur ce que les mesures de décentralisation des validateurs ne parviennent pas à capturer.
Les enjeux peuvent être répartis entre des centaines d’opérateurs indépendants et toujours regroupés derrière la même infrastructure physique. En chaîne, ces validateurs semblent distincts. Du point de vue d’un itinéraire brisé, ce n’est pas le cas.
Solana a échappé à celui-ci sans perdre sa finalité.
Ce que l'incident a révélé, c'est que la véritable redondance du réseau ne dépend pas seulement du nombre de validateurs et de la répartition des enjeux. La concentration d'hébergement, les fournisseurs de transit et les chemins de routage font également partie de ce calcul.
Voir l’article original en anglais
