Os desenvolvedores Prysm divulgaram uma análise post-mortem explicando o incidente na rede Fusaka em 4 de dezembro que ameaçou a estabilidade da rede Ethereum.
Resumo
Um bug no Prysm após Fusaka causou a queda da participação dos validadores para 75%.
A rede perdeu 41 épocas e cerca de 382 ETH em recompensas de prova.
O Ethereum evitou a perda de finalidade graças à diversidade de clientes e às correções rápidas.
O cliente de consenso sofreu esgotamento de recursos devido a recomputações de estado caras ao processar atestaçõess específicas, causando graves problemas operacionais aos validadores.
O bug apareceu imediatamente após a ativação de Fusaka na época 411392 em 4 de dezembro de 2025, às 21:49 UTC.
A rede perdeu 41 épocas, pois a participação dos validadores caiu para 75%, resultando em aproximadamente 382 (ETH) em recompensas de prova perdidas. Os desenvolvedores Prysm implementaram bandeiras de execução de emergência antes de lançar correções permanentes nas versões v7.0.1 e v7.1.0.
Esgotamento de recursos levou a rede ao colapso da finalidade
A falha técnica centrava-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 é pesado em memória de computação, um nó pode ser sobrecarregado por um grande número de replays de estado acontecendo em paralelo.”
Validadores que executam Prysm, representando aproximadamente 15% a 22,71% dos validadores da rede, enfrentaram uma degradação de desempenho severa. A queda na participação, de níveis normais acima de 95% para 75%, colocou o Ethereum perigosamente perto de perder a finalidade.
Se o bug tivesse afetado um cliente de consenso diferente, como o Lighthouse, ao invés do Prysm, a rede poderia ter perdido a finalidade completamente.
Tal evento poderia potencialmente congelar as operações de Layer 2 rollup e bloquear as retiradas de validadores até que os desenvolvedores resolvessem o problema.
A atualização Fusaka introduziu a tecnologia PeerDAS (Peer Data Availability Sampling), projetada para aumentar a capacidade de blobs oito vezes para escalabilidade de Layer 2.
A atualização foi executada com sucesso, sem tempo de inatividade, antes do bug Prysm aparecer.
Dez clientes de consenso impediram o colapso da rede Ethereum
A arquitetura de diversidade de clientes do Ethereum evitou uma falha catastrófica. Enquanto os validadores Prysm enfrentavam dificuldades, outros dez clientes de consenso, incluindo Lighthouse, Nimbus e Teku, continuaram validando blocos sem interrupções.
A estrutura descentralizada de clientes significava que aproximadamente 75% a 85% dos validadores mantiveram operações normais durante a crise. Isso evitou a perda de finalidade e manteve a rede processando transações apesar do estado degradado do Prysm.
A Fundação Ethereum rapidamente emitiu orientações de emergência para os operadores Prysm. Os validadores aplicaram a correção temporária enquanto os desenvolvedores Prysm criavam soluções permanentes.
Até 5 de dezembro, a participação na rede recuperou-se para quase 99%, restabelecendo operações normais dentro de 24 horas após o incidente.
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
O que quebrou a atualização Fusaka do Ethereum? A análise pós-morte do Prysm revela a causa
Resumo
O cliente de consenso sofreu esgotamento de recursos devido a recomputações de estado caras ao processar atestaçõess específicas, causando graves problemas operacionais aos validadores.
O bug apareceu imediatamente após a ativação de Fusaka na época 411392 em 4 de dezembro de 2025, às 21:49 UTC.
A rede perdeu 41 épocas, pois a participação dos validadores caiu para 75%, resultando em aproximadamente 382 (ETH) em recompensas de prova perdidas. Os desenvolvedores Prysm implementaram bandeiras de execução de emergência antes de lançar correções permanentes nas versões v7.0.1 e v7.1.0.
Esgotamento de recursos levou a rede ao colapso da finalidade
A falha técnica centrava-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 é pesado em memória de computação, um nó pode ser sobrecarregado por um grande número de replays de estado acontecendo em paralelo.”
Validadores que executam Prysm, representando aproximadamente 15% a 22,71% dos validadores da rede, enfrentaram uma degradação de desempenho severa. A queda na participação, de níveis normais acima de 95% para 75%, colocou o Ethereum perigosamente perto de perder a finalidade.
Se o bug tivesse afetado um cliente de consenso diferente, como o Lighthouse, ao invés do Prysm, a rede poderia ter perdido a finalidade completamente.
Tal evento poderia potencialmente congelar as operações de Layer 2 rollup e bloquear as retiradas de validadores até que os desenvolvedores resolvessem o problema.
A atualização Fusaka introduziu a tecnologia PeerDAS (Peer Data Availability Sampling), projetada para aumentar a capacidade de blobs oito vezes para escalabilidade de Layer 2.
A atualização foi executada com sucesso, sem tempo de inatividade, antes do bug Prysm aparecer.
Dez clientes de consenso impediram o colapso da rede Ethereum
A arquitetura de diversidade de clientes do Ethereum evitou uma falha catastrófica. Enquanto os validadores Prysm enfrentavam dificuldades, outros dez clientes de consenso, incluindo Lighthouse, Nimbus e Teku, continuaram validando blocos sem interrupções.
A estrutura descentralizada de clientes significava que aproximadamente 75% a 85% dos validadores mantiveram operações normais durante a crise. Isso evitou a perda de finalidade e manteve a rede processando transações apesar do estado degradado do Prysm.
A Fundação Ethereum rapidamente emitiu orientações de emergência para os operadores Prysm. Os validadores aplicaram a correção temporária enquanto os desenvolvedores Prysm criavam soluções permanentes.
Até 5 de dezembro, a participação na rede recuperou-se para quase 99%, restabelecendo operações normais dentro de 24 horas após o incidente.