Ethereum, avviso ai validatori: disattivare Prysm per rischio di stati obsoleti

Gli operatori dei validatori Ethereum che utilizzano il client di consenso Prysm hanno ricevuto un avviso urgente il 4 dicembre. Il team di Prysm ha confermato che alcuni nodi stavano generando stati vecchi per elaborare attestazioni obsolete, un comportamento che può portare a validazioni errate se non corretto. Per prevenirlo, Prysm ha chiesto agli operatori di disattivare immediatamente una funzione specifica aggiungendo un solo flag al proprio beacon node. La correzione non richiede un aggiornamento completo del client e non influisce sui client dei validatori.

Il team ha indicato agli operatori di aggiungere questa linea: --disable-last-epoch-targets. Il flag è compatibile con Prysm v7.0.0, il che significa che la maggior parte dei nodi può applicare la correzione in pochi minuti. L’avvertimento ha generato reazioni rapide all’interno della comunità dei validatori, vista l’ampia diffusione di Prysm nel livello di consenso di Ethereum.

La quota di mercato di Prysm trasforma il problema in un evento di rete

I dati di MigaLabs mostrano che Prysm controlla quasi il 20% della quota di mercato dei client di consenso di Ethereum, risultando il secondo client più utilizzato dopo Lighthouse. Una scala simile è ciò che ha trasformato un bug lato client in una preoccupazione a livello di rete. Quando un client con questo peso elabora dati di stato obsoleti, l’impatto non riguarda un singolo validatore ma può propagarsi causando:

• Attestazioni mancate
• Segnali di fork choice errati
• Maggiore rischio di penalità o slashing in scenari limite

Finora non ci sono evidenze di un blocco della catena o di un problema di finalità legato a questo caso. La preoccupazione riguarda la prevenzione dei rischi, non il contenimento dei danni. Prysm è intervenuto prima che la situazione potesse degenerare. In altre parole, si è trattato di un’esercitazione preventiva, non della gestione di un incidente.

Che cosa è andato storto dentro Prysm

Secondo il team di Prysm, i nodi interessati stavano producendo inutilmente stati vecchi mentre cercavano di elaborare attestazioni datate provenienti da epoche precedenti. Questo comportamento aumenta il carico su CPU e memoria e può alterare il modo in cui un nodo monitora l’avanzamento della catena sotto stress. Non è la prima volta che Ethereum affronta problemi di gestione dello stato: situazioni simili si sono verificate durante:

• l’incidente di finalità del maggio 2023
• precedenti bug legati alla corruzione degli indici di database
• vecchi picchi di memoria verificati su più client

La differenza chiave, questa volta, è la rapidità. Prysm ha individuato il problema presto, pubblicato una soluzione provvisoria in un solo passaggio e soprattutto evitato di costringere migliaia di validatori a un aggiornamento completo urgente.

Cosa devono fare i validatori adesso

Se utilizzi Prysm, la checklist è breve e immediata:

• Aggiungere il flag --disable-last-epoch-targets
• Riavviare il beacon node
• Verificare nei log il normale flusso delle attestazioni
• Monitorare memoria e CPU dopo il riavvio

Non sono necessarie modifiche alle chiavi del validatore. Nessuna risincronizzazione, nessuna uscita.
Per Ethereum nel suo complesso, questo episodio ribadisce una verità nota: la diversità dei client conta ancora. Quando un singolo client detiene quasi il 20% della rete, anche un bug gestibile diventa un evento rilevante. Allo stesso tempo, l’incidente mostra la maturità operativa di Ethereum: il problema è stato individuato, comunicato e mitigato nel giro di poche ore. È così che un layer di regolamento da oltre 400 miliardi di dollari resta resiliente.