MultiversX a suspendu les opérations de son mainnet après qu'un attaquant a tenté d'exploiter un problème d'atomicité des transactions dans la couche machine virtuelle du réseau, laissant des changements invalides enregistrés on-chain. L'équipe a arrêté la production de blocs, mis un correctif en test sur shadow fork et indiqué évaluer une récupération ciblée. Aucun montant de perte confirmé n'a été communiqué.

Ce que MultiversX a confirmé

• Le problème concernait l'atomicité des transactions.
• Des changements invalides ont été enregistrés on-chain.
• Les opérations du mainnet ont été suspendues.
• Un correctif est entré en phase de test sur shadow fork.
• Une récupération ciblée était à l'étude.

Ce qui reste inconnu

• Si les utilisateurs ont définitivement perdu des fonds.
• Quels comptes ou contrats ont été touchés.
• Comment l'attaquant a déclenché la défaillance.
• Quelle méthode de récupération sera adoptée.
• Quand chaque service sera rétabli.

L'arrêt a gelé le problème — il ne l'a pas annulé

Dans sa mise à jour sur l'incident, MultiversX a indiqué qu'un attaquant avait tenté d'exploiter un problème d'atomicité dans la couche machine virtuelle du mainnet. Les développeurs ont suspendu les opérations du réseau pendant qu'ils traçaient les changements d'état résultants et préparaient un correctif. Aucun montant de perte confirmé n'avait été communiqué.

L'arrêt de la production de blocs empêche de nouvelles transactions de s'appuyer sur des enregistrements potentiellement incorrects. Il bloque également une nouvelle tentative utilisant la même méthode pendant que les ingénieurs déterminent quels soldes ou entrées de contrat ont été touchés.

La pause n'annule pas les changements déjà acceptés par le réseau. Ces enregistrements demeurent le point de départ utilisé par les portefeuilles, les applications et les ponts jusqu'à ce que MultiversX adopte un plan de récupération.

Lors d'une vérification le 20 septembre, la page de statut de MultiversX classait le système comme partiellement dégradé. L'API publique, xPortal, Explorer, Wallet, Bridge, xExchange et xLaunchpad affichaient des performances dégradées, tandis que la passerelle et l'index étaient répertoriés comme opérationnels.

Ces libellés décrivent des services individuels et ne confirment pas que le traitement normal des transactions a repris. Le rétablissement des interfaces ne résoudrait pas non plus le problème comptable sous-jacent Pour comprendre pourquoi, il faut commencer par l'atomicité des transactions.

L'atomicité est la version blockchain du « tout ou rien »

Une transaction de smart contract peut contenir plusieurs opérations liées. Un solde peut être réduit, un autre augmenté et un pool de liquidité mis à jour. L'exécution atomique exige que la séquence complète réussisse avant que l'un de ces changements ne devienne permanent.

Résultat attendu : chaque étape requise réussit et tous les changements sont validés ensemble. Si une étape échoue, aucun des changements de la transaction ne doit être validé.

Échec d'atomicité : une opération échoue, mais un changement d'état antérieur demeure. Le réseau peut alors enregistrer un résultat partiel qui n'aurait pas dû exister seul.

Il s'agit d'un exemple simplifié d'atomicité, non d'une reconstitution de l'incident MultiversX. Une transaction défectueuse pourrait laisser un solde de compte, une offre de tokens ou un enregistrement de contrat incohérent avec le résultat prévu. MultiversX n'a pas divulgué le type de données altérées ; il n'existe donc pas suffisamment d'éléments pour affirmer que l'attaquant a créé des tokens, vidé un contrat particulier ou volé un montant connu.

La finalité prouve un accord, pas une exécution sans bug

La finalité blockchain signifie que les validateurs se sont accordés sur le bloc et l'état résultant appartenant à la chaîne canonique. Elle ne prouve pas que le logiciel utilisé pour calculer cet état était exempt de défauts.

Les validateurs exécutent les mêmes règles de protocole et comparent leurs résultats. Si ces règles contiennent la même faille sur chaque nœud, les validateurs peuvent s'accorder de manière cohérente sur un résultat que le protocole n'était jamais censé permettre. Le consensus peut établir quel état le réseau a accepté ; il ne peut pas garantir qu'un bug logiciel n'a pas contribué à produire cet état.

L'installation d'un logiciel corrigé empêche le même chemin d'exécution de fonctionner à nouveau, mais elle ne décide pas du sort des changements déjà enregistrés. MultiversX doit identifier les entrées touchées et fournir aux validateurs un moyen reproductible de vérifier que l'activité non liée reste inchangée.

La shadow fork offre une répétition générale avant le redémarrage du mainnet

MultiversX a préparé un correctif pour test dans un environnement de shadow fork. Une shadow fork copie l'historique et l'état pertinents du mainnet dans un environnement isolé, permettant aux ingénieurs de reproduire les conditions réelles du réseau sans expérimenter sur des soldes réels.

