Ankündigung der Mainnet-Zusammenführung

• Ethereum geht demnächst in Proof-of-Stake (dt. etwa „Anspruchsnachweis“) über! Der Übergang, bezeichnet als „The Merge“, die Zusammenführung, muss zuerst mit dem Bellatrix-Upgrade auf der Beacon Chain aktiviert werden. Sobald dann ein bestimmter Total Difficulty-Wert erreicht ist, geht die Proof-of-Work-Kette in Proof-of-Stake über.
• Das Bellatrix-Upgrade in der Beacon-Chain ist für die Epoche 144896 geplant und wird für den 6. September 2022 um 11:34:47 Uhr UTC erwartet.
• Der Terminal Total Difficulty-Wert, durch den die Zusammenführung ausgelöst wird, wurde mit 58750000000000000000000 festgelegt. Dieser Wert wird voraussichtlich zwischen dem 10. und 20. September 2022 erreicht.
• Hinweis: Wie bereits angekündigt hat, wird das Kiln-Testnet aktuell stillgelegt. Am 6. September 2022 werden die Betreiber geschlossen.

Hintergrund

Nach Jahren harter Arbeit ist Ethereums Proof-Stop-Upgrade endlich da! Die erfolgreiche Aktualisierung aller öffentlichen Testnetze ist nun abgeschlossen und The Merge wurde für das Ethereum mainnet geplant.

Die Zusammenführung unterscheidet sich in zwei Aspekten von früheren Ethereum-Upgrades. Zum einen müssen Node-Betreiber ihre Clients sowohl auf Konsensebene (CL) als auch auf Ausführungsebene (EL) gleichzeitig aktualisieren, also nicht nur jeweils die Clients einer der beiden Ebenen. Zum anderen wird das Upgrade in zwei Phasen aktiviert: Die erste Phase, genannt Bellatrix, erfolgt auf einer Epochenhöhe der Beacon Chain und die zweite, genannt Paris, sobald auf Ausführungsebene ein bestimmter Total Difficulty-Wert erreicht ist.

Informationen zum Upgrade

Zeitplan

Die Zusammenführung ist ein zweistufiger Prozess. In einem ersten Schritt erfolgt ein Netzwerkupgrade (Bellatrix) auf Konsensebene, ausgelöst durch eine Epochenhöhe. Anschließend erfolgt die Umstellung der Ausführungsebene von Proof-of-Work zu Proof-of-Stake (Paris), ausgelöst durch einen bestimmten Total Difficulty-Wert, die sogenannte Terminal Total Difficulty (TTD).

Das Bellatrix-Upgrade in der Beacon-Chain ist für die Epoche 144896 geplant und wird für den 6. September 2022 um 11:34:47 Uhr UTC erwartet.

Paris, die Umstellung auf Ausführungsebene, wird durch die Terminal Total Difficulty (TTD) von 58750000000000000000000 auf der Ausführungsebene ausgelöst und soll zwischen dem 10. und 20. September 2022 erfolgen. Das genaue Datum, an dem TTD erreicht wird, hängt von der Proof-of-Work-Hashrate ab. Schätzungen für den Übergang finden Sie unter bordel.wtf und 797.io/themerge.

Nach Erreichen oder Überschreitung der TTD auf Ausführungsebene wird der spätere Block durch einen Beacon Chain-Validator erzeugt. Der Übergang zum Zusammenführen wird als abgeschlossen betrachtet, sobald die Beacon Chain diesen Block fertigstellt. Unter normalen Netzwerkbedingungen wird dies zwei Epochen bzw. etwa 13 Minuten nach der Erzeugung des ersten Blocks nach Erreichen der TTD der Fall sein!

Das neu eingeführte JSON-RPC-Block-Tag finalized gibt den zuletzt fertiggestellten Block bzw. einen Fehler zurück, wenn nach der Zusammenführung kein solcher Block erzeugt wurde. Mit diesem Tag lässt sich für Anwendungen prüfen, ob die Zusammenführung abgeschlossen ist. Ebenso können Smart Contracts den Opcode DIFFICULTY (0x44) abfragen (der nach der Zusammenführung in PREVRANDAO umbenannt wurde), um festzustellen, ob die Zusammenführung abgeschlossen ist. Wir empfehlen Infrastrukturanbietern, zusätzlich zum Finalisierungsstatus auch die Stabilität des Netzwerks insgesamt zu überwachen.

