Ein zuvor unentdeckter Fehler im Prysm-Konsensclient von Ethereum, der mehr als einen Monat vor dem Fusaka-Upgrade eingeführt wurde, wurde als die Hauptursache für einen Rückgang der Netzwerkbeteiligung identifiziert, der Ethereum Anfang dieses Monats kurzzeitig gestört hat.
Laut einem Nachbericht, der von dem Ethereum-Entwickler Terence Tsao veröffentlicht wurde, ereignete sich der Vorfall am 4. Dezember, als Prysm-Knoten begannen, unter schwerer Ressourcenauslastung zu leiden, was zu verpassten Bestätigungen, reduzierter Validatorenbeteiligung und erheblichen verlorenen Belohnungen führte.
Was mit Prysm schiefgelaufen ist
Das Problem ging von einem Fehler aus, der in Prysm PR 15965 eingeführt wurde, der etwa einen Monat vor dem Fusaka-Mainnet-Upgrade auf Ethereum-Testnets bereitgestellt wurde.
Obwohl der Fehler auf Testnets existierte, wurde er nie ausgelöst, bis die Bedingungen des Mainnets übereinstimmten.
Als Prysm-Knoten Bestätigungen von nicht synchronen Peers erhielten, konnten sie diese nicht effizient verarbeiten. Anstatt den aktuellen Kopfzustand zu referenzieren, spielten die betroffenen Knoten vergangene Epoch-Blöcke erneut ab und berechneten kostspielige Zustandsübergänge von Grund auf neu, was die Rechenlast drastisch erhöhte.
Dies führte zu einem kaskadierenden Leistungsversagen bei Prysm-Validierern.
Netzwerkwirkung: Die Teilnahme fällt auf 75 %
Seit mehr als 42 Epochen erlebte Ethereum erhöhte Störungsmetriken:
Die Netzwerkbeteiligung fiel auf 75 %
Die verpasste Slot-Rate erreichte 18,5 %
Validatoren verloren ungefähr 382 ETH an Bestätigungsbelohnungen
Trotz der Störung vermied Ethereum ein schwerwiegenderes Netzwerkereignis dank der Diversität der Clients.
Prysm-Patch bereitgestellt, vorübergehende Lösung verwendet
Sobald das Problem identifiziert wurde, wiesen Prysm-Entwickler die Knotenbetreiber an, eine vorübergehende Minderung bereitzustellen, während ein vollständiger Patch vorbereitet und kurz danach ausgerollt wurde.
Prysm wurde inzwischen gepatcht, wodurch das fehlerhafte Verhalten, das die übermäßige Neuberechnung und Erschöpfung der Knoten verursachte, behoben wurde.
Die Diversität der Clients verhinderte eine größere Krise
Entwickler betonten, dass der Ausfall viel schlimmer hätte sein können, wenn der Fehler den dominierenden Konsens-Client von Ethereum, Lighthouse, betroffen hätte.
Prysm, entwickelt von Offchain Labs, macht 17,6 % der Ethereum-Konsens-Clients aus und ist damit der zweitgrößte Client nach Anteil. Lighthouse kontrolliert derzeit 52,6 %, ein Rückgang von etwa 56 % zur Zeit des Vorfalls, laut ClientDiversity-Daten.
„Die Diversität der Clients verhinderte eine spürbare Auswirkung auf Ethereum-Nutzer“, bemerkten die Entwickler.
„Ein Client mit mehr als einem Drittel des Netzwerks hätte zu einem vorübergehenden Verlust der Endgültigkeit und mehr verpassten Blöcken geführt.“
Hätte der Fehler einen Client betroffen, der über 33 % des Netzwerks kontrollierte, könnte Ethereum vorübergehend die Endgültigkeit verloren haben. Wenn er einen Client über der Zwei-Drittel-Schwelle betroffen hätte, hätte das Netzwerk eine ungültige Kette finalisieren können.
Eine Erinnerung an vergangene Ethereum-Risiken
Der Vorfall erinnert an frühere Beinahe-Unfälle. Im Mai 2023, kurz nach dem Shanghai-Hardfork, verlor Ethereum vorübergehend die Transaktionsendgültigkeit für fast 25 Minuten, gefolgt von einem weiteren Ausfall, der am nächsten Tag über eine Stunde dauerte – beide wurden ohne dauerhaften Schaden gelöst.
Warum das wichtig ist
Während Ethereum widerstandsfähig blieb, hebt der Prysm-Ausfall zwei kritische Realitäten hervor:
Testnets sind nicht narrensicher, selbst bei Fehlern, die Wochen vor der Bereitstellung des Mainnets vorhanden waren.
Die Diversität der Clients bleibt eine der stärksten Schutzmaßnahmen von Ethereum gegen katastrophale Fehler
Während Ethereum weiterhin durch Upgrades wie Fusaka weiterentwickelt wird, sagen Entwickler, dass die Aufrechterhaltung einer ausgewogenen Verteilung der Clients und rigoroser Tests entscheidend für die Wahrung der Stabilität des Netzwerks bleibt.
