Bug no sequenciador derruba a Base duas vezes em dois dias — e reacende o debate sobre a arquitetura de ponto único de falha

Um bug no construtor de blocos

A causa raiz, segundo o post-mortem da Base, foi uma falha na lógica de construção de blocos do sequenciador. Após uma transação mal-sucedida, o sistema não limpava corretamente o journal state — o registro interno de alterações em contas e slots de armazenamento — deixando um estado "sujo" ou "obsoleto". Quando transações legítimas posteriores eram executadas, esse estado residual causava cálculos anormais de gas, gerando um bloco com uma transição de estado inválida.

Esse bloco inválido provocou uma falha de consenso: o sequenciador produziu um bloco inválido após o bloco 47.806.542, impedindo a rede de construir blocos adicionais. Os operadores de nós não conseguiam continuar a sincronização normal até que o problema fosse resolvido.

Linha do tempo das duas paradas

A segunda interrupção em 26 de junho foi descrita como a mesma classe de falha de produção de blocos, recorrendo logo após o primeiro incidente, embora a rede tenha se recuperado mais rapidamente na segunda vez.

Durante ambos os períodos, a criação de novos blocos foi congelada ou interrompida, paralisando o processamento normal de transações na rede. No entanto, nenhum fundo de usuário foi relatado como estando em risco durante qualquer um dos incidentes.

A correção implantada

A equipe de engenharia da Base aplicou um patch no sequenciador para garantir que o journal state seja atualizado corretamente durante a execução após uma transação com falha. A correção pode ser acompanhada em um pull request público no GitHub (#3806).

Após o patch, as operações normais foram retomadas, mas a Base aconselhou os operadores de nós validadores a reiniciar ou ressincronizar seus nós para restaurar o estado de sincronização. A equipe observou que ambas as interrupções se originaram do mesmo bug, e que um segundo problema relacionado (PR #3805) fez com que o incidente se repetisse no dia seguinte.

Na sequência, a Base adiou o lançamento planejado da atualização da mainnet Beryl e da ativação do padrão de token B20 em um dia para estabilizar a rede.

Arquitetura de sequenciador único: uma preocupação mais ampla

As interrupções consecutivas reavivaram o debate sobre a resiliência do design de sequenciador único da Base, que é comum entre muitos rollups optimistic, mas introduz um ponto único de falha claro.

As principais preocupações levantadas pelo post-mortem e pela cobertura do setor incluem:

• Ponto único de falha: Um bug no sequenciador pode paralisar toda a produção de blocos da Base, congelando novas transações em toda a rede.
• Recuperação manual: A recuperação exigiu que operadores de nós validadores reiniciassem ou ressincronizassem seus nós manualmente, em vez de a rede se autocorrigir.
• Risco de confiabilidade: As falhas consecutivas levantaram novas questões sobre a confiabilidade do ecossistema L2 em rápida expansão, especialmente durante períodos de alta atividade ou atualizações programadas.
• Melhorias planejadas: A Base afirmou que fortaleceria seus testes com fuzz tests, testes de carga, monitoramento e melhores ferramentas de recuperação para reduzir as chances de recorrência.

O incidente mostra que mesmo as maiores redes L2 do Ethereum podem ser derrubadas por um caso extremo de gerenciamento de estado em um único sequenciador — e que sistemas automatizados de failover e recuperação ainda são um trabalho em andamento em todo o ecossistema de rollups.