- Ein seit rund einem Monat im Code schlummernder Bug im Prysm-Client führte am 4. Dezember zu einer deutlichen Störung der Validator-Performance im Ethereum-Netz.
- Laut Post-mortem von Entwickler Terence Tsao gerieten Prysm-Knoten durch attestations von out-of-sync Nodes in eine Art Ressourcenerschöpfung und rechneten alte Epochen mehrfach neu.
Ethereum ringt noch mit den Nachwehen des Fusaka-Upgrades. In einem technischen Post-mortem hat Prysm-Entwickler Terence Tsao erläutert, warum es am 4. Dezember zu sichtbaren Einbrüchen bei der Validator-Teilnahme kam.
Auslöser war ein Bug, der bereits seit mehreren Wochen in der Client-Version steckte, aber erst unter den neuen Bedingungen nach Fusaka praktisch durchschlug.
Der Fehler zeigte sich, als Prysm-Knoten Attestations von Nodes verarbeiten mussten, die nicht sauber mit der Chain synchronisiert waren. Statt diese Meldungen effizient zu filtern, lief der Client in ein Muster, das Tsao als „resource exhaustion“ beschreibt.
Alte Epochen, teure Rechenlast, langsame Knoten
Konkret begannen betroffene Prysm-Instanzen, vergangene Epoch-Blöcke erneut abzuspielen und teure State-Transitions noch einmal zu berechnen. Die Folge war ein drastisch erhöhter Ressourcenverbrauch. CPU und Speicher liefen voll, neue Attestations wurden verzögert verarbeitet oder gingen ganz verloren.
Für das Netzwerk bedeutete das kurzfristig geringere Voting- und Sync-Participation. Die Protokoll-Logik blieb intakt, doch ein auffälliger Teil der Prysm-Validatoren lieferte ihre Signaturen verspätet oder gar nicht ab.
Tsao skizzierte im Bericht nächste Schritte, von Patches zur effizienteren Verarbeitung veralteter Attestations bis zu zusätzlichen Schutzmechanismen gegen ähnliche Muster. Für das Client-Ökosystem ist der Vorfall ein erneuter Hinweis, wie wichtig Diversität bei Konsens-Clients und harte Tests neuer Releases unter realistischen Lastszenarien sind, bevor ein Upgrade wie Fusaka im Mainnet landet.
