Laut Mitbegründer Vitalik Buterin kann es sich Ethereum leisten, ab und zu die Finalität zu verlieren, ohne das Netzwerk ernsthaft zu gefährden. Diese Feststellung steht vor dem Hintergrund eines kürzlich aufgetretenen Client-Fehles, der beinahe beträchtlich den Bestätigungsmechanismus der Blockchain gestört hätte.

Nach dem kürzlich aufgetretenen Fehler im Prysm Ethereum-Client erklärte Buterin in einem X-Beitrag nun, dass es „nichts Schlimmes ist, wenn die Finalität hin und wieder verloren geht“. Er fügte hinzu, dass die Finalität eher nur ein Zeichen dafür ist, dass das Netzwerk „wirklich sicher“ ist, dass ein Block nicht rückgängig gemacht wird.

Buterin argumentierte, dass es „in Ordnung“ sei, wenn die Finalität aufgrund eines größeren Fehlers gelegentlich um einige Stunden verzögert werde, da die Blockchain währenddessen weiterhin problemlos funktioniere. Das eigentliche Problem dahinter beschreibt er wie folgt: „Was es zu vermeiden gilt, ist, das Falsche zu finalisieren.“

Quelle: Vitalik Buterin

Blockchain-Experte bestätigt Buterin

Fabrizio Romano Genovese, Doktor der Informatik an der Universität Oxford, ein Teilhaber des Blockchain-Forschungsunternehmens 20squares und Experte für das Ethereum-Protokoll, stimmte Buterin zu.

Er betonte, dass Ethereum ohne Finalität eher wie Bitcoin (BTC) werde, und wies darauf hin, dass Bitcoin „seit 2009 keine Finalität mehr hat und sich niemand darüber beschwert“.

Eine Proof-of-Work-Blockchain wie die von Bitcoin kann sich in mehrere Chains verzweigen, wobei diejenige, die die meiste Arbeit erbringt (in der Regel die längste), als gültig angesehen wird. Wenn jedoch ein sekundärer Zweig so stark wächst, dass er den Hauptzweig überholt, werden der Hauptzweig und die darin enthaltenen Transaktionen ungültig – dies wird als Reorganisation bezeichnet.

Bei Bitcoin funktioniert es so: Die Finalität ist probabilistisch, nicht deterministisch, denn obwohl es nach dem Hinzufügen einer ausreichenden Anzahl von Blöcken zum Hauptzweig nahezu unmöglich ist, kann theoretisch immer noch eine Reorganisation stattfinden. Genovese erklärt, dass sich Ethereum allerdings davon unterscheidet, da es hier Regeln gibt, die Blöcke als „endgültig“ markieren. Er fügte hinzu:

„Ethereum verfügt über einen Finalisierungsmechanismus: Wenn ein Block mehr als 66 % der Validator-Stimmen erhält, wird er als „legitim“ angesehen. Wenn zu diesem Zeitpunkt mehr als zwei Epochen (64 Blöcke) vergehen, wird der Block finalisiert.”

Das ist nicht nur bloße Theorie, sondern im Mai 2023 bei einem Vorfall, der dem aktuellen Fall mit dem Prysm-Client ähnlich ist, zwischenzeitlich Realität gewesen. Genovese betont, dass diese Vorfälle die Blockchain nicht unsicher machen, sondern „nur bedeuten, dass die Schutzmechanismen vor Reorganisationen vorübergehend wieder probabilistisch und nicht deterministisch sind“.

L2s und Bridges sind von Fehler betroffen

Dennoch merkte Genovese an, dass eine fehlende Finalität Auswirkungen auf die darauf basierende Infrastruktur haben würde, darunter auch einige Inter-Blockchain- oder Layer-2 (L2) Bridges.

Ein Vertreter der Ethereum-Sidechain Polygon teilte Cointelegraph dahingehend mit, dass Polygon den normalen Betrieb fortsetzen werde, aber Überweisungen von Ethereum zur Sidechain „sich möglicherweise verzögern, während auf Finalität gewartet wird“.

Darüber hinaus erklärte der Sprecher von Polygon, dass das Cross-Chain-Zahlungssystem AggLayer ebenfalls Transaktionen von Ethereum auf L2s verzögern wird, bis die Finalität wieder hergestellt sei. Dennoch betonte er zugleich, dass es „kein Szenario gibt, in dem Nutzer aufgrund eines Verlusts der Finalität einen Rollback oder eine Ungültigkeitserklärung ihrer Transaktionen erleben würden”.

„Die praktische Auswirkung einer verzögerten Finalität besteht lediglich darin, dass Einzahlungen möglicherweise länger dauern, bis sie sichtbar werden. Über diese Verzögerung hinaus sind Nutzer keinen durch Reorganisationen verursachten Rückbuchungen ausgesetzt.“

Genovese schob die Schuld für derartige Verzögerungen auf Entwickler, die Finalität verlangen. „Wenn ein Bridge-Service beschließt, keinen Fallback-Mechanismus für den Fall eines Finalitätsverlusts zu implementieren, ist das seine Entscheidung“, resümierte er.