Prysm-Entwickler veröffentlichten eine Post-Mortem-Analyse, in der sie den Fusaka-Mainnet-Vorfall vom 4. Dezember erklärten, der die Stabilität des Ethereum-Netzwerks bedrohte.
Zusammenfassung
- Ein Prysm-Fehler nach Fusaka führte dazu, dass die Validatorbeteiligung auf 75 % sank.
- Das Netzwerk verpasste 41 Epochen und verlor etwa 382 ETH an Beweisprämien.
- Dank der Kundenvielfalt und schnellen Lösungen konnte Ethereum den Verlust seiner Endgültigkeit vermeiden.
Der Konsens-Client litt unter einer Ressourcenerschöpfung durch eine teure Zustandsneuberechnung bei der Verarbeitung bestimmter Attestierungen, was dazu führte, dass Validatoren mit schwerwiegenden Betriebsproblemen konfrontiert waren.
Der Fehler trat unmittelbar nach der Aktivierung von Fusaka in Epoche 411392 am 4. Dezember 2025 um 21:49 UTC auf.
Das Netzwerk verpasste 41 Epochen, da die Beteiligung der Validatoren auf 75 % sank, was zu etwa 382 Ethereum führte (ETH) in Belohnungen für verlorene Beweise. Prysm-Entwickler stellten Notfall-Laufzeitflags bereit, bevor sie dauerhafte Korrekturen in den Versionen v7.0.1 und v7.1.0 implementierten.
Die Erschöpfung der Ressourcen führte dazu, dass das Netzwerk seine Endgültigkeit verlor
Der technische Fehler konzentrierte sich auf veraltete historische Zustände, die zu Denial-of-Service-Bedingungen auf den betroffenen Knoten führten.
Prysm-Kernentwickler Terence Tsao erklärt Da „der historische Zustand viel Rechenspeicher beansprucht, kann ein Knoten durch eine große Anzahl parallel stattfindender Zustandswiederholungen belastet werden.“
Validatoren, die Prysm ausführen, was etwa 15 % bis 22,71 % der Netzwerkvalidatoren ausmacht, waren mit lähmenden Leistungseinbußen konfrontiert. Der Rückgang der Beteiligung von normalen Werten über 95 % auf 75 % brachte Ethereum gefährlich nahe daran, seine Endgültigkeit zu verlieren.
Hätte der Fehler einen anderen Konsens-Client wie Lighthouse anstelle von Prysm betroffen, hätte das Netzwerk möglicherweise völlig seine Endgültigkeit verloren.
Ein solches Ereignis würde möglicherweise Layer-2-Rollup-Vorgänge einfrieren und Validator-Entnahmen blockieren, bis die Entwickler das Problem gelöst haben.
Mit dem Fusaka-Upgrade selbst wurde die PeerDAS-Technologie (Peer Data Availability Sampling) eingeführt, die darauf ausgelegt ist, die Blob-Kapazität für die Layer-2-Skalierung um das Achtfache zu erhöhen.
Das Upgrade wurde erfolgreich und ohne Ausfallzeiten durchgeführt, bevor der Prysm-Fehler auftauchte.
Zehn Konsenskunden verhinderten den Zusammenbruch des Ethereum-Netzwerks
Die Client-Diversity-Architektur von Ethereum verhinderte einen katastrophalen Ausfall. Während Prysm-Validatoren Schwierigkeiten hatten, validierten zehn andere Konsenskunden, darunter Lighthouse, Nimbus und Teku, Blöcke ohne Unterbrechung weiter.
Die dezentrale Kundenstruktur führte dazu, dass etwa 75 bis 85 % der Validatoren während der Krise ihren normalen Betrieb aufrechterhielten. Dies verhinderte einen Verlust der Endgültigkeit und hielt die Netzwerkverarbeitungstransaktionen trotz des verschlechterten Zustands von Prysm aufrecht.
Die Ethereum Foundation gab schnell Notfallleitfäden für Prysm-Betreiber heraus. Validatoren wendeten den temporären Fix an, während Prysm-Entwickler dauerhafte Lösungen entwickelten.
Bis zum 5. Dezember erholte sich die Netzwerkbeteiligung auf fast 99 % und der normale Betrieb konnte innerhalb von 24 Stunden nach dem Vorfall wiederhergestellt werden.
