Il client Prysm di Ethereum ha subito un incidente sulla mainnet, con esaurimento delle risorse che ha causato una massiccia mancanza di blocchi e attestazioni.

Secondo ChainCatcher, il team di Prysm ha pubblicato un rapporto di revisione sull'incidente della mainnet, affermando che durante il periodo Fusaka della mainnet di Ethereum il 4 dicembre, quasi tutti i nodi beacon Prysm hanno esaurito le risorse durante l'elaborazione di specifiche attestations, portando all'incapacità di rispondere tempestivamente alle richieste dei validatori e causando una significativa perdita di blocchi e attestazioni.

L'incidente ha interessato gli epoch da 411439 a 411480, per un totale di 42 epoch; su 1344 slot sono mancati 248 blocchi, con un tasso di mancanza di circa il 18,5%. La partecipazione della rete è scesa temporaneamente al 75% e i validatori hanno perso circa 382 ETH in premi per le attestazioni. La causa principale è che Prysm ha ricevuto attestations da nodi che potrebbero non essere sincronizzati con la mainnet, e queste attestations fanno riferimento alla radice del blocco dell'epoch precedente.

Per verificarne la legittimità, Prysm ha ripetutamente riprodotto lo stato degli epoch precedenti ed eseguito costose transizioni di epoch, portando all'esaurimento delle risorse dei nodi sotto alta concorrenza. Il difetto è stato introdotto dalla PR 15965 di Prysm, già distribuita sulla testnet un mese fa, ma senza che si verificasse lo stesso scenario.

La soluzione temporanea fornita ufficialmente è stata l'attivazione del parametro --disable-last-epoch-target nella versione v7.0; le versioni successive v7.1 e v7.1.0 includono una soluzione a lungo termine, che utilizza lo stato head per verificare le attestations, evitando la ripetizione della riproduzione degli stati storici.

Prysm ha dichiarato che il problema si è progressivamente attenuato dopo le 4:45 UTC del 4 dicembre e che la partecipazione della rete è tornata sopra il 95% all'epoch 411480.

Il team di Prysm ha sottolineato che questo evento evidenzia l'importanza della diversità dei client: se un singolo client supera un terzo della quota, potrebbe verificarsi una temporanea impossibilità di finalizzazione; se supera i due terzi, esiste il rischio di una catena non valida. Hanno inoltre riflettuto sulla comunicazione poco chiara delle funzioni di attivazione/disattivazione e sulla mancata simulazione, nell'ambiente di test, di nodi non sincronizzati su larga scala, impegnandosi a migliorare le strategie di test e la gestione delle configurazioni in futuro.