Base affirme que le même bug de séquenceur a causé les pannes des 25 et 26 juin.

Base a expliqué pourquoi son mainnet a arrêté de produire des blocs deux fois en deux jours

Résumé

• Le dernier post-mortem de Base montre qu’un seul bug du séquenceur a causé deux arrêts du mainnet en deux jours consécutifs.
• Les fonds sont restés en sécurité, mais les files d’attente de transactions ont débordé lorsque Base a temporairement cessé de produire de nouveaux blocs L2.
• L’équipe prévoit des tests de fuzz, des tests de charge, une surveillance et des outils de récupération renforcés après la panne.

Le réseau layer-2 Ethereum soutenu par Coinbase a déclaré que les deux pannes provenaient du même bug dans sa logique de construction de blocs du séquenceur.

La première panne a commencé le 25 juin et a duré environ 116 minutes. La seconde a commencé le 26 juin et a duré environ 20 minutes. Base a déclaré que les fonds sont restés en sécurité lors des deux incidents.

Un bug du séquenceur a arrêté la production de blocs

Dans son post-mortem officiel, Base a indiqué qu’une transaction invalide avait échoué lors de l’exécution, comme prévu. Le problème est survenu après cet échec, lorsque l’état de journal obsolète est resté à l’intérieur du constructeur de blocs.

Le 25 et 26 juin, le mainnet de Base a connu deux pannes de production de blocs, toutes deux causées par le même bug sous-jacent dans la logique du constructeur de blocs.

Nous avons identifié et corrigé la cause racine, et avons communiqué le post-mortem aux chaînes OP en retour.

Tous les fonds étaient en sécurité… pic.twitter.com/eArnK12AgZ

— Base Build (@buildonbase) 27 juin 2026

Cet état obsolète comprenait les comptes et les emplacements de stockage concernés par la transaction ayant échoué. Lorsqu’une transaction valide est arrivée ensuite, le système a utilisé le mauvais état de journal et a facturé du gaz de manière incorrecte.

Cela a créé un bloc avec une transition d’état invalide. Les autres nœuds n’ont pas pu accepter le bloc, donc la chaîne a cessé de produire de nouveaux blocs L2.

« L’intégrité de la chaîne n’a pas été compromise et tous les fonds sur Base étaient en sécurité », a déclaré Base.

L’équipe a ajouté que la production de blocs a repris en toute sécurité après l’atténuation.

Transactions mises en file d’attente pendant l’arrêt

Lors des pannes, les utilisateurs ne pouvaient pas faire inclure de nouvelles transactions sur la chaîne. Base a indiqué que les transactions étaient mises en file d’attente dans le mempool pendant que la chaîne attendait la reprise de la production de blocs.

Le pool de transactions a ensuite dépassé sa capacité de stockage. En conséquence, de nouvelles demandes eth_sendRawTransaction ont renvoyé des erreurs pendant la fenêtre de panne.

L’arrêt a également affecté la progression du séquenceur et du validateur. Base a déclaré que ces nœuds ne pouvaient pas avancer au-delà du bloc invalide jusqu’à ce que le séquencement reprenne.

Comme rapporté précédemment, Base a d’abord signalé une production de blocs malsaine le 25 juin avant que les ingénieurs n’isolent un problème de consensus lié à un bloc invalide.

Un correctif a résolu le problème d’état obsolète

Base a déclaré avoir corrigé le bug principal en appliquant un correctif du séquenceur. Ce correctif garantit que l’état du journal se met à jour correctement pendant l’exécution après une transaction ayant échoué.

L’équipe a également trouvé un deuxième problème lors de la récupération. Base a indiqué que l’atténuation avait pris plus de temps en raison d’une condition de concurrence dans la fonction de réinitialisation du moteur qui empêchait les séquenceurs de rattraper leur retard après un redémarrage.

Ce deuxième problème a aidé à expliquer pourquoi l’incident s’est reproduit le lendemain. Base a déclaré que le problème affectait les séquenceurs, et non les nœuds validateurs, mais qu’il ralentissait toujours la récupération.

La page de statut de Base a montré que le séquencement avait repris le 25 juin. Elle a également demandé aux opérateurs de nœuds de l’écosystème de redémarrer les nœuds Base s’ils étaient encore bloqués.

Des changements dans les tests et la récupération prévus

Base a déclaré qu’elle renforcera les tests de fuzz et les tests de charge du protocole. Ces méthodes aident les équipes à trouver des schémas de transactions étranges qui peuvent exposer des bugs cachés.

L’équipe prévoit également une meilleure surveillance et des contrôles opérationnels. Elle a indiqué que ces changements devraient aider les ingénieurs à détecter plus tôt des problèmes similaires et à réagir plus rapidement.

Base souhaite également ajouter une récupération en douceur à base-consensus. Ce changement faciliterait la poursuite de la synchronisation des nœuds validateurs après des échecs similaires.

La panne est survenue au cours d’une semaine chargée pour le réseau. Base a également avancé avec sa mise à niveau Beryl, qui ajoute le standard de jetons B20 et réduit la période de retrait standard de Base vers Ethereum de sept jours à cinq jours.

L’incident donne aux développeurs et aux utilisateurs une vision plus claire du point faible. Base a maintenant nommé le bug, publié un correctif et listé les tests qu’elle prévoit d’améliorer.