Croyance ferme après une crise de sécurité : pourquoi SUI a-t-il encore un potentiel de hausse à long terme ?

1. Une réaction en chaîne déclenché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'une attaque de hacker. L'attaquant a exploité une vulnérabilité logique liée à un "problème de débordement d'entier" pour effectuer un contrôle précis, entraînant une perte de plus de 200 millions de dollars d'actifs. Cet événement est non seulement l'un des plus grands incidents de sécurité dans le domaine de la DeFi cette année, mais il est également devenu la plus destructrice des attaques de hackers depuis le lancement du réseau principal SUI.

Selon les données de DefiLlama, le TVL de la chaîne SUI a chuté de plus de 330 millions de dollars le jour de l'attaque, tandis que le montant verrouillé du protocole Cetus a même disparu instantanément de 84%, tombant à 38 millions de dollars. En conséquence, plusieurs jetons populaires sur SUI ont chuté de 76% à 97% en seulement une heure, suscitant une large préoccupation du marché concernant la sécurité de SUI et la stabilité de son écosystème.

Mais après cette vague de chocs, l'écosystème SUI a montré une grande résilience et capacité de récupération. Bien que l'incident de Cetus ait entraîné des fluctuations de confiance à court terme, les fonds on-chain et l'activité des utilisateurs n'ont pas connu de déclin durable, au contraire, cela a conduit à une attention significativement accrue sur la sécurité, la construction d'infrastructures et la qualité des projets dans l'ensemble de l'écosystème.

Klein Labs va examiner les raisons de cet incident d'attaque, le mécanisme de consensus des nœuds de SUI, la sécurité du langage MOVE et le développement de l'écosystème de SUI, afin de clarifier le paysage actuel de cette blockchain qui est encore à un stade précoce de développement, et de discuter de 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é de débordement arithmétique clé dans le protocole, utilisant des prêts flash, une manipulation de prix précise et des défauts de contrat, pour voler plus de 200 millions de dollars d'actifs numériques en peu de temps. Le chemin d'attaque peut être divisé en trois étapes principales :

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

Les hackers ont d'abord utilisé un échange instantané avec un glissement maximum de 10 milliards de haSUI en prêt flash, empruntant un montant important de fonds pour manipuler les prix.

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

L'attaquant se prépare ensuite à créer une position de liquidité extrêmement étroite, en définissant avec précision 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 un nombre suffisant de jetons et une énorme liquidité. Par la suite, ils ont également manipulé plusieurs jetons sans valeur réelle.

②Ajouter de la liquidité

L'attaquant crée une position de liquidité étroite, 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 seul jeton.

C'est essentiellement dû à deux raisons :

1. La largeur de la configuration du masque est trop grande : équivalent à un plafond d'ajout de liquidité très élevé, ce qui rend la validation des entrées des utilisateurs dans le contrat complètement inefficace. Les hackers contournent la détection de débordement en définissant des paramètres anormaux, construisant des entrées qui sont toujours inférieures à ce plafond.

2. Dépassement de données tronqué : lors de l'exécution de l'opération de décalage n << 64 sur la valeur n, un dépassement de données s'est produit en raison du déplacement dépassant la largeur de bits effective du type de données uint256 (256 bits). La partie de dépassement de bits élevée a été automatiquement abandonnée, ce qui a conduit à un résultat de calcul 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 s'agit d'un arrondi vers le haut, le résultat final est donc égal à 1, ce qui signifie que le hacker n'a besoin d'ajouter qu'un seul jeton pour échanger une énorme liquidité.

③ Retrait de liquidité

Effectuer le remboursement de prêts instantanés, tout en conservant d'énormes profits. Finalement, retirer des actifs de jetons d'une valeur totale atteignant plusieurs centaines de millions de dollars de plusieurs pools de liquidité.

La situation des pertes 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 américains)

• 60 millions de dollars USDC

• 4,9 millions de dollars Haedal Staked SUI

• 19,5 millions de dollars TOILET

• D'autres jetons comme HIPPO et LOFI ont chuté de 75 à 80 %, la liquidité étant épuisée.

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

Les vulnérabilités de Cetus présentent trois caractéristiques :

1. Coût de réparation extrêmement bas : d'une part, la cause fondamentale de l'incident Cetus réside dans une négligence dans la bibliothèque mathématique de Cetus, et non dans une erreur de mécanisme de prix du protocole ou une erreur d'architecture sous-jacente. D'autre part, la vulnérabilité est strictement 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 frontière, 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 mainnet, garantissant ainsi que la logique des contrats ultérieurs soit complète et éliminant cette vulnérabilité.

2. Haute confidentialité : Le contrat fonctionne de manière stable sans aucune défaillance depuis deux ans, le protocole Cetus a subi plusieurs audits, mais aucune vulnérabilité n'a été trouvée, la principale raison étant que la bibliothèque Integer_Mate utilisée pour les calculs mathématiques n'a pas été incluse dans le périmètre de l'audit.

