Ropsten – Zusammenführungsankündigung

• Ropsten ist das erste bewährte Testnet, das die Zusammenführung durchläuft
• Am 30. Mai 2022 wurde eine neue Ropsten-Beacon Chain eingeführt, mit dem Ziel, Konsens für das Netzwerk bereitzustellen
• Anschließend erfolgt ein Upgrade für die Ropsten-Beacon Chain auf Protokollregeln, die kompatibel mit der Zusammenführung sind (Bellatrix), im Slot 24000, geplant für den 2. Juni 2022
• Danach wird eine Terminal Total Difficulty (TTD) gewählt, um die Zusammenführung auf der Proof-of-Work-Kette zu aktivieren. Knotenbetreiber müssen diesen Wert manuell auf ihren Clients einstellen.
• Eine weitere Ankündigung mit der genauen Terminal Total Difficulty für die Ropsten-Zusammenführung wird am 3. Juni 2022 in diesem Blog veröffentlicht. Benutzer sollten damit rechnen, dass dieser TTD-Wert wenige Tage, nachdem er gewählt wurde, erreicht wird, und sollten bereit sein, um ihre Clients kurzfristig entsprechend zu konfigurieren.

Hintergrund

Nach jahrelanger Arbeit, um Proof of Stake für Ethereum einzuführen, haben wir die letzte Testphase erreicht: die Bereitstellung von Testnets.

Nach den Tests von Client-Implementierungen auf Kintsugi 🍵, Kiln 🔥🧱 und mehreren Shadow Forks sind wir nun bereit, über die Zusammenführung Ropsten auszuführen, das einzige Proof-of-Work-Testnet. Um das Netzwerk auf diesen Schritt vorzubereiten, wird eine Ropsten-Beacon Chain eingeführt, um Konsens für das Netzwerk bereitzustellen.

Sofern der Übergang für Ropsten reibungslos läuft, werden zwei weitere Testnets (Goerli und Sepolia) zu Proof of Stake überführt, bevor die Vorbereitungen für das Mainnet beginnen. Weitere Testnets wie Rinkeby und Kovan werden möglicherweise von der Community separat betreut und aktualisiert, nicht mehr jedoch von Client-Entwicklern überwacht.

Die Zusammenführung unterscheidet sich in zwei Merkmalen von früheren Ethereum-Upgrades. Zum einen müssen Node-Operatoren sowohl ihre Konsensebene als auch ihre Ausführungsebene parallel aktualisieren, und nicht mehr nur eine der beiden. Zum anderen wird das Upgrade in zwei Phasen aktiviert: Die erste Phase erfolgt auf Slot-Höhe der Beacon Chain und die zweite, wenn ein Total Difficulty-Wert in der Ausführungsebene erreicht ist.

Daher wird das Ropsten-Netzwerk, das nach der Zusammenführung verworfen werden wird, über das Upgrade ausgeführt, das für einen früheren Zeitpunkt im Entwicklungsprozess als vorherige Netzwerkupgrades geplant ist. Damit hat die Community mehr Zeit, um sich mit dem Upgradeprozess vertraut zu machen.

Hinweis: Die unten aufgeführten Client-Versionen sind für den Übergang des Ethereum-Mainnets auf Proof of Stake nicht geeignet.

Informationen zum Upgrade

Zeitplan

Die Zusammenführung ist ein zweistufiger Prozess. Als Erstes erfolgt ein Netzwerkupgrade auf der Konsensebene, ausgelöst durch eine Slot-Höhe. Anschließend erfolgt der Übergang der Ausführungsebene von Proof of Work zu Proof of Stake, ausgelöst durch einen bestimmten Total Difficulty-Schwellenwert, die sogenannte Terminal Total Difficulty (TTD).

Am 2. Juni 2022 erfolgt bei Slot 24000 das Bellatrix-Upgrade als Vorbereitung der Ropsten-Beacon Chain für die Zusammenführung. Zu diesem Zeitpunkt beginnen die CL-Clients damit, auf einen TTD-Wert zu warten, der in der Proof-of-Work-Kette erreicht wird.

Da die Hash-Rate von Proof-of-Work-Testnetzen sehr volatil ist, wird der TTD-Wert zunächst auf einen sehr hohen Wert gesetzt, 100000000000000000000000. Bei der derzeitigen Hash-Rate von Ropsten würde es ca. 250 Jahre dauern, um dies zu erreichen.

