Cosa Ha Interrotto l'Aggiornamento Fusaka di Ethereum? Il Post-mortem di Prysm Rivela la Causa

Gli sviluppatori di Prysm hanno rilasciato un'analisi post-mortem che spiega l'incidente del 4 dicembre sulla mainnet Fusaka che ha minacciato la stabilità della Blockchain Ethereum.

Il client di consenso ha subito un esaurimento delle risorse a causa della costosa ricalcolazione dello stato durante l'elaborazione di attestazioni specifiche, causando gravi problemi operativi ai validatori.

Il bug è emerso immediatamente dopo l'attivazione di Fusaka all'epoca 411392 il 4 dicembre 2025, alle 21:49 UTC.

La rete ha perso 41 epoche mentre la partecipazione dei validatori è crollata al 75%, risultando in circa 382 Ethereum (ETH) di ricompense di prova perse. Gli sviluppatori di Prysm hanno implementato flag di runtime di emergenza prima di implementare correzioni permanenti nelle versioni v7.0.1 e v7.1.0.

L'esaurimento delle risorse ha spinto la rete verso la perdita di finalità

Il guasto tecnico si è concentrato su stati storici obsoleti che hanno creato condizioni di denial-of-service sui nodi interessati.

Lo sviluppatore core di Prysm Terence Tsao ha spiegato che "lo stato storico richiede molta memoria di calcolo, un nodo può essere sovraccaricato da un gran numero di replay di stato che avvengono in parallelo."

I validatori che eseguivano Prysm, che rappresentavano circa dal 15% al 22,71% dei validatori della rete, hanno affrontato un degrado delle prestazioni paralizzante. Il calo di partecipazione dai livelli normali superiori al 95% al 75% ha portato Ethereum pericolosamente vicino alla perdita di finalità.

Se il bug avesse colpito un client di consenso diverso come Lighthouse invece di Prysm, la rete avrebbe potuto perdere completamente la finalità.

Un tale evento avrebbe potenzialmente congelato le operazioni di rollup di Layer 2 e bloccato i prelievi dei validatori fino a quando gli sviluppatori non avessero risolto il problema.

L'aggiornamento Fusaka stesso ha introdotto la tecnologia PeerDAS (Peer Data Availability Sampling) progettata per aumentare di otto volte la capacità dei blob per la scalabilità di Layer 2.

L'aggiornamento è stato eseguito con successo senza tempi di inattività prima che emergesse il bug di Prysm.

Dieci client di consenso hanno impedito il collasso della rete Ethereum

L'architettura di diversità dei client di Ethereum ha impedito un guasto catastrofico. Mentre i validatori Prysm erano in difficoltà, altri dieci client di consenso tra cui Lighthouse, Nimbus e Teku hanno continuato a validare i blocchi senza interruzioni.

La struttura client decentralizzata ha fatto sì che circa il 75-85% dei validatori mantenesse operazioni normali durante tutta la crisi. Questo ha impedito la perdita di finalità e ha mantenuto la rete in grado di elaborare transazioni nonostante lo stato degradato di Prysm.

La Ethereum Foundation ha rapidamente emesso linee guida di emergenza per gli operatori Prysm. I validatori hanno applicato la correzione temporanea mentre gli sviluppatori di Prysm costruivano soluzioni permanenti.

Entro il 5 dicembre, la partecipazione alla rete è tornata a quasi il 99%, ripristinando le normali operazioni entro 24 ore dall'incidente.