O que quebrou a atualização Fusaka do Ethereum? Post-mortem do Prysm revela a causa

Os desenvolvedores do Prysm divulgaram uma análise post-mortem explicando o incidente da mainnet Fusaka de 4 de dezembro que ameaçou a estabilidade da Blockchain Ethereum.

O cliente de consenso sofreu esgotamento de recursos devido à recomputação dispendiosa de estados ao processar atestações específicas, fazendo com que os validadores enfrentassem graves problemas operacionais.

O bug surgiu imediatamente após a ativação do Fusaka na época 411392 em 4 de dezembro de 2025, às 21:49 UTC.

A rede perdeu 41 épocas enquanto a participação dos validadores caiu para 75%, resultando em aproximadamente 382 Ethereum (ETH) em recompensas de prova perdidas. Os desenvolvedores do Prysm implementaram flags de runtime de emergência antes de implementar correções permanentes nas versões v7.0.1 e v7.1.0.

Esgotamento de recursos empurrou a rede para a perda de finalidade

A falha técnica centrou-se em estados históricos obsoletos que criaram condições de negação de serviço nos nós afetados.

O desenvolvedor principal do Prysm, Terence Tsao, explicou que "o estado histórico consome muita memória computacional, um nó pode ser sobrecarregado por um grande número de reproduções de estado acontecendo em paralelo."

Os validadores executando Prysm, que representavam aproximadamente 15% a 22,71% dos validadores da rede, enfrentaram degradação severa de desempenho. A queda de participação dos níveis normais acima de 95% para 75% levou o Ethereum perigosamente perto de perder a finalidade.

Se o bug tivesse afetado um cliente de consenso diferente como o Lighthouse em vez do Prysm, a rede poderia ter perdido completamente a finalidade.

Tal evento potencialmente congelaria as operações de rollup da Camada 2 e bloquearia as retiradas dos validadores até que os desenvolvedores resolvessem o problema.

A própria atualização Fusaka introduziu a tecnologia PeerDAS (Peer Data Availability Sampling) projetada para aumentar a capacidade de blob em oito vezes para o escalonamento da Camada 2.

A atualização foi executada com sucesso sem tempo de inatividade antes do surgimento do bug do Prysm.

Dez clientes de consenso impediram o colapso da rede Ethereum

A arquitetura de diversidade de clientes do Ethereum impediu uma falha catastrófica. Enquanto os validadores do Prysm lutavam, outros dez clientes de consenso, incluindo Lighthouse, Nimbus e Teku, continuaram validando blocos sem interrupção.

A estrutura de cliente descentralizada significou que aproximadamente 75% a 85% dos validadores mantiveram operações normais durante toda a crise. Isso impediu a perda de finalidade e manteve a rede processando transações apesar do estado degradado do Prysm.

A Ethereum Foundation rapidamente emitiu orientações de emergência para os operadores do Prysm. Os validadores aplicaram a correção temporária enquanto os desenvolvedores do Prysm construíam soluções permanentes.

Em 5 de dezembro, a participação da rede recuperou-se para quase 99%, restaurando as operações normais dentro de 24 horas após o incidente.