Foi inébranlable après la crise de sécurité : pourquoi SUI a-t-il encore un potentiel de hausse à long terme ?

1. Une réaction en chaîne provoquée par une attaque

Le 22 mai 2025, le protocole AMM de premier plan déployé sur le réseau SUI, Cetus, a été victime d'un piratage. Les attaquants ont exploité une faille logique liée à un "problème de débordement entier" pour mener une manipulation précise, entraînant une perte de plus de 200 millions de dollars d'actifs. Cet incident est non seulement l'un des plus grands accidents de sécurité dans le domaine de la DeFi cette année, mais il est également devenu la cyberattaque la plus destructrice depuis le lancement du réseau principal SUI.

Selon les données de DefiLlama, la TVL totale de la chaîne SUI a chuté de plus de 330 millions de dollars le jour de l'attaque, et le montant verrouillé du protocole Cetus a même évaporé 84% en un instant, tombant à 38 millions de dollars. En conséquence, plusieurs jetons populaires sur SUI (y compris Lofi, Sudeng, Squirtle, etc.) ont chuté de 76% à 97% en seulement une heure, suscitant une large préoccupation du marché concernant la sécurité et la stabilité de l'écosystème SUI.

Mais après cette onde de choc, l'écosystème SUI a montré une grande résilience et capacité de récupération. Bien que l'événement Cetus ait provoqué des fluctuations de confiance à court terme, les fonds en chaîne et l'activité des utilisateurs n'ont pas subi de déclin durable, mais ont plutôt incité l'ensemble de l'écosystème à accorder une attention significative à la sécurité, à la construction d'infrastructures et à la qualité des projets.

Klein Labs se concentrera sur les raisons de cet incident d'attaque, le mécanisme de consensus des nœuds SUI, la sécurité du langage MOVE et le développement de l'écosystème SUI, afin de clarifier le paysage actuel de cet écosystème de blockchain, qui en est encore à ses débuts, et d'explorer son potentiel de développement futur.

2. Analyse des causes de l'attaque de l'événement Cetus

2.1 Processus de mise en œuvre de l'attaque

Selon l'analyse technique de l'incident d'attaque de Cetus par l'équipe Slow Mist, les hackers ont réussi à exploiter une vulnérabilité clé de dépassement arithmétique dans le protocole, en utilisant des prêts flash, des manipulations de prix précises et des défauts de contrat pour voler en peu de temps plus de 200 millions de dollars d'actifs numériques. Le chemin de l'attaque peut être approximativement divisé en trois étapes :

①Lancer un prêt éclair, manipuler les prix

Les hackers ont d'abord utilisé un prêt flash de 10 milliards de haSUI avec un slippage maximal, empruntant d'énormes sommes pour manipuler les prix.

Le prêt éclair permet aux utilisateurs d'emprunter et de rembourser des fonds dans une seule transaction, en ne payant que des frais, avec des caractéristiques de levier élevé, de faible risque et de faible coût. Les hackers ont exploité ce mécanisme pour faire chuter rapidement le prix du marché et le contrôler de manière précise dans une plage très étroite.

Ensuite, l'attaquant prépare à créer une position de liquidité extrêmement étroite, en définissant précisément la plage de prix entre l'offre la plus basse de 300,000 et le prix le plus élevé de 300,200, avec une largeur de prix de seulement 1.00496621 %.

Grâce à la méthode ci-dessus, les hackers ont réussi à manipuler le prix de haSUI en utilisant une quantité suffisante de jetons et une immense liquidité. Par la suite, ils ont également manipulé plusieurs jetons sans valeur réelle.

②Ajouter de la liquidité

L'attaquant crée des positions de liquidité étroites, déclare ajouter de la liquidité, mais en raison d'une vulnérabilité dans la fonction checked_shlw, il ne reçoit finalement qu'un token.

C'est essentiellement dû à deux raisons :

1. Paramètres de masque trop larges : équivalent à une limite d'ajout de liquidité extrêmement élevée, rendant la vérification des entrées utilisateur dans le contrat inefficace. Les hackers contournent la détection de dépassement en configurant des paramètres anormaux, construisant des entrées qui sont toujours inférieures à cette limite.

2. Troncature de débordement de données : Lors de l'exécution de l'opération de décalage n << 64 sur la valeur n, un débordement s'est produit car le décalage dépassait la largeur de bits valide du type de données uint256 (256 bits). La partie de débordement haute a été automatiquement abandonnée, ce qui a conduit à un résultat d'opération bien inférieur aux attentes, amenant ainsi le système à sous-estimer le nombre de haSUI nécessaires pour l'échange. Le résultat final du calcul est d'environ inférieur à 1, mais comme il est arrondi à l'entier supérieur, le résultat final est donc égal à 1, ce qui signifie que le hacker n'a besoin d'ajouter qu'un seul jeton pour obtenir une énorme liquidité.

③ Retrait de liquidité

Effectuer le remboursement du prêt flash, tout en conservant d'énormes bénéfices. Finalement, retirer des actifs tokens d'une valeur totale de plusieurs centaines de millions de dollars de plusieurs pools de liquidité.

