Croyance ferme après une crise de sécurité : Pourquoi SUI possède-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 2023, le protocole AMM de premier plan déployé sur le réseau SUI, Cetus, a subi une attaque de hacker. L'attaquant a exploité une vulnérabilité logique liée à un "problème de débordement d'entier" pour lancer une manipulation précise, entraînant une perte de plus de 200 millions de dollars d'actifs. Cet incident est non seulement l'un des plus grands incidents de sécurité dans le domaine de la DeFi cette année, mais il représente également la cyberattaque la plus destructrice depuis le lancement de la blockchain principale SUI.
Selon les données de DefiLlama, le TVL total de SUI a chuté de plus de 330 millions de dollars le jour de l'attaque, et le montant verrouillé du protocole Cetus a même été instantanément réduit de 84%, tombant à 38 millions de dollars. En conséquence, plusieurs jetons populaires sur SUI ont chuté de 76% à 97% en seulement une heure, suscitant une large préoccupation 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'incident 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.
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, afin de dresser un état des lieux de cette blockchain publique qui en est encore à ses débuts 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 de Slow Mist, 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 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 échange instantané de 10 milliards de haSUI avec un glissement maximum, 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, en ne payant que des frais. Il présente des caractéristiques de haute levée, 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 et les contrôler avec précision dans une plage très étroite.
Ensuite, l'attaquant se prépare à créer une position de liquidité extrêmement étroite, en 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 une quantité suffisante de tokens et une énorme liquidité. Ensuite, ils ont ciblé plusieurs tokens sans valeur réelle pour les manipuler.
②Ajouter de la liquidité
L'attaquant crée une position de liquidité étroite, déclarant ajouter de la liquidité, mais en raison d'une vulnérabilité dans la fonction checked_shlw, il ne reçoit finalement qu'un seul jeton.
Cela est essentiellement dû à deux raisons :
Paramètres de masque trop larges : équivalent à une limite d'ajout de liquidité extrêmement élevée, rendant la validation des entrées des utilisateurs dans le contrat pratiquement inutile. Les hackers contournent la détection de dépassement en définissant des paramètres anormaux, construisant des entrées toujours inférieures à cette limite.
Débordement de données tronqué : lors de l'exécution d'un décalage n << 64 sur la valeur n, un débordement s'est produit car le décalage dépasse la largeur de bits efficace du type de données uint256 (256 bits). La partie de débordement supérieur a été automatiquement abandonné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écessaire pour l'échange. Le résultat final du calcul est d'environ moins de 1, mais comme il s'agit d'un arrondi vers le haut, le résultat final est donc égal à 1, ce qui signifie que le hacker n'a besoin d'ajouter qu'un seul jeton pour obtenir une énorme liquidité.
③ retirer la liquidité
Effectuer le remboursement d'un prêt instantané tout en conservant des profits considérables. Retirer finalement des actifs de jetons d'une valeur totale de plusieurs centaines de millions de dollars de plusieurs pools de liquidité.
La situation des pertes de fonds est grave, l'attaque a entraîné le vol des actifs suivants :
12,9 millions de SUI (environ 5,4 millions de dollars)
60 millions de dollars USDC
490万美元Haedal Staked SUI
19,5 millions de dollars TOILET
D'autres jetons comme HIPPO et LOFI ont chuté de 75 à 80 %, la liquidité s'épuisant.
2.2 Les causes et caractéristiques de la vulnérabilité
La vulnérabilité de Cetus présente trois caractéristiques :
Coût de réparation extrêmement bas : d'une part, la cause fondamentale de l'incident Cetus est une négligence dans la bibliothèque mathématique de Cetus, et non une erreur dans le mécanisme de prix du protocole ou une erreur d'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, 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, assurant ainsi que la logique des contrats ultérieurs est complète et éliminant cette vulnérabilité.
Haute dissimulation : le contrat fonctionne de manière stable et sans défaut depuis deux ans, le protocole Cetus a subi plusieurs audits, 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 avec précision des intervalles de transaction, créant ainsi des scénarios extrêmement rares de soumission d'une 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. 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 unique à Move :
Move est supérieur à de nombreux langages de contrats intelligents en termes 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 survenu car lors de l'ajout de liquidité, un nombre incorrect a d'abord été utilisé pour le contrôle de la limite supérieure lors du calcul du nombre de jetons requis, et une opération de décalage a remplacé l'opération de multiplication conventionnelle. Si des opérations d'addition, de soustraction, de multiplication et de division conventionnelles étaient utilisées, Move vérifierait automatiquement les situations de débordement, évitant ainsi ce problème de troncature des bits supérieurs.
Des vulnérabilités similaires ont également été observées dans d'autres langages (comme Solidity, Rust), et elles peuvent être plus facilement exploitées en raison de leur manque de protection contre le débordement 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 plage. Par exemple, les vulnérabilités des contrats intelligents BEC et SMT en Solidity ont contourné les instructions de vérification dans le contrat grâce à des paramètres soigneusement construits, permettant ainsi des attaques par transfert excessif.
3. Mécanisme de consensus de SUI
3.1 Introduction au mécanisme de consensus SUI
Aperçu :
SUI adopte un cadre de preuve d'enjeu déléguée (DeleGated Proof of Stake, abrégé DPoS)). Bien que le mécanisme DPoS puisse améliorer le débit des transactions, il ne peut pas offrir un niveau de décentralisation aussi élevé que la preuve de travail (PoW). Par conséquent, le niveau de décentralisation de SUI est relativement faible, le seuil de gouvernance est relativement élevé, et il est difficile pour les utilisateurs ordinaires d'influencer directement la gouvernance du réseau.
Nombre moyen de validateurs : 106
Durée moyenne d'Epoch : 24 heures
Mécanisme de processus :
Délégation des 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 à des validateurs candidats pour participer à la garantie de la sécurité du réseau et à la distribution des récompenses. Ce mécanisme peut réduire le seuil de participation pour les utilisateurs ordinaires, leur permettant de participer au consensus du réseau en "employant" des validateurs de confiance. C'est également un grand avantage du DPoS par rapport au PoS traditionnel.
Représente le tour de création de blocs : un petit nombre de validateurs sélectionnés créent 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 comptage des votes, en fonction du poids des votes, une rotation dynamique est effectuée pour réélire l'ensemble des validateurs, garantissant la vitalité des nœuds, la cohérence des intérêts et la décentralisation.
Les avantages de 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 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 considérablement réduites. Par conséquent, les coûts matériels et d'exploitation diminuent, 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.
Haute sécurité : les mécanismes de staking et de délégation augmentent simultanément le coût et le risque d'attaque ; combinés à un mécanisme de confiscation sur la chaîne, ils répriment efficacement les comportements malveillants.
En même temps, dans le mécanisme de consensus de SUI, un algorithme basé sur BFT (tolérance aux pannes byzantines) est utilisé, exigeant que plus des deux tiers des votes des validateurs soient d'accord pour confirmer les transactions. Ce mécanisme garantit que même si quelques nœuds sont malveillants, le réseau peut rester sécurisé et fonctionner de manière efficace. Pour toute mise à niveau ou décision majeure, il est également nécessaire d'avoir plus des deux tiers des votes pour être mis en œuvre.
En essence, le DPoS est en réalité un compromis du triangle impossible, conciliant décentralisation et efficacité. Dans le "triangle impossible" de la sécurité-décente-étendabilité, le DPoS choisit de réduire le nombre de nœuds de validation actifs pour obtenir de meilleures performances, renonçant ainsi à un certain degré de décentralisation totale 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 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 du code, cela empêche les transactions de transfert d'être regroupées et ajoutées à la chaîne. Les nœuds de validation sont des composants clés de la blockchain SUI, responsables de la vérification 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 une sorte de mécanisme similaire au 'gel de compte' dans la finance traditionnelle au niveau du consensus.
SUI intègre un mécanisme de liste de refus (deny list), qui est une fonctionnalité de liste noire, permettant d'empêcher toute transaction impliquant des adresses répertoriées. Étant donné que cette fonctionnalité est déjà présente dans le client, cela signifie que 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 éditer ce fichier, le 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 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 par l'équipe SUI", c'est donc essentiellement la fondation SUI (ou les développeurs autorisés par celle-ci) qui établit et met à jour cette liste de refus.
SUI publie une liste noire, les validateurs peuvent théoriquement choisir de l'adopter ou non ------ mais en réalité, la plupart des gens l'adopteront automatiquement par défaut. Ainsi, bien que cette fonctionnalité protège les fonds des utilisateurs, elle présente en essence un certain degré de centralisation.
3.2.3 La nature de la fonction de liste noire
La fonction de blacklist n'est en réalité pas une logique de niveau protocolaire, elle ressemble davantage à une couche de sécurité supplémentaire destinée à faire face à des situations imprévues et à garantir la sécurité des fonds des utilisateurs.
C'est essentiellement un mécanisme de garantie de sécurité. Semblable à une "chaîne de sécurité" attachée à une porte, elle ne s'active que contre ceux qui souhaitent entrer par effraction, c'est-à-dire contre les personnes malveillantes du protocole. Pour les utilisateurs :
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 du TVL sont toutes contribué par les principaux gros investisseurs. Pour que le protocole se développe durablement, il est impératif de donner la priorité à la sécurité.
Pour les petits investisseurs, contributeurs à l'activité de l'écosystème, soutiens solides de la construction technique et communautaire. L'équipe du projet espère également attirer les petits investisseurs à co-construire,
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.
13 J'aime
Récompense
13
5
Partager
Commentaire
0/400
MEVHunterNoLoss
· Il y a 10h
Cette vague de hack, je n'ai même pas peur de Cut Loss.
Voir l'originalRépondre0
gas_fee_trauma
· Il y a 10h
炒币亏完了就全在这
Répondre0
faded_wojak.eth
· Il y a 11h
Tu as encore le culot de parler de résilience, tu as été complètement dépouillé.
Voir l'originalRépondre0
LiquidationKing
· Il y a 11h
sui n'est pas nécessairement frais, mais il faut faire attention au fer.
La résilience de l'écosystème SUI se manifeste, montrant un potentiel de hausse à long terme après des événements de sécurité.
Croyance ferme après une crise de sécurité : Pourquoi SUI possède-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 2023, le protocole AMM de premier plan déployé sur le réseau SUI, Cetus, a subi une attaque de hacker. L'attaquant a exploité une vulnérabilité logique liée à un "problème de débordement d'entier" pour lancer une manipulation précise, entraînant une perte de plus de 200 millions de dollars d'actifs. Cet incident est non seulement l'un des plus grands incidents de sécurité dans le domaine de la DeFi cette année, mais il représente également la cyberattaque la plus destructrice depuis le lancement de la blockchain principale SUI.
Selon les données de DefiLlama, le TVL total de SUI a chuté de plus de 330 millions de dollars le jour de l'attaque, et le montant verrouillé du protocole Cetus a même été instantanément réduit de 84%, tombant à 38 millions de dollars. En conséquence, plusieurs jetons populaires sur SUI ont chuté de 76% à 97% en seulement une heure, suscitant une large préoccupation 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'incident 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.
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, afin de dresser un état des lieux de cette blockchain publique qui en est encore à ses débuts 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 de Slow Mist, 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 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 échange instantané de 10 milliards de haSUI avec un glissement maximum, 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, en ne payant que des frais. Il présente des caractéristiques de haute levée, 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 et les contrôler avec précision dans une plage très étroite.
Ensuite, l'attaquant se prépare à créer une position de liquidité extrêmement étroite, en 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 une quantité suffisante de tokens et une énorme liquidité. Ensuite, ils ont ciblé plusieurs tokens sans valeur réelle pour les manipuler.
②Ajouter de la liquidité
L'attaquant crée une position de liquidité étroite, déclarant ajouter de la liquidité, mais en raison d'une vulnérabilité dans la fonction checked_shlw, il ne reçoit finalement qu'un seul jeton.
Cela est essentiellement dû à deux raisons :
Paramètres de masque trop larges : équivalent à une limite d'ajout de liquidité extrêmement élevée, rendant la validation des entrées des utilisateurs dans le contrat pratiquement inutile. Les hackers contournent la détection de dépassement en définissant des paramètres anormaux, construisant des entrées toujours inférieures à cette limite.
Débordement de données tronqué : lors de l'exécution d'un décalage n << 64 sur la valeur n, un débordement s'est produit car le décalage dépasse la largeur de bits efficace du type de données uint256 (256 bits). La partie de débordement supérieur a été automatiquement abandonné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écessaire pour l'échange. Le résultat final du calcul est d'environ moins de 1, mais comme il s'agit d'un arrondi vers le haut, le résultat final est donc égal à 1, ce qui signifie que le hacker n'a besoin d'ajouter qu'un seul jeton pour obtenir une énorme liquidité.
③ retirer la liquidité
Effectuer le remboursement d'un prêt instantané tout en conservant des profits considérables. Retirer finalement des actifs de jetons d'une valeur totale de plusieurs centaines de millions de dollars de plusieurs pools de liquidité.
La situation des pertes de fonds est grave, l'attaque a entraîné le vol des actifs suivants :
12,9 millions de SUI (environ 5,4 millions de dollars)
60 millions de dollars USDC
490万美元Haedal Staked SUI
19,5 millions de dollars TOILET
D'autres jetons comme HIPPO et LOFI ont chuté de 75 à 80 %, la liquidité s'épuisant.
2.2 Les causes et caractéristiques de la vulnérabilité
La vulnérabilité de Cetus présente trois caractéristiques :
Coût de réparation extrêmement bas : d'une part, la cause fondamentale de l'incident Cetus est une négligence dans la bibliothèque mathématique de Cetus, et non une erreur dans le mécanisme de prix du protocole ou une erreur d'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, 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, assurant ainsi que la logique des contrats ultérieurs est complète et éliminant cette vulnérabilité.
Haute dissimulation : le contrat fonctionne de manière stable et sans défaut depuis deux ans, le protocole Cetus a subi plusieurs audits, 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 avec précision des intervalles de transaction, créant ainsi des scénarios extrêmement rares de soumission d'une 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. 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 contrats intelligents en termes 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 survenu car lors de l'ajout de liquidité, un nombre incorrect a d'abord été utilisé pour le contrôle de la limite supérieure lors du calcul du nombre de jetons requis, et une opération de décalage a remplacé l'opération de multiplication conventionnelle. Si des opérations d'addition, de soustraction, de multiplication et de division conventionnelles étaient utilisées, Move vérifierait automatiquement les situations de débordement, évitant ainsi ce problème de troncature des bits supérieurs.
Des vulnérabilités similaires ont également été observées dans d'autres langages (comme Solidity, Rust), et elles peuvent être plus facilement exploitées en raison de leur manque de protection contre le débordement 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 plage. Par exemple, les vulnérabilités des contrats intelligents BEC et SMT en Solidity ont contourné les instructions de vérification dans le contrat grâce à des paramètres soigneusement construits, permettant ainsi des attaques par transfert excessif.
3. Mécanisme de consensus de SUI
3.1 Introduction au mécanisme de consensus SUI
Aperçu :
SUI adopte un cadre de preuve d'enjeu déléguée (DeleGated Proof of Stake, abrégé DPoS)). Bien que le mécanisme DPoS puisse améliorer le débit des transactions, il ne peut pas offrir un niveau de décentralisation aussi élevé que la preuve de travail (PoW). Par conséquent, le niveau de décentralisation de SUI est relativement faible, le seuil de gouvernance est relativement élevé, et il est difficile pour les utilisateurs ordinaires d'influencer directement la gouvernance du réseau.
Nombre moyen de validateurs : 106
Durée moyenne d'Epoch : 24 heures
Mécanisme de processus :
Délégation des 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 à des validateurs candidats pour participer à la garantie de la sécurité du réseau et à la distribution des récompenses. Ce mécanisme peut réduire le seuil de participation pour les utilisateurs ordinaires, leur permettant de participer au consensus du réseau en "employant" des validateurs de confiance. C'est également un grand avantage du DPoS par rapport au PoS traditionnel.
Représente le tour de création de blocs : un petit nombre de validateurs sélectionnés créent 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 comptage des votes, en fonction du poids des votes, une rotation dynamique est effectuée pour réélire l'ensemble des validateurs, garantissant la vitalité des nœuds, la cohérence des intérêts et la décentralisation.
Les avantages de 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 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 considérablement réduites. Par conséquent, les coûts matériels et d'exploitation diminuent, 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.
Haute sécurité : les mécanismes de staking et de délégation augmentent simultanément le coût et le risque d'attaque ; combinés à un mécanisme de confiscation sur la chaîne, ils répriment efficacement les comportements malveillants.
En même temps, dans le mécanisme de consensus de SUI, un algorithme basé sur BFT (tolérance aux pannes byzantines) est utilisé, exigeant que plus des deux tiers des votes des validateurs soient d'accord pour confirmer les transactions. Ce mécanisme garantit que même si quelques nœuds sont malveillants, le réseau peut rester sécurisé et fonctionner de manière efficace. Pour toute mise à niveau ou décision majeure, il est également nécessaire d'avoir plus des deux tiers des votes pour être mis en œuvre.
En essence, le DPoS est en réalité un compromis du triangle impossible, conciliant décentralisation et efficacité. Dans le "triangle impossible" de la sécurité-décente-étendabilité, le DPoS choisit de réduire le nombre de nœuds de validation actifs pour obtenir de meilleures performances, renonçant ainsi à un certain degré de décentralisation totale 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 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 du code, cela empêche les transactions de transfert d'être regroupées et ajoutées à la chaîne. Les nœuds de validation sont des composants clés de la blockchain SUI, responsables de la vérification 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 une sorte de mécanisme similaire au 'gel de compte' dans la finance traditionnelle au niveau du consensus.
SUI intègre un mécanisme de liste de refus (deny list), qui est une fonctionnalité de liste noire, permettant d'empêcher toute transaction impliquant des adresses répertoriées. Étant donné que cette fonctionnalité est déjà présente dans le client, cela signifie que 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 éditer ce fichier, le 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 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 par l'équipe SUI", c'est donc essentiellement la fondation SUI (ou les développeurs autorisés par celle-ci) qui établit et met à jour cette liste de refus.
SUI publie une liste noire, les validateurs peuvent théoriquement choisir de l'adopter ou non ------ mais en réalité, la plupart des gens l'adopteront automatiquement par défaut. Ainsi, bien que cette fonctionnalité protège les fonds des utilisateurs, elle présente en essence un certain degré de centralisation.
3.2.3 La nature de la fonction de liste noire
La fonction de blacklist n'est en réalité pas une logique de niveau protocolaire, elle ressemble davantage à une couche de sécurité supplémentaire destinée à faire face à des situations imprévues et à garantir la sécurité des fonds des utilisateurs.
C'est essentiellement un mécanisme de garantie de sécurité. Semblable à une "chaîne de sécurité" attachée à une porte, elle ne s'active que contre ceux qui souhaitent entrer par effraction, c'est-à-dire contre les personnes malveillantes du protocole. Pour les utilisateurs :
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 du TVL sont toutes contribué par les principaux gros investisseurs. Pour que le protocole se développe durablement, il est impératif de donner la priorité à la sécurité.
Pour les petits investisseurs, contributeurs à l'activité de l'écosystème, soutiens solides de la construction technique et communautaire. L'équipe du projet espère également attirer les petits investisseurs à co-construire,