Foi solide 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'une attaque de hacker. L'attaquant a exploité une faille 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 incident est non seulement l'un des plus grands accidents de sécurité dans le domaine de la DeFi cette année, mais il constitue également la cyberattaque la plus dévastatrice depuis le lancement de la 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 rapidement disparu de 84%, tombant à 38 millions de dollars. En conséquence, plusieurs tokens 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é 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 sur la chaîne et l'activité des utilisateurs n'ont pas subi de déclin persistant, 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 Cetus
2.1 Processus de réalisation 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é d'overflow arithmétique dans le protocole, en utilisant des prêts flash, une manipulation précise des prix 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 éclair avec un glissement maximal de 10 milliards haSUI via un prêt éclair, empruntant d'importants 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é, de faible risque et de faible coût. Les hackers ont utilisé ce mécanisme pour faire baisser le prix du marché en peu de temps et l'ont contrôlé de manière précise dans une plage très étroite.
Ensuite, l'attaquant se prépare à créer une position de liquidité extrêmement étroite, en définissant avec précision l'intervalle de prix entre l'offre la plus basse à 300 000 et le prix le plus élevé à 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 liquidité énorme. Ensuite, 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 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 :
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 inutile. 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 de l'opération de décalage n << 64 sur la valeur numérique 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 de débordement haute 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 nécessaires pour l'échange. Le résultat final du calcul est d'environ moins de 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 pouvoir échanger une énorme liquidité.
③ Retrait de liquidités
Effectuer le remboursement du prêt flash, tout en conservant d'énormes profits. Finalement, retirer des pools de liquidité un total de plusieurs centaines de millions de dollars d'actifs en tokens.
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)
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é étant épuisée.
2.2 Les causes et caractéristiques de cette vulnérabilité
La vulnérabilité de Cetus présente trois caractéristiques :
Coût de réparation extrêmement bas : 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 du mécanisme de prix du protocole ou de 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 une vérification de condition limite, et 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 ainsi que la logique des contrats ultérieurs est complète et éliminant cette vulnérabilité.
Haute confidentialité : Le contrat a fonctionné sans faille pendant deux ans depuis son lancement, 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 d'audit.
Les hackers utilisent des valeurs extrêmes pour construire précisément des intervalles de transaction, créant des scénarios très rares de soumission d'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 les zones d'ombre de la perception humaine, c'est pourquoi il reste inaperçu pendant longtemps avant d'être découvert.
Ce n'est pas un problème exclusif à Move :
Move est supérieur à plusieurs 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 situations courantes. Ce dépassement est survenu lors de l'ajout de liquidité, lorsque le nombre de jetons requis a été calculé en utilisant d'abord une valeur incorrecte pour le contrôle de limite, et en remplaçant l'opération de multiplication habituelle par un décalage binaire. En revanche, si des opérations d'addition, de soustraction, de multiplication ou de division habituelles étaient utilisées dans Move, un contrôle de dépassement serait automatiquement effectué, évitant ainsi ce problème de troncature des bits supérieurs.
Des vulnérabilités similaires se sont également produites dans d'autres langages (comme Solidity, Rust), et elles 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, des débordements d'addition, de soustraction et de multiplication se sont produits, la cause directe étant que le résultat des calculs dépassait la plage. Par exemple, les vulnérabilités sur les deux contrats intelligents BEC et SMT du langage Solidity ont contourné les déclarations de vérification dans le contrat à l'aide de paramètres soigneusement construits, permettant ainsi des attaques par transfert excessif.
3. Mécanisme de consensus 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 offrir un niveau de décentralisation aussi élevé que celui de la preuve de travail (PoW). Par conséquent, le niveau de décentralisation de SUI est relativement faible, 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 de 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 les déléguer à des validateurs candidats pour participer à la garantie de 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 les tours de bloc : 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 du vote, un roulement dynamique est effectué pour réélire l'ensemble des Validateurs, garantissant la vitalité des nœuds, la cohérence des intérêts et la décentralisation.
Avantages du DPoS :
Haute efficacité : Grâce à un nombre contrôlé de nœuds de validation, le réseau peut confirmer en millisecondes, répondant aux besoins élevés en TPS.
Coûts réduits : Moins de nœuds participant au consensus, la bande passante 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 diminution des coûts matériels et d'exploitation, une baisse des exigences en matière de puissance de calcul et des coûts plus bas. En fin de compte, cela permet d'atteindre des frais d'utilisateur plus bas.
Haute sécurité : le mécanisme de mise en jeu et de délégation synchronise l'augmentation des coûts et des risques d'attaque ; associé au mécanisme de confiscation sur chaîne, il inhibe 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 soit atteinte pour confirmer une transaction. Ce mécanisme garantit que même si quelques nœuds agissent de manière malveillante, le réseau peut maintenir une opération sécurisée et efficace. Pour toute mise à niveau ou décision majeure, plus des deux tiers des votes sont également requis pour être mise en œuvre.
En substance, le DPoS est en réalité une sorte de compromis du triangle impossible, conciliant décentralisation et 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é, renonçant à 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 Fonctionnement du mécanisme de gel
Dans cet événement, SUI a rapidement gelé les adresses liées à l'attaquant.
D'un point de vue du code, cela rend impossible l'emballage des transactions de transfert sur la chaîne. Les nœuds de validation sont des composants essentiels 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, au niveau du consensus, un mécanisme similaire au "gel de compte" dans la finance traditionnelle.
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 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 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 modifier 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 assurer 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 a publié une liste noire, les validateurs peuvent théoriquement 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 présente 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, mais plutôt 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 à la porte, elle est activée uniquement pour ceux qui souhaitent pénétrer chez vous, c'est-à-dire pour ceux qui veulent nuire à l'accord. 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 tvl proviennent principalement de la contribution des gros investisseurs. Pour assurer le développement durable du protocole, il est impératif de prioriser la sécurité.
Pour les petits investisseurs, contributeurs à l'activité de l'écosystème, et fervents soutiens de la construction commune entre technologie et communauté. Les porteurs de projet espèrent également attirer les petits investisseurs pour co-construire, afin de perfectionner progressivement l'écosystème et d'augmenter le taux de rétention. Quant au domaine de la defi, la priorité reste la sécurité des fonds.
Le critère pour juger "si c'est décentralisé" devrait être si les utilisateurs ont le contrôle de leurs actifs. À cet égard, SUI met en œuvre cette idée 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.
10 J'aime
Récompense
10
6
Reposter
Partager
Commentaire
0/400
RektRecorder
· Il y a 8h
Première rangée de pertes massives sur le site
Voir l'originalRépondre0
LiquidityNinja
· Il y a 8h
Baissier, j'ai liquidé ma position.
Voir l'originalRépondre0
MevHunter
· Il y a 9h
Attendre le dump au fond, le temps est long.
Voir l'originalRépondre0
NeverVoteOnDAO
· Il y a 9h
Ce n'est pas la première fois que je me fais hacker, il faut s'habituer.
Voir l'originalRépondre0
BtcDailyResearcher
· Il y a 9h
Cut Loss sorti gg
Voir l'originalRépondre0
consensus_whisperer
· Il y a 9h
Vous voulez encore tromper les gens en rattrapant un couteau qui tombe après avoir explosé comme ça ?
L'écosystème SUI montre une résilience : analyse de l'upgrade de sécurité après l'attaque de Cetus et du potentiel de hausse à long terme.
Foi solide 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'une attaque de hacker. L'attaquant a exploité une faille 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 incident est non seulement l'un des plus grands accidents de sécurité dans le domaine de la DeFi cette année, mais il constitue également la cyberattaque la plus dévastatrice depuis le lancement de la 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 rapidement disparu de 84%, tombant à 38 millions de dollars. En conséquence, plusieurs tokens 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é 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 sur la chaîne et l'activité des utilisateurs n'ont pas subi de déclin persistant, 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 Cetus
2.1 Processus de réalisation 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é d'overflow arithmétique dans le protocole, en utilisant des prêts flash, une manipulation précise des prix 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 éclair avec un glissement maximal de 10 milliards haSUI via un prêt éclair, empruntant d'importants 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é, de faible risque et de faible coût. Les hackers ont utilisé ce mécanisme pour faire baisser le prix du marché en peu de temps et l'ont contrôlé de manière précise dans une plage très étroite.
Ensuite, l'attaquant se prépare à créer une position de liquidité extrêmement étroite, en définissant avec précision l'intervalle de prix entre l'offre la plus basse à 300 000 et le prix le plus élevé à 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 liquidité énorme. Ensuite, 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 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 :
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 inutile. 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 de l'opération de décalage n << 64 sur la valeur numérique 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 de débordement haute 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 nécessaires pour l'échange. Le résultat final du calcul est d'environ moins de 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 pouvoir échanger une énorme liquidité.
③ Retrait de liquidités
Effectuer le remboursement du prêt flash, tout en conservant d'énormes profits. Finalement, retirer des pools de liquidité un total de plusieurs centaines de millions de dollars d'actifs en tokens.
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)
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é étant épuisée.
2.2 Les causes et caractéristiques de cette vulnérabilité
La vulnérabilité de Cetus présente trois caractéristiques :
Coût de réparation extrêmement bas : 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 du mécanisme de prix du protocole ou de 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 une vérification de condition limite, et 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 ainsi que la logique des contrats ultérieurs est complète et éliminant cette vulnérabilité.
Haute confidentialité : Le contrat a fonctionné sans faille pendant deux ans depuis son lancement, 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 d'audit.
Les hackers utilisent des valeurs extrêmes pour construire précisément des intervalles de transaction, créant des scénarios très rares de soumission d'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 les zones d'ombre de la perception humaine, c'est pourquoi il reste inaperçu pendant longtemps avant d'être découvert.
Move est supérieur à plusieurs 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 situations courantes. Ce dépassement est survenu lors de l'ajout de liquidité, lorsque le nombre de jetons requis a été calculé en utilisant d'abord une valeur incorrecte pour le contrôle de limite, et en remplaçant l'opération de multiplication habituelle par un décalage binaire. En revanche, si des opérations d'addition, de soustraction, de multiplication ou de division habituelles étaient utilisées dans Move, un contrôle de dépassement serait automatiquement effectué, évitant ainsi ce problème de troncature des bits supérieurs.
Des vulnérabilités similaires se sont également produites dans d'autres langages (comme Solidity, Rust), et elles 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, des débordements d'addition, de soustraction et de multiplication se sont produits, la cause directe étant que le résultat des calculs dépassait la plage. Par exemple, les vulnérabilités sur les deux contrats intelligents BEC et SMT du langage Solidity ont contourné les déclarations de vérification dans le contrat à l'aide de paramètres soigneusement construits, permettant ainsi des attaques par transfert excessif.
3. Mécanisme de consensus 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 offrir un niveau de décentralisation aussi élevé que celui de la preuve de travail (PoW). Par conséquent, le niveau de décentralisation de SUI est relativement faible, 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 de 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 les déléguer à des validateurs candidats pour participer à la garantie de 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 les tours de bloc : 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 du vote, un roulement dynamique est effectué pour réélire l'ensemble des Validateurs, garantissant la vitalité des nœuds, la cohérence des intérêts et la décentralisation.
Avantages du DPoS :
Haute efficacité : Grâce à un nombre contrôlé de nœuds de validation, le réseau peut confirmer en millisecondes, répondant aux besoins élevés en TPS.
Coûts réduits : Moins de nœuds participant au consensus, la bande passante 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 diminution des coûts matériels et d'exploitation, une baisse des exigences en matière de puissance de calcul et des coûts plus bas. En fin de compte, cela permet d'atteindre des frais d'utilisateur plus bas.
Haute sécurité : le mécanisme de mise en jeu et de délégation synchronise l'augmentation des coûts et des risques d'attaque ; associé au mécanisme de confiscation sur chaîne, il inhibe 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 soit atteinte pour confirmer une transaction. Ce mécanisme garantit que même si quelques nœuds agissent de manière malveillante, le réseau peut maintenir une opération sécurisée et efficace. Pour toute mise à niveau ou décision majeure, plus des deux tiers des votes sont également requis pour être mise en œuvre.
En substance, le DPoS est en réalité une sorte de compromis du triangle impossible, conciliant décentralisation et 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é, renonçant à 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 Fonctionnement du mécanisme de gel
Dans cet événement, SUI a rapidement gelé les adresses liées à l'attaquant.
D'un point de vue du code, cela rend impossible l'emballage des transactions de transfert sur la chaîne. Les nœuds de validation sont des composants essentiels 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, au niveau du consensus, un mécanisme similaire au "gel de compte" dans la finance traditionnelle.
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 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 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 modifier 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 assurer 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 a publié une liste noire, les validateurs peuvent théoriquement 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 présente 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, mais plutôt 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 à la porte, elle est activée uniquement pour ceux qui souhaitent pénétrer chez vous, c'est-à-dire pour ceux qui veulent nuire à l'accord. 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 tvl proviennent principalement de la contribution des gros investisseurs. Pour assurer le développement durable du protocole, il est impératif de prioriser la sécurité.
Pour les petits investisseurs, contributeurs à l'activité de l'écosystème, et fervents soutiens de la construction commune entre technologie et communauté. Les porteurs de projet espèrent également attirer les petits investisseurs pour co-construire, afin de perfectionner progressivement l'écosystème et d'augmenter le taux de rétention. Quant au domaine de la defi, la priorité reste la sécurité des fonds.
Le critère pour juger "si c'est décentralisé" devrait être si les utilisateurs ont le contrôle de leurs actifs. À cet égard, SUI met en œuvre cette idée grâce au langage de programmation Move.