White-hat bot MEV de Ronin Network

Le 6 août 2024, le pont du réseau Ronin — le même pont fameusement drainé pour 625 M$ par Lazarus en 2022 — a été exploité à nouveau, cette fois pour 12 millions de dollars. L'exploiteur s'est avéré être un opérateur de bot MEV white-hat qui a identifié un bug d'initialisation dans du code mort et a démontré sa sévérité en extrayant la limite maximale par transaction. Tous les fonds ont été restitués en échange d'une prime de 500 000 $.

Ce qui s'est passé

Les contrats de pont de Ronin avaient subi une mise à niveau qui incluait deux fonctions d'initialisation différentes — v3 et v4 — définissant la logique de configuration du contrat pour deux versions successives. Seul l'initialiseur v4 a été effectivement appelé lors du déploiement. L'initialiseur v3 a été laissé dans le code mais jamais exécuté, traité effectivement comme du code mort.

La faille fatale : l'initialiseur v3 était responsable de définir _totalOperatorWeight — une variable critique utilisée pour calculer minimumVoteWeight, le nombre de votes de validateurs requis pour approuver une transaction cross-chain.

Parce que v3 n'a jamais été exécuté, _totalOperatorWeight n'a jamais été initialisé. Il est resté à sa valeur par défaut Solidity : zéro. Combiné à la logique de comptage des votes du pont, cela a défini minimumVoteWeight à effectivement zéro — signifiant que toute transaction avec ne serait-ce qu'une signature valide pouvait être approuvée pour un retrait cross-chain, anéantissant tout le modèle de sécurité multi-validateurs.

Un opérateur de bot MEV surveillant les contrats de Ronin a remarqué l'écart. Pour démontrer la sévérité :

1. Drainage du montant maximum par transaction depuis le pont — environ 4 000 ETH (~10 M$) et 2 millions d'USDC.
2. Sans se mettre au calme. A immédiatement contacté l'équipe de Ronin.
3. Négociation d'une restitution : tous les fonds pour une prime de 500 K$.

Conséquences

• En quelques heures, l'opérateur de bot MEV a restitué tous les fonds, classant l'événement comme une opération white-hat d'école.
• Ronin a mis le pont en pause et livré un déploiement corrigé avec une initialisation appropriée de _totalOperatorWeight.
• La prime payée était modeste selon les standards white-hat mais acceptée par l'opérateur sans négociation.

Pourquoi c'est important

L'incident Ronin 2024 est une étude de cas nette pour deux leçons récurrentes :

1. Le code mort est du code actif. Solidity n'a pas de marqueur « cette fonction n'a jamais été appelée » ; un initialiseur non appelé est juste un état non initialisé, qui est une valeur par défaut, qui peut ne pas être la valeur que la logique du contrat suppose. Le schéma se répète dans les proxies modifiables, dans les bibliothèques avec une configuration spécifique à la version, et dans tout contrat qui livre plusieurs chemins d'init et n'en exécute que certains.

2. Le MEV white-hat est maintenant une classe d'actifs significative. Plusieurs entreprises (BlockSec, HYDN, certains opérateurs Flashbots) et opérateurs individuels de bots MEV surveillent les contrats majeurs pour des conditions exploitables et exécutent des attaques de « sauvetage » qui démontrent la vulnérabilité tout en gardant les fonds récupérables. L'alignement économique est simple : la prime est fiable ; les recettes blanchies d'un exploit réel sont incertaines et de plus en plus difficiles à monétiser.

La réponse de l'équipe Ronin — accepter le cadrage white-hat, payer la prime, livrer la correction — est maintenant la réponse standard du protocole lorsqu'un opérateur white-hat connu fait surface un bug critique à grande échelle. Le modèle a ses critiques (il normalise le comportement « compromettre d'abord, demander plus tard ») mais il a manifestement épargné aux vrais protocoles de l'argent réel en 2024-2026.