Sui dévoile ce qui a provoqué trois arrêts de son réseau principal après une mise à jour majeure

bitcoinistPublished on 2026-06-02Last updated on 2026-06-02

Abstract

Le réseau principal de Sui a connu trois interruptions distinctes les 28 et 29 mai, suite à la mise à jour 1.72 qui a révélé des cas limites dans la logique de facturation du gas et de redémarrage des validateurs, selon un rapport post-mortem de la Fondation Sui. Aucun fonds utilisateur n'a été compromis et le réseau a repris son activité normalement. Les deux premières interruptions étaient liées à un bug dans l'interaction entre la nouvelle fonctionnalité de solde d'adresse (introduite pour payer le gas) et la logique existante, provoquant un dépassement inférieur lors du règlement des transactions. Un correctif temporaire a été appliqué, mais une faiblesse résiduelle a causé la seconde panne. La troisième interruption, distincte, est survenue lors d'un changement d'époque programmé. Après les redémarrages, un bug latent dans la persistance de l'état du protocole de génération de clés distribuée (DKG) a empêché la finalisation de l'époque. La solution a consisté à persister l'état du DKG et à ajouter un mécanisme de clôture forcée coordonnée. La Fondation Sui a présenté ces incidents comme une leçon pour renforcer la résilience des changements d'époque et appliquer une rigueur accrue à la logique de facturation du gas, au même titre que d'autres composants fondamentaux du protocole.

Selon un rapport post-mortem de la Sui Foundation, le réseau principal de Sui a subi trois pannes distinctes les 28 et 29 mai après que la version 1.72 du réseau a exposé des cas limites dans la logique de facturation du gas et le redémarrage des validateurs. La fondation a déclaré que les problèmes ont depuis été résolus, que l'activité du réseau a repris et que « aucun fond utilisateur n'était en danger ».

Les incidents ont commencé jeudi 28 mai, lorsque le réseau principal de Sui s'est arrêté vers 7h (heure du Pacifique) et est resté hors service jusqu'à environ 13h30 (heure du Pacifique). Une seconde panne a suivi vendredi matin, commençant vers 5h (heure du Pacifique) et se terminant vers 8h30 (heure du Pacifique). Le troisième arrêt a débuté vendredi après-midi vers 13h30 (heure du Pacifique) et a été résolu vers 19h20 (heure du Pacifique).

Selon la fondation, les deux premières pannes provenaient de bugs de plantage liés à l'interaction entre la logique de facturation du gas et la mise à jour 1.72 de Sui, qui a introduit les soldes d'adresse. La troisième panne était distincte, déclenchée lors d'un changement d'époque planifié après que les redémarrages des validateurs ont exposé un bug latent dans la manière dont l'état d'aléatoire était préservé.

« Pendant les pannes, aucun fond utilisateur n'était en danger, et le réseau n'a annulé aucune transaction validée à son retour », a déclaré la Sui Foundation. « À l'heure actuelle, les validateurs ont entièrement résolu les problèmes connus causés à la fois par le bug initial de facturation du gas et par le bug de l'état d'aléatoire, et l'activité du réseau a repris. »

Le bug de facturation du gas de Sui a déclenché les premiers arrêts

Le premier problème concernait la nouvelle fonctionnalité de solde d'adresse de Sui, qui permet aux utilisateurs de stocker des fonds et de payer le gas sans dépendre uniquement des objets "coin". Les transactions sur Sui peuvent payer le gas via les soldes d'adresse, les objets "coin" ou une structure hybride combinant les deux.

Le cas limite est apparu dans ce chemin de paiement hybride. Lorsqu'une transaction tentait de dépenser un solde d'adresse qui ne pouvait pas couvrir des transactions concurrentes, l'ordonnanceur l'annulait correctement avec une erreur InsufficientFundsForWithdraw. Mais plus tard, pendant le "gas smashing" — le processus de fusion des "coins" d'entrée en une seule "coin" de paiement de gas — la même réservation pouvait encore tenter de débiter des fonds à nouveau.

Dans l'explication de la fondation, le plantage ne s'est pas produit directement pendant le "gas smashing" mais pendant le règlement, lorsque les variations de soldes étaient réconciliées par une transaction système. Une variation négative appliquée à un solde nul a provoqué un dépassement inférieur.

La solution immédiate était conceptuellement simple : éviter le "gas smashing" lorsqu'une transaction est annulée avec InsufficientFundsForWithdraw. Les validateurs ont adopté ce correctif jeudi, ramenant le réseau en ligne. Mais la fondation a reconnu que le correctif était une mesure intérimaire, choisie pour rétablir le réseau pendant que les ingénieurs développaient une solution plus complète.

