Le mainnet de Sui s'est arrêté à trois reprises entre le 28 et le 29 mai après qu'une nouvelle fonctionnalité d'équilibre par adresse livrée dans la version v1.72 a exposé un cas limite dans la logique de facturation du gaz de la blockchain Layer-1, a indiqué la Sui Foundation dans un post-mortem publié dimanche. Chaque correctif a soit déclenché, soit exposé la panne suivante, la chaîne étant hors service pendant une durée cumulée d'environ 18 heures.
La première panne a commencé vers 7 h PT jeudi et a duré près de sept heures. Selon la fondation, elle provenait d'un problème rare dans la façon dont le réseau facturait le gaz pour les transactions payant avec un mélange de la nouvelle fonctionnalité d'équilibre par adresse et d'objets coin traditionnels. Les validateurs ont planté avec une erreur d'underflow lorsqu'une transaction a été annulée pour fonds insuffisants, mais la routine de gas-smashing a tout de même tenté de dépenser ces mêmes fonds. L'équipe principale a remis le mainnet en service vers 13 h 30 PT avec un « correctif provisoire » qui acceptait un risque connu, de faible probabilité, de déclencher une nouvelle panne.
Ce risque s'est concrétisé le lendemain matin. Une deuxième panne a commencé vers 5 h PT vendredi lorsqu'une variante masquée du même bug a contourné le patch provisoire, et l'équipe a finalisé un correctif plus robuste que les validateurs ont adopté vers 9 h 40 PT. Le troisième arrêt a suivi en cascade : lorsque les validateurs ont redémarré pour installer le correctif, la participation au protocole qui initialise l'aléa on-chain est tombée sous le seuil requis et l'aléa s'est désactivé comme prévu — et un bug latent a ensuite échoué à persister cet état désactivé sur disque, bloquant le changement d'époque suivant pendant près de six heures.
Pourquoi c'est important
Trois arrêts en 48 heures, voilà le type de schéma que les allocateurs institutionnels et les opérateurs de bridges traitent comme un signal de risque structurel, même quand aucun fonds n'est en jeu. L'effet cascade est plus difficile à défendre que n'importe quelle panne isolée — chaque correctif provisoire portait un risque connu que l'équipe a accepté, et ce risque s'est matérialisé le lendemain matin. Le positionnement de Sui comme Layer-1 grand public à haut débit repose entièrement sur la disponibilité, et il s'agit désormais du troisième incident majeur de fiabilité du réseau depuis le lancement de son mainnet en 2023, après un bug de planification des transactions de deux heures en novembre 2024 et une divergence de consensus de six heures en janvier 2026.
Questions fréquemment posées
-
Qu'est-ce qui a causé les trois pannes du mainnet de Sui les 28 et 29 mai ?
Une nouvelle fonctionnalité d'équilibre par adresse livrée dans la v1.72 a exposé un cas limite dans la logique de facturation du gaz de Sui. Les deux premiers arrêts venaient de bugs dans les paiements de gaz mixtes quand des transactions manquaient de fonds ; le troisième était une panne en cascade du protocole…
-
Des fonds utilisateurs ont-ils été perdus ou des transactions annulées pendant les pannes ?
Non. Le post-mortem de la Sui Foundation indique qu'aucun fonds utilisateur n'était en risque durant les trois arrêts et qu'aucune transaction engagée n'a été annulée.
-
De combien le token SUI a-t-il chuté pendant la cascade de pannes ?
$SUI a perdu environ 8 % pendant la cascade jusqu'à un plus bas de $0,90 et s'échangeait autour de $0,90 lundi, laissant le token en baisse d'environ 19 % sur la semaine, selon les données CoinDesk.
-
Combien d'incidents majeurs de fiabilité Sui a-t-il connus depuis le lancement du mainnet ?
Trois : la cascade des 28-29 mai, un bug de planification des transactions de deux heures en novembre 2024, et une divergence de consensus de six heures en janvier 2026. Le mainnet de Sui a été lancé en 2023.
-
Quel est le bug d'aléa on-chain qui a causé la troisième panne ?
Quand les validateurs ont redémarré pour installer le deuxième correctif, la participation au protocole d'initialisation de l'aléa est tombée sous le seuil requis et l'aléa s'est désactivé comme prévu. Un bug latent a ensuite échoué à persister cet état désactivé sur disque, donc les validateurs au redémarrage suivant…