Analyse des deux courtes interruptions du réseau principal de Base : un bug dans la gestion de l’état du séquenceur a entraîné l’interruption de la production des blocs

Foresight News rapporte que Base a publié un rapport d’analyse a posteriori indiquant que deux interruptions de production de blocs ont eu lieu sur le mainnet les 25 et 26 juin, durant environ 116 minutes et 20 minutes respectivement. L’équipe officielle souligne que l’incident n’a pas compromis la sécurité des actifs sur la blockchain, et que les fonds des utilisateurs sont restés disponibles à tout moment. La cause principale de cette défaillance réside dans une faille de la logique de construction des blocs du sequencer : après l’échec d’une transaction, le système n’a pas correctement nettoyé l’état du journal historique, entraînant une anomalie de calcul du gas lors de l’exécution de transactions légitimes ultérieures, ce qui a généré des blocs de transfert d’état invalides et conduit à l’arrêt de toute la production de blocs sur le réseau L2. Durant l’interruption, plusieurs problèmes sont survenus, notamment l’arrêt total de la production de blocs, l’impossibilité d’enregistrer de nouvelles transactions sur la blockchain et une congestion du mempool, les requêtes eth_sendRawTransaction soumises par les utilisateurs retournant constamment des erreurs.

Les équipes ont ensuite corrigé le problème à l’aide d’un correctif (PR #3806), rétablissant la production de blocs. Cependant, une condition de compétition liée à la réinitialisation du moteur durant le redémarrage du cluster de sequencers a entravé la reprise de la synchronisation et a également constitué une cause indirecte d’une courte interruption supplémentaire le lendemain.

Pour l’avenir, Base indique qu’elle va se concentrer sur le renforcement des capacités de fuzz testing et de stress testing au niveau protocolaire afin d’identifier plus tôt des scénarios de transaction anormaux ; elle compte également mettre à jour les systèmes de monitoring et d’exploitation, ainsi qu’introduire un mécanisme de « graceful recovery » pour améliorer la capacité de récupération rapide du réseau face à ce type d’incidents à l’avenir.