Client-Versionen

Die folgenden Client-Versionen unterstützen die Zusammenführung des Ethereum Mainnet. Node-Betreiber müssen sowohl einen Client auf Ausführungsebene als auch auf Konsensebene ausführen, um während und nach der Zusammenführung im Netzwerk zu bleiben.

Bei der Auswahl des auszuführenden Clients sollten Validatoren insbesondere die Risiken berücksichtigen, die die Ausführung eines Majority-Clients sowohl auf der Ausführungsebene (EL) als auch auf der Konsensebene (CL) mit sich bringt. Eine Erläuterung der Risiken und Folgen finden Sie hier. Eine Schätzung der aktuellen EL- und CL-Client-Verteilung sowie Leitfäden für den Wechsel von einem Client zu einem anderen finden Sie hier.

Konsensebene

Ausführungsebene

Warnung: geth version v1.10. 2 enthält ein kritisches Datenbankproblem, verwenden Sie diese Version nicht, und wenn Sie bereits aktualisiert haben, aktualisieren Sie so schnell wie möglich auf v1.10.23.

Upgrade-Spezifikationen

Konsenskritische Änderungen für die Zusammenführung werden an zwei Stellen angegeben:

• Änderungen auf Konsensebene im Ordner Bellatrix des Repositorys der Konsensspezifikationen
• Änderungen auf Ausführungsebene in der Spezifikation Paris im Repository der Ausführungsspezifikationen

Zwei weitere Spezifikationen legen darüber hinaus die Interaktion der Clients auf Konsens- und Ausführungsebene fest:

• Die im Repository für Ausführungs-APIs angegebene Engine-API steuert die Kommunikation zwischen der Konsens- und Ausführungsebene
• Optimistic Sync, angegeben im Ordner sync des Repositorys für Konsensspezifikationen, steuert den Blockimport auf Konsensebene während der Client-Synchronisierung auf Ausführungsebene. Zudem bietet es eine teilweise Ansicht des Chain-Heads, von der ersteren zur letzteren Ebene.

Kopfgeld für das Aufdecken von Fehlern zusammenführen

Alle auf die Zusammenführung bezogenen Kopfgelder für Vulnerabilitäten haben von heute bis zum 8. September einen 4x Multiplikator erhalten. Kritische Fehler sind jetzt bis zu $1 Million USD wert.

Siehe Bug Bounty Programm für weitere Details.

Häufig gestellte Fragen

Was muss ich als Node-Betreiber tun?

Nach der Zusammenführung ist ein vollständiger Ethereum-Node die Kombination aus einem Client auf Konsensebene (CL), der den Proof-of-Stake auf der Beacon Chain durchführt, und einem Client auf Ausführungsebene (EL), der die Benutzerstatus verwaltet und die Verarbeitung von Transaktionen durchführt. Die Kommunikation des EL- und CL-Clients erfolgt über einen authentifizierten Port mittels eines neuen Satzes an JSON RPC-Methoden, die sogenannte Engine-API. Der EL- und der CL-Client authentifizieren sich gegenseitig mit einem JWT-Geheimnis. Informationen zur Erstellung und Konfiguration dieses Werts finden Node-Betreiber in der Dokumentation ihrer Clients.

Wenn Sie also bereits einen Node auf der Beacon Chain ausführen, müssen Sie nun zusätzlich einen Client auf der Ausführungsebene betreiben. Ähnlich verhält es sich, wenn Sie einen Node im aktuellen Proof-of-Work-Netzwerk ausführen. Dann müssen Sie nun auch einen Client auf Konsensebene betreiben. Damit diese Clients sicher miteinander kommunizieren können, muss an beide Clients ein JWT-Token übergeben werden. Die einzelnen Schritte werden auf der Website ethereum.org in einer Neufassung des Abschnitts „Ausführung eines Knotens“ ausführlich beschrieben.

Bitte beachten Sie, dass sich die Ausführung eines Beacon Node von der Ausführung eines Validator-Clients unterscheidet, obwohl beide Teile der Client-Versionen auf Konsensebene sind. Staker müssen beide Komponenten ausführen, Node-Operatoren hingegen nur den Beacon Node. Eine ausführliche Beschreibung der Unterschiede zwischen beiden Komponenten finden Sie hier.