« Changer la logique du gas est une opération délicate », a écrit la fondation. « Comme expliqué ci-dessus, il existe des interactions complexes entre les soldes d'adresse et les "coins". Hormis la correction de bugs, les changements de logique du gas doivent préserver tout le comportement précédent ou utiliser une porte de version appropriée. »

Ce correctif intérimaire contenait une faiblesse connue. Si une transaction avait plusieurs raisons d'annulation, une autre erreur pouvait masquer la condition InsufficientFundsForWithdraw. Lorsque cela s'est produit vendredi matin, le chemin du dépassement inférieur d'origine pouvait toujours être atteint, provoquant un second arrêt.

Le changement d'époque a exposé un bug de l'état d'aléatoire

La troisième panne est survenue après que le réseau avait repris son fonctionnement normal vendredi matin. Au prochain changement d'époque planifié, les validateurs n'ont pas pu terminer la transition en raison d'un bug lié au protocole de génération de clés distribuées de Sui (DKG), qui amorce l'aléatoire pour les transactions dépendant d'un aléatoire "on-chain".

Pendant le cycle de redémarrage précédent, la participation n'était pas assez élevée pour le processus DKG de l'époque suivante, donc l'aléatoire a été désactivé comme prévu. Le problème était que la constatation d'échec n'a pas été écrite sur le disque. Lorsque les validateurs ont redémarré à nouveau, ils sont revenus sans se souvenir que le DKG avait échoué.

« Les validateurs ne se souvenant plus que le DKG avait échoué, ni l'un ni l'autre ne pouvait se produire, la file d'attente en pause a grossi, et la logique de fin d'époque — qui doit vider cette file avant de fermer — est restée en attente d'un DKG qui ne viendrait jamais », a déclaré la fondation.

Le correctif comportait deux parties : persister le statut DKG entre les redémarrages et ajouter un mécanisme permettant aux validateurs de clore l'époque bloquée à un moment coordonné. Ce mécanisme a été utilisé une fois pour clore l'époque concernée, après quoi le réseau est passé à l'époque suivante et l'aléatoire a été restauré.

Le post-mortem a présenté ces pannes comme une leçon d'ingénierie plus large pour Sui. La fondation a déclaré que la résilience en fin d'époque nécessitait davantage d'investissements, en particulier autour de la dégradation gracieuse et des mécanismes de fermeture forcée opérationnels. Elle a également déclaré que la facturation du gas méritait le même niveau de rigueur que le Move VM ou le consensus Mysticeti, compte tenu de son interaction avec le règlement, les vérifications de conservation et l'ordonnancement.

Au moment de la rédaction, le SUI s'échangeait à 0,8798 $.

Sui reste sous la moyenne mobile exponentielle sur 20 semaines, graphique 1 semaine | Source : SUIUSDT sur TradingView.com

Related Questions

QQu'est-ce qui a causé les trois arrêts du mainnet de Sui après la mise à niveau du réseau ?

ALes trois arrêts ont été causés par des cas limites révélés après la mise à jour 1.72. Les deux premières pannes provenaient de bugs de plantage liés à l'interaction entre la logique de tarification du gaz (gas charging) et la nouvelle fonctionnalité des soldes d'adresse. La troisième panne était distincte, déclenchée par un bug latent dans la préservation de l'état d'aléatoire (randomness state) lors d'un changement d'époque (epoch change) après des redémarrages de validateurs.

QComment le bug de tarification du gaz (gas charging) a-t-il provoqué les premières pannes ?

ALe bug concernait le nouveau chemin hybride de paiement du gaz, combinant soldes d'adresse et objets coin (coin objects). Lorsqu'une transaction annulée pour fonds insuffisants (InsufficientFundsForWithdraw) passait ensuite par l'étape de 'gas smashing' (combinaison des coins), une tentative de débiter à nouveau les fonds pouvait survenir. Pendant le règlement, l'application d'un delta négatif à un solde nul provoquait un dépassement inférieur (underflow), faisant planter le réseau.

QQuel était le problème à l'origine de la troisième panne liée au changement d'époque (epoch change) ?

ALa troisième panne était due à un bug dans la préservation de l'état du protocole de génération de clés distribuée (DKG), qui initialise l'aléatoire pour le réseau. Après des redémarrages, le verdict d'échec d'un processus DKG n'était pas enregistré sur le disque. Les validateurs redémarrés ne se souvenaient donc pas de cet échec, ce qui bloquait la file d'attente et empêchait la logique de fin d'époque de se terminer, provoquant l'arrêt du réseau.

QQuelles ont été les solutions mises en œuvre pour résoudre ces problèmes ?