Sobald das Bellatrix-Upgrade auf der Beacon Chain stattgefunden hat, wird ein neuer TTD-Wert gewählt und bekanntgegeben, der voraussichtlich einige Tage später erreicht wird. Die Benutzer müssen dann ihren Node mit diesem neuen Wert konfigurieren. Eine Anleitung dazu finden Sie hier..

Wenn dieser neue TTD in Ropsten erreicht oder überschritten wird, wird der Teil der Ausführungsebene des Übergangs gestartet, der den Codenamen Paris trägt. Noch einmal, die Hashrate auf Ropsten ist bekanntermaßen variabel. Daher ist der Zeitpunkt, zu dem die Terminal Total Difficulty erreicht wird, nicht eindeutig bestimmbar.

Sobald die Ausführungsebene die TTD überschritten hat, wird der nächste Block vollständig von einem Beacon Chain-Validator erzeugt. Die Zusammenführung wird als abgeschlossen betrachtet, sobald die Beacon Chain diesen Block fertiggestellt hat. Unter normalen Neztwerkbedingungen sollte es 2 Epochen oder etwa 13 Minuten dauern, bis der erste Post-TTD-Block bereit ist.

Ein neues JSON-RPC-Blocktag, finalized, gibt den letzten fertiggestellten Block oder einen Fehler zurück, wenn nach der Zusammenführung kein solcher Block vorhanden ist. Mit diesem Tag 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 Verschmelzung in PREVRANDAO umbenannt wurde, um festzustellen, ob die Zusammenführung stattgefunden hat. Wir empfehlen Infrastrukturanbietern, zusätzlich zum Finalisierungsstatus auch die gesamte Netzwerkstabilität zu überwachen.

Client-Versionen

Folgende Client-Versionen bieten Unterstützung für die Zusammenführung im Ropsten-Testnet. Node-Operatoren müssen botheinen Client der Ausführungs- und Konsensebene ausführen, um auch nach der Zusammenführung im Netzwerk zu verbleiben.

Wie oben erwähnt, haben die folgenden Versionen eine fest kodierte Terminal Total Difficulty von 1000000000000000000000000000, die manuell aktualisiert werden muss, nachdem das Bellatrix-Upgrade auf der Beacon Chain aktiviert wurde.

Bei der Auswahl des auszuführenden Clients sollten Validatoren besonders die Risiken berücksichtigen, die bestehen, wenn ein Mehrheits-Client sowohl auf der Ausführungsebene (EL) als auch auf der Konsensebene (CL) läuft. 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.

Hinweis: Wenn Sie zuvor eine Client-Version mit einer Ropsten TTD von 43531756765713534 heruntergeladen haben, müssen Sie entweder Ihre Version aktualisieren oder die TTD manuell auf 100000000000000000000000 überschreiben, wie hier angegeben.

Konsensebene

Lodestar-Hinweis: Die letzte Lodestar Version, v0.37.0, hat einen veralteten Ropsten TTD Wert von 43531756765713534. Um mit der Ropsten-Zusammenführung kompatibel zu sein, die jetzt eine TTD von 100000000000000000000000 verwendet, müssen Lodestar-Benutzer diesen Wert manuell überschreiben. Eine Anleitung dazu finden Sie in der Veröffentlichungsankündigung des Teams.

Ausführungsebene

Geth-Hinweis: Die neueste go-ethereum (geth)_Version, Sharblu (v1.10.18), hat einen veralteten Ropsten TTD-Wert von 43531756765713534. Um mit der Ropsten-Zusammenführung kompatibel zu sein, die jetzt eine TTD von 100000000000000000000000 verwendet, müssen geth Benutzer entweder:

• Aus der Quelle des neuesten Master-Branch programmieren
• Das neueste Docker-Image verwenden
• Die TTD manuell TTD durch den folgenden Befehl beim Start des Clients aufheben: --override.terminaltotaldifficulty 100000000000000000000000.

Upgradespezifikationen

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

• Die Änderungen an der Konsensebene unter dem Ordner bellatrix des Repositorys der Konsensspezifikationen
• Die Änderungen an der Ausführungsebene unter den Paris-Spezifikationen im Repository der Ausführungsspezifikationen

Zusätzlich dazu decken zwei weitere Spezifikationen die Interaktion der Clients auf Konsens- und Ausführungsebene ab:

• 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 Konsensspezifikation, wird von der Konsensebene zum Importieren von Blöcken bei der Synchronisierung des Ausführungsebenen-Clients verwendet. Er beitet eine teilweise Ansicht des Chain-Heads, vom ersten zum letzten.

