MultiversX a déclaré prévoir un hard fork coordonné à partir de points de contrôle reconnus comme fiables, après ce qu’il a décrit comme un incident d’attaque provoqué par une erreur dans une séquence opérationnelle. Le projet a ajouté que les validateurs avaient maîtrisé la situation et que les échanges et les ponts inter-chaînes rouvriraient progressivement après le redémarrage du réseau.

Selon la déclaration du projet, la cause profonde de l’incident était une erreur dans une séquence opérationnelle, et non une défaillance du protocole qui n’aurait pas encore été divulguée. MultiversX a indiqué que les validateurs avaient réagi rapidement et maîtrisé la situation, et a proposé un hard fork coordonné utilisant des points de contrôle reconnus comme fiables comme base de la récupération.

Le projet a précisé que le processus de récupération serait d’abord répété avec les validateurs sur le testnet et le réseau de développement. Il a également indiqué que le code concerné avait été rendu public et que les tests étaient toujours en cours. Jusqu’à l’achèvement officiel de la récupération, MultiversX a demandé aux utilisateurs de ne pas soumettre ni rediffuser de transactions.

MultiversX a aussi indiqué que les comptes de l’attaquant avaient été identifiés et gelés sur de grandes plateformes d’échange, et que les autorités chargées de l’application de la loi étaient impliquées. Toutefois, la déclaration ne précise ni quelles plateformes ont gelé les comptes, ni quelles autorités participent, ni si des actifs ont déjà été récupérés.

Les consignes opérationnelles du réseau allaient au-delà de l’activité on-chain. MultiversX a indiqué qu’il ne fallait pas accéder à EGLD et ESDT via les échanges ou les ponts inter-chaînes avant l’avis officiel de récupération, soulignant que l’incident affecte non seulement la coordination des validateurs, mais aussi l’infrastructure tierce connectée à la chaîne.

Pourquoi c’est important

Un hard fork coordonné pour récupérer après un incident constitue une étape à haut risque pour toute blockchain, car il met simultanément à l’épreuve la coordination des validateurs, le soutien des plateformes d’échange et la confiance des utilisateurs. Dans ce cas, le plan de récupération ne se limite pas à corriger le code : il dépend aussi de la sélection des points de contrôle, d’une action synchronisée de l’infrastructure et d’une réouverture ordonnée des plateformes de négociation et des ponts.

Cet épisode met également en évidence la rapidité avec laquelle des incidents de sécurité peuvent se répercuter sur l’infrastructure de marché centralisée. Même lorsqu’un réseau affirme que la situation est maîtrisée, les gels opérés par les échanges, les restrictions sur les ponts et l’implication des autorités peuvent influencer la fluidité avec laquelle les actifs reviennent à une circulation normale après le redémarrage de la chaîne.