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

bitcoinist发布于2026-06-02更新于2026-06-02

文章摘要

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

相关问答

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.

你可能也喜欢

XRP Ledger 发布 3.2.0 版本升级并启用 XRPLd 新品牌名

XRP Ledger发布了3.2.0版本,这是对其底层区块链基础设施的一次重要升级。本次更新的核心是将运行网络的软件名称从“rippled”更名为“xrpld”,以更好地反映整个项目生态。 与此前侧重于前端功能的版本不同,3.2.0版本优先进行了后端升级和效率提升,旨在增强网络性能并为未来的扩展做准备。关键改进包括内存优化措施,预计可节省高达40%的服务器内存使用。 此次升级引入了名为“fixCleanup3_2_0”的修改,为单资产金库、借贷协议、权限系统、去中心化交易所、多用途代币和权限域等多个模块带来了安全性增强。开发团队还新增了不变性检查,以确保已删除账户不会在账本上留下不一致的数据,从而加强整个网络的完整性和可靠性。 对于开发者而言,新版本增加了一项重要功能:应用程序无需连接服务器即可检索XRP Ledger协议和服务器定义信息,这将极大便利钱包、区块链浏览器和API等的开发工作。 在可扩展性和稳定性方面,更新包括可配置的区块大小、通过nuDB实现的高效数据库存储,以及将gRPC服务器的TLS/双向TLS支持改为可选,以提升企业用户的性能和连接性。此外,默认对等端口从51235更改为2459,并修复了涉及自动做市商、支付、代币托管、多用途代币、订单簿和RPC等多个方面的问题。出于性能考虑,3.2.0版本暂时禁用了交易不变性检查,但开发团队表示这不会构成安全威胁。

TheNewsCrypto1小时前

XRP Ledger 发布 3.2.0 版本升级并启用 XRPLd 新品牌名

TheNewsCrypto1小时前

交易

现货
合约

热门文章

如何购买SUI

欢迎来到HTX.com!我们已经让购买SUI Network(SUI)变得简单而便捷。跟随我们的逐步指南,放心开始您的加密货币之旅。第一步:创建您的HTX账户使用您的电子邮件、手机号码注册一个免费账户在HTX上。体验无忧的注册过程并解锁所有平台功能。立即注册第二步:前往买币页面,选择您的支付方式信用卡/借记卡购买:使用您的Visa或Mastercard即时购买SUI Network(SUI)。余额购买:使用您HTX账户余额中的资金进行无缝交易。第三方购买:探索诸如Google Pay或Apple Pay等流行支付方法以增加便利性。C2C购买:在HTX平台上直接与其他用户交易。HTX场外交易台(OTC)购买:为大量交易者提供个性化服务和竞争性汇率。第三步:存储您的SUI Network(SUI)购买完您的SUI Network(SUI)后,将其存储在您的HTX账户钱包中。您也可以通过区块链转账将其发送到其他地方或者用于交易其他加密货币。第四步:交易SUI Network(SUI)在HTX的现货市场轻松交易SUI Network(SUI)。访问您的账户,选择您的交易对,执行您的交易,并实时监控。HTX为初学者和经验丰富的交易者提供了友好的用户体验。

1.6k人学过发布于 2024.05.09更新于 2026.06.02

如何购买SUI

相关讨论

欢迎来到HTX社区。在这里,您可以了解最新的平台发展动态并获得专业的市场意见。以下是用户对SUI(SUI)币价的意见。

活动图片