Rédigé par: KarenZ, Foresight News
À l'aube du 26 juin, heure de Pékin, Base a donné au marché une leçon silencieuse sur les infrastructures.
La chronologie de cette panne est claire :
- À 00h03, Base signale un état anormal de production de blocs sur le mainnet, l'équipe enquête.
- À 00h52, Base identifie qu'un problème provient d'un bloc spécifique, qui perturbe la construction des blocs suivants.
- À 01h21, Base a localisé un problème de consensus ayant conduit au classement d'un bloc invalide. Cela a empêché la génération de nouveaux blocs après le bloc 47806542. Le séquenceur interne et les nœuds ont été restaurés initialement.
- À 01h51, le classement des nouveaux blocs a repris, la synchronisation des nœuds internes est normale.
- À 01h58, Base confirme que la construction saine des blocs a repris, les infrastructures de l'écosystème peuvent reprendre leur synchronisation.
- À 03h22, Base indique en outre que le séquenceur et les systèmes associés restent stables, les blocs sont générés normalement, et précise que l'équipe a identifié la cause racine de cet arrêt, valide actuellement le correctif et publiera un rapport d'analyse complet par la suite.
La page d'état de Base indique que cet incident a affecté les dépôts, retraits, production de blocs et logiciels clients du mainnet Base.
Un séquenceur actif unique, rendant l'arrêt plus visible
Base est un Rollup construit sur Ethereum. Il exécute un grand nombre de transactions sur la L2, puis soumet les données nécessaires et les informations d'état sur Ethereum.
Ce que les utilisateurs perçoivent directement chaque jour, ce n'est pas un schéma d'architecture, mais si les transactions peuvent entrer dans un bloc, si les nœuds peuvent se synchroniser, si les portefeuilles, les échanges et les services cross-chain fonctionnent normalement.
Avant le lancement de Flashblocks, Base utilisait un système de séquenceurs à haute disponibilité : parmi cinq instances de séquenceurs, une instance assumait le rôle de leader, responsable de la construction des blocs et de leur propagation en P2P, les quatre autres agissant comme followers pour synchroniser l'état de la chaîne ; si le leader actuel cessait de produire des blocs, le système procédait à un basculement de leadership.
Cette conception montre que Base n'était pas dépourvue de redondance. Le problème est que la redondance résout davantage le basculement en cas de panne et la disponibilité, mais n'est pas équivalente à plusieurs séquenceurs indépendants participant simultanément à la production de blocs. La production quotidienne de blocs reste assurée par le leader actuel, et dès qu'un problème survient au niveau du consensus, du classement ou de la chaîne de synchronisation des nœuds, la première chose que les utilisateurs constatent est l'arrêt de l'avancée des nouveaux blocs.
Après le lancement de Flashblocks, la construction des blocs sur Base a gagné une couche supplémentaire de mécanisme de pré-confirmation à l'échelle des 200 millisecondes. La documentation de Base précise que Flashblocks est toujours activé sur Base, tous les blocs sont construits par le constructeur Flashblocks ; les applications peuvent choisir d'utiliser ou non les données de pré-confirmation, ou continuer d'attendre la confirmation standard des blocs toutes les 2 secondes via un RPC standard. En d'autres termes, Flashblocks fait déjà partie de l'infrastructure de la construction actuelle des blocs sur Base, mais est une option pour les applications souhaitant intégrer l'expérience de pré-confirmation.
L'explication donnée sur la page d'état de sécurité de Base est plus précise : un problème de consensus a conduit au classement d'un bloc invalide, empêchant ainsi la génération de nouveaux blocs après le bloc 47806542. La raison exacte nécessite d'attendre le rapport d'analyse complet de l'officiel.
La précédente panne de Base était due à l'impossibilité de configurer un nouveau séquenceur
Ce n'est pas la première fois que Base interrompt la production de blocs en raison de problèmes liés au séquenceur. Le 5 août 2025, le mainnet de Base avait connu une interruption de réseau de 33 minutes. Dans son analyse post-incident, l'équipe avait indiqué que le séquenceur actif commençait à présenter des retards dus à l'activité sur la chaîne, le Conductor, responsable de la gestion du cluster à haute disponibilité (HA), avait automatiquement transféré le leadership à un nouveau séquenceur ; mais ce nouveau séquenceur était alors encore en cours de configuration et incapable de produire des blocs, et comme le Conductor n'était pas encore pleinement activé sur ce séquenceur, le système n'a pas pu initier un autre basculement. L'équipe a ensuite suspendu manuellement le HA et transféré le leadership vers un séquenceur sain, rétablissant ainsi pleinement le service.
En considérant les deux incidents ensemble, il faut être prudent : le problème d'août 2025 pointait vers le processus de basculement de haute disponibilité du séquenceur, tandis que l'incident d'aujourd'hui est un problème de consensus ayant conduit au classement d'un bloc invalide et empêchant la génération de nouveaux blocs après le bloc 47806542.
Ils pointent tous deux vers une réalité : les L2 peuvent dépendre d'Ethereum pour la disponibilité des données, le règlement, la sécurité et la finalité, mais leur disponibilité quotidienne dépend fortement du séquenceur et des systèmes opérationnels associés. Tant que de nouveaux blocs ne peuvent pas être générés, les utilisateurs voient leurs transactions bloquées en chemin.
Cette panne survient à proximité de la fenêtre de lancement de B20
Le moment de l'incident est délicat. Base se trouvait alors à proximité de la fenêtre de mise à niveau Beryl.
L'activation initiale du mainnet Beryl était prévue pour le 26 juin à 02h00, heure de Pékin, elle a désormais été reportée au 27 juin à 02h00.
Les éléments clés de Beryl incluent trois points : l'introduction du standard natif de token B20, la réduction de la période de finalisation des retraits à preuve unique de 7 à 5 jours, et une réduction pouvant atteindre 50% de l'espace disque utilisé ainsi qu'une amélioration d'environ 33% du débit grâce à Reth V2.
La différence de B20 réside dans son implémentation sous-jacente. Alors que les tokens ERC-20 sont majoritairement déployés sous forme de contrats intelligents EVM, B20 est implémenté via un precompile Rust et créé par le singleton B20Factory. Il intègre également des fonctionnalités natives telles que les rôles et permissions, la limite d'offre, le mint/burn, la suspension, les stratégies de transfert, les mémo et le permit ERC-2612. Pour le dire plus simplement, Base a transformé de nombreuses fonctionnalités de base des tokens que les émetteurs construisaient, auditaient et maintenaient de manière répétée, en une boîte à outils au niveau de la chaîne.
B20 est ce qui suscite le plus d'associations d'idées sur le marché, certains membres de la communauté évoquant même un possible lancement de token par Base. Cependant, B20 traite de « comment les autres peuvent émettre des actifs de manière plus standardisée sur Base » ; le lancement d'un token par Base concerne la question de « si Base introduira à l'avenir son propre token de réseau ».
Le premier est déjà intégré dans la mise à niveau Beryl, le second reste un sujet qui intéresse le marché mais n'a pas encore été annoncé officiellement.
Cet arrêt rendra les discussions sur un éventuel token Base plus concrètes. Le marché se demandait auparavant : Base va-t-elle lancer un token, quand, et comment sera distribué l'airdrop. Après l'incident, il est plus pertinent de se demander : si un token de réseau est effectivement introduit à l'avenir, à quelles responsabilités devra-t-il correspondre ? La décentralisation du séquenceur, les contraintes de gouvernance, le budget de sécurité, ou la répartition des droits et responsabilités dans la réponse aux incidents ?
