• Reth a fusionné le correctif de la racine d’état via la pull request #28264 le 3 novembre à 21 h UTC.

• Reth a publié le correctif dans la version v2.10.0, classée comme hautement prioritaire pour les nœuds qui construisent des charges utiles comme pour ceux qui n’en construisent pas.

• Base a publié la version v1.5.3 de son nœud, éliminant le risque que les validateurs s’arrêtent en cas de racine d’état invalide.

Reth v2.10.0 intègre le correctif hautement prioritaire

Reth a publié un correctif hautement prioritaire pour un bogue qui pouvait, dans certains cas, laisser un nœud de blockchain avec une racine d’état erronée — le hash unique qui résume l’état complet d’une chaîne. Base a mis à la disposition des opérateurs sa propre version corrigée du nœud dès jeudi. La racine d’état permet à une chaîne de type Ethereum de prouver l’exactitude de sa comptabilité : si un client la calcule mal, il diverge de ses pairs, et un validateur qui l’exécute peut proposer ou attester des blocs que le reste du réseau rejette. Les clients d’exécution constituent la couche logicielle qui traite les transactions et suit les soldes ; une erreur de calcul à ce niveau se situe donc à la base de toute la pile. Le correctif a été intégré à la version v2.10.0, et les responsables de la maintenance ont classé la mise à niveau comme hautement prioritaire pour tous les types de nœuds, qu’ils produisent des blocs ou se contentent de les valider. Aucun opérateur n’a donc été invité à attendre le créneau d’une mise à jour de routine. Le changement a été apporté via la pull request #28264, fusionnée le 3 novembre à 21 h UTC. Les horodatages de cette fusion et de l’avis de statut de Base indiquent qu’environ 43 heures se sont écoulées entre le correctif et l’alerte publique. Base a découvert le bogue le 4 novembre et a corrigé le même jour chacun de ses producteurs de blocs, les machines qui assemblent de nouveaux blocs. Elle a ensuite recommandé aux opérateurs d’installer sa propre version du nœud, v1.5.3, qui élimine le risque que les validateurs de Base s’arrêtent à cause d’une racine d’état invalide, et a indiqué qu’aucune resynchronisation n’était nécessaire pour l’appliquer. Base fonctionne sur OP Stack et s’appuie sur op-reth, la version de Reth adaptée à OP Stack, où l’incident signalé s’est produit. Les deux volets de ces instructions sont importants : la mise à niveau corrige le problème, tandis que la dispense de resynchronisation réduit presque à zéro le coût de son installation pour les opérateurs très sollicités.

Base confirme sa racine d’état, la DeFi prend ses précautions

L’avis de Base, publié jeudi, comportait deux messages à la fois : rassurer les utilisateurs et donner des instructions aux opérateurs. Sur le premier point, la chaîne a déclaré avoir recalculé la racine d’état et confirmé qu’elle était correcte. « Nous avons vérifié que la racine d’état actuelle est correcte et que les utilisateurs n’ont pas été affectés », indiquait l’avis, une phrase visant clairement à couper court au FUD autour de l’incident. Base a étayé cette affirmation en évoquant son architecture : son système de preuve vérifie chaque racine d’état au moyen d’une implémentation distincte, de sorte qu’une véritable incohérence aurait été signalée. Cette vérification indépendante est le fait déterminant qui justifie le feu vert. Sur le second point, Base a renouvelé son appel à passer à la version v1.5.3 et confirmé qu’aucune resynchronisation n’était nécessaire. Les réactions ont dépassé le cadre de la chaîne elle-même. Frax Finance a déclaré que LayerZero « avait temporairement suspendu certains itinéraires inter-chaînes par précaution et devrait les rétablir bientôt », reliant cette mesure à l’incident signalé dans op-reth et précisant qu’aucun de ses actifs ni contrats intelligents n’avait été affecté. LayerZero permet de transférer des actifs entre chaînes ; la suspension a donc brièvement empêché les jetons d’emprunter ces itinéraires. Gauntlet, le gestionnaire des risques, a limité les nouveaux dépôts dans ses coffres V1 tout en laissant les retraits ouverts, suspendu les allocations et réduit son exposition aux actifs transférés via LayerZero, en précisant n’avoir connaissance d’aucune exploitation signalée ; sa publication sur ces mesures a depuis été supprimée. Limiter les dépôts tout en laissant les retraits ouverts est la posture habituelle d’une équipe de gestion des risques qui ne peut pas encore modéliser pleinement un système. Un résumé des publications de Blockaid, relayé sur un fil d’actualité d’une plateforme d’échange de cryptomonnaies, décrivait le problème comme un bogue de calcul au sein des nœuds, et non comme une attaque. Aucune perte de fonds n’était connue, mais les clients utilisant encore l’ancienne version du code risquaient de se bloquer ou de fournir des preuves d’état erronées. Ces suspensions préventives sont intervenues plus de six mois après l’exploitation du pont rsETH de Kelp DAO, qui avait entraîné une perte de 292 millions de dollars. LayerZero avait attribué cette attaque au groupe Lazarus de Corée du Nord ; rien ne relie le bogue de Reth à une quelconque exploitation.

Cet épisode ressemble à un test de résistance de la dépendance à un client unique. Base, l’un des réseaux de couche 2 les plus fréquentés, s’appuie sur un seul client Rust pour l’exécution. Une faille à ce niveau a fait peser des risques sur les opérateurs de ponts et les gestionnaires des risques en quelques heures, même si aucune exploitation n’a été signalée. L’architecture a tenu bon : le recalcul indépendant du système de preuve explique pourquoi aucun impact sur les utilisateurs n’a été constaté. Et comme le correctif a été diffusé sous la forme d’une mise à jour du client, et non d’un fork de la chaîne, la version v1.5.3 n’a nécessité aucune resynchronisation. Les notes de version complètent le tableau : elles précisent le changement et le classent comme hautement prioritaire pour tous les types d’opérateurs. Le chiffre qui résume l’histoire est 43 heures : le délai entre la fusion du correctif en amont et l’avis public invitant les opérateurs à effectuer la mise à jour.