Foi indéfectible après la crise de sécurité : pourquoi SUI possède-t-il encore un potentiel de hausse à long terme ?
1. Une réaction en chaîne déclenchée par une attaque
Le 22 mai 2025, le protocole AMM de premier plan Cetus, déployé sur le réseau SUI, a été victime d'une attaque de hacker. L'attaquant a exploité une faille logique liée à un "problème de débordement entier" pour lancer un contrôle précis, entraînant des pertes de plus de 200 millions de dollars d'actifs. Cet incident est non seulement l'une des plus grandes affaires de sécurité dans le domaine de la DeFi jusqu'à présent cette année, mais il est également devenu la plus destructrice des attaques de hackers depuis le lancement du réseau principal de SUI.
Selon les données de DefiLlama, la TVL totale 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é réduit de 84 % en un instant, tombant à 38 millions de dollars. Par conséquent, plusieurs tokens populaires sur SUI ont connu une chute de 76 % à 97 % en seulement une heure, suscitant une large préoccupation du marché concernant la sécurité de SUI et la stabilité de son écosystème.
Mais après cette onde de choc, l'écosystème SUI a montré une grande résilience et une 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 durable, mais ont plutôt incité l'ensemble de l'écosystème à accorder une attention significative à la sécurité, à la construction d'infrastructures et à la qualité des projets.
Klein Labs va examiner les raisons de cet incident d'attaque, le mécanisme de consensus des nœuds de SUI, la sécurité du langage MOVE et le développement de l'écosystème de SUI, afin de dresser un état des lieux de l'écosystème actuel de cette blockchain encore en phase de développement précoce, et d'explorer son potentiel de développement futur.
2. Analyse des causes de l'attaque de l'événement Cetus
2.1 Processus de mise en œuvre de l'attaque
Selon l'analyse technique de l'incident d'attaque de Cetus par l'équipe Slow Mist, les hackers ont réussi à exploiter une vulnérabilité d'arithmétique clé 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 de l'attaque peut être généralement divisé en trois phases :
①Lancer un prêt éclair, manipuler les prix
Les hackers ont d'abord utilisé un prêt flash de 10 milliards de haSUI avec un glissement maximal pour emprunter une grande quantité de fonds et 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 exploité 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.
L'attaquant se prépare ensuite à créer une position de liquidité extrêmement étroite, en définissant précisément la plage de prix entre l'offre la plus basse de 300 000 et le prix le plus élevé de 300 200, avec une largeur de prix de seulement 1,00496621 %.
Grâce à la méthode ci-dessus, les hackers ont réussi à manipuler le prix de haSUI en utilisant un nombre suffisant de tokens et une énorme liquidité. Par la suite, ils ont également manipulé plusieurs tokens sans valeur réelle.
②Ajouter de la liquidité
L'attaquant crée une position de liquidité étroite, 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 : équivalent à une limite d'ajout de liquidité extrêmement élevée, rendant la vérification 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épassement de données tronqué : lors de l'exécution de l'opération de décalage n << 64 sur la valeur n, un dépassement de la largeur de bit efficace du type de données uint256 (256 bits) se produit, entraînant une troncature des données. La partie de débordement est automatiquement abandonnée, ce qui fait que le résultat du calcul est bien en dessous des attentes, amenant ainsi le système à sous-estimer le nombre de haSUI nécessaires pour l'échange. Le résultat final du calcul est d'environ moins de 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 énorme liquidité.
③ Retrait de liquidité
Effectuer le remboursement d'un prêt éclair, tout en conservant d'énormes profits. Finalement, retirer des actifs de tokens d'une valeur totale atteignant plusieurs centaines de millions de dollars de plusieurs pools de liquidités.
La situation des pertes financières 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 millions de dollars Haedal Staked SUI
19,5 millions de dollars TOILET
D'autres tokens comme HIPPO et LOFI ont chuté de 75 à 80 %, la liquidité s'épuise.
2.2 Causes et caractéristiques de cette vulnérabilité
La faille de Cetus présente trois caractéristiques :
Coût de réparation extrêmement bas : d'une part, la cause fondamentale de l'incident de Cetus est une erreur dans la bibliothèque mathématique de 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 limitée à Cetus lui-même et n'a rien à voir avec le code de SUI. La racine de la vulnérabilité réside dans un jugement de condition de frontière, il suffit de modifier deux lignes de code pour éliminer complètement le risque ; une fois la réparation 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 sans aucune défaillance depuis deux ans, le Cetus Protocol a été audité plusieurs fois, mais aucune vulnérabilité n'a été découverte, la raison principale é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 intervalles de transaction, créant des scénarios très rares avec une liquidité exceptionnellement élevée, ce qui déclenche une logique anormale, indiquant que ce type de problème est difficile à détecter par des tests ordinaires. Ces problèmes se situent souvent dans des zones d'ombre de la perception humaine, c'est pourquoi ils restent latents pendant longtemps avant d'être découverts.
Ce n'est pas un problème exclusif à Move :
Move est supérieur à de nombreux langages de contrat intelligent 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 dû à l'utilisation d'une valeur incorrecte pour le contrôle de la limite lors du calcul du nombre de jetons requis pour ajouter de la liquidité, et à l'utilisation d'opérations de décalage à la place de l' multiplication conventionnelle. Si des opérations de base comme l'addition, la soustraction, la multiplication et la division étaient utilisées, Move vérifierait automatiquement les situations de débordement, évitant ainsi ce problème de troncature de bits élevés.
Des vulnérabilités similaires sont également apparues dans d'autres langages (comme Solidity, Rust), et peuvent même être plus facilement exploitées en raison de leur manque de protection contre le débordement d'entier ; 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 ont eu lieu, la cause directe étant 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 détection dans le contrat grâce à des paramètres soigneusement construits, permettant ainsi 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 augmenter le débit des transactions, il ne peut pas offrir un niveau de décentralisation aussi élevé que le PoW (preuve de travail). Par conséquent, le niveau de décentralisation de SUI est relativement 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 eux-mêmes un nœud, ils peuvent simplement staker SUI et le déléguer à des 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 "employant" des validateurs de confiance. C'est également un grand avantage de DPoS par rapport à PoS traditionnel.
Représente le tour de production 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.
Élection dynamique : à la fin de chaque cycle de vote, en fonction du poids des votes, un roulement dynamique est effectué pour réélire le groupe de Validateurs, garantissant ainsi 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 de haute TPS.
Coût faible : Moins de nœuds participant au consensus, la bande passante réseau et les ressources de calcul nécessaires pour la synchronisation des informations et l'agrégation des signatures sont significativement réduites. Cela entraîne une baisse des coûts matériels et d'exploitation, une diminution des exigences en matière de puissance de calcul et des coûts plus faibles. Finalement, cela permet d'atteindre des frais d'utilisateur plus bas.
Haute sécurité : le mécanisme de staking et de délégation augmente de manière synchronisée le coût et le risque des attaques ; combiné avec le mécanisme de confiscation sur la chaîne, il inhibe 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 des validateurs s'accorde pour confirmer une transaction. 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ûr et fonctionner de manière efficace. Pour toute mise à niveau ou décision majeure, il est également nécessaire d'obtenir plus des deux tiers des votes pour pouvoir être mise en œuvre.
En essence, le DPoS est en réalité un compromis du triangle impossible, représentant un équilibre entre décentralisation et efficacité. Dans le "triangle impossible" de la sécurité - décentralisation - évolutivité, le DPoS choisit de réduire le nombre de nœuds de production actifs pour obtenir de meilleures performances, 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 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 codage, cela rend les transactions de transfert impossibles à empaqueter 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 mettent en œuvre, au niveau du consensus, un mécanisme similaire à celui du '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 listées. Étant donné que cette fonction est déjà présente dans le client, lorsque l'attaque se produit,
SUI peut immédiatement geler l'adresse 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 apparence, chaque validateur semble libre d'exprimer ses propres valeurs.
En réalité, pour assurer la cohérence et l'efficacité des politiques 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 donc 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 s'ils souhaitent l'adopter ------ mais en pratique, la plupart des gens l'adoptent automatiquement par défaut. Par conséquent, bien que cette fonctionnalité protège les fonds des utilisateurs, elle présente en réalité un certain degré de centralisation.
3.2.3 L'essence de la fonction de liste noire
La fonction de liste noire n'est en réalité pas une logique de niveau protocolaire, elle ressemble davantage à une couche de sécurité supplémentaire pour faire face aux situations d'urgence et garantir la sécurité des fonds des utilisateurs.
C'est essentiellement un mécanisme de garantie de sécurité. Semblable à une "chaîne de sécurité" attachée à une porte, elle ne s'active que pour ceux qui souhaitent pénétrer dans la maison, c'est-à-dire pour ceux qui veulent nuire au protocole. Pour l'utilisateur :
Pour les gros investisseurs, principaux fournisseurs de liquidité, le protocole souhaite avant tout garantir la sécurité des fonds, car en réalité, les données on-chain de la tvl sont entièrement fournies par les principaux gros investisseurs. Pour assurer le développement durable du protocole, il est impératif de prioriser la sécurité.
Pour les investisseurs particuliers, contributeurs à l'activité de l'écosystème, et solides soutiens de la technologie et de la co-construction communautaire. Les équipes de projet espèrent également attirer les particuliers à co-construire, c'est ainsi que
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.
12 J'aime
Récompense
12
4
Partager
Commentaire
0/400
GweiWatcher
· 08-01 19:47
Donc, il faut encore acheter au point le plus bas ? C'est terrible.
Voir l'originalRépondre0
DefiPlaybook
· 08-01 19:44
D'après l'analyse des données off-chain, la vulnérabilité de Cetus a exposé les risques inhérents des smart contracts, la baisse de 83,7 % du TVL souligne la vulnérabilité de la Liquidité.
Voir l'originalRépondre0
GigaBrainAnon
· 08-01 19:37
Il n'y a rien que l'on puisse faire pour réparer le ciel.
Voir l'originalRépondre0
0xSherlock
· 08-01 19:30
Vraiment, ce n'est que de la spéculation et des big pumps et des big dumps.
La résilience de l'écosystème SUI se démarque, avec un potentiel de hausse à long terme même après des incidents de sécurité.
Foi indéfectible après la crise de sécurité : pourquoi SUI possède-t-il encore un potentiel de hausse à long terme ?
1. Une réaction en chaîne déclenchée par une attaque
Le 22 mai 2025, le protocole AMM de premier plan Cetus, déployé sur le réseau SUI, a été victime d'une attaque de hacker. L'attaquant a exploité une faille logique liée à un "problème de débordement entier" pour lancer un contrôle précis, entraînant des pertes de plus de 200 millions de dollars d'actifs. Cet incident est non seulement l'une des plus grandes affaires de sécurité dans le domaine de la DeFi jusqu'à présent cette année, mais il est également devenu la plus destructrice des attaques de hackers depuis le lancement du réseau principal de SUI.
Selon les données de DefiLlama, la TVL totale 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é réduit de 84 % en un instant, tombant à 38 millions de dollars. Par conséquent, plusieurs tokens populaires sur SUI ont connu une chute de 76 % à 97 % en seulement une heure, suscitant une large préoccupation du marché concernant la sécurité de SUI et la stabilité de son écosystème.
Mais après cette onde de choc, l'écosystème SUI a montré une grande résilience et une 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 durable, mais ont plutôt incité l'ensemble de l'écosystème à accorder une attention significative à la sécurité, à la construction d'infrastructures et à la qualité des projets.
Klein Labs va examiner les raisons de cet incident d'attaque, le mécanisme de consensus des nœuds de SUI, la sécurité du langage MOVE et le développement de l'écosystème de SUI, afin de dresser un état des lieux de l'écosystème actuel de cette blockchain encore en phase de développement précoce, et d'explorer son potentiel de développement futur.
2. Analyse des causes de l'attaque de l'événement Cetus
2.1 Processus de mise en œuvre de l'attaque
Selon l'analyse technique de l'incident d'attaque de Cetus par l'équipe Slow Mist, les hackers ont réussi à exploiter une vulnérabilité d'arithmétique clé 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 de l'attaque peut être généralement divisé en trois phases :
①Lancer un prêt éclair, manipuler les prix
Les hackers ont d'abord utilisé un prêt flash de 10 milliards de haSUI avec un glissement maximal pour emprunter une grande quantité de fonds et 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 exploité 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.
L'attaquant se prépare ensuite à créer une position de liquidité extrêmement étroite, en définissant précisément la plage de prix entre l'offre la plus basse de 300 000 et le prix le plus élevé de 300 200, avec une largeur de prix de seulement 1,00496621 %.
Grâce à la méthode ci-dessus, les hackers ont réussi à manipuler le prix de haSUI en utilisant un nombre suffisant de tokens et une énorme liquidité. Par la suite, ils ont également manipulé plusieurs tokens sans valeur réelle.
②Ajouter de la liquidité
L'attaquant crée une position de liquidité étroite, 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 : équivalent à une limite d'ajout de liquidité extrêmement élevée, rendant la vérification 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épassement de données tronqué : lors de l'exécution de l'opération de décalage n << 64 sur la valeur n, un dépassement de la largeur de bit efficace du type de données uint256 (256 bits) se produit, entraînant une troncature des données. La partie de débordement est automatiquement abandonnée, ce qui fait que le résultat du calcul est bien en dessous des attentes, amenant ainsi le système à sous-estimer le nombre de haSUI nécessaires pour l'échange. Le résultat final du calcul est d'environ moins de 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 énorme liquidité.
③ Retrait de liquidité
Effectuer le remboursement d'un prêt éclair, tout en conservant d'énormes profits. Finalement, retirer des actifs de tokens d'une valeur totale atteignant plusieurs centaines de millions de dollars de plusieurs pools de liquidités.
La situation des pertes financières 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 millions de dollars Haedal Staked SUI
19,5 millions de dollars TOILET
D'autres tokens comme HIPPO et LOFI ont chuté de 75 à 80 %, la liquidité s'épuise.
2.2 Causes et caractéristiques de cette vulnérabilité
La faille de Cetus présente trois caractéristiques :
Coût de réparation extrêmement bas : d'une part, la cause fondamentale de l'incident de Cetus est une erreur dans la bibliothèque mathématique de 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 limitée à Cetus lui-même et n'a rien à voir avec le code de SUI. La racine de la vulnérabilité réside dans un jugement de condition de frontière, il suffit de modifier deux lignes de code pour éliminer complètement le risque ; une fois la réparation 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 sans aucune défaillance depuis deux ans, le Cetus Protocol a été audité plusieurs fois, mais aucune vulnérabilité n'a été découverte, la raison principale é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 intervalles de transaction, créant des scénarios très rares avec une liquidité exceptionnellement élevée, ce qui déclenche une logique anormale, indiquant que ce type de problème est difficile à détecter par des tests ordinaires. Ces problèmes se situent souvent dans des zones d'ombre de la perception humaine, c'est pourquoi ils restent latents pendant longtemps avant d'être découverts.
Move est supérieur à de nombreux langages de contrat intelligent 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 dû à l'utilisation d'une valeur incorrecte pour le contrôle de la limite lors du calcul du nombre de jetons requis pour ajouter de la liquidité, et à l'utilisation d'opérations de décalage à la place de l' multiplication conventionnelle. Si des opérations de base comme l'addition, la soustraction, la multiplication et la division étaient utilisées, Move vérifierait automatiquement les situations de débordement, évitant ainsi ce problème de troncature de bits élevés.
Des vulnérabilités similaires sont également apparues dans d'autres langages (comme Solidity, Rust), et peuvent même être plus facilement exploitées en raison de leur manque de protection contre le débordement d'entier ; 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 ont eu lieu, la cause directe étant 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 détection dans le contrat grâce à des paramètres soigneusement construits, permettant ainsi 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 augmenter le débit des transactions, il ne peut pas offrir un niveau de décentralisation aussi élevé que le PoW (preuve de travail). Par conséquent, le niveau de décentralisation de SUI est relativement 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 eux-mêmes un nœud, ils peuvent simplement staker SUI et le déléguer à des 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 "employant" des validateurs de confiance. C'est également un grand avantage de DPoS par rapport à PoS traditionnel.
Représente le tour de production 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.
Élection dynamique : à la fin de chaque cycle de vote, en fonction du poids des votes, un roulement dynamique est effectué pour réélire le groupe de Validateurs, garantissant ainsi 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 de haute TPS.
Coût faible : Moins de nœuds participant au consensus, la bande passante réseau et les ressources de calcul nécessaires pour la synchronisation des informations et l'agrégation des signatures sont significativement réduites. Cela entraîne une baisse des coûts matériels et d'exploitation, une diminution des exigences en matière de puissance de calcul et des coûts plus faibles. Finalement, cela permet d'atteindre des frais d'utilisateur plus bas.
Haute sécurité : le mécanisme de staking et de délégation augmente de manière synchronisée le coût et le risque des attaques ; combiné avec le mécanisme de confiscation sur la chaîne, il inhibe 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 des validateurs s'accorde pour confirmer une transaction. 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ûr et fonctionner de manière efficace. Pour toute mise à niveau ou décision majeure, il est également nécessaire d'obtenir plus des deux tiers des votes pour pouvoir être mise en œuvre.
En essence, le DPoS est en réalité un compromis du triangle impossible, représentant un équilibre entre décentralisation et efficacité. Dans le "triangle impossible" de la sécurité - décentralisation - évolutivité, le DPoS choisit de réduire le nombre de nœuds de production actifs pour obtenir de meilleures performances, 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 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 codage, cela rend les transactions de transfert impossibles à empaqueter 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 mettent en œuvre, au niveau du consensus, un mécanisme similaire à celui du '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 listées. Étant donné que cette fonction est déjà présente dans le client, lorsque l'attaque se produit,
SUI peut immédiatement geler l'adresse 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 apparence, chaque validateur semble libre d'exprimer ses propres valeurs.
En réalité, pour assurer la cohérence et l'efficacité des politiques 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 donc 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 s'ils souhaitent l'adopter ------ mais en pratique, la plupart des gens l'adoptent automatiquement par défaut. Par conséquent, bien que cette fonctionnalité protège les fonds des utilisateurs, elle présente en réalité un certain degré de centralisation.
3.2.3 L'essence de la fonction de liste noire
La fonction de liste noire n'est en réalité pas une logique de niveau protocolaire, elle ressemble davantage à une couche de sécurité supplémentaire pour faire face aux situations d'urgence et garantir la sécurité des fonds des utilisateurs.
C'est essentiellement un mécanisme de garantie de sécurité. Semblable à une "chaîne de sécurité" attachée à une porte, elle ne s'active que pour ceux qui souhaitent pénétrer dans la maison, c'est-à-dire pour ceux qui veulent nuire au protocole. Pour l'utilisateur :
Pour les gros investisseurs, principaux fournisseurs de liquidité, le protocole souhaite avant tout garantir la sécurité des fonds, car en réalité, les données on-chain de la tvl sont entièrement fournies par les principaux gros investisseurs. Pour assurer le développement durable du protocole, il est impératif de prioriser la sécurité.
Pour les investisseurs particuliers, contributeurs à l'activité de l'écosystème, et solides soutiens de la technologie et de la co-construction communautaire. Les équipes de projet espèrent également attirer les particuliers à co-construire, c'est ainsi que