APour le bug de tarification du gaz, un correctif provisoire a évité le 'gas smashing' pour les transactions annulées pour fonds insuffisants. Un correctif plus complet a suivi. Pour le bug lié à l'état d'aléatoire, la solution a été double : persister le statut du DKG lors des redémarrages et ajouter un mécanisme permettant aux validateurs de clore de force une époque bloquée à un moment coordonné, ce qui a permis au réseau de passer à l'époque suivante.

QQuels enseignements la Fondation Sui a-t-elle tirés de ces incidents ?

ALa Fondation Sui a indiqué que ces pannes soulignaient la nécessité d'investir davantage dans la résilience des transitions de fin d'époque, notamment via des mécanismes de dégradation gracieuse et de fermeture forcée opérationnelle. Elle a également souligné que la logique de tarification du gaz méritait le même niveau de rigueur que la Move VM ou le consensus Mysticeti, en raison de ses interactions complexes avec le règlement, les vérifications de conservation et l'ordonnancement.

Related Reads

Pricing OpenAI Pre-IPO: A New, Life-or-Death Business on Hyperliquid Lasting Half a Year

Pricing OpenAI Pre-IPO: Hyperliquid's High-Stakes, Six-Month Business Venture The article analyzes the nascent market for pre-IPO perpetual contracts on the Hyperliquid blockchain, exemplified by two contrasting teams: Trade.xyz and Ventuals. Trade.xyz, an anonymous team, successfully built the largest pre-market on Hyperliquid. Its strategy focused on near-term events, like the SpaceX IPO. By listing a SpaceX contract with a known launch date and price, the market had a tangible "anchor" (the eventual Nasdaq opening price) to converge upon, which kept speculation in check. This approach fueled significant growth. In stark contrast, Ventuals, backed by Paradigm, failed despite holding coveted contracts for OpenAI and Anthropic. Its critical flaw was its pricing mechanism for these companies, which have no imminent IPO. Ventuals' oracle price was half-derived from infrequent private market transactions and half from its own contract's moving average. This created a self-reinforcing loop where buying pressure artificially inflated the price, disconnecting it from real supply and demand. The market became illiquid and structurally skewed. Ventuals shut down nine months after launch, reportedly through an acquisition. Its final settlement prices—OpenAI at ~$1,341 and Anthropic at ~$1,618—were thus partially products of its flawed model. Ironically, some company employees and late-stage VCs reportedly used these prices for valuation reference, highlighting the desperate demand for price discovery in opaque private markets. The failure of Ventuals exposes the core challenge of this business: price for illiquid, non-public assets requires a robust, self-correcting market, which is absent without a definitive public listing event. Nevertheless, demand is driving major players like Coinbase and traditional finance (e.g., Citi) to enter the space, aiming to provide 24/7 trading for coveted private company shares. The venture's ultimate viability, however, hinges on solving the fundamental pricing problem Ventuals could not.

marsbit1h ago

Pricing OpenAI Pre-IPO: A New, Life-or-Death Business on Hyperliquid Lasting Half a Year

marsbit1h ago

Trading

Spot
Futures

Hot Articles

How to Buy SUI

Welcome to HTX.com! We've made purchasing SUI Network (SUI) simple and convenient. Follow our step-by-step guide to embark on your crypto journey.Step 1: Create Your HTX AccountUse your email or phone number to sign up for a free account on HTX. Experience a hassle-free registration journey and unlock all features.Get My AccountStep 2: Go to Buy Crypto and Choose Your Payment MethodCredit/Debit Card: Use your Visa or Mastercard to buy SUI Network (SUI) instantly.Balance: Use funds from your HTX account balance to trade seamlessly.Third Parties: We've added popular payment methods such as Google Pay and Apple Pay to enhance convenience.P2P: Trade directly with other users on HTX.Over-the-Counter (OTC): We offer tailor-made services and competitive exchange rates for traders.Step 3: Store Your SUI Network (SUI)After purchasing your SUI Network (SUI), store it in your HTX account. Alternatively, you can send it elsewhere via blockchain transfer or use it to trade other cryptocurrencies.Step 4: Trade SUI Network (SUI)Easily trade SUI Network (SUI) on HTX's spot market. Simply access your account, select your trading pair, execute your trades, and monitor in real-time. We offer a user-friendly experience for both beginners and seasoned traders.

8.3k Total ViewsPublished 2024.03.29Updated 2026.06.02

How to Buy SUI

Discussions

Welcome to the HTX Community. Here, you can stay informed about the latest platform developments and gain access to professional market insights. Users' opinions on the price of SUI (SUI) are presented below.

活动图片