Häufig gestellte Fragen

Was sollte ich als Node-Betreiber tun?

Nach der Zusammenführung führt ein vollständiger Ethereum-Node einen Konsensebenen-Client, der Proof of Stake auf der Beacon Chain durchführt, mit einem Ausführungsebenen-Client zusammen, der Benutzerstatus verwaltet und die Verarbeitung von Transaktionen durchführt. Die Kommunikation erfolgt über einen authentifizierten Port über einen neuen Satz aus JSON RPC-Methoden, die sogenannte Engine-API. Der EL und der CL-Client authentifizieren sich gegenseitig mit einem JWT-Geheimnis. Node-Betreiber sollten in der Dokumentation ihrer Clients nachlesen, wie diese zu erstellen und zu konfigurieren sind.

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 betreiben würden: Sie müssen einen Client auf Konsensebene ausführen. Damit sie sicher kommunizieren können, muss ein JWT-Token an jeden Client übergeben werden.

Wir möchten betonen, dass obwohl beide Teile der Client-Versionen auf Konsensebene sind, sich die Ausführung eines Beacon-Node von der Ausführung eines Validator-Clients unterscheidet. 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 jede Ebene ein eigener Satz aus Peers verwaltet werden muss und eigene APIs erforderlich sind. Die Beacon- und JSON RPC-APIs funktionieren weiterhin erwartungsgemäß.

Vergessen Sie nicht, am 6. und 7. Juni wieder vorbeizuschauen, wenn in diesem Blog der endgültige Wert des Ropsten TTD bekannt gegeben wird.

Was muss ich als Staker tun?

Wie oben bereits ausgeführt, müssen Validatoren auf der Beacon Chain nach der Zusammenführung einen Client auf der Ausführungsebene ausführen, und zwar zusätzlich zu den Clients auf der Konsensebene. Vor der Zusammenführung wurde diese Vorgehensweise bereits dringend empfohlen, doch Validatoren konnten diese Funktionen an Drittanbieter auslagern. Dies war möglich, weil die einzigen Daten, die auf der Ausführungsebene benötigt wurden, Aktualisierungen des Einlagenvertrags waren.

Nach der Zusammenführung müssen Validatoren sicherstellen, dass die Transaktionen in den von ihnen erstellten und bescheinigten Blöcken gültig sind. Dafür muss jeder Beacon-Node mit einem Client der Ausführungsebene gekoppelt werden. Hinweis: Es ist weiterhin möglich, mehrere Validatoren mit einer einzigen Kombination aus Beacon-Node und Client auf Ausführungsebene zu koppeln. Dadurch werden zwar die Aufgaben der Prüfer erweitert, aber ein Prüfer, der einen Block vorschlägt, erhält auch das Recht auf die damit verbundenen Transaktionsprioritätsgebühren (die derzeit an die Miner gehen).

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.

Nach der Aktualisierung des Konsens-Clients sollten Sie sicherstellen, dass fee recipient Teil Ihrer Validator-Client-Konfigurationen ist, damit Transaktionsgebühren auch garantiert an eine Adresse gesendet werden, die Sie kontrollieren.

Wenn Sie für das Staking mit einem Drittanbieter zusammengearbeitet haben, obliegt es Ihrem Anbieter, anzugeben, wie diese Gebühren verteilt werden.

Upgrades für das Testnet bieten Validatoren die letzte Möglichkeit, um sicherzustellen, dass ihre Einrichtung erwartungsgemäß läuft, und ggf. Probleme zu lösen. Informationen zum Ausführen eines Validators auf der Ropsten-Beacon Chain zur Vorbereitung auf die Zusammenführung finden Sie auf dem Ropsten Staking-Launchpad.

Wir empfehlen dringend, dass Mainnet-Validatoren die Zusammenführung auf Ropsten und weiteren Testnets durchlaufen, bevor der Übergang auf Proof of Stake im Ethereum-Mainnet erfolgt.

Was sollte ich als Anwendungs- oder Toolentwickler tun?

Im Rahmen der Durchführung der Zusammenführung auf Ropsten sollten Sie sicherstellen, dass Ihr Produkt mit dem Proof-of-Stake-Übergang und nach der Zusammenführung erwartungsgemäß funktioniert. Wie bereits in einem vorherigen Beitrag erläutert, hat die Zusammenführung nur minimale Auswirkungen auf eine Untergruppe aus Verträgen, die auf Ethereum bereitgestellt sind. Keiner davon sollte in seiner Funktionsweise beeinträchtigt werden. Darüber hinaus wird der Großteil unserer API-Endpunkte stabil bleiben (sofern Sie nicht Methoden nutzen, die Proof-of-Work-spezifisch sind, wie zum Beispiel eth_getWork).