La situation de perte de fonds est grave, l'attaque a entraîné le vol des actifs suivants :

• 12,9 millions de SUI (environ 5,4 millions de dollars)

• 60 millions de dollars USDC

• 490 millions de dollars Haedal Staked SUI

• 19,5 millions de dollars TOILET

• D'autres tokens comme HIPPO et LOFI ont chuté de 75 à 80 %, la liquidité s'épuisant.

2.2 Causes et caractéristiques de la vulnérabilité

Cette vulnérabilité de Cetus présente trois caractéristiques :

1. Coût de réparation extrêmement bas : d'une part, la cause fondamentale de l'incident de Cetus est une négligence dans la bibliothèque mathématique de Cetus, et non une erreur dans le mécanisme de prix du protocole ou une erreur dans l'architecture sous-jacente. D'autre part, la vulnérabilité est limitée à Cetus lui-même et n'est pas liée au code de SUI. La source de la vulnérabilité réside dans un jugement de condition de limite, et il suffit de modifier deux lignes de code pour éliminer complètement le risque ; une fois la réparation effectuée, elle peut être immédiatement déployée sur le réseau principal, garantissant ainsi que la logique des contrats ultérieurs est complète et éliminant cette vulnérabilité.

2. Haute dissimulation : Le contrat a fonctionné de manière stable sans aucune panne pendant deux ans, le protocole Cetus a subi plusieurs audits, mais aucune vulnérabilité n'a été trouvée, la raison principale étant que la bibliothèque Integer_Mate utilisée pour les calculs mathématiques n'a pas été incluse dans le champ d'audit.

Les hackers utilisent des valeurs extrêmes pour construire avec précision des plages de transactions, créant des scénarios extrêmement rares avec une liquidité très élevée, ce qui déclenche une logique anormale, indiquant que ce type de problème est difficile à détecter par des tests ordinaires. Ces problèmes se situent souvent dans des zones aveugles de la perception humaine, et c'est pourquoi ils restent latents pendant longtemps avant d'être découverts.

3. Ce n'est pas un problème propre à Move :

Move est supérieur à de nombreux langages de contrats intelligents en matière de sécurité des ressources et de vérification des types, intégrant une détection native des problèmes de dépassement d'entier dans des scénarios courants. Ce dépassement est dû à une vérification erronée de la valeur maximale lors du calcul du nombre de jetons nécessaires lors de l'ajout de liquidités, utilisant d'abord une valeur incorrecte pour la vérification de la limite supérieure, et remplaçant l'opération de multiplication habituelle par un décalage binaire. En revanche, avec les opérations d'addition, de soustraction, de multiplication et de division habituelles, Move vérifie automatiquement les situations de dépassement, évitant ainsi ce problème de troncature de bits élevés.

Des vulnérabilités similaires ont également été observées dans d'autres langages (comme Solidity, Rust), et étaient même plus facilement exploitées en raison de leur manque de protection contre les débordements d'entiers ; avant la mise à jour de la version de Solidity, la vérification des débordements était très faible. Historiquement, il y a eu des débordements d'addition, de soustraction, de multiplication, etc., dont la cause directe était que le résultat de l'opération dépassait la plage. Par exemple, les vulnérabilités des contrats intelligents BEC et SMT dans le langage Solidity ont contourné les instructions de vérification dans le contrat en utilisant des paramètres soigneusement construits, ce qui a permis des transferts excessifs pour réaliser des attaques.

3. Mécanisme de consensus de SUI

3.1 Introduction au mécanisme de consensus SUI

Aperçu :

SUI adopte un cadre de Preuve d'Enjeu Déléguée (DeleGated Proof of Stake, abrégé DPoS)). Bien que le mécanisme DPoS puisse améliorer le débit des transactions, il ne peut pas offrir un niveau de décentralisation aussi élevé que le PoW (Preuve de Travail). Par conséquent, le niveau de décentralisation de SUI est relativement bas, le seuil de gouvernance est relativement élevé, et il est difficile pour les utilisateurs ordinaires d'influencer directement la gouvernance du réseau.

• Nombre moyen de validateurs : 106

• Durée moyenne de l'Epoch : 24 heures

Mécanisme de processus :

• Délégation des droits : Les utilisateurs ordinaires n'ont pas besoin d'exécuter eux-mêmes un nœud, il leur suffit de déléguer leurs SUI à des validateurs candidats pour participer à la garantie de la sécurité du réseau et à la distribution des récompenses. Ce mécanisme peut réduire le seuil de participation pour les utilisateurs ordinaires, leur permettant de participer au consensus du réseau en "employant" des validateurs de confiance. C'est également un grand avantage du DPoS par rapport au PoS traditionnel.

• Représente le tour de validation : un petit nombre de validateurs sélectionnés produisent des blocs dans un ordre fixe ou aléatoire, ce qui améliore la vitesse de confirmation et augmente le TPS.

• Élection dynamique : À la fin de chaque cycle de vote, en fonction du poids des votes, une rotation dynamique est effectuée pour réélire l'ensemble des Validateurs, garantissant la vitalité des nœuds, la cohérence des intérêts et la décentralisation.

