Le cofondateur de deBridge tire la sonnette d'alarme concernant les plans de redémarrage de Flow après le piratage

Alex Smirnov, cofondateur de deBridge, a pointé du doigt certains points qu'il considère comme des erreurs critiques alors que l'équipe Flow continue de se remettre de la récente attaque qui a touché son réseau. 

Dans le cadre de ses efforts de redressement, l'équipe de Flow a suggéré une restauration, ce qui a suscité des interrogations, car des critiques comme Smirnov, dont la société deBridge est intégrée à Flow, ont affirmé n'avoir reçu aucune communication ni coordination de la part de l'équipe de Flow.

Et ce, malgré de Flow les affirmations ils se synchronisaient avec des partenaires clés.

Pourquoi de deBridge s'intéresse-t-il au flux ?

Selon Smirnov, la décision de revenir en arrière a été prise précipitamment 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 dépositaires, 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 Flow à ne pas valider les transactions sur la chaîne restaurée tant que certaines questions cruciales n'auront pas reçu de réponse claire.

L'une de ces questions est de savoir comment Flow prévoit de gérer les soldes doublés pour les utilisateurs qui ont quitté Flow pendant la période de restauration et dont les soldes ont doublé en raison de cette restauration, et comment les utilisateurs qui ont rejoint Flow pendant cette même période seront remboursés.

Il souhaite également obtenir des réponses sur la manière dont les dépositaires de l'écosystème, tels que LayerZero, géreront les cas de transactions exécutées juste pendant la période de restauration.

Smirnov a souligné desdentsimilaires, affirmant qu'ils avaient été gérés de manière beaucoup plus professionnelle, les pirates ayant été isolés sans qu'il soit nécessaire de revenir en arrière.

« Pourquoi Flow adopte-t-il une approche différente ? » demanda-t-il. « Qui a pris la décision de revenir en arrière ? »

Smirnov a exhorté les validateurs de Flow à suspendre les nœuds et à interrompre 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 autre tweet, Smirnov a insisté sur l'inutilité de la solution de Flow en soulignant que l'attaquant avait déjà « transféré environ 4 millions de dollars et consolidé les fonds à cette adresse avant de poursuivre ».

« À ce stade, une restauration n’a aucun impact sur l’attaquant de Flow et ne nuit qu’aux utilisateurs innocents, aux fournisseurs de liquidités et aux partenaires de l’écosystème qui ont agi honnêtement pendant la période de restauration », a-t-il écrit.

de la réclamation de fluxLe retour enest la méthode la plus sûre pour procéder

Selon l'équipe Flow, la seule solution logique est de restaurer le réseau à un état antérieur à l'exploitation de la faille. Le plan consiste à supprimer les transactions non autorisées du registre.

La période de restauration concernera les transactions soumises entre environ 23h25 PST (26 décembre) et l'arrêt du réseau à 5h30 PST ( 27 décembre). devront être soumises à nouveau après le redémarrage, y compris celles des utilisateurs légitimes que la solution proposée pourrait gêner.

Les validateurs ont accepté et déployé le correctif 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.

À compter du 28 décembre, la synchronisation a été étendue afin de garantir que tous les partenaires reviennent à leur état antérieur à l'exploitation de la faille.