Foi ferme après une crise de sécurité : pourquoi SUI a-t-il toujours un potentiel de hausse à long terme ?
1. Une réaction en chaîne déclenchée par une attaque.
Le 22 mai 2025, le protocole AMM de premier plan déployé sur le réseau SUI, Cetus, a été victime d'une attaque de hackers. Les attaquants ont exploité une faille logique liée à un "problème de débordement d'entier" pour effectuer une manipulation précise, entraînant une perte de plus de 200 millions de dollars d'actifs. Cet événement est non seulement l'un des plus grands incidents de sécurité dans le domaine DeFi cette année, mais il est aussi la plus destructrice des attaques de hackers depuis le lancement du réseau principal SUI.
Selon les données, la TVL totale de la chaîne 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 disparu instantanément 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 une large préoccupation du marché concernant la sécurité de SUI et la stabilité de son écosystème.
Mais après cette onde de choc, l'écosystème SUI a montré une grande résilience et capacité de récupération. Bien que l'incident Cetus ait provoqué des fluctuations de confiance à court terme, les fonds en 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.
Nous allons 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. Nous allons également analyser la configuration actuelle de cet écosystème d'une blockchain qui en est encore à ses débuts et discuter de son potentiel de développement futur.
2. Analyse des causes de l'attaque de l'événement Cetus
2.1 Processus de réalisation de l'attaque
Selon l'analyse technique de l'incident d'attaque de Cetus, les hackers ont réussi à exploiter une vulnérabilité clé de débordement arithmétique 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 grossièrement divisé en trois étapes :
①Lancer un prêt éclair, manipuler les prix
Les hackers ont d'abord utilisé un prêt flash de 10 milliards haSUI avec un glissement maximum pour emprunter d'importants 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 utilisé ce mécanisme pour faire chuter le prix du marché en peu de temps et le contrôler précisément dans une fourchette très étroite.
Ensuite, l'attaquant se prépare à 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 %.
En utilisant 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 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 :
Paramètres de masque trop larges : équivaut à une limite d'ajout de liquidité extrêmement élevée, rendant les vérifications des entrées des utilisateurs dans le contrat complètement inutiles. Les hackers contournent la détection de dépassement en définissant des paramètres anormaux et en construisant des entrées toujours inférieures à cette limite.
Débordement de données tronqué : Lors de l'exécution d'une opération de décalage n << 64 sur la valeur n, un débordement s'est produit en raison d'un 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 rejetée, entraînant un résultat de calcul bien inférieur aux attentes, ce qui a conduit le système à sous-estimer le nombre de haSUI nécessaires pour l'échange. Le résultat final est d'environ moins de 1, mais comme il est arrondi vers le haut, il finit par être égal à 1, ce qui signifie que le hacker n'a qu'à ajouter 1 jeton pour échanger une énorme liquidité.
③ Retrait de liquidité
Effectuer le remboursement d'un prêt éclair, tout en conservant d'énormes bénéfices. Finalement, retirer des actifs de jetons d'une valeur totale de plusieurs centaines de millions de dollars de plusieurs pools de liquidité.
La situation des pertes 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 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'est épuisée.
2.2 Causes et caractéristiques de la vulnérabilité
Cette vulnérabilité de Cetus présente trois caractéristiques :
Coût de réparation très bas : d'une part, la cause fondamentale de l'incident Cetus est une omission dans la bibliothèque mathématique de Cetus, et non une erreur du mécanisme de prix du protocole ou une erreur 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 un jugement de condition de frontière, et 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 que la logique des contrats à venir 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, et a subi plusieurs audits, mais aucune vulnérabilité n'a été trouvée. La raison principale est que la bibliothèque Integer_Mate utilisée pour les calculs mathématiques n'a pas été incluse dans le champ d'audit.
Les hackers utilisent des valeurs extrêmes pour construire précisément des intervalles de trading, créant ainsi des scénarios très rares avec une liquidité extrêmement élevée, ce qui déclenche une logique anormale, indiquant que ce type de problème est difficile à détecter par des tests ordinaires. Ces problèmes se trouvent souvent dans des zones d'ombre de la perception humaine, c'est pourquoi ils ont été 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 contrats intelligents en matière de sécurité des ressources et de vérification des types, et il intègre une détection native des problèmes de dépassement d'entier dans des situations courantes. Ce dépassement est survenu parce que lors de l'ajout de liquidités, une valeur incorrecte a d'abord été utilisée pour le contrôle de limite supérieure lors du calcul du nombre de jetons requis, et une opération de décalage a été utilisée à la place de la multiplication conventionnelle. Si des opérations d'addition, de soustraction, de multiplication ou de division conventionnelles avaient été effectuées, Move aurait automatiquement vérifié les situations de dépassement, évitant ainsi ce problème de troncature des bits de poids élevé.
Des vulnérabilités similaires se sont également produites dans d'autres langages (comme Solidity, Rust), et étaient même plus faciles à exploiter en raison de leur manque de protection contre le dépassement d'entier ; avant la mise à jour de la version de Solidity, les vérifications de dépassement étaient très faibles. Historiquement, il y a eu des dépassements d'addition, de soustraction, de multiplication, etc., 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 vérification dans le contrat en utilisant des paramètres soigneusement construits, permettant ainsi des attaques par transferts excessifs.
3. Mécanisme de consensus de SUI
3.1 Introduction au mécanisme de consensus SUI
Aperçu :
SUI adopte un cadre de Preuve d'Enjeu Déléguée (DeleGated Proof of Stake, abrégé DPoS)). Bien que le mécanisme DPoS puisse améliorer le débit des transactions, il ne peut pas fournir un niveau de décentralisation aussi élevé que le PoW (Preuve de Travail). Par conséquent, le niveau de décentralisation de SUI est relativement faible, et le seuil de gouvernance est relativement élevé, ce qui rend 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 un nœud eux-mêmes, il leur suffit de staker SUI et de le déléguer à un validateur candidat 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 "employant" des validateurs de confiance. C'est également un grand avantage du DPoS par rapport au 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.
Élections dynamiques : à la fin de chaque cycle de vote, un roulement dynamique est effectué pour réélire l'ensemble des Validateurs en fonction du poids des votes, garantissant ainsi 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ôlable de nœuds de production de blocs, le réseau peut confirmer en millisecondes, répondant ainsi aux besoins élevés en 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 entraîne une diminution des coûts matériels et d'exploitation, ainsi qu'une diminution des exigences en matière de puissance de calcul, ce qui réduit les coûts. En fin de compte, cela a permis d'atteindre des frais de transaction utilisateur plus bas.
Haute sécurité : le mécanisme de mise en jeu et de délégation amplifie le coût et le risque des attaques ; associé au mécanisme de confiscation sur la chaîne, cela réduit efficacement les comportements malveillants.
En même temps, le mécanisme de consensus de SUI utilise un algorithme basé sur le BFT (tolérance aux pannes byzantines), exigeant 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 rester sécurisé et fonctionner de manière efficace. Pour toute mise à niveau ou décision majeure, il faut également obtenir plus des deux tiers des votes pour être mise en œuvre.
En essence, le DPoS est en réalité un compromis dans le triangle impossible, faisant un compromis entre décentralisation et efficacité. Dans le "triangle impossible" de la sécurité - décentralisation - évolutivité, le DPoS choisit de réduire le nombre de nœuds actifs de production de blocs pour obtenir une meilleure performance, renonçant à un certain degré de décentralisation complète par rapport au pure PoS ou PoW, mais améliorant considérablement le débit du réseau et la vitesse des transactions.
3.2 La performance de SUI lors de cette attaque
3.2.1 Mécanisme de gel en fonctionnement
Lors de cet événement, SUI a rapidement gelé les adresses liées à l'attaquant.
D'un point de vue code, cela rend les transactions de transfert impossibles à empaqueter et à enregistrer 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 en lui-même 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. Comme 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 fonction, même si SUI n'a que 113 validateurs, il serait difficile de coordonner tous les validateurs un par un en peu 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 faisant fonctionner un nœud peut éditer 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 garantir 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 d'urgence poussée", c'est essentiellement la fondation (ou ses développeurs autorisés) qui établit et met à jour cette liste de refus.
SUI a publié une liste noire, théoriquement les validateurs peuvent choisir de l'adopter ou non------ mais en pratique, la plupart des gens l'adoptent automatiquement par défaut. Par conséquent, bien que cette fonctionnalité protège les fonds des utilisateurs, elle présente en réalité un certain degré de centralisation.
3.2.3 La nature de la fonctionnalité de liste noire
La fonctionnalité de liste noire n'est en réalité pas une logique de base du protocole, mais elle ressemble plutôt à une couche de sécurité supplémentaire pour faire face à des situations imprévues et garantir la sécurité des fonds des utilisateurs.
Il s'agit essentiellement d'un mécanisme de garantie de sécurité. Semblable à une "chaîne de sécurité" attachée à la porte, elle ne s'active que pour ceux qui souhaitent pénétrer dans la maison, c'est-à-dire pour ceux qui cherchent à mal utiliser le protocole. Pour l'utilisateur :
Pour les gros investisseurs, principaux fournisseurs de liquidité, le protocole cherche avant tout à garantir la sécurité des fonds, car en réalité, les données en chaîne TVL proviennent principalement de ces gros investisseurs. Pour assurer le développement durable du protocole, la sécurité doit être priorisée.
Pour les petits investisseurs, contributeurs à l'activité de l'écosystème, soutiens puissants de la construction technique et communautaire. Les porteurs de projet espèrent également attirer les petits investisseurs pour co-construire, afin de pouvoir progressivement améliorer l'écosystème et renforcer la rétention.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
14 J'aime
Récompense
14
7
Partager
Commentaire
0/400
CodeZeroBasis
· Il y a 12h
Ce bug me fait peur.
Voir l'originalRépondre0
MoonMathMagic
· Il y a 12h
D'accord, si je perds, je perds. Qui n'a jamais perdu d'argent ?
Voir l'originalRépondre0
MeltdownSurvivalist
· Il y a 12h
Encore un incident de Hacker, c'est vraiment énorme.
Voir l'originalRépondre0
BearMarketBro
· Il y a 12h
C'est juste une réputation sans fondement, ce genre de faille peut aussi se produire.
Voir l'originalRépondre0
BridgeTrustFund
· Il y a 12h
sui vient de provoquer un effondrement en trois minutes, n'est-ce pas ?
Voir l'originalRépondre0
0xSunnyDay
· Il y a 13h
sui, quand va-t-il chuter à 0 ?
Voir l'originalRépondre0
AirdropHarvester
· Il y a 13h
Boum boum boum, l'écosystème SUI est presque à sec.
La résilience de l'écosystème SUI : réflexions sur la sécurité après l'attaque de Cetus et perspectives de développement.
Foi ferme après une crise de sécurité : pourquoi SUI a-t-il toujours un potentiel de hausse à long terme ?
1. Une réaction en chaîne déclenchée par une attaque.
Le 22 mai 2025, le protocole AMM de premier plan déployé sur le réseau SUI, Cetus, a été victime d'une attaque de hackers. Les attaquants ont exploité une faille logique liée à un "problème de débordement d'entier" pour effectuer une manipulation précise, entraînant une perte de plus de 200 millions de dollars d'actifs. Cet événement est non seulement l'un des plus grands incidents de sécurité dans le domaine DeFi cette année, mais il est aussi la plus destructrice des attaques de hackers depuis le lancement du réseau principal SUI.
Selon les données, la TVL totale de la chaîne 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 disparu instantanément 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 une large préoccupation du marché concernant la sécurité de SUI et la stabilité de son écosystème.
Mais après cette onde de choc, l'écosystème SUI a montré une grande résilience et capacité de récupération. Bien que l'incident Cetus ait provoqué des fluctuations de confiance à court terme, les fonds en 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.
Nous allons 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. Nous allons également analyser la configuration actuelle de cet écosystème d'une blockchain qui en est encore à ses débuts et discuter de son potentiel de développement futur.
2. Analyse des causes de l'attaque de l'événement Cetus
2.1 Processus de réalisation de l'attaque
Selon l'analyse technique de l'incident d'attaque de Cetus, les hackers ont réussi à exploiter une vulnérabilité clé de débordement arithmétique 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 grossièrement divisé en trois étapes :
①Lancer un prêt éclair, manipuler les prix
Les hackers ont d'abord utilisé un prêt flash de 10 milliards haSUI avec un glissement maximum pour emprunter d'importants 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 utilisé ce mécanisme pour faire chuter le prix du marché en peu de temps et le contrôler précisément dans une fourchette très étroite.
Ensuite, l'attaquant se prépare à 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 %.
En utilisant 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 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 :
Paramètres de masque trop larges : équivaut à une limite d'ajout de liquidité extrêmement élevée, rendant les vérifications des entrées des utilisateurs dans le contrat complètement inutiles. Les hackers contournent la détection de dépassement en définissant des paramètres anormaux et en construisant des entrées toujours inférieures à cette limite.
Débordement de données tronqué : Lors de l'exécution d'une opération de décalage n << 64 sur la valeur n, un débordement s'est produit en raison d'un 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 rejetée, entraînant un résultat de calcul bien inférieur aux attentes, ce qui a conduit le système à sous-estimer le nombre de haSUI nécessaires pour l'échange. Le résultat final est d'environ moins de 1, mais comme il est arrondi vers le haut, il finit par être égal à 1, ce qui signifie que le hacker n'a qu'à ajouter 1 jeton pour échanger une énorme liquidité.
③ Retrait de liquidité
Effectuer le remboursement d'un prêt éclair, tout en conservant d'énormes bénéfices. Finalement, retirer des actifs de jetons d'une valeur totale de plusieurs centaines de millions de dollars de plusieurs pools de liquidité.
La situation des pertes 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 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'est épuisée.
2.2 Causes et caractéristiques de la vulnérabilité
Cette vulnérabilité de Cetus présente trois caractéristiques :
Coût de réparation très bas : d'une part, la cause fondamentale de l'incident Cetus est une omission dans la bibliothèque mathématique de Cetus, et non une erreur du mécanisme de prix du protocole ou une erreur 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 un jugement de condition de frontière, et 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 que la logique des contrats à venir 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, et a subi plusieurs audits, mais aucune vulnérabilité n'a été trouvée. La raison principale est que la bibliothèque Integer_Mate utilisée pour les calculs mathématiques n'a pas été incluse dans le champ d'audit.
Les hackers utilisent des valeurs extrêmes pour construire précisément des intervalles de trading, créant ainsi des scénarios très rares avec une liquidité extrêmement élevée, ce qui déclenche une logique anormale, indiquant que ce type de problème est difficile à détecter par des tests ordinaires. Ces problèmes se trouvent souvent dans des zones d'ombre de la perception humaine, c'est pourquoi ils ont été latents pendant longtemps avant d'être découverts.
Move est supérieur à de nombreux langages de contrats intelligents en matière de sécurité des ressources et de vérification des types, et il intègre une détection native des problèmes de dépassement d'entier dans des situations courantes. Ce dépassement est survenu parce que lors de l'ajout de liquidités, une valeur incorrecte a d'abord été utilisée pour le contrôle de limite supérieure lors du calcul du nombre de jetons requis, et une opération de décalage a été utilisée à la place de la multiplication conventionnelle. Si des opérations d'addition, de soustraction, de multiplication ou de division conventionnelles avaient été effectuées, Move aurait automatiquement vérifié les situations de dépassement, évitant ainsi ce problème de troncature des bits de poids élevé.
Des vulnérabilités similaires se sont également produites dans d'autres langages (comme Solidity, Rust), et étaient même plus faciles à exploiter en raison de leur manque de protection contre le dépassement d'entier ; avant la mise à jour de la version de Solidity, les vérifications de dépassement étaient très faibles. Historiquement, il y a eu des dépassements d'addition, de soustraction, de multiplication, etc., 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 vérification dans le contrat en utilisant des paramètres soigneusement construits, permettant ainsi des attaques par transferts excessifs.
3. Mécanisme de consensus de SUI
3.1 Introduction au mécanisme de consensus SUI
Aperçu :
SUI adopte un cadre de Preuve d'Enjeu Déléguée (DeleGated Proof of Stake, abrégé DPoS)). Bien que le mécanisme DPoS puisse améliorer le débit des transactions, il ne peut pas fournir un niveau de décentralisation aussi élevé que le PoW (Preuve de Travail). Par conséquent, le niveau de décentralisation de SUI est relativement faible, et le seuil de gouvernance est relativement élevé, ce qui rend 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 un nœud eux-mêmes, il leur suffit de staker SUI et de le déléguer à un validateur candidat 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 "employant" des validateurs de confiance. C'est également un grand avantage du DPoS par rapport au 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.
Élections dynamiques : à la fin de chaque cycle de vote, un roulement dynamique est effectué pour réélire l'ensemble des Validateurs en fonction du poids des votes, garantissant ainsi 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ôlable de nœuds de production de blocs, le réseau peut confirmer en millisecondes, répondant ainsi aux besoins élevés en 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 entraîne une diminution des coûts matériels et d'exploitation, ainsi qu'une diminution des exigences en matière de puissance de calcul, ce qui réduit les coûts. En fin de compte, cela a permis d'atteindre des frais de transaction utilisateur plus bas.
Haute sécurité : le mécanisme de mise en jeu et de délégation amplifie le coût et le risque des attaques ; associé au mécanisme de confiscation sur la chaîne, cela réduit efficacement les comportements malveillants.
En même temps, le mécanisme de consensus de SUI utilise un algorithme basé sur le BFT (tolérance aux pannes byzantines), exigeant 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 rester sécurisé et fonctionner de manière efficace. Pour toute mise à niveau ou décision majeure, il faut également obtenir plus des deux tiers des votes pour être mise en œuvre.
En essence, le DPoS est en réalité un compromis dans le triangle impossible, faisant un compromis entre décentralisation et efficacité. Dans le "triangle impossible" de la sécurité - décentralisation - évolutivité, le DPoS choisit de réduire le nombre de nœuds actifs de production de blocs pour obtenir une meilleure performance, renonçant à un certain degré de décentralisation complète par rapport au pure PoS ou PoW, mais améliorant considérablement le débit du réseau et la vitesse des transactions.
3.2 La performance de SUI lors de cette attaque
3.2.1 Mécanisme de gel en fonctionnement
Lors de cet événement, SUI a rapidement gelé les adresses liées à l'attaquant.
D'un point de vue code, cela rend les transactions de transfert impossibles à empaqueter et à enregistrer 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 en lui-même 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. Comme 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 fonction, même si SUI n'a que 113 validateurs, il serait difficile de coordonner tous les validateurs un par un en peu 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 faisant fonctionner un nœud peut éditer 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 garantir 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 d'urgence poussée", c'est essentiellement la fondation (ou ses développeurs autorisés) qui établit et met à jour cette liste de refus.
SUI a publié une liste noire, théoriquement les validateurs peuvent choisir de l'adopter ou non------ mais en pratique, la plupart des gens l'adoptent automatiquement par défaut. Par conséquent, bien que cette fonctionnalité protège les fonds des utilisateurs, elle présente en réalité un certain degré de centralisation.
3.2.3 La nature de la fonctionnalité de liste noire
La fonctionnalité de liste noire n'est en réalité pas une logique de base du protocole, mais elle ressemble plutôt à une couche de sécurité supplémentaire pour faire face à des situations imprévues et garantir la sécurité des fonds des utilisateurs.
Il s'agit essentiellement d'un mécanisme de garantie de sécurité. Semblable à une "chaîne de sécurité" attachée à la porte, elle ne s'active que pour ceux qui souhaitent pénétrer dans la maison, c'est-à-dire pour ceux qui cherchent à mal utiliser le protocole. Pour l'utilisateur :
Pour les gros investisseurs, principaux fournisseurs de liquidité, le protocole cherche avant tout à garantir la sécurité des fonds, car en réalité, les données en chaîne TVL proviennent principalement de ces gros investisseurs. Pour assurer le développement durable du protocole, la sécurité doit être priorisée.
Pour les petits investisseurs, contributeurs à l'activité de l'écosystème, soutiens puissants de la construction technique et communautaire. Les porteurs de projet espèrent également attirer les petits investisseurs pour co-construire, afin de pouvoir progressivement améliorer l'écosystème et renforcer la rétention.