Ankündigung der Goerli/Prater-Zusammenführung

• Im Zuge der letzten Proof-of-Stake-Umstellung des Testnetzes wird Goerli mit Prater zusammengeführt. Die beiden Netzwerke fusionieren unter dem Namen Goerli.
• Prater wird durch das Upgrade Bellatrix auf die Zusammenführung vorbereitet. Dieses Uprade erfolgt in der Epoche 112260 nach derzeitiger Erwartung am 4. August 2022 um 12:24 Uhr UTC.
• Nach der Aktivierung von Bellatrix erfolgt die Zusammenführung von Goerli und Prater, sobald Goerli vermutlich zwischen dem 6. und 12. August 2022 einen Total Difficulty-Wert von 10790000 erreicht.
• Nach der Zusammenführung bleibt Goerlis Validator-Set für die Ausführung von Testnetz-Validatoren für einzelne Staker offen. Staker können Goerli/Prater-Validatoren über das Prater-Launchpad starten.

Hintergrund

Nach jahrelanger Arbeit am Proof-of-Stake für Ethereum haben wir die letzte Testphase erreicht: die Bereitstellung von Testnetzen.

Nach mehreren Devnets, Shadow Forks und Zusammenführungen in veralteten Testnetzen wurde Sepolia kürzlich auf Proof-of-Stake umgestellt. Jetzt verbleibt nur noch ein Testnetz: Goerli und die zugehörige Beacon Chain Prater.

Die Zusammenführung unterscheidet sich in zwei Merkmalen 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. Als Erstes 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 auf der Beacon Chain Prater ist für Epoche 112260 geplant, nach derzeitiger Erwartung am 4. August 2022 um 12:24 Uhr UTC. Paris, die Umstellung auf Ausführungsebene, wird durch Erreichen einer Terminal Total Difficulty (TTD) von 10790000 auf Goerli ausgelöst, erwartet zwischen dem 6. und 12. August 2022.

Nach Überschreiten der TTD auf Ausführungsebene wird der nächste Block vollständig durch einem Beacon Chain-Validator erzeugt. Die Zusammenführung wird als abgeschlossen betrachtet, sobald die Beacon Chain diesen Block fertiggestellt hat. Unter normalen Netzwerkbedingungen sollte die Erstellung des ersten Blocks nach Erreichen der TTD zwei Epochen bzw. etwa 13 Minuten dauern.

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 vorhanden ist. Anhand dieses Tags lässt sich für Anwendungen prüfen, ob die Zusammenführung abgeschlosen 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 gesamte Netzwerkstabilität zu überwachen.

Client-Versionen

Die folgenden Client-Versionen unterstützen die Zusammenführung der Goerli- und Prater-Testnetze. 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

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 wird für die Kommunikation zwischen der Konsens- und Ausführungsebene genutzt.
• Optimistic Sync, angegeben im Ordner sync des Repositorys der Konsensspezifikationen, wird von der Konsensebene zum Importieren von Blöcken bei der Synchronisierung der Clients auf Ausführungsebene verwendet. Zudem bietet es eine teilweise Ansicht des Chain-Heads, vom ersten zum letzten.

Häufig gestellte Fragen

Was muss ich als Node-Betreiber machen?

Nach der Zusammenführung führt ein vollständiger Ethereum-Node einen Client auf Konsensebene (CL), der den Proof-of-Stake auf der Beacon Chain durchführt, mit einem Client auf Ausführungsebene (EL) zusammen, der die Benutzerstatus verwaltet und die Verarbeitung von Transaktionen durchführt. Die Kommunikation 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 Client-Erstellung und -Konfiguration 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. Eine Zusammenfassung der Anweisungen zur Ausführung eines Node im Goerli/Prater-Netzwerk finden Sie hier.

Wir möchten betonen, 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. In diesem Beitrag werden die Unterschiede zwischen den beiden Komponenten ausführlicher erläutert.

Beachten Sie außerdem, dass für beide Ebenen ein eigener Peer-Satz verwaltet werden muss und eigene APIs erforderlich sind. Die Beacon- und JSON RPC-APIs funktionieren weiterhin erwartungsgemäß.

Was muss ich als Staker machen?

Die Goerli/Prater-Zusammenführung ist Ihre letzte Gelegenheit vor der Umstellung des Mainnet sicherzustellen, dass Ihre Validatoren korrekt konfiguriert sind. Das Durchlaufen der Umstellung wird dringend empfohlen, um unerwartete Probleme im Mainnet zu vermeiden.

