Ethereum Fusaka Upgrade Ereignisanalyse: Prysm Nachbericht enthüllt die Hauptursache des Scheiterns

Prysm Entwicklungsteam veröffentlichte kürzlich einen Post-Mortem-Bericht, der das Hauptnetz-Problem am 4. Dezember 2025 nach dem Fusaka-Upgrade detailliert erklärt. Dieses Problem bedrohte zeitweise die Stabilität des Ethereum-Netzwerks, konnte jedoch letztlich durch die Vielfalt der Client-Implementierungen entschärft werden.

Der Bericht zeigt, dass das Problem im 411.392. epoch nach Aktivierung des Fusaka-Updates auftrat (4. Dezember, 21:49 UTC). Der Prysm-Konsens-Client löste bei der Verarbeitung bestimmter Beweis-Daten eine große Anzahl an wiederholten Berechnungen historischer Zustände aus, was zu einem schnellen Verbrauch von CPU- und Speicherressourcen führte und einen DoS-ähnlichen Leistungsabfall des Knotens verursachte. Dies ist kein Protokoll-Designfehler, sondern ein Implementierungsproblem des Clients unter bestimmten Grenzbedingungen.

Betroffene Prysm-Validierungs-Knoten machen etwa 15 % bis 22,71 % des Netzwerks aus. Während des Vorfalls sank die Gesamtbeteiligungsrate der Validatoren von über 95 % auf etwa 75 %, das Netzwerk verpasste 41 aufeinanderfolgende Epochs, was zu einem Verlust von etwa 382 ETH an Beweisprämien führte und zeitweise die Finalität gefährdete. Terence Tsao, leitender Entwickler bei Prysm, wies darauf hin, dass die Berechnung des historischen Zustands-Backups enorm ist und bei paralleler Ausführung in mehreren Threads die Leistung der Knoten deutlich verlangsamt wird.

Bemerkenswert ist, dass das Fusaka-Upgrade selbst erfolgreich war. Es führte die PeerDAS-Technologie (Peer Data Availability Sampling) ein, mit dem Ziel, die Blob-Kapazität von Layer 2 auf das Achtfache zu erhöhen. Der Upgrade-Prozess erfolgte ohne Downtime oder Konsens-Fork.

Der Grund, warum das Ethereum-Netzwerk schwerwiegendere Folgen vermeiden konnte, liegt in der Vielfalt der Clients. Neben Prysm liefen auch andere zehn Konsens-Clients wie Lighthouse, Teku und Nimbus während des gesamten Vorfalls normal weiter, so dass etwa 75 % bis 85 % der Validatoren online blieben und die Finalität des Netzwerks gewährleistet wurde. Hätte ein höherer Anteil an Clients betroffen gewesen, wären die Konsequenzen gravierender gewesen, einschließlich einer Pause bei Layer-2-Zusammenfassungen und erschwerter Validator-Auszahlungen.

Nach dem Vorfall veröffentlichte die Ethereum Foundation schnell eine Notfallanleitung, das Prysm-Team setzte vorübergehende Runtime-Fehlerbehebungen um und führte in den Versionen v7.0.1 und v7.1.0 dauerhafte Lösungen ein. Bis zum 5. Dezember erholte sich die Netzwerkbeteiligung fast vollständig auf 99 %, und das Ethereum-Hauptnetz kehrte innerhalb von 24 Stunden zum Normalbetrieb zurück.