Base diz que o mesmo bug do sequenciador causou as interrupções de 25 e 26 de junho.

A Base explicou por que a sua mainnet parou de produzir blocos duas vezes em dois dias

Resumo

• A mais recente autópsia da Base mostra que um erro no sequenciador causou duas paragens da mainnet em dois dias consecutivos.
• Os fundos permaneceram seguros, mas as filas de transações transbordaram enquanto a Base parou temporariamente de produzir novos blocos L2.
• A equipa planeia testes de fuzzing mais robustos, testes de carga, monitorização e ferramentas de recuperação após a interrupção.

A rede Ethereum layer-2 apoiada pela Coinbase afirmou que ambas as interrupções resultaram do mesmo erro na sua lógica de construção de blocos do sequenciador.

A primeira interrupção começou a 25 de junho e durou cerca de 116 minutos. A segunda começou a 26 de junho e durou cerca de 20 minutos. A Base afirmou que os fundos permaneceram seguros durante ambos os incidentes.

Erro no sequenciador interrompeu a produção de blocos

Na sua autópsia oficial, a Base afirmou que uma transação inválida falhou durante a execução, como esperado. O problema surgiu após essa falha, quando um estado de diário desatualizado permaneceu dentro do construtor de blocos.

A 25 e 26 de junho, a mainnet da Base sofreu duas interrupções na produção de blocos, ambas causadas pelo mesmo erro subjacente na lógica do construtor de blocos.

Identificámos e corrigimos a causa raiz, e comunicámos a autópsia às cadeias OP como feedback.

Todos os fundos estavam seguros… pic.twitter.com/eArnK12AgZ

— Base Build (@buildonbase) 27 de junho de 2026

Esse estado desatualizado incluía contas e slots de armazenamento tocados pela transação falhada. Quando uma transação válida chegou a seguir, o sistema usou o estado de diário errado e cobrou gás incorretamente.

Isso criou um bloco com uma transição de estado inválida. Outros nós não conseguiram aceitar o bloco, pelo que a cadeia parou de produzir novos blocos L2.

“A integridade da cadeia não foi comprometida e todos os fundos na Base estavam seguros,” afirmou a Base.

A equipa acrescentou que a produção de blocos foi retomada de forma segura após a mitigação.

Transações em fila durante a paragem

Durante as interrupções, os utilizadores não conseguiram que novas transações fossem incluídas na cadeia. A Base afirmou que as transações ficaram em fila no mempool enquanto a cadeia aguardava a recuperação da produção de blocos.

A pool de transações cresceu posteriormente além da sua capacidade de armazenamento. Como resultado, novos pedidos eth_sendRawTransaction devolviam erros durante o período de interrupção.

A paragem também afetou o progresso do sequenciador e do validador. A Base afirmou que estes nós não conseguiam avançar para além do bloco inválido até o sequenciamento ser retomado.

Conforme reportado anteriormente, a Base sinalizou pela primeira vez uma produção de blocos insalubre a 25 de junho, antes de os engenheiros isolarem um problema de consenso ligado a um bloco inválido.

Correção resolveu problema de estado desatualizado

A Base afirmou que corrigiu o erro principal aplicando uma correção no sequenciador. A correção garante que as atualizações de estado do diário ocorrem corretamente durante a execução após uma transação falhada.

A equipa também encontrou um segundo problema durante a recuperação. A Base afirmou que a mitigação demorou mais porque uma condição de corrida na funcionalidade de reinicialização do motor impediu os sequenciadores de recuperar o atraso após o reinício.

Esse segundo problema ajudou a explicar por que o incidente se repetiu no dia seguinte. A Base afirmou que o problema afetou os sequenciadores, não os nós validadores, mas ainda assim atrasou a recuperação.

A página de estado da Base mostrou que o sequenciamento foi retomado a 25 de junho. Também instruiu os operadores de nós do ecossistema a reiniciar os nós da Base se ainda estivessem bloqueados.

Mudanças nos testes e na recuperação planeadas

A Base afirmou que irá reforçar os testes de fuzzing e os testes de carga do protocolo. Estes métodos ajudam as equipas a encontrar padrões estranhos de transações que possam expor erros ocultos.

A equipa também planeia uma melhor monitorização e verificações operacionais. Afirmou que estas mudanças devem ajudar os engenheiros a detetar problemas semelhantes mais cedo e a responder mais rapidamente.

A Base também quer adicionar recuperação graciosa ao base-consensus. Essa mudança facilitaria a continuação da sincronização dos nós validadores após falhas semelhantes.

A interrupção ocorreu durante uma semana movimentada para a rede. A Base também avançou com a sua atualização Beryl, que adiciona o padrão de token B20 e reduz o período padrão de levantamento da Base para a Ethereum de sete dias para cinco dias.

O incidente dá aos programadores e utilizadores uma visão mais clara do ponto fraco. A Base identificou agora o erro, lançou uma correção e listou os testes que planeia melhorar.