Beachten Sie außerdem, dass auf beiden Ebenen ein eigener Peer-Satz geführt wird und jeweils eigene APIs verwendet werden. Die Beacon- und JSON RPC-APIs funktionieren weiterhin wie gewohnt.

Was muss ich als Staker tun?

Wie erläutert müssen Validatoren auf der Beacon Chain nach der Zusammenführung einen Client auf Ausführungsebene ausführen, und zwar zusätzlich zu den Clients auf Konsensebene. Diese Praxis wurde bereits vor der Zusammenführung dringend empfohlen, jedoch haben einige Validatoren diese Funktionen auch an Drittanbieter ausgelagert. Dies war möglich, weil die einzigen auf Ausführungsebene erforderlichen Daten Aktualisierungen am Einlagenvertrag waren.

Nach der Zusammenführung müssen Validatoren sicherstellen, dass die Benutzertransaktionen und Statusübergänge in den von ihnen erstellten und bescheinigten Blöcken gültig sind. Hierzu muss jeder Beacon-Node mit einem Client auf Ausführungsebene gekoppelt werden. Nach wie vor ist es jedoch möglich, mehrere Validatoren mit einer einzigen Kombination aus Beacon Node und Client auf Ausführungsebene zu koppeln. Validatoren erhalten dadurch mehr Verantwortung für die von ihnen vorgeschlagenen Blöcke, jedoch auch Anspruch auf Transaktionsprioritätsgebühren, die derzeit noch Minern zustehen.

Validatorprämien sammeln sich nach wie vor auf der Beacon Chain an und können erst nach einem Upgrade entnommen werden, wohingegen Transaktionsgebühren auf Ausführungsebene bezahlt, verbraucht und verteilt werden. Validatoren können jede beliebige Ethereum-Adresse als Empfänger für Transaktionsgebühren angeben.

Geben Sie nach der Aktualisierung Ihres Clients auf Konsensebene im Zuge der Konfiguration Ihres Validator-Clients in fee recipient eine von Ihnen kontrollierte Adresse an, an die Ihre Transaktionsgebühren gesendet werden sollen. Wenn Ihr Staking über einen Drittanbieter erfolgt, entscheidet Ihr Provider, wie diese Gebühren verrechnet werden.

Im Staking-Launchpad finden Sie eine Checkliste für die Bereitschaft für die Zusammenführung, anhand derer Sie als Staker überprüfen können, ob Sie alle erforderlichen Prozessschritte abgeschlossen haben. Auf EthStaker wurden zu diesem Thema bereits Workshops zur Vorbereitung von Validatoren durchgeführt und es werden noch weitere folgen.

Staker, die zur Vorbereitung der Umstellung des Mainnet auf Proof-of-Stake einen Validator in einem Testnetz ausführen möchten, können dies im nunmehr mit Prater zusammengeführten Goerli machen, das ebenfalls eine Instanz des Staking-Launchpad bereitstellt.

Warum lässt sich das geschätzte Datum, an dem die Terminal Total Difficulty erreicht wird, nicht genauer festlegen?

Die pro Block hinzugefügte inkrementelle Difficulty ist von der Netzwerk-Hashrate abhängig. Diese ist aber volatil. Je höher die Hashrate im Netzwerk ist, desto früher wird der TTD-Wert erreicht. Umgekehrt wird der TTD-Wert später erreicht, wenn die Hashrate geringer ausfällt. Im Falle eines signifikanten Rückgangs der Hashrate kann – wie schon bei Ropsten – ein TTD Override koordiniert werden.

Was muss ich als Anwendungs- oder Toolentwickler tun?

Wie bereits in einem früheren Beitrag erwähnt hat die Zusammenführung eine nur geringe Auswirkung auf wenige der unter Ethereum bereitgestellten Verträge, wobei keiner davon in seiner Funktionsweise beeinträchtigt sein sollte. Der größte Teil der API-Endpunkte der Benutzer sollte zudem stabil bleiben, zumindest, wenn Sie keine Proof-of-Work-spezifischen Methoden wie zum Beispiel eth_getWork nutzen.

