Validadores de Ethereum aconselhados a desativar o Prysm devido ao risco de estado desatualizado

Os operadores de validadores Ethereum que utilizam o cliente de consenso Prysm receberam um alerta urgente a 4 de dezembro. A equipa do Prysm confirmou que alguns nós estavam a gerar estados antigos para processar atestações desatualizadas, o que pode levar a comportamentos incorretos de validação se não for corrigido. Para evitar isto, a Prysm instruiu todos os operadores a desativarem imediatamente uma função específica, adicionando um único parâmetro ao seu nó beacon. A correção não requer uma atualização completa do cliente e não afeta os clientes dos validadores.

A equipa instruiu os operadores a adicionar esta linha: –disable-last-epoch-targets. Este parâmetro funciona com o Prysm v7.0.0, o que significa que a maioria dos nós pode aplicar a correção em minutos. O aviso desencadeou reações rápidas em toda a comunidade de validadores. Isto deve-se à grande presença do Prysm na camada de consenso do Ethereum.

A quota de mercado do Prysm torna isto um evento ao nível da rede

Dados da MigaLabs mostram que o Prysm controla cerca de 20% da quota de mercado dos clientes de consenso do Ethereum, sendo o segundo maior cliente depois do Lighthouse. Essa escala transformou um bug do lado do cliente numa preocupação em toda a cadeia. Quando um cliente com este peso processa dados de estado desatualizados, não afeta apenas um validador. Pode propagar-se para:

• Atestações falhadas
• Sinais de escolha de fork incorretos
• Maior risco de penalizações ou slashing em casos extremos

Até agora, não há evidências de paragem da cadeia em tempo real ou falha de finalização relacionada com este problema. No entanto, a preocupação é puramente sobre prevenção de riscos, não controlo de danos. O Prysm agiu antes que a situação se agravasse. Em outras palavras, isto foi um exercício de prevenção, não uma limpeza após incidente.

O que correu mal dentro do Prysm

Segundo a equipa Prysm, os nós afetados estavam a produzir estados antigos desnecessários ao tentar processar atestações desatualizadas de épocas anteriores. Esse comportamento aumenta o consumo de CPU e memória e pode distorcer a forma como um nó acompanha o progresso da cadeia sob stress. Este tipo de comportamento não é novo na história do Ethereum. Problemas semelhantes de gestão de estados surgiram durante:

• O incidente de finalização de maio de 2023
• Bugs de corrupção de índice de base de dados anteriores
• Picos de memória em clientes múltiplos no passado

A diferença chave desta vez é a velocidade. O Prysm detetou o problema cedo, publicou uma solução temporária de um só passo e evitou forçar milhares de validadores a uma atualização completa de emergência.

O que os validadores devem fazer agora

Se utiliza o Prysm, a lista de tarefas é curta e urgente:

• Adicione o parâmetro –disable-last-epoch-targets
• Reinicie o nó beacon
• Verifique os logs para confirmar o fluxo normal de atestações
• Monitorize a memória e CPU após o reinício

Não são necessárias alterações às chaves dos validadores. Não é necessário ressincronizar nem sair. Para o Ethereum como um todo, este episódio reforça uma verdade conhecida: a diversidade de clientes continua a ser importante. Quando um cliente detém quase 20% da rede, mesmo um bug gerível torna-se um evento de destaque. Ainda assim, este incidente também mostra a maturidade operacional do Ethereum. O problema foi identificado, divulgado e mitigado em poucas horas, não dias. É assim que uma camada de liquidação ao vivo de mais de $400B permanece resiliente. Atualmente, a cadeia mantém-se estável. O único prazo real é para que os operadores Prysm ajam rapidamente e ativem a medida de segurança.