Croyance ferme après la crise de sécurité : pourquoi SUI a-t-il toujours un potentiel de hausse à long terme ?
1. Une réaction en chaîne provoquée par une attaque
Le 22 mai 2023, le protocole AMM de premier plan déployé sur le réseau SUI, Cetus, a été victime d'une attaque de hacker. L'attaquant a exploité une vulnérabilité logique liée à un "problème de débordement 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 de la DeFi cette année, mais il représente également la plus destructrice des attaques de hacker depuis le lancement de la mainnet 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, tandis que le montant verrouillé du protocole Cetus a également soudainement disparu de 84%, tombant à 38 millions de dollars. En conséquence, plusieurs jetons populaires sur SUI (y compris Lofi, Sudeng, Squirtle, etc.) ont chuté de 76% à 97% en seulement une heure, suscitant une large préoccupation du marché sur la sécurité de SUI et la stabilité de son écosystème.
Mais après cette onde de choc, l'écosystème SUI a montré une grande résilience et capacité de récupération. Bien que l'événement Cetus ait provoqué des fluctuations de confiance à court terme, les fonds en chaîne et l'activité des utilisateurs n'ont pas subi de déclin prolongé, mais ont plutôt incité l'ensemble de l'écosystème à accorder une attention significative à la sécurité, à l'infrastructure 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, en clarifiant la configuration actuelle de l'écosystème de cette blockchain qui en est encore à ses débuts et en discutant de 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 de sécurité, 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, pour voler plus de 200 millions de dollars d'actifs numériques en peu de temps. Le chemin d'attaque peut être grossièrement divisé en trois étapes principales :
①Lancer un prêt flash, manipuler le prix
Les hackers ont d'abord utilisé un échange instantané avec un slippage maximum de 10 milliards de haSUI grâce à un prêt flash, 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. Il présente des caractéristiques de levier élevé, de faible risque et de faible coût. Les hackers ont utilisé ce mécanisme pour faire chuter les prix du marché en peu de temps, en les contrôlant précisément dans une plage très étroite.
Ensuite, l'attaquant 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 %.
Grâce à ces méthodes, les hackers ont réussi à manipuler le prix de haSUI en utilisant un nombre suffisamment important de jetons et une énorme liquidité. Ensuite, ils ont également manipulé plusieurs jetons sans valeur réelle.
②Ajouter de la liquidité
L'attaquant crée des positions de liquidité étroites, prétendant 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, rendant la vérification des entrées utilisateur dans le contrat complètement inefficace. Les hackeurs contournent la détection de débordement en définissant des paramètres anormaux, créant des entrées 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 s'est produit en raison du dépassement de la largeur de bits effective du type de données uint256 (256 bits). La partie de débordement supérieure a été automatiquement abandonnée, entraînant un résultat de calcul bien inférieur aux attentes, ce qui a amené le système à sous-estimer le nombre de haSUI nécessaires pour l'échange. Le résultat final du calcul est d'environ inférieur à 1, mais comme il est arrondi à l'entier supérieur, le résultat final est donc égal à 1, c'est-à-dire qu'un hacker n'a besoin d'ajouter qu'un seul jeton pour échanger une énorme liquidité.
③ Retrait de liquidité
Effectuer le remboursement du prêt flash, en conservant d'énormes profits. Retirer finalement des pools de liquidité multiples des actifs de tokens d'une valeur totale de plusieurs centaines de millions de dollars.
La situation des pertes de fonds est grave, l'attaque a entraîné le vol des actifs suivants :
12,9 millions de SUI (environ 5,4 millions de dollars américains)
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é 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 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 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é se trouve dans une condition limite, il suffit de modifier deux lignes de code pour éliminer complètement le risque ; une fois la réparation effectuée, elle peut être immédiatement déployée sur le réseau principal, garantissant la complétude de la logique des contrats ultérieurs et éliminant cette vulnérabilité.
Haute confidentialité : le contrat a fonctionné de manière stable et sans défauts pendant deux ans depuis son lancement. Le protocole Cetus a subi plusieurs audits, mais aucune vulnérabilité n'a été découverte, principalement parce 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 avec précision des plages de transactions, créant ainsi des scénarios extrêmement rares de soumission de liquidité très élevée, ce qui déclenche une logique anormale, indiquant que ce type de problème est difficile à détecter par des tests ordinaires. Ce type de problème se situe souvent dans des zones d'ombre de la perception des gens, c'est pourquoi il reste latent pendant longtemps avant d'être découvert.
Ce n'est pas un problème exclusif à Move :
Move est supérieur à de nombreux langages de contrats intelligents en matière de sécurité des ressources et de vérification des types, et intègre une détection native des problèmes de dépassement d'entier dans des situations courantes. Ce dépassement est survenu lors de l'ajout de liquidités, lorsque le nombre de jetons requis a d'abord été vérifié avec une valeur incorrecte pour le contrôle de la limite, et que des opérations de décalage ont été utilisées à la place des opérations de multiplication conventionnelles. En revanche, si des opérations d'addition, de soustraction, de multiplication ou de division conventionnelles sont utilisées dans Move, un contrôle automatique des dépassements s'effectue, évitant ainsi ce problème de troncature de bit supérieur.
Des vulnérabilités similaires sont également apparues dans d'autres langages (comme Solidity, Rust), et elles étaient même plus faciles à exploiter en raison de leur manque de protection contre les débordements d'entiers ; avant la mise à jour de la version de Solidity, la vérification des débordements était très faible. Historiquement, il y a eu des débordements d'addition, de soustraction, de multiplication, etc., dont la cause directe était que le résultat des calculs dépassait la portée. Par exemple, les vulnérabilités des contrats intelligents BEC et SMT dans le langage Solidity ont contourné les instructions de détection dans le contrat grâce à des paramètres soigneusement construits, permettant ainsi des attaques par des transferts excessifs.
3. Mécanisme de consensus de SUI
3.1 Introduction au mécanisme de consensus SUI
Aperçu :
SUI adopte un cadre de preuve d'enjeu déléguée (DeleGated Proof of Stake, abrégé DPoS). Bien que le mécanisme DPoS puisse augmenter le débit des transactions, il ne peut pas offrir un niveau de décentralisation aussi élevé que la preuve de travail (PoW). 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 miser SUI et de 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 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.
Élections dynamiques : À la fin de chaque cycle de vote, en fonction du poids des votes, une rotation dynamique est effectuée pour réélire l'ensemble des validateurs, garantissant la vitalité des nœuds, l'unité des intérêts et la décentralisation.
Les avantages de DPoS :
Haute efficacité : grâce à un nombre contrôlable de nœuds de production de blocs, le réseau peut terminer la confirmation en millisecondes, répondant ainsi à des besoins de TPS élevés.
Coût faible : Moins de nœuds participant au consensus, la bande passante et les ressources informatiques nécessaires pour la synchronisation des informations et l'agrégation des signatures sont considérablement réduites. Par conséquent, le coût des matériels et de l'exploitation diminue, les exigences en matière de puissance de calcul diminuent, ce qui réduit les coûts. Cela permet finalement d'atteindre des frais d'utilisateur plus bas.
Sécurité élevée : le mécanisme de staking 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éprime efficacement les comportements malveillants.
Parallèlement, 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 agit de manière malveillante, le réseau peut rester sécurisé et fonctionner efficacement. Pour toute mise à niveau ou décision majeure, plus des deux tiers des votes sont également nécessaires pour être mises en œuvre.
Essentiellement, le DPoS est en réalité une solution de compromis au triangle impossible, réalisant un compromis entre décentralisation et efficacité. Dans le "triangle impossible" de sécurité-décialisation-scalabilité, le DPoS choisit de réduire le nombre de nœuds de validation 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 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 technique, cela rend impossible l'emballage des transactions de transfert 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 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. Étant donné que cette fonctionnalité existe déjà dans le client, lorsque l'attaque se produit
SUI peut immédiatement geler l'adresse des hackers. Sans cette fonctionnalité, même si SUI n'a que 113 validateurs, il serait difficile pour Cetus de coordonner tous les validateurs un par un dans un court laps de temps.
3.2.2 Qui a le pouvoir de modifier la liste noire ?
TransactionDenyConfig est un fichier de configuration YAML/TOML chargé localement par chaque validateur. Toute personne exécutant un nœud peut éditer ce fichier, recharger à chaud ou redémarrer le nœud, et mettre à jour la liste. En apparence, chaque validateur semble exprimer librement ses 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", il appartient essentiellement à la fondation SUI (ou à ses développeurs autorisés) de mettre en place et de mettre à jour cette liste de refus.
SUI publie une liste noire, les validateurs peuvent théoriquement 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 fonction de liste noire
La fonctionnalité de liste noire n'est en réalité pas une logique de bas niveau du protocole, 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.
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 n'est activée que pour ceux qui souhaitent s'introduire chez vous, c'est-à-dire pour les personnes malintentionnées envers le protocole. Pour l'utilisateur :
Pour les gros détenteurs, principaux fournisseurs de liquidité, le protocole cherche avant tout à garantir la sécurité des fonds, car en réalité, les données on-chain de tvl sont entièrement fournies par les principaux gros détenteurs. Pour assurer le développement à long terme du protocole, il est impératif de garantir la sécurité en priorité.
Pour les petits investisseurs, contributeurs à l'activité de l'écosystème, soutiens solides de la technologie et de la co-construction de la communauté. Projet
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
10 J'aime
Récompense
10
6
Partager
Commentaire
0/400
GhostInTheChain
· Il y a 23h
Hacker est vraiment trop impitoyable, l'univers de la cryptomonnaie doit encore être joué avec prudence.
Voir l'originalRépondre0
MevHunter
· Il y a 23h
C'est toujours amusant d'acheter la dip dans un marché baissier.
Voir l'originalRépondre0
FlashLoanKing
· 07-07 02:36
Critique ou critique, buy the dip et amusez-vous!
Voir l'originalRépondre0
GweiTooHigh
· 07-07 02:35
Qui est responsable de ce bug ?
Voir l'originalRépondre0
MEVHunter
· 07-07 02:29
La vulnérabilité de débordement p2=p1 peut encore être exploitée. Code poubelle à gogo. Les arbitragistes sont ravis.
Voir l'originalRépondre0
MaticHoleFiller
· 07-07 02:25
prendre les gens pour des idiots et Rug Pull. Où est la prochaine victime ?
Résilience après la crise de sécurité de l'écosystème SUI : au-delà de l'incident Cetus, perspective sur le potentiel de hausse à long terme
Croyance ferme après la crise de sécurité : pourquoi SUI a-t-il toujours un potentiel de hausse à long terme ?
1. Une réaction en chaîne provoquée par une attaque
Le 22 mai 2023, le protocole AMM de premier plan déployé sur le réseau SUI, Cetus, a été victime d'une attaque de hacker. L'attaquant a exploité une vulnérabilité logique liée à un "problème de débordement 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 de la DeFi cette année, mais il représente également la plus destructrice des attaques de hacker depuis le lancement de la mainnet 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, tandis que le montant verrouillé du protocole Cetus a également soudainement disparu de 84%, tombant à 38 millions de dollars. En conséquence, plusieurs jetons populaires sur SUI (y compris Lofi, Sudeng, Squirtle, etc.) ont chuté de 76% à 97% en seulement une heure, suscitant une large préoccupation du marché sur la sécurité de SUI et la stabilité de son écosystème.
Mais après cette onde de choc, l'écosystème SUI a montré une grande résilience et capacité de récupération. Bien que l'événement Cetus ait provoqué des fluctuations de confiance à court terme, les fonds en chaîne et l'activité des utilisateurs n'ont pas subi de déclin prolongé, mais ont plutôt incité l'ensemble de l'écosystème à accorder une attention significative à la sécurité, à l'infrastructure 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, en clarifiant la configuration actuelle de l'écosystème de cette blockchain qui en est encore à ses débuts et en discutant de 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 de sécurité, 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, pour voler plus de 200 millions de dollars d'actifs numériques en peu de temps. Le chemin d'attaque peut être grossièrement divisé en trois étapes principales :
①Lancer un prêt flash, manipuler le prix
Les hackers ont d'abord utilisé un échange instantané avec un slippage maximum de 10 milliards de haSUI grâce à un prêt flash, 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. Il présente des caractéristiques de levier élevé, de faible risque et de faible coût. Les hackers ont utilisé ce mécanisme pour faire chuter les prix du marché en peu de temps, en les contrôlant précisément dans une plage très étroite.
Ensuite, l'attaquant 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 %.
Grâce à ces méthodes, les hackers ont réussi à manipuler le prix de haSUI en utilisant un nombre suffisamment important de jetons et une énorme liquidité. Ensuite, ils ont également manipulé plusieurs jetons sans valeur réelle.
②Ajouter de la liquidité
L'attaquant crée des positions de liquidité étroites, prétendant 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, rendant la vérification des entrées utilisateur dans le contrat complètement inefficace. Les hackeurs contournent la détection de débordement en définissant des paramètres anormaux, créant des entrées 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 s'est produit en raison du dépassement de la largeur de bits effective du type de données uint256 (256 bits). La partie de débordement supérieure a été automatiquement abandonnée, entraînant un résultat de calcul bien inférieur aux attentes, ce qui a amené le système à sous-estimer le nombre de haSUI nécessaires pour l'échange. Le résultat final du calcul est d'environ inférieur à 1, mais comme il est arrondi à l'entier supérieur, le résultat final est donc égal à 1, c'est-à-dire qu'un hacker n'a besoin d'ajouter qu'un seul jeton pour échanger une énorme liquidité.
③ Retrait de liquidité
Effectuer le remboursement du prêt flash, en conservant d'énormes profits. Retirer finalement des pools de liquidité multiples des actifs de tokens d'une valeur totale de plusieurs centaines de millions de dollars.
La situation des pertes de fonds est grave, l'attaque a entraîné le vol des actifs suivants :
12,9 millions de SUI (environ 5,4 millions de dollars américains)
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é 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 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 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é se trouve dans une condition limite, il suffit de modifier deux lignes de code pour éliminer complètement le risque ; une fois la réparation effectuée, elle peut être immédiatement déployée sur le réseau principal, garantissant la complétude de la logique des contrats ultérieurs et éliminant cette vulnérabilité.
Haute confidentialité : le contrat a fonctionné de manière stable et sans défauts pendant deux ans depuis son lancement. Le protocole Cetus a subi plusieurs audits, mais aucune vulnérabilité n'a été découverte, principalement parce 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 avec précision des plages de transactions, créant ainsi des scénarios extrêmement rares de soumission de liquidité très élevée, ce qui déclenche une logique anormale, indiquant que ce type de problème est difficile à détecter par des tests ordinaires. Ce type de problème se situe souvent dans des zones d'ombre de la perception des gens, c'est pourquoi il reste latent pendant longtemps avant d'être découvert.
Move est supérieur à de nombreux langages de contrats intelligents en matière de sécurité des ressources et de vérification des types, et intègre une détection native des problèmes de dépassement d'entier dans des situations courantes. Ce dépassement est survenu lors de l'ajout de liquidités, lorsque le nombre de jetons requis a d'abord été vérifié avec une valeur incorrecte pour le contrôle de la limite, et que des opérations de décalage ont été utilisées à la place des opérations de multiplication conventionnelles. En revanche, si des opérations d'addition, de soustraction, de multiplication ou de division conventionnelles sont utilisées dans Move, un contrôle automatique des dépassements s'effectue, évitant ainsi ce problème de troncature de bit supérieur.
Des vulnérabilités similaires sont également apparues dans d'autres langages (comme Solidity, Rust), et elles étaient même plus faciles à exploiter en raison de leur manque de protection contre les débordements d'entiers ; avant la mise à jour de la version de Solidity, la vérification des débordements était très faible. Historiquement, il y a eu des débordements d'addition, de soustraction, de multiplication, etc., dont la cause directe était que le résultat des calculs dépassait la portée. Par exemple, les vulnérabilités des contrats intelligents BEC et SMT dans le langage Solidity ont contourné les instructions de détection dans le contrat grâce à des paramètres soigneusement construits, permettant ainsi des attaques par des transferts excessifs.
3. Mécanisme de consensus de SUI
3.1 Introduction au mécanisme de consensus SUI
Aperçu :
SUI adopte un cadre de preuve d'enjeu déléguée (DeleGated Proof of Stake, abrégé DPoS). Bien que le mécanisme DPoS puisse augmenter le débit des transactions, il ne peut pas offrir un niveau de décentralisation aussi élevé que la preuve de travail (PoW). 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 miser SUI et de 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 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.
Élections dynamiques : À la fin de chaque cycle de vote, en fonction du poids des votes, une rotation dynamique est effectuée pour réélire l'ensemble des validateurs, garantissant la vitalité des nœuds, l'unité des intérêts et la décentralisation.
Les avantages de DPoS :
Haute efficacité : grâce à un nombre contrôlable de nœuds de production de blocs, le réseau peut terminer la confirmation en millisecondes, répondant ainsi à des besoins de TPS élevés.
Coût faible : Moins de nœuds participant au consensus, la bande passante et les ressources informatiques nécessaires pour la synchronisation des informations et l'agrégation des signatures sont considérablement réduites. Par conséquent, le coût des matériels et de l'exploitation diminue, les exigences en matière de puissance de calcul diminuent, ce qui réduit les coûts. Cela permet finalement d'atteindre des frais d'utilisateur plus bas.
Sécurité élevée : le mécanisme de staking 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éprime efficacement les comportements malveillants.
Parallèlement, 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 agit de manière malveillante, le réseau peut rester sécurisé et fonctionner efficacement. Pour toute mise à niveau ou décision majeure, plus des deux tiers des votes sont également nécessaires pour être mises en œuvre.
Essentiellement, le DPoS est en réalité une solution de compromis au triangle impossible, réalisant un compromis entre décentralisation et efficacité. Dans le "triangle impossible" de sécurité-décialisation-scalabilité, le DPoS choisit de réduire le nombre de nœuds de validation 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 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 technique, cela rend impossible l'emballage des transactions de transfert 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 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. Étant donné que cette fonctionnalité existe déjà dans le client, lorsque l'attaque se produit
SUI peut immédiatement geler l'adresse des hackers. Sans cette fonctionnalité, même si SUI n'a que 113 validateurs, il serait difficile pour Cetus de coordonner tous les validateurs un par un dans un court laps de temps.
3.2.2 Qui a le pouvoir de modifier la liste noire ?
TransactionDenyConfig est un fichier de configuration YAML/TOML chargé localement par chaque validateur. Toute personne exécutant un nœud peut éditer ce fichier, recharger à chaud ou redémarrer le nœud, et mettre à jour la liste. En apparence, chaque validateur semble exprimer librement ses 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", il appartient essentiellement à la fondation SUI (ou à ses développeurs autorisés) de mettre en place et de mettre à jour cette liste de refus.
SUI publie une liste noire, les validateurs peuvent théoriquement 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 fonction de liste noire
La fonctionnalité de liste noire n'est en réalité pas une logique de bas niveau du protocole, 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.
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 n'est activée que pour ceux qui souhaitent s'introduire chez vous, c'est-à-dire pour les personnes malintentionnées envers le protocole. Pour l'utilisateur :
Pour les gros détenteurs, principaux fournisseurs de liquidité, le protocole cherche avant tout à garantir la sécurité des fonds, car en réalité, les données on-chain de tvl sont entièrement fournies par les principaux gros détenteurs. Pour assurer le développement à long terme du protocole, il est impératif de garantir la sécurité en priorité.
Pour les petits investisseurs, contributeurs à l'activité de l'écosystème, soutiens solides de la technologie et de la co-construction de la communauté. Projet