Análise do evento de atualização Fusaka do Ethereum: Relatório pós-fato do Prysm revela causa raiz da falha

A equipa de desenvolvimento Prysm publicou recentemente um relatório de análise pós-evento, explicando detalhadamente o incidente na rede principal após a atualização Fusaka em 4 de dezembro de 2025. O problema ameaçou a estabilidade da rede Ethereum, mas foi finalmente resolvido graças ao mecanismo de diversidade de clientes.

O relatório indica que o problema ocorreu no epoch 411.392 após a ativação da atualização Fusaka (21:49 UTC de 4 de dezembro). O cliente de consenso Prysm, ao processar certos dados de prova, desencadeou uma repetição de cálculos de estados históricos em grande escala, levando ao esgotamento rápido dos recursos de CPU e memória, resultando numa degradação de desempenho do tipo negação de serviço (DoS). Este não é um defeito de projeto do protocolo, mas sim um problema de implementação do cliente sob condições específicas de limite.

Os nós validados Prysm afetados representam aproximadamente entre 15% e 22,71% de toda a rede. Durante o evento, a participação geral dos validadores caiu abruptamente de mais de 95% para cerca de 75%, a rede perdeu continuamente 41 epochs, causando uma perda de aproximadamente 382 ETH em recompensas de prova, e chegou a quase perder a finalidade. Terence Tsao, desenvolvedor principal do Prysm, destacou que o cálculo de reprodução de estados históricos é extremamente intensivo, e a execução paralela multithread pode desacelerar significativamente o desempenho do nó.

É importante notar que a atualização Fusaka foi bem-sucedida. Ela introduziu a tecnologia PeerDAS (amostragem de disponibilidade de dados peer-to-peer), com o objetivo de aumentar a capacidade de blob do Layer 2 para oito vezes a original, sem interrupções ou bifurcações de consenso durante o processo de atualização.

A razão pela qual a rede Ethereum evitou consequências mais graves foi a diversidade de clientes. Além do Prysm, outros dez clientes de consenso, como Lighthouse, Teku e Nimbus, continuaram a produzir blocos normalmente durante todo o incidente, mantendo entre 75% e 85% dos validadores online, garantindo que a finalização da rede não fosse comprometida. Se um problema semelhante ocorresse em clientes com maior participação, as consequências poderiam ser mais severas, incluindo a suspensão do Layer 2 e obstáculos na retirada dos validadores.

Após o incidente, a Fundação Ethereum rapidamente publicou diretrizes de emergência, a equipe Prysm implementou uma correção temporária em tempo de execução, e soluções permanentes foram lançadas nas versões v7.0.1 e v7.1.0. Até 5 de dezembro, a participação na rede voltou a aproximadamente 99%, e a rede principal Ethereum recuperou-se completamente em 24 horas.