Wie bereits 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 konnten Validatoren diese Funktionen auch an Drittanbieter auslagern. Das war möglich, da die einzigen auf der Ausführungsebene erforderlichen Daten Aktualisierungen am Einlagenvertrag waren.

Nach der Zusammenführung müssen Validatoren sicherstellen, dass die Transaktionen 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 zwar mehr Verantwortung, für die von ihnen vorgeschlagenen Blöcke jedoch auch Anspruch auf Transaktionsprioritätsgebühren, die bislang Minern zustehen.

Validatorprämien sammeln sich auf der Beacon Chain an und können erst nach einem Upgrade entnommen werden, während Transaktionsgebühren weiterhin auf der 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 von Prater finden Sie eine Checkliste für die Bereitschaft für die Zusammenführung, anhand der Sie als Staker überprüfen können, ob Sie alle erforderlichen Prozessschritte abgeschlossen haben. Darüber hinaus bietet das EthStaker-Team am 29. Juli 2022 einen Workshop für Validatoren zur Vorbereitung auf die Zusammenführung an.

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

Gegenüber Block- oder Epochenhöhen erschwert die Volatilität der inkrementellen Schwierigkeit pro Block die Einschätzung des voraussichtlichen TTD-Fensters erheblich. Daher lässt sich der erwartete Zeitraum nicht enger eingrenzen. Für Benutzer gilt zu beachten, dass dies aufgrund der Hash-Ratenschwankungen in Proof-of-Work auch auf die Umstellung des Mainnet zutrifft.

Was muss ich als Anwendungs- oder Toolentwickler machen?

Nach der Live-Schaltung der Zusammenführung auf Goerli haben Sie ein letztes Mal die Gelegenheit, im Zuge der Proof-of-Stake-Umstellung sowie im Kontext nach der Zusammenführung sicherzustellen, dass Ihr Produkt erwartungsgemäß funktioniert. Wie bereits in einem früheren Beitrag erwähnt, hat die Zusammenführung nur minimale 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. Wir empfehlen Entwicklern daher die Durchführung eines vollständigen Test- und Bereitstellungszyklus auf Sepolia, Ropsten oder Kiln 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?

Nein. Das Ethereum-Mainnet ist von diesem Testnetz nicht betroffen. Vor der Umstellung des Mainnets erfolgen in diesem Blog entsprechende Ankündigungen.

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 dem Zeitpunkt der Umstellung wird Mining im Netzwerk nicht mehr möglich sein.

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. Dabei sind Änderungen, die nicht mit der Umstellung zusammenhängen, 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 diese richten?

Die EthStaker-Community hat einen Discord-Kanal eingerichtet, auf dem die Community Fragen von Stakern und Node-Betreibern beantwortet. Dem Discord der Community können Sie hier beitreten und bei Fragen zum Kanal #goerli-prater wechseln. Wie bereits erwähnt, bietet EthStaker am 29. Juli 2022 auch einen Workshop für Validatoren zur Vorbereitung auf die Zusammenführung an.

Für den 12. August, 14:00 UTC, ist darüber hinaus ein Community Call zur Zusammenführung geplant. Hier werden Client-Entwickler und -Wissenschaftler Fragen von Node-Betreibern, Stakern, Infrastruktur- und Toolanbietern sowie Community-Mitgliedern beantworten. Dieser Community Call wird voraussichtlich jedoch nach der Goerli/Prater-Zusammenführung stattfinden.

Wann erfolgt die Zusammenführung?

Zum Zeitpunkt der Veröffentlichung dieses Beitrags war das Umstellungsdatum auf Proof-of-Stake für das Ethereum-Mainnet noch nicht festgelegt. Jede andere Behauptung ist falsch. Verlässliche Neuigkeiten erhalten Sie in diesem Blog. Halten Sie sich hier informiert!

Sofern bei der Goerli/Sepolia-Zusammenführung keine Probleme auftreten und sobald Client-Versionen mit stabilen Funktionen vorliegen, werden auf der Beacon Chain eine Slot-Höhe für das Bellatrix-Upgrade sowie für die Umstellung des Mainnets die Terminal Total Difficulty festgelegt. Für die Clients werden dann Versionen veröffentlicht, die die Zusammenführung auch im Mainnet unterstützen. Eine entsprechende Ankündigung erfolgt in diesem Blog und in weiteren Community-Publikationen.

Falls jedoch an irgendeiner Stelle während dieses Prozesses Probleme auftreten oder die Testabdeckung als unzureichend eingeschätzt wird, wird der Bereitstellungsprozess erst fortgesetzt, wenn die erkannten Probleme behoben sind.

Erst dann kann das genaue Datum der Zusammenführung bestimmt werden.

Mit anderen Worten: 🔜.