Foi inébranlable après la crise de la sécurité : pourquoi SUI possède-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, Cetus, déployé sur le réseau SUI, a subi une attaque de hacker. L'attaquant a exploité une faille 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 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 plus destructrice des attaques de hacker depuis le lancement du réseau principal 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, tandis que le montant verrouillé du protocole Cetus a immédiatement disparu de 84%, 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 de vives inquiétudes sur 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'événement Cetus ait entraîné des fluctuations de confiance à court terme, les fonds en chaîne et l'activité des utilisateurs n'ont pas subi de déclin prolongé, 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.
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é d'overflow arithmétique clé dans le protocole, en utilisant des prêts flash, une manipulation précise des prix et des défauts de contrat, et ont volé plus de 200 millions de dollars d'actifs numériques en peu de temps. Le chemin de l'attaque peut être divisé en trois étapes principales :
①Lancer un prêt éclair, manipuler les prix
Les hackers ont d'abord utilisé un échange éclair de 10 milliards de haSUI avec un slippage maximal, empruntant 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, en ne payant que des frais, avec des caractéristiques de levier élevé, de faible risque et de faible coût. Les hackers ont utilisé ce mécanisme pour abaisser le prix du marché en peu de temps et le contrôler avec précision dans une plage très étroite.
Ensuite, l'attaquant se prépare à créer une position de liquidité extrêmement étroite, en fixant précisément la plage de prix entre le prix le plus bas de 300 000 et le prix le plus élevé de 300 200, dont la largeur de prix n'est que de 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 é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éclare ajouter de la liquidité, mais en raison d'une vulnérabilité dans la fonction checked_shlw, ne reçoit finalement qu'un seul jeton.
C'est essentiellement dû à deux raisons :
Paramètres de masque trop larges : équivalent à une limite d'ajout de liquidité extrêmement élevée, ce qui rend la validation des entrées utilisateur dans le contrat pratiquement inutile. Les pirates exploitent des paramètres anormaux pour construire des entrées qui sont toujours inférieures à cette limite, contournant ainsi la détection de dépassement.
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 du déplacement dépassant la largeur de bits effective du type de données uint256 (256 bits). La partie supérieure débordante a été automatiquement abandonnée, ce qui a conduit à un résultat de calcul bien inférieur aux attentes, entraînant une sous-estimation par le système du nombre de haSUI requis pour l'échange. Le résultat final du calcul est d'environ moins de 1, mais comme il a été 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 échanger une énorme liquidité.
③ Retrait de liquidités
Effectuer le remboursement du prêt éclair, en conservant d'énormes bénéfices. En fin de compte, 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
490万美元Haedal Staked SUI
19,5 millions de dollars TOILET
D'autres jetons comme HIPPO et LOFI ont chuté de 75 à 80 %, la liquidité s'est tarie.
2.2 Causes et caractéristiques de la vulnérabilité
Cette faille 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 Cetus, et non une erreur dans le mécanisme de prix du protocole ou 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 SUI. La source de la vulnérabilité réside dans un jugement de condition limite, 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 la complétude logique des contrats ultérieurs et éliminant cette vulnérabilité.
Haute discrétion : Le contrat fonctionne sans interruption depuis deux ans avec zéro défaut, 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 utilisent des valeurs extrêmes pour construire précisément des plages de transactions, 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. Ce type de problème se situe souvent dans des zones d'ombre de la vision des gens, c'est pourquoi il peut rester caché pendant longtemps avant d'être découvert.
Ce n'est 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, et intègre une détection native des problèmes de dépassement d'entier dans des scénarios courants. Ce dépassement est survenu lors de l'ajout de liquidités, lorsque le nombre de jetons requis a d'abord été vérifié avec une valeur erronée pour la vérification de la limite, et que l'opération de décalage a été utilisée à la place de la multiplication conventionnelle. Dans Move, les opérations d'addition, de soustraction, de multiplication et de division vérifient automatiquement les dépassements, évitant ainsi ce problème de troncature de bits.
Des vulnérabilités similaires se sont également produites dans d'autres langages (comme Solidity, Rust), et sont 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, les vérifications de débordement étaient très faibles. Dans l'histoire, il y a eu des débordements d'addition, des débordements de soustraction, des débordements de multiplication, etc., dont la cause directe était 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 toutes deux contourné les déclarations de vérification dans le contrat grâce à des paramètres soigneusement construits, permettant ainsi d'effectuer 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 PoW (preuve de travail). Par conséquent, le niveau de décentralisation de SUI est relativement faible, le seuil de gouvernance est relativement élevé, et les utilisateurs ordinaires ont du mal à 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 de droits : Les utilisateurs ordinaires n'ont pas besoin de faire fonctionner un nœud 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 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ésente la génération de blocs par tour : 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 du DPoS :
Haute efficacité : Grâce à un nombre contrôlé de nœuds de production de blocs, le réseau peut confirmer en millisecondes, répondant aux besoins en haute 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 permet des coûts plus bas. Au final, cela a permis d'atteindre des frais d'utilisateur plus bas.
Haute sécurité : les mécanismes de staking et de délégation amplifient simultanément le coût et le risque des attaques ; combinés à un mécanisme de confiscation en chaîne, ils répriment 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 qu'une majorité de plus des deux tiers des votes des validateurs s'accorde 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 efficacement. Pour toute mise à niveau ou décision majeure, il est également nécessaire d'avoir plus des deux tiers des votes pour être mis en œuvre.
Essentiellement, le DPoS est en réalité un compromis dans le triangle impossible, qui fait le choix d'une décentralisation et d'une efficacité. Dans le "triangle impossible" de la sécurité-décetralisation-scalabilité, le DPoS opte pour une réduction du nombre de nœuds de validation actifs afin d'obtenir de meilleures performances, renonçant ainsi à un certain degré de décentralisation totale par rapport à un PoS ou PoW pur, mais améliorant considérablement le débit du réseau et la vitesse des transactions.
3.2 Performances de SUI lors de cette attaque
Le fonctionnement du mécanisme de gel 3.2.1
Dans cet événement, SUI a rapidement gelé les adresses liées à l'attaquant.
D'un point de vue du code, cela empêche les transactions de transfert d'être regroupées et enregistrées sur 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 ont en quelque sorte mis en œuvre un mécanisme similaire à celui de '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 fonctionnalité de liste noire permettant de bloquer toute transaction impliquant des adresses répertoriées. Étant donné que cette fonctionnalité 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 rapidement tous les validateurs un par un.
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. Quiconque exécute un nœud peut modifier ce fichier, le recharger à chaud ou redémarrer le nœud, et mettre à jour la liste. En apparence, chaque validateur semble libre d'exprimer ses propres 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 critique 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 ses développeurs autorisés) qui établit 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 réalité, la plupart des gens l'adoptent automatiquement par défaut. Ainsi, bien que cette fonctionnalité protège les fonds des utilisateurs, elle tend à avoir un certain degré de centralisation.
3.2.3 La nature de la fonction de liste noire
La fonction de liste noire n'est en réalité pas une logique de base du protocole, mais ressemble davantage à une couche de sécurité supplémentaire destinée à faire face à des situations imprévues 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 cherchent à pénétrer dans la maison, c'est-à-dire pour ceux qui souhaitent mal utiliser le protocole. Pour l'utilisateur :
Pour les gros investisseurs, principaux fournisseurs de liquidités, le protocole veut garantir la sécurité des fonds, car en réalité, les données on-chain tvl proviennent principalement des contributions des gros investisseurs. Pour assurer le développement à long terme du protocole, il est impératif de garantir la sécurité en premier lieu.
Pour les petits investisseurs, contributeurs à l'activité de l'écosystème, et soutiens solides de la construction technique et communautaire. L'équipe du projet espère également attirer les petits investisseurs pour co-construire, afin de parfaire progressivement l'écosystème et d'améliorer le taux de rétention. Quant au domaine de la defi, la sécurité des fonds reste la priorité.
Le facteur clé pour juger de "l'centralisation" est de savoir si les utilisateurs ont le contrôle de leurs actifs. À cet égard, SUI s'appuie sur 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.
11 J'aime
Récompense
11
5
Partager
Commentaire
0/400
Web3ProductManager
· Il y a 19h
en regardant les données de rétention des utilisateurs... ce hack pourrait être un point de friction majeur pour l'adoption de masse à vrai dire
Voir l'originalRépondre0
MEVHunterWang
· Il y a 19h
Un si grand bug, personne ne l'a remarqué ? Quelle surprise, quelle surprise.
Voir l'originalRépondre0
fren.eth
· Il y a 19h
C'est horrible, je suis vraiment malheureux, j'ai perdu plusieurs fois.
Voir l'originalRépondre0
¯\_(ツ)_/¯
· Il y a 19h
prendre les gens pour des idiots une fois de moins, hein ? Quand ça doit hausser, ça haussera.
Voir l'originalRépondre0
MetaverseMigrant
· Il y a 19h
Cette voiture n'est plus là, ceux qui osent entrer dans une position sont vraiment des guerriers.
Analyse de l'écosystème SUI : Résilience et potentiel de hausse à long terme après l'incident d'attaque de Cetus
Foi inébranlable après la crise de la sécurité : pourquoi SUI possède-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, Cetus, déployé sur le réseau SUI, a subi une attaque de hacker. L'attaquant a exploité une faille 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 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 plus destructrice des attaques de hacker depuis le lancement du réseau principal 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, tandis que le montant verrouillé du protocole Cetus a immédiatement disparu de 84%, 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 de vives inquiétudes sur 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'événement Cetus ait entraîné des fluctuations de confiance à court terme, les fonds en chaîne et l'activité des utilisateurs n'ont pas subi de déclin prolongé, 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.
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é d'overflow arithmétique clé dans le protocole, en utilisant des prêts flash, une manipulation précise des prix et des défauts de contrat, et ont volé plus de 200 millions de dollars d'actifs numériques en peu de temps. Le chemin de l'attaque peut être divisé en trois étapes principales :
①Lancer un prêt éclair, manipuler les prix
Les hackers ont d'abord utilisé un échange éclair de 10 milliards de haSUI avec un slippage maximal, empruntant 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, en ne payant que des frais, avec des caractéristiques de levier élevé, de faible risque et de faible coût. Les hackers ont utilisé ce mécanisme pour abaisser le prix du marché en peu de temps et le contrôler avec précision dans une plage très étroite.
Ensuite, l'attaquant se prépare à créer une position de liquidité extrêmement étroite, en fixant précisément la plage de prix entre le prix le plus bas de 300 000 et le prix le plus élevé de 300 200, dont la largeur de prix n'est que de 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 é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éclare ajouter de la liquidité, mais en raison d'une vulnérabilité dans la fonction checked_shlw, ne reçoit finalement qu'un seul jeton.
C'est essentiellement dû à deux raisons :
Paramètres de masque trop larges : équivalent à une limite d'ajout de liquidité extrêmement élevée, ce qui rend la validation des entrées utilisateur dans le contrat pratiquement inutile. Les pirates exploitent des paramètres anormaux pour construire des entrées qui sont toujours inférieures à cette limite, contournant ainsi la détection de dépassement.
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 du déplacement dépassant la largeur de bits effective du type de données uint256 (256 bits). La partie supérieure débordante a été automatiquement abandonnée, ce qui a conduit à un résultat de calcul bien inférieur aux attentes, entraînant une sous-estimation par le système du nombre de haSUI requis pour l'échange. Le résultat final du calcul est d'environ moins de 1, mais comme il a été 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 échanger une énorme liquidité.
③ Retrait de liquidités
Effectuer le remboursement du prêt éclair, en conservant d'énormes bénéfices. En fin de compte, 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
490万美元Haedal Staked SUI
19,5 millions de dollars TOILET
D'autres jetons comme HIPPO et LOFI ont chuté de 75 à 80 %, la liquidité s'est tarie.
2.2 Causes et caractéristiques de la vulnérabilité
Cette faille 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 Cetus, et non une erreur dans le mécanisme de prix du protocole ou 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 SUI. La source de la vulnérabilité réside dans un jugement de condition limite, 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 la complétude logique des contrats ultérieurs et éliminant cette vulnérabilité.
Haute discrétion : Le contrat fonctionne sans interruption depuis deux ans avec zéro défaut, 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 utilisent des valeurs extrêmes pour construire précisément des plages de transactions, 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. Ce type de problème se situe souvent dans des zones d'ombre de la vision des gens, c'est pourquoi il peut rester caché pendant longtemps avant d'être découvert.
Move est supérieur à de nombreux langages de contrats intelligents en matière de sécurité des ressources et de vérification des types, et intègre une détection native des problèmes de dépassement d'entier dans des scénarios courants. Ce dépassement est survenu lors de l'ajout de liquidités, lorsque le nombre de jetons requis a d'abord été vérifié avec une valeur erronée pour la vérification de la limite, et que l'opération de décalage a été utilisée à la place de la multiplication conventionnelle. Dans Move, les opérations d'addition, de soustraction, de multiplication et de division vérifient automatiquement les dépassements, évitant ainsi ce problème de troncature de bits.
Des vulnérabilités similaires se sont également produites dans d'autres langages (comme Solidity, Rust), et sont 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, les vérifications de débordement étaient très faibles. Dans l'histoire, il y a eu des débordements d'addition, des débordements de soustraction, des débordements de multiplication, etc., dont la cause directe était 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 toutes deux contourné les déclarations de vérification dans le contrat grâce à des paramètres soigneusement construits, permettant ainsi d'effectuer 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 PoW (preuve de travail). Par conséquent, le niveau de décentralisation de SUI est relativement faible, le seuil de gouvernance est relativement élevé, et les utilisateurs ordinaires ont du mal à 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 de droits : Les utilisateurs ordinaires n'ont pas besoin de faire fonctionner un nœud 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 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ésente la génération de blocs par tour : 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 du DPoS :
Haute efficacité : Grâce à un nombre contrôlé de nœuds de production de blocs, le réseau peut confirmer en millisecondes, répondant aux besoins en haute 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 permet des coûts plus bas. Au final, cela a permis d'atteindre des frais d'utilisateur plus bas.
Haute sécurité : les mécanismes de staking et de délégation amplifient simultanément le coût et le risque des attaques ; combinés à un mécanisme de confiscation en chaîne, ils répriment 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 qu'une majorité de plus des deux tiers des votes des validateurs s'accorde 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 efficacement. Pour toute mise à niveau ou décision majeure, il est également nécessaire d'avoir plus des deux tiers des votes pour être mis en œuvre.
Essentiellement, le DPoS est en réalité un compromis dans le triangle impossible, qui fait le choix d'une décentralisation et d'une efficacité. Dans le "triangle impossible" de la sécurité-décetralisation-scalabilité, le DPoS opte pour une réduction du nombre de nœuds de validation actifs afin d'obtenir de meilleures performances, renonçant ainsi à un certain degré de décentralisation totale par rapport à un PoS ou PoW pur, mais améliorant considérablement le débit du réseau et la vitesse des transactions.
3.2 Performances de SUI lors de cette attaque
Le fonctionnement du mécanisme de gel 3.2.1
Dans cet événement, SUI a rapidement gelé les adresses liées à l'attaquant.
D'un point de vue du code, cela empêche les transactions de transfert d'être regroupées et enregistrées sur 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 ont en quelque sorte mis en œuvre un mécanisme similaire à celui de '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 fonctionnalité de liste noire permettant de bloquer toute transaction impliquant des adresses répertoriées. Étant donné que cette fonctionnalité 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 rapidement tous les validateurs un par un.
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. Quiconque exécute un nœud peut modifier ce fichier, le recharger à chaud ou redémarrer le nœud, et mettre à jour la liste. En apparence, chaque validateur semble libre d'exprimer ses propres 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 critique 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 ses développeurs autorisés) qui établit 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 réalité, la plupart des gens l'adoptent automatiquement par défaut. Ainsi, bien que cette fonctionnalité protège les fonds des utilisateurs, elle tend à avoir un certain degré de centralisation.
3.2.3 La nature de la fonction de liste noire
La fonction de liste noire n'est en réalité pas une logique de base du protocole, mais ressemble davantage à une couche de sécurité supplémentaire destinée à faire face à des situations imprévues 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 cherchent à pénétrer dans la maison, c'est-à-dire pour ceux qui souhaitent mal utiliser le protocole. Pour l'utilisateur :
Pour les gros investisseurs, principaux fournisseurs de liquidités, le protocole veut garantir la sécurité des fonds, car en réalité, les données on-chain tvl proviennent principalement des contributions des gros investisseurs. Pour assurer le développement à long terme du protocole, il est impératif de garantir la sécurité en premier lieu.
Pour les petits investisseurs, contributeurs à l'activité de l'écosystème, et soutiens solides de la construction technique et communautaire. L'équipe du projet espère également attirer les petits investisseurs pour co-construire, afin de parfaire progressivement l'écosystème et d'améliorer le taux de rétention. Quant au domaine de la defi, la sécurité des fonds reste la priorité.
Le facteur clé pour juger de "l'centralisation" est de savoir si les utilisateurs ont le contrôle de leurs actifs. À cet égard, SUI s'appuie sur Move.