L'équipe peut appliquer le correctif, rejouer la séquence touchée et tester une récupération proposée avant que les validateurs ne l'installent sur le mainnet. Ce processus doit établir :

• Si les nœuds calculent le même état réparé.
• Si les soldes non touchés restent inchangés.
• Si les applications lisent correctement les enregistrements corrigés.
• Si les ponts et les exchanges peuvent rapprocher leurs données.
• Si les validateurs peuvent redémarrer sans produire de chaînes concurrentes.

La réussite de ces tests ne réouvrirait pas automatiquement chaque service. Le déploiement nécessite toujours une coordination entre validateurs, exchanges, ponts et fournisseurs d'infrastructure reliant les utilisateurs et les applications à MultiversX.

Une réparation ciblée éviterait de rembobiner toute la chaîne

MultiversX a déclaré évaluer une récupération ciblée visant à préserver l'historique des transactions finalisées et les enregistrements légit des utilisateurs tout en ne traitant que les changements liés à l'incident. Le projet n'a pas expliqué comment cette correction serait mise en œuvre.

Correction d'état ciblée. Seuls les soldes, le stockage des contrats ou autres enregistrements liés à l'incident seraient réparés, et les transactions sans lien pourraient demeurer dans l'historique finalisé. La principale difficulté consiste à prouver que la correction inclut chaque changement invalide — et rien d'autre.

Rembobinage complet de la chaîne. Le réseau reviendrait à un bloc antérieur et reconstruirait à partir de là. Les transactions effectuées après ce point pourraient disparaître même sans lien avec l'incident. La principale difficulté est que les transferts légitimes et l'activité applicative pourraient devoir être répétés ou rapprochés.

Le coût d'un rembobinage plus large a été visible après l'exploit Tectonic, lorsque les validateurs de Cronos ont supprimé près de 11 000 blocs couvrant presque deux heures. Le rembobinage a annulé la majeure partie des emprunts liés à l'incident encore enregistrés sur Cronos, mais il a également annulé des transactions sans lien effectuées durant cette période. Les deux incidents ont des causes différentes ; l'exemple de Cronos importe ici parce qu'il illustre le coût collatéral du rembobinage d'un registre partagé.

MultiversX indique envisager une réparation plus étroite, mais n'a pas encore montré comment les enregistrements touchés seraient isolés. Une réparation ciblée ne supprimerait pas nécessairement les blocs d'origine : l'historique des transactions pourrait rester visible pendant qu'un changement de protocole coordonné établit l'état que les applications et les validateurs reconnaîtront après le redémarrage. La méthode ne peut être correctement évaluée tant que MultiversX n'a pas publié son schéma de récupération.

Ce que les utilisateurs de MultiversX doivent faire pendant la pause

Pour les détenteurs ordinaires, l'instruction la plus simple est d'attendre. MultiversX n'a demandé à personne de migrer des tokens, de connecter un portefeuille à un site de récupération ni d'approuver une transaction corrective.

• Ne soumettez ni ne retransmettez de transactions.
• Ne déposez ni ne retirez d'EGLD ou d'ESDT via des exchanges.
• Évitez de déplacer ces actifs via des ponts inter-chaînes.
• Conservez le hash de toute transaction soumise à proximité de l'arrêt.
• Ignorez les liens de récupération, les migrations et les messages d'assistance non sollicités.
• Attendez que MultiversX et la plateforme concernée confirment la réouverture.

Une réparation du réseau serait adoptée par les validateurs et les opérateurs d'infrastructure. Elle n'exigerait pas que les utilisateurs révèlent leurs phrases mnémoniques ou envoient des actifs vers une nouvelle adresse.

Les portefeuilles et les explorers peuvent également avoir besoin de temps pour se resynchroniser après la reprise de la production de blocs. Un solde obsolète ou une transaction récente manquante dans une interface ne prouverait pas, en soi, que les actifs sous-jacents ont changé.

Un redémarrage doit être vérifiable

La reprise de la production de blocs rétablira la disponibilité, mais elle ne répondra pas à elle seule à la question de la finalité. MultiversX doit encore divulguer quels comptes ou contrats ont été touchés, comment l'état réparé a été calculé et comment les validateurs ont abouti de manière indépendante au même résultat.

Si ce registre montre que seuls les changements liés à l'incident ont été corrigés, la récupération ciblée pourrait préserver davantage d'activité légitime qu'un rembobinage complet. Sans cela, le réseau pourrait reprendre pendant que les utilisateurs restent incapables de vérifier pourquoi certains changements finalisés ont étéérés et d'autres conservés.

Cet article est fourni à titre informatif uniquement et ne constitue pas un conseil financier ou d'investissement. Les conditions du réseau et les instructions de récupération peuvent évoluer à mesure que MultiversX publie de nouvelles mises à jour.