Mercredi 12 août, le réseau Solana s'est retrouvé à deux doigts d'un arrêt complet, frôlant l'effondrement à seulement 14 %, après que 28,83 % du $SOL déposé sur le réseau soit sorti du consensus.
Un défaut de paiement sur le serveur Teraswitch, signalé par la plateforme de staking Marinade Finance, aurait pu mettre fin à 30 mois de fonctionnement sans interruption du réseau Solana. Cependant, le réseau n'a atteint que 86 % de ce seuil.
Si le volume de $SOL staké non comptabilisé sur le réseau avait atteint le seuil de 33,34 %, Solana aurait connu un échec et le réseau se serait arrêté.
Pourquoi le réseau Solana échoue-t-il ?
Solana cesse de finaliser les blocs lorsque plus d'un tiers (33,34 %) de tous les jetons $SOL déposés sur le réseau deviennent invalides. L'invalidité survient lorsqu'un validateur du réseau quitte soudainement la liste des participants au consensus.
Le réseau s'est approché du seuil de 33,34 % de validations, atteignant 28,83 %, puis la situation a commencé à se stabiliser.
Selon Marinade, le défaut de paiement a touché 90 validateurs, qui ont perdu 333 $SOL en récompenses pendant qu'ils étaient hors ligne. Ironiquement, au prix de $SOL à 76,9 dollars au moment de la publication de cet article par Cryptopolitan, l'ensemble de Solana aurait pu être temporairement arrêtée à cause d'une anomalie de 25 600 dollars.
Comme la crise a été évitée, la page d'état officielle de Solana affiche toujours un fonctionnement sans interruption à 100 % du cluster au cours des 90 derniers jours. Le dernier arrêt complet du réseau remonte au 6 février 2024 et a duré environ cinq heures.
Comment la correction a-t-elle été appliquée ?
Selon la page d'état du réseau Teraswitch, « Les clients sur les stations LON1, AMS1, AMS2, AMS3, DUB1, DUB2, FRA2, SGP1, SGP2, TYO1, TYO2 et TYO3 ont rencontré une perte d'accès aux ressources Internet, ainsi qu'au réseau dorsal interne de Teraswitch entre les stations affectées. D'autres stations en Amérique du Nord n'ont pas été affectées »
La déclaration indique également que dans le cadre des mesures de réponse, l'entreprise a intentionnellement exclu MIA1 (Miami, Floride) du réseau dorsal
L'incident, qui, selon Marinade, « n'a pratiquement été enregistré nulle part », a été résolu après que les ingénieurs de Teraswitch ont « identifié une route déformée dans les 10 minutes suivant son apparition et ont supprimé MIA1 du réseau dorsal pour empêcher toute propagation ultérieure. »
Teraswitch a précisé que « les sites affectés sont passés à leurs routes locales par défaut, et le service a été rétabli à 04:16:15 UTC »
Quels validateurs Solana ont échoué ?
Sur les 74 validateurs testés par Marinade, seuls trois se sont rétablis sans problème : laine de Solana Strategies et Cogent Crypto, ainsi que Lion3d.
Le reste du pool de validateurs a temporairement échoué pendant la durée de l'épisode. Le deuxième plus grand validateur de Solana, Helius, est resté indisponible pendant toute la durée de la panne de 33 minutes.
Concernant les 333 $SOL de récompenses perdues, Marinade a déclaré que les opérateurs supporteraient les pertes et que les stakers ne subiraient aucun préjudice.
Le temps de fonctionnement sans interruption de Solana a presque disparu
Deux jours avant cet incident qui a failli provoquer une panne, Solana fonctionnait sans interruption depuis 30 mois consécutifs. La cause première avait alors été une erreur dans le cache JIT de LoadedPrograms, qui obligeait les validateurs à recompiler les données de manière répétée jusqu'à ce que le consensus se bloque sur un seul bloc, selon Solana Compass. Anza a corrigé l'erreur et le réseau a repris après cinq heures.
La justification de la fiabilité repose sur trois changements mis en œuvre en 2023 et 2024 : la couche de transport QUIC avec qualité de service pondérée par la part pour limiter le spam, le marché des frais prioritaires qui assure désormais environ 88 % des revenus quotidiens provenant des frais, et Firedancer, un validateur indépendant que Jump Crypto a lancé sur le réseau principal fin 2025.
Le lancement d'un deuxième client signifie qu'une erreur dans un fragment de code ne peut plus entraîner l'arrêt de l'ensemble du réseau.
end-content
