Skip to content
Blockchain Posts

infrastructure

Base : post-mortem du séquenceur — deux pannes en 24 h, même bug de journal state

Le post-mortem Base impute les arrêts du 25 juin (~116 min) et du 26 juin (~20 min) à un même bug du block builder, aggravé par une race condition au redémarrage. Fonds en sécurité.

par 5 min de lecture
infrastructurebaseethereuml2post-mortem

Base, le rollup L2 sur OP Stack incubé par Coinbase, a publié le post-mortem des deux arrêts mainnet consécutifs des 25 et 26 juin 2026. Les deux incidents proviennent du même bug dans la logique du block builder du séquenceur : un stale journal state hérité d'une transaction qui avait échoué à l'exécution. La récidive du 26 juin résulte par ailleurs d'une race condition dans la routine de réinitialisation du moteur, qui a empêché les séquenceurs de rattraper la tête de chaîne après le redémarrage. Aucun fonds utilisateur n'a été touché ; le hardfork Beryl initialement prévu le 25 a été décalé à cause de l'incident.

Chronologie

  • 25 juin 2026, ~16:03 UTC. Le statut Base passe « unhealthy » sur la production de blocs mainnet. La halte court environ 116 minutes ; le séquençage est rétabli à 17:51 UTC (voir notre couverture du premier arrêt).
  • 26 juin 2026, ~15:34 UTC. Deuxième arrêt sur le même schéma. Reprise à 15:54 UTC, soit une interruption d'environ 20 minutes.
  • 27 juin 2026. Base publie le post-mortem détaillé attribuant les deux incidents au même bug et annonce le report de l'activation Beryl (B20).

Le bug — stale journal state dans le block builder

Selon le post-mortem, une transaction invalide a échoué à l'exécution, comme attendu. Le problème vient de ce qui n'a pas été nettoyé après cet échec : l'état journal du block builder a conservé les comptes et slots de stockage touchés par la transaction abandonnée. Lorsqu'une transaction valide suivante a été traitée, le moteur s'est appuyé sur ce journal state obsolète, a calculé le gaz incorrectement, et a produit un bloc dont la transition d'état était invalide. Les nœuds full ont rejeté ce bloc ; sans tête valide pour bâtir le bloc suivant, le séquenceur unique de Base s'est arrêté.

Le correctif livré par l'équipe Base met à jour la routine du block builder pour vider le journal après une exécution échouée, avant d'enchaîner sur la transaction suivante. Le patch a été appliqué entre les deux incidents.

La race condition — pourquoi la panne est revenue 24 h plus tard

La seconde halte du 26 juin n'est pas un nouveau bug : c'est une condition de course dans la fonctionnalité de réinitialisation du moteur (engine reset) qui s'active au redémarrage. Cette race condition a empêché les séquenceurs de rattraper la tête canonique après application du patch du 25, exposant à nouveau le chemin défectueux jusqu'à ce que l'équipe coupe le trafic et redémarre proprement. Base précise dans le post-mortem que le correctif livré sur le block builder restait sain, mais que la procédure de reprise elle-même devait être durcie.

Chiffres

- Réseau                  : Base mainnet (OP Stack, séquenceur unique)
- Arrêt 1 (25 juin)       : début 16:03 UTC, reprise 17:51 UTC (~116 min)
- Arrêt 2 (26 juin)       : début 15:34 UTC, reprise 15:54 UTC (~20 min)
- Cause racine            : stale journal state dans le block builder
- Cause de la récidive    : race condition dans l'engine reset au redémarrage
- Fonds utilisateurs      : aucun à risque (Base, Jesse Pollak)
- Dernier bloc valide arrêt 1 : 47 806 542
- Activation Beryl (B20)  : repoussée
- Diffusion du correctif  : remontée aux autres chaînes OP Stack
- Mesures annoncées       : fuzz testing protocole, load testing, monitoring

Que surveiller

  1. La publication exacte du patch et son adoption par les opérateurs OP Stack tiers (Optimism, Mode, Zora, Worldchain, Mantle…). Le bug touche la couche op-node / block builder partagée ; les chaînes qui restent sur la version pré-correctif gardent la même fenêtre.
  2. Le nouveau calendrier de Beryl (B20). Base a confirmé que l'activation est repoussée mais n'a pas publié de date ferme au moment de l'incident. La feature concernée — registre de tokens Beryl — est attendue pour un futur saut de version.
  3. L'avenir du séquenceur unique. Deux haltes en 24 h sur le même point de défaillance relancent la pression sur la feuille de route de décentralisation du séquenceur côté Base et plus largement OP Stack. La ligne officielle reste qu'un séquenceur unique est temporaire, mais aucun calendrier d'introduction de séquenceurs externes n'a été reposé après ces incidents.
  4. Le harnais de tests promis. Base a annoncé renforcer le fuzz testing du protocole et l'ajout de load testing sur le chemin du block builder. C'est là que se jugera si l'incident est exceptionnel ou symptomatique d'une dette d'outillage.

Contexte — récidive après Optimism, et un mois de pannes L2 chargé

Les arrêts du séquenceur ne sont pas nouveaux sur OP Stack : Optimism a connu plusieurs interruptions multi-heures sur séquenceur unique en 2023-2024, et Linea a halté son séquenceur en 2024 après une exploitation détectée. Sur le mois de juin 2026 seul, l'écosystème L2 a aussi traversé des incidents de production de blocs (voir notre récap Sui v1.72). La leçon que tire le post-mortem Base — un état non nettoyé après abort silencieux, exposé seulement par une combinaison de transactions précise — est exactement le type de bug que les frameworks de fuzzing ciblés sur la machine d'exécution sont conçus pour trouver. Que Base ait dû l'apprendre en production et non en staging sera le point le plus discuté du suivi.

Sources

Articles liés