Dieser Artikel wurde von BlockWeeks zusammengestellt und organisiert
Merge ist der Übergang von Ethereum vom Proof-of-Work-Konsens (PoW) zum Proof-of-Stake (PoS) und zugleich die komplexeste und radikalste Codeänderung in der Geschichte von Ethereum. Sein Aktivierungsprozess unterscheidet sich von jedem bisherigen Hard Fork: Er besteht aus drei großen Schritten und erfordert, dass Knotenbetreiber von der Ausführung nur eines Software-Clients zur gleichzeitigen Ausführung zweier Clients übergehen. Als die weltweit größte Allzweck-Blockchain nach Marktkapitalisierung und Total Value Locked sind der Wert und der Ruf, die bei Ethereums Übergang auf dem Spiel stehen, enorm.
Was der Merge lösen soll: Die Fusion zweier Chains
Derzeit werden Ethereum-Transaktionen durch ein PoW-Konsensprotokoll namens ethash finalisiert. Parallel zu dieser PoW-Chain läuft die Beacon Chain – eine unabhängige Blockchain, die seit Dezember 2020 Ethereums neues PoS-Konsensprotokoll Gasper eigenständig betreibt.
Das Ziel des Merge ist es, die beiden Chains zu fusionieren: Ethereums bestehende Blockchain soll sich vollständig auf die Beacon Chain stützen, um Netzwerkkonsens zu erzeugen, und Proof-of-Work vollständig aufgeben. Das Ethereum, das wir heute kennen, wird keine Transaktionen mehr über ethash verarbeiten, sondern nur noch als Execution Layer (EL) existieren, damit dezentrale Anwendungen und Nutzer Transaktionen ausstrahlen können. Die Ethereum Virtual Machine (EVM), Ethereums Berechnungsmaschine, wird auf der Execution Layer weiterhin normal funktionieren.
Die Beacon Chain wird dann zu Ethereums Consensus Layer (CL): Transaktionen von der Execution Layer werden hier empfangen, verarbeitet und finalisiert. Das Verpacken von Execution-Layer-Transaktionen in Blöcke und deren Finalisierung durch das Gasper-Protokoll wird zur Verantwortung der Beacon-Chain-Validatoren. Nach dem Merge müssen alle Validatoren und Full-Node-Betreiber, um der Ethereum-Hauptchain zu folgen, zwei Software-Clients gleichzeitig ausführen – einen Execution-Layer-Client und einen Consensus-Layer-Client.
Schritt eins: Der Bellatrix-Hard-Fork
Zunächst führt Ethereums Consensus Layer einen Hard Fork namens Bellatrix aus. Bellatrix führt auf der Consensus Layer eine neue Beacon-Chain-Blockstruktur ein, um Blöcke aufzunehmen, die Execution-Layer-Transaktionen tragen. Außerdem ist eine Reihe von Anweisungen eingebaut, damit Consensus-Layer-Knoten erst dann damit beginnen, Execution-Layer-Transaktionen in Beacon-Blöcke zu packen, wenn die Execution Layer eine bestimmte „Terminal Total Difficulty“ (TTD) erreicht. Alle Consensus-Layer-Knoten müssen vor einer festgelegten Slot-Höhe (entspricht der Blockhöhe auf der PoW-Chain) auf Bellatrix aktualisieren. Nach Abschluss von Bellatrix beginnen die Consensus-Layer-Knoten, die TTD zu überwachen.
Zentrales Design: Warum TTD statt Blockhöhe verwenden
Terminal Total Difficulty misst die kumulative Mining-Schwierigkeit von Ethereums Execution Layer. „Schwierigkeit“ bezieht sich hier darauf, wie schwer es für Miner ist, einen neuen Block an die Blockchain anzuhängen, und gibt an, wie viele Kombinationen Miner typischerweise ausprobieren müssen, um den korrekten Hash zu finden, der den nächsten Block erzeugt. Mit wachsender Rechenleistung (Hashrate), die Miner beitragen, steigt die Schwierigkeit automatisch. TTD ist die Summe der Mining-Schwierigkeit aller Blöcke in Ethereums Geschichte.
Historisch stützten sich Aktivierungen von Execution-Layer-Hard-Forken nie auf eine bestimmte TTD, sondern auf eine vorab festgelegte Blockhöhe. Der Merge gab diesen Ansatz wegen der Möglichkeit eines „Fast-Fork“-Angriffs auf: Ein Angreifer könnte mit einer Minderheit an Hashleistung die Execution Layer forken und schneller als die Hauptchain bis zur angegebenen Blocknummer minen. Wenn dies geschähe, könnte der Consensus Layer fälschlicherweise den Merge mit der Minderheitschain des Angreifers statt mit der Hauptchain abschließen. Daher entschieden sich die Entwickler, TTD als Schwellenwert für die Auslösung des Merge zu verwenden, weil es für böswillige Akteure viel schwieriger zu manipulieren ist.
Aber die Verwendung von TTD als Schwellenwert hat auch einen Preis: TTD ist ein extrem schwer vorherzusagender Wert, was auch die Vorhersage des Zeitpunkts der Merge-Aktivierung nach Bellatrix heikel und unpräzise macht. Diese Konsequenz zeigte sich, als Kernentwickler erstmals versuchten, den Merge im Ropsten-Testnetz zu aktivieren – die ursprüngliche TTD-Einstellung war ungenau, wodurch die Aktivierungszeit von den Erwartungen abwich.
Schritt zwei und Schritt drei: Paris und der Wechsel der Ausführungsschicht
Wenn die Ausführungsschicht den TTD-Schwellenwert erreicht, werden zwei Upgrade-Vorschläge für die Ausführungsschicht ausgelöst, von denen einer EIP-4399 ist: Es ändert die Art und Weise, wie On-Chain-Zufälligkeit erzeugt wird, und verlässt sich nicht mehr auf die Mining-Schwierigkeit, um zufällige Ganzzahlen für dApps zu erzeugen. Beide EIPs werden gleichzeitig in dem Moment aktiviert, in dem der TTD erreicht wird. Gleichzeitig beginnen auch die Knoten der Konsensschicht, die auf diesen TTD-Wert gewartet und ihn überwacht haben, ab diesem Moment mit der Verarbeitung von Transaktionen aus der Ausführungsschicht.
Das Tempo der Client-Veröffentlichungen und der Kommunikation mit den Stakeholdern muss betont werden. Zur Vorbereitung auf den Bellatrix-Hard-Fork wird die Ethereum Foundation voraussichtlich mehrere Wochen im Voraus einen Blogbeitrag veröffentlichen, in dem die Client-Versionen aufgeführt sind, die den Upgrades Paris und Bellatrix entsprechen, damit Knotenbetreiber sie im Voraus herunterladen können. Diese ersten Versionen werden mit einem ungewöhnlich großen TTD-Wert als Platzhalter gefüllt. Da Bellatrix bei einer bestimmten Slot-Höhe aktiviert wird, werden auch Datum und geschätzte Uhrzeit dieses Upgrades den relevanten Parteien mitgeteilt.
Nach Abschluss von Bellatrix wird der neue TTD-Wert den Knotenbetreibern erneut über einen zweiten Blogbeitrag mitgeteilt. Diesmal ist kein vollständiges Upgrade der Clients der Konsensschicht oder der Ausführungsschicht erforderlich; mindestens muss nur eine Codezeile zu jedem der beiden Client-Typen hinzugefügt werden, um den vorherigen TTD-Wert manuell zu überschreiben. Zu diesem Zeitpunkt können auch optionale Client-Upgrades angeboten werden, aber das ist eine Entscheidung jedes einzelnen Client-Teams und keineswegs eine obligatorische Veröffentlichung, die erforderlich ist, um die letzte Phase der Merge zu befolgen.
Nachdem der TTD-Überschreibungswert angekündigt wurde, beginnt die Phase des Wartens auf das Erreichen des neuen Schwellenwerts. Obwohl es grobe Zeitschätzungen geben wird, können das genaue Datum und die genaue Uhrzeit der Aktivierung von Paris nicht im Voraus genau bekannt sein.
Ausführungsrisiken, die nicht ignoriert werden können
1. Das operationelle Vakuum durch unvorhersehbare Zeitpunkte
Die Unfähigkeit, den TTD genau vorherzusagen, bedeutet, dass alle Dienste, die auf Ethereum angewiesen sind, den genauen Zeitpunkt des „Moments der Merge“ nicht im Voraus festlegen können. Für Unternehmen, die Ein- und Auszahlungen pausieren oder einfrieren müssen, stellt dies eine echte operationelle Herausforderung dar.
2. Der operationelle Druck der Dual-Client-Architektur
Nach der Merge müssen Knotenbetreiber gleichzeitig Clients der Ausführungsschicht und der Konsensschicht betreiben, und jede Fehlkonfiguration oder Versionsinkongruenz auf einer der beiden Seiten könnte dazu führen, dass ein Knoten zurückfällt. Frühe Probeläufe in Testnetzen (Sepolia, Goerli) werden daher entscheidend.
3. Eine grundlegende Veränderung der Blockproduktion und der Finalitätslogik
Nach der Merge werden Blöcke nicht mehr in Einheiten der Blockhöhe finalisiert, sondern in Einheiten von Slots und Epochen. Validatoren verarbeiten alle 12 Sekunden einen Slot, und 32 Slots bilden eine Epoche, d. h. eine Epoche alle 6,4 Minuten. Transaktionen auf der Beacon Chain erreichen nach 2 Epochen, etwa 12,8 Minuten, Finalität. Für Börsen, DEXs und andere DeFi-Anwendungen, die auf unterschiedlichen Annahmen über Transaktionsfinalität und Bestätigungsgeschwindigkeit aufbauen, müssen diese bevorstehenden Änderungen im Voraus antizipiert und vorbereitet werden, um Dienstunterbrechungen oder Ausnutzungen zu vermeiden.
Fazit: Geringe Wahrscheinlichkeit, große Auswirkung
Ethereums Übergang von PoW zu PoS ist das am genauesten beobachtete und am weitesten reichende Layer-1-Blockchain-Upgrade in der Geschichte der Kryptowährungen; noch nie zuvor hat ein Netzwerk vergleichbarer Größe und Bedeutung wie Ethereum eine so drastische Veränderung durchgemacht. Da die Entwickler enorm viel in Tests und Vorbereitung investiert haben, ist die Wahrscheinlichkeit, dass die oben genannten Risiken Benutzer und dApps schwer beeinträchtigen, nicht hoch; aber wenn eines der in diesem Artikel beschriebenen Szenarien eintritt, und sei es nur in dem Maße, dass das Netzwerk das Upgrade durch einen Notfall-Hard-Fork zurückrollen muss, könnten Ethereums Wert und Ruf als Allzweck-Blockchain beschädigt werden.
Daher sollten sich alle Stakeholder dieser Risiken bewusst sein und Maßnahmen ergreifen, um die Auswirkungen potenzieller Probleme auf ihre eigene Nutzung des Netzwerks abzumildern, beispielsweise indem sie Einzahlungen und Auszahlungen während kritischer Zeitfenster, in denen Unterbrechungen auftreten können, pausieren oder einfrieren. Gleichzeitig sollten Validatoren, dApps und Dienstanbieter sich vorbereiten, indem sie an nachfolgenden Aktivierungsproben auf den Sepolia- und Goerli-Testnetzen teilnehmen, die sowohl sicherstellen können, dass Knotenbetreiber bewährte Verfahren zur Befolgung des Merge-Upgrades beherrschen, als auch Probleme im Prozess vor der Mainnet-Aktivierung aufdecken. Darüber hinaus ist die Wachsamkeit der Ethereum Foundation, der Client-Teams und vertrauenswürdiger Medien gegenüber Fehlinformationen im Zusammenhang mit dem Merge während der Aktivierung besonders kritisch – einschließlich falscher TTD-Werte, falscher Client-Versionen, falscher Zeitplanerwartungen und falscher Betriebsanleitungen – und sie müssen sich schnell koordinieren, um die relevanten Parteien klar darüber zu informieren, worauf sie als Nächstes vorbereiten müssen, bis das Merge-Upgrade vollständig abgeschlossen ist.