Allerdings umfassen die meisten Anwendungen auf Ethereum weit mehr als On-Chain-Verträge. Daher ist jetzt der Zeitpunkt, um sicherzustellen, dass Ihr Front-End-Code, Ihre Tools, die Bereitstellungspipeline und weitere Off-Chain-Komponenten erwartungsgemäß funktionieren. Wir empfehlen dringend, dass Entwickler auf Ropsten (oder Kiln) einen vollständigen Test- und Bereitstellungszyklus durchlaufen und alle Probleme mit Tools oder Abhängigkeiten an die Betreuer dieser Projekte melden. Wenn Sie unsicher sind, ob Sie ein Ticket eröffnen sollen, verwenden Sie dieses Repository.

Muss ich als Ethereum-Nutzer oder Ether-Besitzer irgendetwas tun?

Nein. Das Ethereum-Mainnet ist von diesem Testnet nicht betroffen. Vor dem Übergang des Mainnets erfolgen entsprechende Ankündigungen auf diesem Blog.

Muss ich als Miner irgendetwas tun?

Nein. Wenn Sie Miner im Ethereum-Mainnet oder auf Ropsten sind, sollten Sie sich darüber im Klaren sein, dass alle Netzwerke nach der Zusammenführung vollständig mit Proof of Stake arbeiten. Zu diesem Zeitpunkt wird das Mining im Netz nicht mehr möglich sein.

Auf Ropsten wird das rund um den 8. Juni 2022 der Fall sein und später in diesem Jahr dann im Ethereum-Mainnet.

Kann ich als Prüfer meinen Stake zurückziehen?

Nein. "The Merge" ist das bisher komplizierteste Upgrade von Ethereum. Um das Risiko von Netzwerkunterbrechungen zu minimieren, wurde ein minimaler Ansatz gewählt. Dabei sind Änderungen, die nicht mit dem Übergang zusammenhängen, von diesem Upgrade ausgeschlossen.

Die Möglichkeit zur Entnahme aus der Beacon Chain wird voraussichtlich mit dem ersten Upgrade nach der Zusammenführung eingeführt. Spezifikationen für die Konsens- und die Ausführungsebene sind in Arbeit.

Ich habe weitere Fragen, wo kann ich diese stellen?

Ein Community Call zur Zusammenführung ist für den 3. Juni, 14:00 UTC, geplant. Client-Entwickler und Forscher werden zur Verfügung stehen, um Fragen von Node-Betreibern, Stakern, Infrastruktur- und Tooling-Anbietern und Community-Mitgliedern zu beantworten.

Wann findet die Zusammenführung statt?

Mit der Veröffentlichung dieses Beitrags ist das Datum für den Proof-of-Stake-Übergang für das Ethereum-Mainnet nicht festgelegt. Jede Quelle, die etwas anderes behauptet, ist wahrscheinlich Scam. Aktualisierungen werden in diesem Blog veröffentlicht. Bitte bleiben Sie sicher!

Wenn für Ropsten nach Abschluss der Client-Tests keine Fehler gefunden werden, durchlaufen die weiteren Ethereum-Testnets die Zusammenführung. Sobald der Übergang von Goerli und Sepolia erfolgreich abgeschlossen und eine Stabilisierung erfolgt ist, wird eine ///Slot-Höhe für das Bellatrix-Upgrade auf der Beacon Chain festgelegt und ein Difficulty-Wert wird für den Mainnet-Übergang bestimmt. Für Clients werden dann Versionen veröffentlicht, die die Zusammenführung im Mainnet ermöglichen. Eine Ankündigung dazu erfolgt auf diesem Blog und in anderen Community-Veröffentlichungen.

Voraussetzung dafür ist, dass keine Probleme gefunden werden. Wenn jedoch Probleme an einer Stelle im Prozess auftreten oder die Testabdeckung als unzureichend eingeschätzt wird, werden diese Punkte gelöst, bevor die Fortsetzung des Bereitstellungsprozesses erfolgt.

Erst dann wird es möglich sein, den genauen Termin für die Zusammenführung zu bestimmen.

Mit anderen Worten: 🔜.