Ethereum: Finalisierung von Transaktionen vorübergehend ausgesetzt

Ende letzter Woche stoppte die Finalisierung von Ethereum-Transaktionen zeitweise. Das klingt bedrohlich. User haben zwar nichts bemerkt – doch Ethereum schlitterte knapp an einer größere Katastrophe vorbei. Wir erklären, was vorfiel, was es bedeutet, und wie es technisch einzuordnen ist.

Am 11. Mai stoppte die Finalisierung von Transaktionen auf der Beaconchain von Ethereum für 30 Minuten oder drei „Epochen“. Warum, wusste zu diesem Zeitpunkt niemand. Doch einen Tag später begann der Spuk erneut, diesmal sogar für mehr als eine Stunde oder acht Epochen. Warum, wusste noch immer niemand.

Der Vorfall, ist weniger gruselig als es sich anhört. Die Beaconchain, Ethereums „Konsens-Layer“, hat zu keinem Zeitpunkt aufgehört zu arbeiten. User konnten weiterhin Transaktionen versenden, und die Validatoren haben diese auch weiterhin bestätigt.

Aber was bedeutet es dann, wenn die Finalisierung stoppt? Irgendeinen Effekt muss es ja haben, ansonsten gäbe es sie ja nicht.

Der Unterschied zwischen einer Bestätigung und einer Finalisierung

Bestätigungen und Finalisierungen sind bei allen Blockchains etwas anderes. Auch bei Bitcoin: Die meisten Börsen warten drei oder sechs Bestätigungen ab, um sicher zu sein, dass eine Transaktion auch tatsächlich „finalisiert“ ist. Erst dann kann man sicher sein, dass sie nicht mehr rückgängig gemacht werden kann, auch nicht von einem mächtigen, bösartigen Akteur. Satoshi hat dies im Bitcoin-Whitepaper durchexerziert.

Aber hier geht es um Ethereum. Wenn ein Validator eine Transaktion in einen Block packt, gilt diese als bestätigt. Das dauert maximal 12 Sekunden und ist für die allermeisten Anwendungen ausreichend. Ein Block ist Teil einer „Epoche“, welche maximal 32 Blöcke enthält und rund 15 Minuten dauert. Nach ihrem Ablauf stimmen alle Validatoren darüber ab, ob die Epoche korrekt war. Stimmen mindestens zwei Drittel zu, ist sie finalisiert. Nun kann auch eine Supermehrheit der Validatoren sie nicht mehr ändern.

Bei den Vorfällen am 11. und 12. Mai stürzte die Wahlbeteiligung der entsprechenden Epochen auf unter 50 Prozent ab. So war eine Finalisierung nicht mehr möglich. Das war an sich zunächst unproblematisch: Transaktionen wurden ja weiterhin bestätigt, und die nächste Epoche konnte problemlos anbrechen. Es fehlte lediglich der Stempel der Validatoren, der bestätigte, dass diese 32 Blöcke auch wirklich valide sind.

Das Inactivity Leak

Dennoch war der Druck auf die Ethereum-Entwickler, den Fehler zu identifizieren und zu fixen, enorm. Einerseits, weil es natürlich nicht optimal ist, wenn Ethereum nicht so funktioniert, wie es sollte.

Andererseits aber, weil es eine Art Sicherheitsprotokoll gibt, wenn die Finalisierung ausbleibt, welches in letzter Instanz zu einer Spaltung der Blockchain führen kann.

1/2

Eth beacon chain finality has now failed for over an hour, we’re at inactivity leak time and there is no denying this is now a liveness fault.

Hoping that this is just an implementation issue for a single client to fix and not a larger protocol issue… either way not good https://t.co/b8EBi972NJ

— Adam Cochran (adamscochran.eth) (@adamscochran) May 12, 2023

Dieses Protokoll ist das „Inactivity Leak“: „Wenn die Beacon Chain mehr als vier Epochen lang nicht finalisiert, wird ein Notfall-Protokoll mit dem Namen „Inactivit Leak“ aktiviert […] Es saugt das Stake der inaktiven Validatoren schrittweise ab, bis sie weniger als ein Drittel des gesamten Stakes kontrollieren.“ Wenn Epochen nicht finalisiert werden, weil zu viele Nodes inaktiv sind, wird das Problem also damit gelöst, dass der Stake – Einfluss – der inaktiven Nodes so lange reduziert wird, bis der Stimmenanteil der aktiven Nodes so weit gewachsen ist, dass sie die Epoche finalisieren können.

