Croyance ferme après la crise de sécurité : pourquoi SUI a-t-il toujours 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 entier" pour lancer une manipulation précise, entraînant une perte de plus de 200 millions de dollars d'actifs. Cet événement est non seulement l'un des plus grands accidents de sécurité dans le domaine DeFi jusqu'à présent cette année, mais il représente également la cyberattaque la plus destructrice depuis le lancement du mainnet SUI.
Selon les données de DefiLlama, le TVL total de 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 été instantanément réduit de 84 %, tombant à 38 millions de dollars. En conséquence, plusieurs jetons populaires sur SUI ont chuté de 76 % à 97 % en l'espace d'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 onde de choc, l'écosystème SUI a montré une grande résilience et capacité de récupération. Bien que l'incident Cetus ait entraîné des fluctuations de confiance à court terme, les fonds sur la chaîne et l'activité des utilisateurs n'ont pas subi de déclin durable, mais ont plutôt conduit à une attention significativement accrue de l'ensemble de l'écosystème sur la sécurité, la construction d'infrastructures et la qualité des projets.
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 de Slow Mist, les hackers ont réussi à exploiter une vulnérabilité d'overflow arithmétique clé dans le protocole, en utilisant des prêts éclair, 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 grossièrement divisé en trois étapes suivantes :
①Lancer un prêt flash, manipuler les prix
Les hackers ont d'abord utilisé un échange éclair avec un glissement maximal pour emprunter 10 milliards de haSUI par le biais d'un prêt éclair, empruntant ainsi d'énormes sommes d'argent 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é, de faible risque et de faible coût. Les hackers ont utilisé ce mécanisme pour faire chuter le prix du marché en peu de temps et le contrôler avec précision dans une fourchette très étroite.
Ensuite, l'attaquant se prépare à 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 du 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 des positions de liquidité étroites, déclarant qu'il ajoute 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 :
Masque réglé trop large : équivaut à une limite d'ajout de liquidité extrêmement élevée, rendant la validation des entrées de l'utilisateur dans le contrat complètement inefficace. Les hackers contournent la détection de dépassement en définissant des paramètres anormaux, construisant des entrées qui sont toujours inférieures à cette limite.
Débordement de données tronqué : lors de l'exécution d'une opération de décalage n << 64 sur la valeur n, un débordement de données s'est produit en raison d'un décalage dépassant la largeur de bits efficace du type de données uint256 (256 bits). La partie haute du débordement a été automatiquement abandonnée, ce qui a conduit à un résultat de calcul bien inférieur aux attentes, conduisant 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 égal à 1, ce qui signifie que le hacker n'a besoin d'ajouter qu'un seul jeton pour obtenir une immense liquidité.
③ retrait de liquidité
Effectuer le remboursement d'un prêt éclair tout en conservant d'énormes profits. Finalement, retirer des actifs de jetons d'une valeur totale de 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)
6000万美元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é est épuisée.
2.2 Causes et caractéristiques de la vulnérabilité
Cette vulnérabilité de Cetus présente trois caractéristiques :
Coût de réparation très faible : d'une part, la cause fondamentale de l'incident 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 strictement limitée à Cetus lui-même et n'est pas liée au code de SUI. La racine de la vulnérabilité réside dans une condition de frontière, il suffit de modifier deux lignes de code pour éliminer complètement le risque ; une fois la réparation terminée, elle peut être immédiatement déployée sur le réseau principal, garantissant que la logique des contrats ultérieurs est complète et éliminant cette vulnérabilité.
Haute discrétion : Le contrat fonctionne de manière stable et sans défauts depuis deux ans, le Cetus Protocol 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 champ d'audit.
Les hackers utilisent des valeurs extrêmes pour construire précisément des intervalles de transaction, créant ainsi des scénarios très rares de soumission d'une liquidité extrêmement élevée, ce qui déclenche une logique anormale. Cela montre 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 humaine, c'est pourquoi ils restent latents pendant longtemps avant d'être découverts.
Pas un problème exclusif à 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, avec une détection native des problèmes de débordement d'entiers dans des situations courantes. Ce débordement est survenu parce que lors de l'ajout de liquidités, une valeur incorrecte a d'abord été utilisée pour vérifier la limite supérieure du nombre de jetons requis, et que des opérations de décalage ont été utilisées à la place des opérations de multiplication habituelles. Si des opérations d'addition, de soustraction, de multiplication ou de division classiques avaient été effectuées, Move aurait automatiquement vérifié les cas de débordement, évitant ainsi ce problème de troncature des bits élevés.
Des vulnérabilités similaires sont également apparues dans d'autres langages (comme Solidity, Rust), et étaient même plus faciles à exploiter 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, des débordements d'addition, de soustraction et de multiplication se sont produits, la cause directe étant toujours que le résultat des opérations dépassait la plage. Par exemple, les vulnérabilités des contrats intelligents BEC et SMT en langage Solidity ont contourné les instructions de vérification dans le contrat à l'aide de paramètres soigneusement construits, réalisant ainsi des attaques par des transferts excessifs.
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 augmenter le débit des transactions, il ne peut pas fournir 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 faible, avec un seuil de gouvernance relativement élevé, rendant difficile pour les utilisateurs ordinaires d'influencer directement la gouvernance du réseau.
Nombre moyen de validateurs : 106
Durée moyenne d'Epoch : 24 heures
Mécanisme de processus :
Délégation des droits : les utilisateurs ordinaires n'ont pas besoin de faire fonctionner eux-mêmes un nœud, il leur suffit de mettre en gage SUI et de le déléguer à un validateurs candidats pour participer à 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 "embauchant" des validateurs de confiance. C'est également un grand avantage du DPoS par rapport au PoS traditionnel.
Représentant le tour de création de blocs : 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.
Élections dynamiques : à la fin de chaque cycle de vote, en fonction du poids des votes, un roulement dynamique est effectué pour réélire le groupe de Validators, garantissant la vitalité des nœuds, la cohérence des intérêts et la décentralisation.
Avantages de DPoS :
Haute efficacité : Grâce à un nombre contrôlable de nœuds de validation, le réseau peut réaliser des confirmations en millisecondes, répondant ainsi aux besoins élevés en TPS.
Coût faible : Moins de nœuds participent 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. Par conséquent, les coûts matériels et d'exploitation diminuent, les exigences en matière de puissance de calcul sont réduites, ce qui entraîne des coûts plus bas. Cela permet finalement d'obtenir des frais de transaction utilisateur plus bas.
Haute sécurité : les mécanismes de mise en jeu et de délégation amplifient les coûts et les risques d'attaque ; associés à un mécanisme de confiscation en chaîne, ils répriment 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é, exigeant qu'une majorité de plus des deux tiers des votes parmi les validateurs soit atteinte pour confirmer les transactions. Ce mécanisme garantit que même si un petit nombre de nœuds agissent de manière malveillante, le réseau peut rester sécurisé et fonctionner efficacement. Pour toute mise à niveau ou décision majeure, il est également nécessaire d'obtenir plus des deux tiers des votes avant de pouvoir mettre en œuvre.
Essentiellement, le DPoS est en réalité un compromis dans le triangle impossible, faisant un compromis entre décentralisation et efficacité. Dans le "triangle impossible" de la sécurité, de la décentralisation et de l'évolutivité, le DPoS choisit de réduire le nombre de nœuds de validation actifs pour obtenir des performances supérieures, renonçant à 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 La performance de SUI lors de cette attaque
3.2.1 Mécanisme de gel en fonctionnement
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 ajoutées à la chaîne. Les nœuds de validation sont des composants clés de la blockchain SUI, responsables de la validation 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 un mécanisme similaire à celui du 'gel de compte' dans la finance traditionnelle au niveau du consensus.
SUI intègre un mécanisme de liste de refus (deny list), qui est une fonction de liste noire permettant de bloquer toute transaction impliquant les adresses répertorié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 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 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 exprimer librement ses valeurs.
En réalité, pour assurer la cohérence et l'efficacité de la stratégie 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 d'urgence poussée par l'équipe SUI", c'est donc essentiellement la fondation SUI (ou les développeurs autorisés par elle) 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. Ainsi, bien que cette fonctionnalité protège les fonds des utilisateurs, elle a en essence 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 niveau protocolaire, elle ressemble plutôt à une couche de sécurité supplémentaire pour faire face à des situations imprévues et garantir la sécurité des fonds des utilisateurs.
Il s'agit essentiellement d'un mécanisme de garantie de sécurité. Semblable à une "chaîne de sécurité" attachée à la porte, elle ne s'active que contre ceux qui souhaitent s'introduire chez vous, c'est-à-dire ceux qui cherchent à mal utiliser le protocole. Pour les utilisateurs :
Pour les gros investisseurs, 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 de ces gros investisseurs. Pour assurer un développement durable du protocole, il est impératif de prioriser la sécurité.
Pour les petits investisseurs, contributeurs à l'activation de l'écosystème, de puissants soutiens à la co-construction technique et communautaire. Les équipes de projet espèrent également attirer les petits investisseurs à co-construire, afin de progressivement améliorer l'écosystème et d'augmenter le taux de rétention. En ce qui concerne le domaine de la DeFi, la sécurité des fonds reste la priorité.
Le critère pour juger "s'il est décentralisé" devrait être si les utilisateurs ont le contrôle de leurs actifs. À cet égard, SUI met en avant le contrôle des actifs des utilisateurs grâce au langage de programmation Move.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
14 J'aime
Récompense
14
6
Partager
Commentaire
0/400
LiquidityOracle
· Il y a 3h
L'expérience est l'expérience, ceux qui ont perdu grandissent~
Voir l'originalRépondre0
SchrodingersPaper
· 07-21 04:20
Encore une vague de Rekt, SUI m'a tué dix mille fois... mais je ne peux pas m'empêcher de vouloir suivre le pullback.
Voir l'originalRépondre0
MEVHunterLucky
· 07-21 04:18
sui est terrible, de toute façon je me souviens que je n'ai jamais perdu.
Résilience de l'écosystème SUI : Réflexions sur la sécurité après l'attaque de Cetus et analyse du potentiel de développement à long terme
Croyance ferme après la crise de sécurité : pourquoi SUI a-t-il toujours 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 entier" pour lancer une manipulation précise, entraînant une perte de plus de 200 millions de dollars d'actifs. Cet événement est non seulement l'un des plus grands accidents de sécurité dans le domaine DeFi jusqu'à présent cette année, mais il représente également la cyberattaque la plus destructrice depuis le lancement du mainnet SUI.
Selon les données de DefiLlama, le TVL total de 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 été instantanément réduit de 84 %, tombant à 38 millions de dollars. En conséquence, plusieurs jetons populaires sur SUI ont chuté de 76 % à 97 % en l'espace d'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 onde de choc, l'écosystème SUI a montré une grande résilience et capacité de récupération. Bien que l'incident Cetus ait entraîné des fluctuations de confiance à court terme, les fonds sur la chaîne et l'activité des utilisateurs n'ont pas subi de déclin durable, mais ont plutôt conduit à une attention significativement accrue de l'ensemble de l'écosystème sur la sécurité, la construction d'infrastructures et la qualité des projets.
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 de Slow Mist, les hackers ont réussi à exploiter une vulnérabilité d'overflow arithmétique clé dans le protocole, en utilisant des prêts éclair, 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 grossièrement divisé en trois étapes suivantes :
①Lancer un prêt flash, manipuler les prix
Les hackers ont d'abord utilisé un échange éclair avec un glissement maximal pour emprunter 10 milliards de haSUI par le biais d'un prêt éclair, empruntant ainsi d'énormes sommes d'argent 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é, de faible risque et de faible coût. Les hackers ont utilisé ce mécanisme pour faire chuter le prix du marché en peu de temps et le contrôler avec précision dans une fourchette très étroite.
Ensuite, l'attaquant se prépare à 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 du 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 des positions de liquidité étroites, déclarant qu'il ajoute 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 :
Masque réglé trop large : équivaut à une limite d'ajout de liquidité extrêmement élevée, rendant la validation des entrées de l'utilisateur dans le contrat complètement inefficace. Les hackers contournent la détection de dépassement en définissant des paramètres anormaux, construisant des entrées qui sont toujours inférieures à cette limite.
Débordement de données tronqué : lors de l'exécution d'une opération de décalage n << 64 sur la valeur n, un débordement de données s'est produit en raison d'un décalage dépassant la largeur de bits efficace du type de données uint256 (256 bits). La partie haute du débordement a été automatiquement abandonnée, ce qui a conduit à un résultat de calcul bien inférieur aux attentes, conduisant 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 égal à 1, ce qui signifie que le hacker n'a besoin d'ajouter qu'un seul jeton pour obtenir une immense liquidité.
③ retrait de liquidité
Effectuer le remboursement d'un prêt éclair tout en conservant d'énormes profits. Finalement, retirer des actifs de jetons d'une valeur totale de 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 :
2.2 Causes et caractéristiques de la vulnérabilité
Cette vulnérabilité de Cetus présente trois caractéristiques :
Coût de réparation très faible : d'une part, la cause fondamentale de l'incident 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 strictement limitée à Cetus lui-même et n'est pas liée au code de SUI. La racine de la vulnérabilité réside dans une condition de frontière, il suffit de modifier deux lignes de code pour éliminer complètement le risque ; une fois la réparation terminée, elle peut être immédiatement déployée sur le réseau principal, garantissant que la logique des contrats ultérieurs est complète et éliminant cette vulnérabilité.
Haute discrétion : Le contrat fonctionne de manière stable et sans défauts depuis deux ans, le Cetus Protocol 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 champ d'audit.
Les hackers utilisent des valeurs extrêmes pour construire précisément des intervalles de transaction, créant ainsi des scénarios très rares de soumission d'une liquidité extrêmement élevée, ce qui déclenche une logique anormale. Cela montre 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 humaine, c'est pourquoi ils restent latents pendant longtemps avant d'être découverts.
Move est supérieur à de nombreux langages de contrats intelligents en matière de sécurité des ressources et de vérification des types, avec une détection native des problèmes de débordement d'entiers dans des situations courantes. Ce débordement est survenu parce que lors de l'ajout de liquidités, une valeur incorrecte a d'abord été utilisée pour vérifier la limite supérieure du nombre de jetons requis, et que des opérations de décalage ont été utilisées à la place des opérations de multiplication habituelles. Si des opérations d'addition, de soustraction, de multiplication ou de division classiques avaient été effectuées, Move aurait automatiquement vérifié les cas de débordement, évitant ainsi ce problème de troncature des bits élevés.
Des vulnérabilités similaires sont également apparues dans d'autres langages (comme Solidity, Rust), et étaient même plus faciles à exploiter 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, des débordements d'addition, de soustraction et de multiplication se sont produits, la cause directe étant toujours que le résultat des opérations dépassait la plage. Par exemple, les vulnérabilités des contrats intelligents BEC et SMT en langage Solidity ont contourné les instructions de vérification dans le contrat à l'aide de paramètres soigneusement construits, réalisant ainsi des attaques par des transferts excessifs.
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 augmenter le débit des transactions, il ne peut pas fournir 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 faible, avec un seuil de gouvernance relativement élevé, rendant difficile pour les utilisateurs ordinaires d'influencer directement la gouvernance du réseau.
Mécanisme de processus :
Délégation des droits : les utilisateurs ordinaires n'ont pas besoin de faire fonctionner eux-mêmes un nœud, il leur suffit de mettre en gage SUI et de le déléguer à un validateurs candidats pour participer à 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 "embauchant" des validateurs de confiance. C'est également un grand avantage du DPoS par rapport au PoS traditionnel.
Représentant le tour de création de blocs : 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.
Élections dynamiques : à la fin de chaque cycle de vote, en fonction du poids des votes, un roulement dynamique est effectué pour réélire le groupe de Validators, garantissant la vitalité des nœuds, la cohérence des intérêts et la décentralisation.
Avantages de DPoS :
Haute efficacité : Grâce à un nombre contrôlable de nœuds de validation, le réseau peut réaliser des confirmations en millisecondes, répondant ainsi aux besoins élevés en TPS.
Coût faible : Moins de nœuds participent 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. Par conséquent, les coûts matériels et d'exploitation diminuent, les exigences en matière de puissance de calcul sont réduites, ce qui entraîne des coûts plus bas. Cela permet finalement d'obtenir des frais de transaction utilisateur plus bas.
Haute sécurité : les mécanismes de mise en jeu et de délégation amplifient les coûts et les risques d'attaque ; associés à un mécanisme de confiscation en chaîne, ils répriment 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é, exigeant qu'une majorité de plus des deux tiers des votes parmi les validateurs soit atteinte pour confirmer les transactions. Ce mécanisme garantit que même si un petit nombre de nœuds agissent de manière malveillante, le réseau peut rester sécurisé et fonctionner efficacement. Pour toute mise à niveau ou décision majeure, il est également nécessaire d'obtenir plus des deux tiers des votes avant de pouvoir mettre en œuvre.
Essentiellement, le DPoS est en réalité un compromis dans le triangle impossible, faisant un compromis entre décentralisation et efficacité. Dans le "triangle impossible" de la sécurité, de la décentralisation et de l'évolutivité, le DPoS choisit de réduire le nombre de nœuds de validation actifs pour obtenir des performances supérieures, renonçant à 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 La performance de SUI lors de cette attaque
3.2.1 Mécanisme de gel en fonctionnement
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 ajoutées à la chaîne. Les nœuds de validation sont des composants clés de la blockchain SUI, responsables de la validation 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 un mécanisme similaire à celui du 'gel de compte' dans la finance traditionnelle au niveau du consensus.
SUI intègre un mécanisme de liste de refus (deny list), qui est une fonction de liste noire permettant de bloquer toute transaction impliquant les adresses répertorié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 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 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 exprimer librement ses valeurs.
En réalité, pour assurer la cohérence et l'efficacité de la stratégie 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 d'urgence poussée par l'équipe SUI", c'est donc essentiellement la fondation SUI (ou les développeurs autorisés par elle) 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. Ainsi, bien que cette fonctionnalité protège les fonds des utilisateurs, elle a en essence 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 niveau protocolaire, elle ressemble plutôt à une couche de sécurité supplémentaire pour faire face à des situations imprévues et garantir la sécurité des fonds des utilisateurs.
Il s'agit essentiellement d'un mécanisme de garantie de sécurité. Semblable à une "chaîne de sécurité" attachée à la porte, elle ne s'active que contre ceux qui souhaitent s'introduire chez vous, c'est-à-dire ceux qui cherchent à mal utiliser le protocole. Pour les utilisateurs :
Pour les gros investisseurs, 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 de ces gros investisseurs. Pour assurer un développement durable du protocole, il est impératif de prioriser la sécurité.
Pour les petits investisseurs, contributeurs à l'activation de l'écosystème, de puissants soutiens à la co-construction technique et communautaire. Les équipes de projet espèrent également attirer les petits investisseurs à co-construire, afin de progressivement améliorer l'écosystème et d'augmenter le taux de rétention. En ce qui concerne le domaine de la DeFi, la sécurité des fonds reste la priorité.
Le critère pour juger "s'il est décentralisé" devrait être si les utilisateurs ont le contrôle de leurs actifs. À cet égard, SUI met en avant le contrôle des actifs des utilisateurs grâce au langage de programmation Move.