Was hat Ethereums Fusaka-Upgrade unterbrochen? Prysm-Post-Mortem enthüllt die Ursache

Prysm-Entwickler haben eine Post-Mortem-Analyse veröffentlicht, die den Vorfall im Fusaka-Mainnet vom 4. Dezember erklärt, der die Stabilität des Ethereum-Netzwerks bedrohte.

Der Konsens-Client litt unter Ressourcenerschöpfung durch teure Zustandsneuberechnungen bei der Verarbeitung bestimmter Attestierungen, was bei Validatoren zu schwerwiegenden Betriebsproblemen führte.

Der Fehler trat unmittelbar nach der Aktivierung von Fusaka in Epoche 411392 am 04.12.2025 um 21:49 UTC auf.

Das Netzwerk verpasste 41 Epochen, da die Validator-Beteiligung auf 75% sank, was zu einem Verlust von etwa 382 Ethereum (ETH) an Proof-Belohnungen führte. Prysm-Entwickler setzten Notfall-Laufzeitflags ein, bevor sie dauerhafte Fehlerbehebungen in den Versionen v7.0.1 und v7.1.0 implementierten.

Ressourcenerschöpfung trieb das Netzwerk in Richtung Finalitätsverlust

Der technische Fehler konzentrierte sich auf obsolete historische Zustände, die Denial-of-Service-Bedingungen auf betroffenen Knoten verursachten.

Prysm-Kernentwickler Terence Tsao erklärte, dass "historischer Zustand rechen- und speicherintensiv ist, ein Knoten kann durch eine große Anzahl parallel stattfindender Zustandswiederholungen überlastet werden."

Validatoren, die Prysm ausführten und etwa 15% bis 22,71% der Netzwerkvalidatoren ausmachten, waren mit lähmender Leistungsverschlechterung konfrontiert. Der Rückgang der Beteiligung von normalerweise über 95% auf 75% brachte Ethereum gefährlich nahe an den Verlust der Finalität.

Hätte der Fehler einen anderen Konsens-Client wie Lighthouse anstelle von Prysm betroffen, hätte das Netzwerk die Finalität vollständig verlieren können.

Ein solches Ereignis hätte potenziell Layer-2-Rollup-Operationen einfrieren und Validator-Abhebungen blockieren können, bis Entwickler das Problem gelöst hätten.

Das Fusaka-Upgrade selbst führte die PeerDAS-Technologie (Peer Data Availability Sampling) ein, die entwickelt wurde, um die Blob-Kapazität für Layer-2-Skalierung zu verachtfachen.

Das Upgrade wurde erfolgreich ohne Ausfallzeit durchgeführt, bevor der Prysm-Bug auftrat.

Zehn Konsens-Clients verhinderten den Zusammenbruch des Ethereum-Netzwerks

Die Client-Diversitätsarchitektur von Ethereum verhinderte einen katastrophalen Ausfall. Während Prysm-Validatoren zu kämpfen hatten, setzten zehn andere Konsens-Clients, darunter Lighthouse, Nimbus und Teku, die Validierung von Blöcken ohne Unterbrechung fort.

Die dezentrale Client-Struktur bedeutete, dass etwa 75% bis 85% der Validatoren während der gesamten Krise den normalen Betrieb aufrechterhielten. Dies verhinderte den Verlust der Finalität und hielt das Netzwerk trotz des beeinträchtigten Zustands von Prysm am Laufen.

Die Ethereum Foundation gab schnell Notfallanweisungen für Prysm-Betreiber heraus. Validatoren wendeten die temporäre Fehlerbehebung an, während Prysm-Entwickler permanente Lösungen erarbeiteten.

Am 5. Dezember erholte sich die Netzwerkbeteiligung auf fast 99% und stellte den normalen Betrieb innerhalb von 24 Stunden nach dem Vorfall wieder her.