Le co-fondateur de deBridge soulève des inquiétudes concernant les plans de reprise de Flow après le piratage
- Alex Smirnov, co-fondateur de deBridge, a remis en question la décision de l'équipe de Flow de revenir en arrière sur son réseau suite à un récent piratage.
- Smirnov a exhorté les validateurs du réseau à ne pas mettre en pause leurs nœuds et à ne pas arrêter la validation tant que plus de détails ne sont pas fournis par l'équipe.
- L'équipe estime que le retour en arrière est la manière la plus sûre de procéder, mais le réseau reste en mode lecture seule pendant que les problèmes sont résolus.
Alex Smirnov, co-fondateur de deBridge a souligné certains éléments qu'il perçoit comme des erreurs critiques alors que l'équipe de Flow continue de se remettre de la récente attaque qui a frappé son réseau.
Dans le cadre de ses efforts de récupération, l'équipe de Flow a suggéré un retour en arrière (rollback), ce qui a soulevé des interrogations, car des critiques comme Smirnov, dont l'entreprise deBridge, est intégrée à Flow, ont affirmé n'avoir reçu aucune communication ni coordination de la part de l'équipe de Flow.
C'est bien que Flow ait affirmé qu'ils se synchronisaient avec des partenaires critiques.
Pourquoi deBridge's Smirnov inquiet concernant Flow ?
Selon Smirnov, la décision de revenir en arrière a été précipitée et entraînera probablement des dommages financiers bien supérieurs à l'impact de l'exploitation initiale.
« Un retour en arrière introduit des problèmes systémiques qui affectent les ponts, les gardiens, les utilisateurs et les contreparties qui ont agi honnêtement pendant la période concernée », a expliqué Smirnov avant d'exhorter tous les validateurs de Flow à ne pas valider les transactions sur la chaîne retournée jusqu'à ce que des questions cruciales soient clairement répondues.
L'une de ces questions concerne la manière dont Flow compte gérer les soldes doublés pour les utilisateurs qui ont ponté vers l'extérieur de Flow pendant la fenêtre de retour en arrière et dont les soldes ont été doublés en raison de l'annulation, ainsi que la manière dont les utilisateurs qui ont ponté vers Flow pendant la fenêtre de retour en arrière seront remboursés.
Une autre question à laquelle il souhaite des réponses concerne la manière dont les gardiens de l'écosystème, tels que LayerZero, géreront les cas de transactions exécutées juste dans la fenêtre de retour en arrière.
Smirnov a mis en lumière des incidents similaires, affirmant qu'ils avaient été gérés de manière beaucoup plus professionnelle, avec les pirates isolés sans besoin de retour en arrière.
« Pourquoi Flow adopte-t-il une approche différente ? » a-t-il demandé. « Qui a pris la décision de revenir en arrière sur la chaîne ? »
Smirnov a exhorté les validateurs de Flow à mettre en pause les nœuds et à arrêter la validation jusqu'à ce que des plans de remédiation clairs aient été communiqués par l'équipe, que les partenaires de l'écosystème aient été correctement coordonnés et que des groupes de sécurité comme Security Alliance aient été impliqués.
Dans un tweet séparé, Smirnov a réitéré l'inutilité de la solution de Flow en soulignant que l'attaquant avait déjà « ponté ~4 M$ et consolidé les fonds à cette adresse avant de les déplacer plus loin.
« À ce stade, un retour en arrière n'a aucun impact sur l'attaquant de Flow et nuit uniquement aux utilisateurs innocents, aux fournisseurs de liquidités et aux partenaires de l'écosystème qui ont agi honnêtement pendant la fenêtre de retour en arrière », a-t-il écrit.
Allégation de Flows rollback is the safest way to se poursuivra
Selon l'équipe de Flow, elle n'a pas d'autre moyen logique d'avancer que de restaurer le réseau à un point de contrôle antérieur à l'exploitation. Le plan consiste à supprimer les transactions non autorisées du registre.
La fenêtre de retour en arrière couvrira les transactions soumises entre environ 23 h 25 HNP (26 décembre) et l'arrêt du réseau à 5 h 30 HNP (26 décembre 27) devront être resoumises après le redémarrage, y compris pour tout utilisateur légitime que le remède proposé pourrait gêner.
Les validateurs ont accepté et déployé la correction Mainnet-28, mais le réseau est toujours en mode lecture seule pour la synchronisation avec les ponts, les CEX et les DEX afin d'éviter les incohérences d'état.
Au 28 décembre, la synchronisation a été prolongée pour garantir que tous les partenaires réinitialisent leur état à celui d'avant l'exploitation.
Les esprits les plus brillants du secteur crypto lisent déjà notre newsletter. Vous aussi ? Rejoignez-les.
Avertissement. Les informations fournies ne constituent pas des conseils en matière d'investissement. Cryptopolitan.com ne saurait être tenue responsable des investissements réalisés sur la base des informations fournies sur cette page. Nous recommandons vivement de mener vos propres recherches et/ou de consulter un professionnel qualifié avant de prendre toute décision d'investissement.
Hannah Collymore
Hannah est rédactrice et éditrice avec près de dix ans d'expérience dans la rédaction de blogs et le reporting d'événements dans l'espace crypto. Chez Cryptopolitan, Hannah contribue à la page actualités, en rapportant et en analysant les derniers développements dans les secteurs de la DeFi, des RWA, de la régulation des crypto-monnaies, de l'IA et des technologies de pointe. Elle est diplômée de l'Université Arcadia avec un diplôme en administration des affaires.
