Im Ethereum Prysm-Client kam es zu einem Vorfall im Mainnet, bei dem Ressourcen erschöpft wurden, was zu einem massiven Fehlen von Blöcken und Attestierungen führte.

Laut ChainCatcher hat das Prysm-Team einen Bericht zur Analyse des Vorfalls im Mainnet veröffentlicht. Demnach kam es am 4. Dezember während der Fusaka-Periode im Ethereum-Mainnet bei nahezu allen Prysm-Beacon-Knoten zu einem Ressourcenengpass, als sie bestimmte Attestations verarbeiteten. Dies führte dazu, dass sie nicht rechtzeitig auf Anfragen von Validatoren reagieren konnten, was zu einem massiven Fehlen von Blöcken und Attestations führte.

Der Vorfall betraf die Epochen 411439 bis 411480, insgesamt 42 Epochen. In 1344 Slots fehlten 248 Blöcke, was einer Fehlerrate von etwa 18,5 % entspricht. Die Netzwerkteilnahme sank zeitweise auf 75 %, und die Validatoren verloren etwa 382 ETH an Attestations-Belohnungen. Die Ursache lag darin, dass Prysm Attestations von möglicherweise nicht mit dem Mainnet synchronisierten Knoten erhielt, die sich auf den Block-Root der vorherigen Epoche bezogen.

Um deren Gültigkeit zu überprüfen, spielte Prysm wiederholt den Zustand alter Epochen ab und führte kostenintensive Epoch-Transitions durch, was bei hoher Parallelität zu einem Ressourcenengpass der Knoten führte. Der zugrunde liegende Fehler stammte aus Prysm PR 15965, das bereits einen Monat zuvor im Testnet implementiert worden war, dort jedoch nicht das gleiche Szenario auslöste.

Als temporäre Lösung empfahl das Team, in Version v7.0 den Parameter --disable-last-epoch-target zu aktivieren. Die nachfolgenden Versionen v7.1 und v7.1.0 enthalten bereits eine langfristige Lösung, indem sie Attestations anhand des Head State validieren und so das wiederholte Abspielen historischer Zustände vermeiden.

Prysm teilte mit, dass sich das Problem ab dem 4. Dezember um 4:45 UTC allmählich abschwächte und die Netzwerkteilnahme bis Epoche 411480 wieder auf über 95 % anstieg.

Das Prysm-Team betonte, dass dieses Ereignis die Bedeutung der Client-Diversität unterstreicht: Wenn ein einzelner Client mehr als ein Drittel des Netzwerks ausmacht, kann dies zu vorübergehender Nicht-Finalität führen; bei mehr als zwei Dritteln besteht das Risiko einer ungültigen Finalitätskette. Zudem reflektierte das Team über unklare Kommunikation bezüglich Feature-Switches und die Tatsache, dass die Testumgebung keine groß angelegte Asynchronität simulieren konnte. Künftig sollen Teststrategien und Konfigurationsmanagement verbessert werden.