Les avantages de DPoS :

• Haute efficacité : grâce au nombre contrôlable de nœuds de validation, le réseau peut confirmer en millisecondes, répondant ainsi à la demande élevée de TPS.

• Coût réduit : moins de nœuds participant au consensus, ce qui réduit considérablement la bande passante réseau et les ressources de calcul nécessaires pour la synchronisation des informations et l'agrégation des signatures. Cela réduit les coûts matériels et d'exploitation, diminue les exigences en matière de puissance de calcul et entraîne des coûts plus bas. En fin de compte, cela permet de réaliser des frais de transaction utilisateurs plus bas.

• Haute sécurité : les mécanismes de mise en jeu et de délégation synchronisent l'augmentation des coûts et des risques d'attaque ; associés au mécanisme de saisie sur chaîne, ils inhibent efficacement les comportements malveillants.

En même temps, dans le mécanisme de consensus de SUI, un algorithme basé sur le BFT (tolérance aux pannes byzantines) est utilisé, nécessitant qu'un vote de plus des deux tiers des validateurs parvienne à un consensus pour confirmer les transactions. Ce mécanisme garantit que même si quelques nœuds agissent de manière malveillante, le réseau peut rester sécurisé et fonctionner efficacement. Pour effectuer toute mise à niveau ou prendre des décisions importantes, un vote de plus des deux tiers est également requis pour la mise en œuvre.

En essence, le DPoS est en réalité une solution de compromis au triangle impossible, faisant le choix d'une centralisation et d'une efficacité. Le DPoS choisit de réduire le nombre de nœuds de validation actifs pour obtenir de meilleures performances dans le "triangle impossible" de la sécurité, de la décentralisation et de l'évolutivité, abandonnant ainsi un certain degré de décentralisation complète par rapport au PoS pur ou au PoW, mais améliorant de manière significative le débit du réseau et la vitesse des transactions.

3.2 La performance de SUI lors de cette attaque

3.2.1 Mécanisme de gel en fonctionnement

Lors de cet incident, SUI a rapidement gelé les adresses liées à l'attaquant.

D'un point de vue technique, cela empêche les transactions de transfert d'être enregistrées sur la blockchain. Les nœuds de validation sont des composants essentiels de la blockchain SUI, responsables de la vérification des transactions et de l'exécution des règles du protocole. En ignorant collectivement les transactions liées à l'attaquant, ces validateurs mettent en œuvre, au niveau du consensus, un mécanisme similaire à celui du 'gel de compte' dans la finance traditionnelle.

SUI intègre en lui-même un mécanisme de liste de refus (deny list), qui est une fonction de liste noire permettant d'empêcher toute transaction impliquant les adresses répertoriées. Étant donné que cette fonctionnalité existe déjà dans le client, lorsque l'attaque se produit,

SUI peut immédiatement geler l'adresse d'un hacker. Sans cette fonctionnalité, même si SUI n'a que 113 validateurs, il serait difficile pour Cetus de coordonner tous les validateurs un par un en peu de temps.

3.2.2 Qui a le pouvoir de modifier la liste noire ?

TransactionDenyConfig est un fichier de configuration YAML/TOML chargé localement par chaque validateur. Toute personne exécutant un nœud peut éditer ce fichier, le recharger à chaud ou redémarrer le nœud, et mettre à jour la liste. En surface, chaque validateur semble libre d'exprimer ses propres valeurs.

En réalité, pour garantir la cohérence et l'efficacité des stratégies de sécurité, la mise à jour de cette configuration clé est généralement coordonnée. Étant donné qu'il s'agit d'une "mise à jour urgente poussée par l'équipe SUI", c'est essentiellement la fondation SUI (ou les développeurs autorisés par celle-ci) qui établit et met à jour cette liste de refus.

SUI publie une liste noire, théoriquement les validateurs peuvent choisir de l'adopter ou non ------ mais en réalité, la plupart des gens l'adoptent automatiquement par défaut. Par conséquent, bien que cette fonctionnalité protège les fonds des utilisateurs, elle a en réalité un certain degré de centralisation.

3.2.3 L'essence de la fonction de liste noire

La fonction de liste noire n'est en réalité pas une logique de base du protocole, elle ressemble plutôt à une couche de sécurité supplémentaire destinée à faire face à des situations d'urgence et à garantir la sécurité des fonds des utilisateurs.

C'est essentiellement un mécanisme de garantie de sécurité. Semblable à une "chaîne de sécurité" attachée à la porte, elle ne s'active que pour ceux qui souhaitent entrer par effraction, c'est-à-dire pour ceux qui maltraitent le protocole. Pour l'utilisateur :

• Pour les gros détenteurs, principaux fournisseurs de liquidité, le protocole cherche avant tout à garantir la sécurité des fonds, car en réalité, les données on-chain TVL proviennent principalement des contributions des gros détenteurs. Pour assurer le développement durable du protocole, il est impératif de garantir la sécurité en priorité.

• Pour les petits investisseurs, une forte contribution à l'animation de l'écosystème, la co-construction technique et communautaire.