Jedoch umfassen die meisten Anwendungen auf Ethereum mehr als nur On-Chain-Verträge. Daher ist dies ein guter Zeitpunkt, zu überprüfen, ob Ihr Front-End-Code, Ihre Tools, die Bereitstellungspipeline und weitere Off-Chain-Komponenten erwartungsgemäß funktionieren. Aus diesem Grund empfehlen wir Entwicklern die Durchführung eines vollständigen Test- und Bereitstellungszyklus auf Sepolia oder Goerli sowie die Zurückmeldung aller Probleme mit Tools oder Abhängigkeiten an die Projektverantwortlichen. Wenn Sie sich nicht sicher sind, an wen Sie Ihre Anfrage richten sollen, finden Sie in diesem Repository nähere Informationen.

Beachten Sie zudem, dass alle Testnetze, ausgenommen Sepolia und Goerli, nach der Zusammenführung stillgelegt werden. Als Benutzer von Ropsten, Rinkeby oder Kiln sollten Sie die Migration auf Goerli oder Sepolia planen. Weitere Informationen finden Sie hier.

Muss ich als Ethereum-Benutzer oder Ether-Inhaber Umstellungen vornehmen?

Ganz gleich, ob Sie Ethereum-Anwendungen on-chain verwenden oder in einer Exchange oder selbstverwalteten Wallet Ether-Anteile halten – Sie müssen nichts ändern. Falls Sie von einer von Ihnen genutzten Anwendung, Exchange oder Wallet diesbezüglich Anweisungen oder Empfehlungen erhalten, sollten Sie unbedingt überprüfen, ob diese tatsächlich vom behaupteten Herausgeber stammen. Seien Sie hellhörig! Dahinter könnten sich auch betrügerische Absichten verbergen.

Muss ich als Miner Umstellungen vornehmen?

Nein. Wenn Sie Miner im Ethereum-Mainnet sind, sollte Ihnen bewusst sein, dass das Netzwerk nach der Zusammenführung vollständig im Proof-of-Stake-Modus arbeitet. Ab diesem Zeitpunkt ist Mining im Netzwerk nicht mehr möglich.

Was passiert, wenn ich als Miner oder Node-Betreiber die Umstellung nicht durchführe?

Wenn Sie einen der oben aufgeführten Ethereum-Clients verwenden und dieser nicht auf die neueste Version aktualisiert wurde, wird Ihr Client nach dem Upgrade auf die Pre-Fork-Blockchain synchronisiert.

Sie arbeiten dann mit einer inkompatiblen Chain, die den alten Regeln folgt, und können keine Ether versenden oder Ihre Dienste im Post-Merge-Ethereum Netzwerk betreiben.

Kann ich als Validator meinen Einsatz zurückziehen?

Nein. Die Zusammenführung ist das bislang komplizierteste Upgrade von Ethereum. Um das Risiko von Netzwerkunterbrechungen zu minimieren, wurde ein minimaler Ansatz gewählt. Daher sind Änderungen, die nicht mit der Umstellung in Verbindung stehen, von diesem Upgrade ausgeschlossen.

Die Möglichkeit der Entnahme von Einsätzen aus der Beacon Chain wird voraussichtlich mit dem ersten Upgrade nach der Zusammenführung eingeführt. Spezifikationen sowohl für die Konsens- als auch die Ausführungsebene werden derzeit ausgearbeitet.

Ich habe weitere Fragen. An wen kann ich mich damit wenden?

Schließen Sie sich den Client-Team-Entwicklern, Mitgliedern von ETHStaker, Forschern und anderen beim nächsten Merge Community Call am Freitag, den 9. September um 14:00 UTC an!

Vielen Dank

Der Übergang von Ethereum zu Proof-of-Stake ist gut vorbereitet und wird schon seit langem erwartet. Es ist uns ein großes Anliegen, uns bei allen zu bedanken, die durch Nachforschungen, Spezifikationen, Entwicklungen, Analysen, Tests, Aufspüren von Fehlern und deren Korrekturen und die vielen Beschreibungen auch der kleinsten Details dazu beigetragen haben, dass die Zusammenführung Realität wird.

Es gab zu jeder Zeit einfach zu viele fantastische Mitwirkende, um sie hier alle aufzuführen. Aber jeder von Ihnen weiß, dass wir auch Sie meinen und Ihnen unseren Dank aussprechen. Ohne Ihre engagierte Hilfe hätten wir diese Kathedrale nicht errichtet.

Wann erfolgt die Zusammenführung? Sehr bald 🔜.

Vielen Dank an Joseph Schweitzer und Tomo Saito für das Titelbild dieses Beitrags!