Mantle intègre le correctif Reth des racines d'état dans op-reth v1.6.3 après le bug du 5 novembre, les actifs sont sûrs
Points clés
- •Mantle Network a publié op-reth mantle-v1.6.3, une version sur sa propre ligne de production qui rétroporte le correctif amont de Reth au lieu de passer à la dernière version amont.
- •La société de sécurité Blockaid a révélé le 5 novembre que les nœuds non corrigés pouvaient générer des racines d'état incorrectes et renvoyer des preuves d'état erronées via eth_getProof, la méthode RPC utilisée par les applications et les ponts pour vérifier l'état on-chain.
- •Le correctif amont est arrivé dans Reth le 3 novembre, deux jours avant la divulgation publique, dans des versions corrigées comprenant Reth v2.10.0 et op-reth v2.8.1.
- •Blockaid a classé le problème comme un bug d'exactitude plutôt que comme un exploit et n'a constaté aucune perte de fonds, tandis que Mantle a confirmé que les actifs sont sûrs, qu'aucune action des utilisateurs n'est requise et qu'aucune migration de base de données n'est nécessaire.
- •Comme la plupart des chaînes OP Stack partagent le client op-reth, le bug a créé un risque corrélé entre des réseaux par ailleurs indépendants, provoquant des réponses telles que la publication de node-reth v1.5.3 par Base et l'intégration d'un rétroportage par Celo.

Le réseau Mantle est resté en ligne tout au long d'un bug de racine d'état présent dans Reth, le client d'exécution amont à la base de sa pile op-reth, qui affectait plus largement les réseaux compatibles Ethereum. L'équipe a publié op-reth mantle-v1.6.3, une version sur la propre ligne de version de production de Mantle qui rétroporte le correctif amont du bug au lieu de passer à la dernière version amont. Dans une annonce sur X, Mantle a indiqué que les actifs sont sûrs, qu'aucune action des utilisateurs n'est requise et qu'aucune migration de base de données n'est nécessaire, tout en demandant aux opérateurs de nœuds d'effectuer la mise à niveau (publication).
Un incident bref mais aux enjeux élevés
L'épisode a été court et invisible pour les utilisateurs finaux, ce qui pourrait le faire paraître sans importance. Il ne l'est pas : les racines d'état sont des engagements cryptographiques utilisés pour prouver la validité des soldes de comptes et du stockage des contrats, et un calcul erroné peut faire bloquer les nœuds, renvoyer des preuves invalides ou provoquer une divergence de la chaîne canonique. « Pour qu'un Layer 2 règle ses transactions sur Ethereum, l'exactitude à ce niveau est fondamentale », a souligné l'annonce de Mantle.
Ce qui s'est passé et qui a été touché
La faille se trouvait dans Reth, une implémentation en Rust d'un client d'exécution Ethereum, et dans op-reth, sa variante OP Stack déployée par plusieurs réseaux Layer 2. Le 5 novembre, la société de sécurité Blockaid a révélé que les nœuds non corrigés pouvaient produire des racines d'état incorrectes et renvoyer des preuves d'état erronées via eth_getProof, la méthode RPC sur laquelle s'appuient les applications et les ponts pour vérifier l'état on-chain. Blockaid a classé le problème comme un bug d'exactitude plutôt que comme un exploit et n'a constaté aucune perte de fonds. Le correctif amont était arrivé dans Reth le 3 novembre — deux jours avant la divulgation publique de Blockaid — dans des versions corrigées comprenant Reth v2.10.0 et op-reth v2.8.1.
La réponse s'est étendue à tout l'écosystème. Base a publié node-reth v1.5.3 et a déclaré avoir revérifié l'exactitude de son nœud, tandis que Celo a intégré un rétroportage. Mantle a choisi une voie différente, corrigeant directement sa ligne de production plutôt que de passer à la dernière version — la voie du rétroportage, qui apporte un correctif ciblé à une ligne de version existante sans introduire de modifications non liées issues de versions amont plus récentes.
Pourquoi c'est important pour l'écosystème crypto au sens large
Les clients d'exécution figurent parmi les composants les moins visibles mais les plus déterminants de l'infrastructure blockchain. Les développeurs y ajoutent des API et y font fonctionner des indexeurs. Les institutions dépendent des dépositaires, des plateformes d'échange et des fournisseurs de données. Chacune de ces couches repose sur le consensus des nœuds sur l'état. Une mauvaise racine d'état ne signifie pas nécessairement des fonds volés — elle peut signifier des preuves inexactes, une synchronisation interrompue ou des applications recevant des données incohérentes.
Lorsque les ponts et les services de messagerie inter-chaînes dépendent d'un état prouvable, même une brève incohérence peut déclencher des arrêts préventifs. Ces arrêts étaient une réponse défensive, et non le résultat d'une exploitation, mais ils démontrent à quelle vitesse le bug d'un seul client peut créer une disruption à l'échelle de l'écosystème.
L'événement met également en évidence l'importance de la diversité des clients, et ses limites. La couche d'exécution d'Ethereum bénéficie de l'exécution de plusieurs clients, réduisant le risque systémique en cas de défaillance de l'un d'eux. La plupart des chaînes OP Stack, cependant, partagent op-reth. Un bug dans ce composant commun crée donc un risque corrélé entre des réseaux par ailleurs indépendants.
Prochaines étapes pour Mantle et les réseaux OP Stack
L'étape immédiate est l'adoption par les opérateurs. Un correctif ne réduit le risque qu'une fois déployé par les opérateurs de nœuds, les fournisseurs RPC, les validateurs et les équipes d'infrastructure, et les opérateurs sont invités à planifier les mises à niveau et à tester leurs nœuds. Blockaid a conseillé aux protocoles et aux ponts de vérifier que leurs fournisseurs sont corrigés.
À plus long terme, cet épisode souligne trois tendances : une divulgation et des rétroportages plus rapides pour les lignes de production qui ne peuvent pas se mettre à jour immédiatement ; davantage de mesures d'urgence pour les bugs de clients, y compris la vérification des preuves pour les messages inter-chaînes lorsque celles-ci ne peuvent pas être considérées comme fiables ; et une analyse continue des dépendances partagées entre les chaînes OP Stack.
Pour Mantle, l'épreuve sera la continuité. Sa proposition fondatrice repose sur l'évolutivité, les frais réduits et le règlement de confiance pour la finance décentralisée, les jeux et les applications grand public. Rester en ligne malgré un bug amont soutient cette proposition, mais le réseau doit encore démontrer que sa ligne de production reste synchronisée avec les correctifs de sécurité amont. La sécurité blockchain, en fin de compte, dépend aussi du logiciel qui calcule l'état — et de la vitesse à laquelle il est corrigé.