Pannes en série du réseau Base : un bogue du séquenceur et les risques d’un point de défaillance unique

Un bogue dans le constructeur de blocs

La cause racine, selon le rapport d'incident de Base, est une faille dans la logique de construction de blocs du séquenceur. Après l'échec de l'exécution d'une transaction, le système n'a pas correctement nettoyé l'état du journal — l'enregistrement interne des modifications des comptes et des slots de stockage — laissant un état « obsolète » ou « sale ». Lorsque des transactions légitimes ultérieures ont été exécutées, cet état obsolète a provoqué des calculs de gas anormaux, générant à son tour un bloc avec une transition d'état invalide.

Ce bloc invalide a déclenché une défaillance du consensus : le séquenceur a produit un bloc invalide après le bloc 47 806 542, empêchant le réseau de construire d'autres blocs. Les opérateurs de nœuds n'ont pas pu poursuivre la synchronisation normale tant que le problème n'a pas été résolu.

Chronologie des deux arrêts

Le second incident du 26 juin a été décrit comme la même classe sous-jacente de défaillance de production de blocs qui s'est reproduite peu après le premier incident, bien que le réseau ait récupéré plus rapidement la deuxième fois.

Pendant ces deux périodes, la création de nouveaux blocs a été gelée ou interrompue, perturbant le traitement normal des transactions en chaîne. Cependant, aucun fonds d'utilisateur n'a été signalé comme étant en danger lors de l'un ou l'autre incident.

Le correctif déployé

L'équipe d'ingénierie de Base a appliqué un correctif au séquenceur pour garantir que l'état du journal soit correctement mis à jour lors de l'exécution après une transaction échouée. Le correctif peut être suivi dans une demande de tirage GitHub publique (#3806).

Après le correctif, les opérations normales ont repris, mais Base a conseillé aux opérateurs de nœuds validateurs de redémarrer ou de resynchroniser leurs nœuds pour restaurer l'état de synchronisation. L'équipe a noté que les deux pannes provenaient du même bogue et qu'un second problème connexe (PR #3805) a provoqué la récidive de l'incident le lendemain.

Dans la foulée, Base a reporté d'un jour le déploiement de sa mise à niveau prévue du mainnet Beryl et de l'activation du standard de token B20 afin de stabiliser le réseau.

Architecture à séquenceur unique : une préoccupation plus large

Ces pannes consécutives ont relancé le débat sur la résilience de la conception à séquenceur unique de Base, courante parmi de nombreux rollups optimistes, mais qui introduit un point de défaillance unique évident.

Les principales préoccupations soulevées par le rapport d'incident et la couverture médiatique du secteur sont les suivantes :

• Point de défaillance unique : Un bogue au niveau du séquenceur dans la logique de construction de blocs peut arrêter toute la production de blocs de Base, gelant la création de nouveaux blocs sur l'ensemble du réseau.
• Récupération manuelle : La récupération a nécessité que les opérateurs de nœuds validateurs redémarrent ou resynchronisent leurs nœuds manuellement, plutôt que de compter sur une auto-réparation du réseau.
• Risque de fiabilité : Ces défaillances consécutives ont soulevé de nouvelles questions sur la fiabilité de l'écosystème L2 en pleine expansion, en particulier pendant les périodes de forte activité ou de mises à niveau planifiées.
• Améliorations prévues : Base a annoncé qu'elle renforcerait ses tests avec des tests fuzz, des tests de charge, une surveillance et de meilleurs outils de récupération pour réduire les risques de récidive.

Cet incident montre que même les plus grands réseaux L2 d'Ethereum peuvent être mis hors ligne par un cas limite de gestion d'état dans un seul séquenceur — et que les systèmes de basculement et de récupération automatisés sont encore un chantier en cours dans l'écosystème des rollups.