O cliente Prysm da Ethereum sofreu um incidente na mainnet, com esgotamento de recursos causando grande ausência de blocos e atestados

De acordo com o ChainCatcher, a equipe do Prysm divulgou um relatório de revisão do incidente na mainnet, afirmando que, durante o período Fusaka da mainnet do Ethereum em 4 de dezembro, quase todos os nós beacon do Prysm sofreram esgotamento de recursos ao processar determinadas attestations, o que resultou na incapacidade de responder prontamente às solicitações dos validadores, causando uma grande quantidade de blocos e attestations ausentes.

O impacto do incidente abrangeu do epoch 411439 ao 411480, totalizando 42 epochs, com 248 blocos ausentes em 1344 slots, uma taxa de ausência de aproximadamente 18,5%. A taxa de participação da rede chegou a cair para 75%, e os validadores perderam cerca de 382 ETH em recompensas de attestations. A causa raiz foi que o Prysm recebeu attestations de nós que possivelmente estavam fora de sincronia com a mainnet, e essas attestations faziam referência ao bloco root do epoch anterior.

Para verificar sua legitimidade, o Prysm repetidamente reproduziu o estado do epoch antigo e executou a transição de epoch, que tem alto custo computacional, levando os nós a esgotarem recursos sob alta concorrência. O defeito está relacionado ao PR 15965 do Prysm, que já havia sido implementado na testnet há um mês, mas não havia desencadeado o mesmo cenário.

A solução temporária oficial foi ativar o parâmetro --disable-last-epoch-target na versão v7.0; as versões subsequentes v7.1 e v7.1.0 já incluem uma solução de longo prazo, utilizando o head state para validar as attestations e evitando a repetição da reprodução de estados históricos.

O Prysm informou que o problema começou a ser mitigado gradualmente após 4:45 UTC de 4 de dezembro, e a taxa de participação da rede foi restaurada para mais de 95% no epoch 411480.

A equipe do Prysm destacou que este incidente ressalta a importância da diversidade de clientes: se um único cliente ultrapassar um terço da participação, pode haver períodos de impossibilidade de finalização; se ultrapassar dois terços, existe o risco de uma cadeia inválida ser finalizada. A equipe também refletiu sobre a comunicação inadequada das opções de funcionalidade e sobre o fato de que o ambiente de testes não conseguiu simular nós em grande escala fora de sincronia, e afirmou que irá aprimorar as estratégias de teste e a gestão de configurações no futuro.