À la suite des hacks de ponts blockchain, où un attaquant prend le contrôle pour "frapper" des millions de tokens non autorisés sur une chaîne secondaire comme la BNB Chain, une question technique courante émerge au sein de la communauté : "Pourquoi le projet ne brûle-t-il pas simplement un montant équivalent de tokens sur la chaîne Ethereum d'origine pour rééquilibrer l'offre ?"
D'un point de vue comptable, ça peut sembler une manière logique de prévenir l'inflation. Cependant, dans le DeFi, "brûler des tokens" n'est pas une baguette magique qui résout les conséquences d'une attaque. Voici pourquoi cette approche est souvent inefficace et peut même causer davantage de dommages aux utilisateurs.
1. Le "dépeggement" du mécanisme de garantie
La plupart des ponts fonctionnent sur le principe que les actifs sur une chaîne secondaire (BNB Chain) doivent être soutenus 1:1 par des actifs réels verrouillés dans un "coffre" (smart contract) sur la chaîne principale (Ethereum). Lorsqu'un hacker crée des tokens non autorisés sur la BNB Chain, ces tokens sont "non soutenus".
Si un projet décide de brûler 100 millions de tokens réels du coffre Ethereum pour "équilibrer" contre les 100 millions de faux tokens créés par le hacker, le projet détruit involontairement la valeur de garantie de l'ensemble de l'écosystème. Les utilisateurs détenant des tokens "wrapped" sur la BNB Chain se retrouveraient dans une situation où leurs actifs n'ont plus de valeur sous-jacente réelle. Au lieu de résoudre le problème, cette action transforme effectivement les actifs des utilisateurs en "déchets."
2. La réalité de la liquidité drainée
Le point clé que beaucoup négligent est le suivant : les hackers n'attaquent pas pour conserver des tokens ; ils attaquent pour les liquider. Immédiatement après avoir réussi à créer les tokens, le hacker les vendra sur des échanges décentralisés (DEX) pour siphonner des actifs précieux comme USDT, USDC, ETH ou BNB.
Une fois que le hacker les a vendus, il a déjà drainé la vraie liquidité (argent réel) du projet. Brûler des tokens après coup ne fait que réduire le chiffre de l'offre totale sur le tableau de bord ; l'argent réel que le hacker a volé est perdu à jamais. Brûler des tokens à ce stade est comme "fermer la porte de la grange après que les vaches aient déjà été volées."
3. "Nettoyage" ou punir les utilisateurs ?
Dans un smart contract, les tokens sont généralement échangeables. C'est extrêmement difficile pour un projet de distinguer entre les tokens "propres" achetés par des utilisateurs avec de l'argent réel et les tokens "sales" créés par un hacker. Si un projet applique un mécanisme de brûlage ou intervient agressivement dans l'offre, le plus grand risque est que des utilisateurs innocents deviennent les principales victimes. Ils perdent non seulement foi en le projet, mais font également face à une dévaluation soudaine de leurs actifs en raison de l'instabilité de l'offre.
Brûler des tokens pour compenser un hack est simplement une solution "réactive" sur le papier, manquant d'application pratique dans la sécurité blockchain. Au lieu de manipuler l'offre, les projets devraient se concentrer sur l'isolement du hacker : geler les adresses de portefeuille suspectes, coordonner avec les CEX pour bloquer le flux des fonds volés, et effectuer un audit complet de l'infrastructure de pont pour identifier la vulnérabilité racine.
La sécurité des utilisateurs ne réside pas dans des chiffres brûlés, mais dans la capacité d'un projet à contrôler et protéger ses actifs réels contre les attaquants. #humanity #Hack $H