Das Inactivity Leak wurde dafür gemacht, um die Blockchain auch unter extrem katastrophalen Umständen zu erhalten, erklärt Ben Edgington im ETH2-Book, etwa einem Dritten Weltkrieg. Dafür priorisiert es Verfügbarkeit über Konsistenz – besser man spaltet die inaktiven Nodes ab, anstatt von ihnen gelähmt zu werden. „Das Resultat kann sein, dass die Beacon Chain sich permanent in zwei unabhängige Blockchains spaltet, was als ein vernünftiges Ergebnis eines Problems gilt, das nicht in einigen Wochen zu lösen ist.“

Das Leak fängt mit geringen Beträgen an, aber steigert sich quadratisch, so dass auch in extremen Situationen die Anzahl der verfügbaren Nodes nach spätestens 31,5 Tagen wieder ausreichend ist, um Finalität zu schaffen.

Am 12. Mai wurde das Inactivity Leak zum ersten Mal überhaupt aktiviert. Da es allerdings nur um wenige Epochen ging, waren die Verluste sehr überschaubar. Jeder Validator, der offline war, musste etwa 0,00007 Ether bezahlen, was insgesamt auf 28 Ether hinauslief.

Lots of people asking how much ETH was burned by yesterday's inactivity leak. Back of envelope (assumes 8 epoch leak, 65% validators offlne):

About 28 ETH (c. 0.0006 ETH/offline validator).

However, attestation rewards were zero for the duration, so that's ~50 ETH not issued. https://t.co/VNzFueza5D

— Ben Edgington (@benjaminion_xyz) May 13, 2023

Danach setzte die Finalisierung wieder ein, und es kam bisher zu keinen neuen Ausfällen.

Die Ursache und Lösung

Aber was war die Ursache? Diese Frage ist schwieriger zu beantworten. Denn offenbar weiß niemand exakt, was der Grund war, und wenn, dann wird darüber nur hinter vorgehaltener Hand geredet. Vermutlich, um keine Nachahmer auf den Platz zu rufen, oder um abzuwarten, bis jeder Bug gefixt ist und man ein Statement veröffentlichen kann, dem alle zustimmen.

Superphiz, ein selbsternannter „Ethereum Beacon Chain Community Health Consultant“, postet immerhin ein Update der beiden Clients Prysm und Teku: einen Screenshot einer Mitteilung, angeblich vom Blog der Ethereum Foundation, was einigermaßen merkwürdig ist, da es dort (noch?) nicht zu finden ist.

We can start putting this loss of finality issue behind us, @Teku_ConsenSys and @prylabs have deployed fixes that will prevent the attestation flooding. This is one step on our diversity & decentralization journey, let's learn from it and move forward with greater purpose. pic.twitter.com/cSRgPTWeuy

— superphiz.eth 🦇🔊🛡️ (@superphiz) May 13, 2023

Laut diesem Screenshot bestätigen die beiden Beacon Chain Clients, dass es wegen der hohen Belastung der Clients, welche „durch ein außergewöhnliches Szenario“ verursacht worden war, zu Finalisierungsproblemen gekommen war. Doch wegen der hohen Diversität der Clients habe dies für User keine Folgen gehabt.

Tatsächlich gibt es fünf Clients für die Beaconchain, neben Prysm und Teku Nimbus, Lighthouse und Lodestar. Unter diesen Clients haben Lighthouse und Prysm mit jeweils knapp 40 Prozent den höchsten Anteil, gefolgt von Teku mit knapp 17 und Nimbus mit gut 6 Prozent.

Gm! Here's another round of summary from the incident yesterday. We are also working on a writeup to capture everything: 👇🧵

— terence.eth (@terencechain) May 12, 2023

Während des Vorfalls am 11. und 12. Mai haben die Prysm-Nodes angeblich problematische Bescheinigungen für vergangene Epochen erhalten, welche die Nodes dazu zwangen, immer mehr CPU-Ressourcen aufzuwenden. Sie haben sich quasi ins Koma gerechnet. Dieses Problem schienen alle Nodes außer Lighthouse zu haben. So hat die Diversität der Clients tatsächlich Ethereum vor einer Katastrophe bewahrt. Denn wären alle Clients betroffen, wäre das Netzwerk wirklich down gewesen und hätte keine Transaktionen mehr bestätigt.

Was den Vorfall aber ausgelöst hat, wird noch evaluiert. Spezielle Transaktionen oder Smart Contracts? Oder ein Angriff? Auch wenn dies noch unklar scheint, haben Teku und Prysm Upgrades herausgegeben, die Optimierungen enthalten, die verhindern, dass es zu einem so hohen Ressourcenverbrauch der Nodes kommt.

Fürs erste scheint dies auszureichen. Man sollte aber nicht vergessen, dass Ethereum beinahe wirklich gestoppt hätte, wenn der Fehler auch im Lighthouse-Client zugeschlagen hätte.