Les hackers exploitent des valeurs extrêmes pour construire précisément des intervalles de transaction, créant des scénarios très rares avec une liquidité extrêmement é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 d'ombre de la perception des gens, 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ébordement d'entiers dans des contextes courants. Ce débordement est survenu lors de l'ajout de liquidités, lorsque le nombre de jetons requis a d'abord été vérifié avec une valeur incorrecte pour le contrôle de la limite, et qu'une opération de décalage a été utilisée à la place d'une opération de multiplication conventionnelle. Si des opérations conventionnelles d'addition, de soustraction, de multiplication ou de division étaient utilisées, Move vérifierait automatiquement les cas de débordement, évitant ainsi ce problème de troncature des bits supérieurs.

Des vulnérabilités similaires sont également apparues dans d'autres langages (comme Solidity, Rust), et ont même été 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 grâce à des paramètres soigneusement construits, permettant ainsi une attaque par transfert excessif.

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 degré de décentralisation aussi élevé que le PoW (preuve de travail). Par conséquent, le degré de décentralisation de SUI est relativement faible, avec une barrière à l'entrée pour la gouvernance relativement élevée, rendant 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 de faire fonctionner des nœuds eux-mêmes, il leur suffit de staker SUI et de le déléguer à 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 d'entrée pour les utilisateurs ordinaires, leur permettant de participer au consensus du réseau en "embauchant" des validateurs de confiance. C'est également un grand avantage du DPoS par rapport au PoS traditionnel.

• Représentation de l'itération de blocs : un nombre restreint de validateurs choisis 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 à un nombre contrôlé de nœuds de production de blocs, le réseau peut réaliser des confirmations en millisecondes, répondant ainsi à la demande élevée de TPS.

• Coût faible : Moins de nœuds participant au consensus, la bande passante réseau et les ressources de calcul nécessaires pour la synchronisation des informations et l'agrégation des signatures sont considérablement réduites. Cela entraîne une baisse des coûts matériels et de maintenance, une diminution des exigences en matière de puissance de calcul, et donc des coûts plus bas. Cela permet finalement de réaliser des frais d'utilisateur plus bas.

• Haute sécurité : le mécanisme de mise en jeu et de délégation augmente simultanément le coût et le risque d'attaque ; associé au mécanisme de confiscation sur la chaîne, cela réduit efficacement les comportements malveillants.

En même temps, le mécanisme de consensus de SUI utilise un algorithme basé sur le BFT (tolérance aux pannes byzantines), exigeant que plus des deux tiers des votes des validateurs soient en accord pour confirmer une transaction. 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 de manière efficace. Pour toute mise à niveau ou décision majeure, il est également nécessaire d'avoir plus des deux tiers des votes pour être mise en œuvre.

En essence, le DPoS est en réalité un compromis au sein du triangle impossible, cherchant à équilibrer décentralisation et efficacité. Dans le "triangle impossible" de la sécurité - décentralisation - évolutivité, le DPoS choisit de réduire le nombre de nœuds de validation actifs pour obtenir de meilleures performances, renonçant ainsi à un certain degré de décentralisation complète par rapport au PoS pur ou au PoW, mais améliorant considérablement le débit du réseau et la vitesse des transactions.

3.2 lors de cette attaque, SUI a montré une performance

3.2.1 fonctionnement du mécanisme de gel

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

D'un point de vue code, cela empêche les transactions de transfert d'être empaquetées sur la chaîne. Les nœuds de validation sont des composants clés de la blockchain SUI, chargés de valider les transactions et d'appliquer les 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 une fonction de liste de refus (deny list), qui est une fonctionnalité de liste noire permettant de bloquer toute transaction impliquant des adresses listées. Étant donné que cette fonction est déjà présente dans le client, lorsque l'attaque se produit,

SUI peut immédiatement geler l'adresse des hackers. 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 dans un court laps 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 politiques de sécurité, la mise à jour de ces configurations clés 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 configure et met à jour cette liste de refus.

SUI publie une liste noire, en théorie, les validateurs peuvent choisir de l'adopter ou non ------ mais en pratique, 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 essence un certain degré de centralisation.

3.2.3 La nature de la fonction de liste noire

La fonctionnalité de liste noire n'est en réalité pas une logique de niveau protocolaire, mais plutôt une couche de sécurité supplémentaire destinée à faire face aux 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 à une porte, elle n'est activée que pour ceux qui souhaitent s'introduire chez vous, c'est-à-dire pour ceux qui cherchent à nuire au protocole. Pour l'utilisateur :

• Pour les gros investisseurs, principaux fournisseurs de liquidité, le protocole souhaite avant tout garantir la sécurité des fonds, car en réalité, les données on-chain de tvl proviennent entièrement de la contribution des principaux gros investisseurs. Pour assurer le développement à long terme du protocole, il est impératif de donner la priorité à la sécurité.

• Pour les petits investisseurs, contributeurs à l'activité de l'écosystème, et forts soutiens à la co-construction technique et communautaire. L'équipe du projet espère également attirer les petits investisseurs à co-construire.