Ethereum wechselt zum Proof-of-Stake! Der Übergang, bekannt als The Merge, muss zuerst auf der Beacon Chain mit dem Bellatrix-Upgrade aktiviert werden. Danach wird die Proof-of-Work-Kette zum Proof-of-Stake migriert, wenn ein bestimmter Gesamtschwierigkeitswert erreicht wird. Das Bellatrix-Upgrade ist für Epoche 144896 auf der Beacon Chain – 11:34:47 Uhr UTC am 6. September 2022 geplant. Der Terminal-Gesamtschwierigkeitswert, der The Merge auslöst, beträgt 58750000000000000000000, erwartet zwischen dem 10. und 20. September 2022. Hinweis: wie früher angekündigt , das Brennofen-Testnetz wird untergegangen. Die Betreiber werden am 6. September 2022 geschlossen.
Hintergrund
Nach Jahren harter Arbeit ist das Proof-of-Stake-Upgrade von Ethereum endlich da! Das erfolgreiche Upgrade aller öffentlichen Testnetze ist nun abgeschlossen, und The Merge wurde für das Ethereum-Mainnet geplant.
Die Zusammenführung unterscheidet sich in zweierlei Hinsicht von früheren Netzwerk-Upgrades. Erstens müssen Knotenbetreiber sowohl ihre Clients der Consensus-Layer (CL) als auch der Ausführungs-Layer (EL) im Tandem aktualisieren und nicht nur einen der beiden. Zweitens wird das Upgrade in zwei Phasen aktiviert: die erste mit dem Namen Bellatrix auf einer Epochenhöhe auf der Beacon-Kette und die zweite mit dem Namen Paris beim Erreichen eines Gesamtschwierigkeitswerts auf der Ausführungsebene.
Upgrade-Informationen
Zeitliche Koordinierung
Die Zusammenführung ist ein zweistufiger Prozess. Der erste Schritt ist ein Netzwerk-Upgrade, Bellatrix, auf der Konsensebene, ausgelöst durch eine Epochenhöhe. Darauf folgt der Übergang der Ausführungsschicht vom Proof-of-Work zum Proof-of-Stake, Paris, ausgelöst durch eine bestimmte Gesamtschwierigkeitsschwelle, die als Terminal Total Difficulty (TTD) bezeichnet wird.
Das Bellatrix-Upgrade ist für Epoche 144896 auf der Beacon Chain geplant – 11:34:47 Uhr UTC am 6. September 2022.
Paris, der Anteil der Ausführungsschicht am Übergang, wird durch die Terminal Total Difficulty (TTD) von 58750000000000000000000000000000 ausgelöst, die zwischen dem 10. und 20. September 2022 erwartet wird. Das genaue Datum, an dem TTD erreicht wird, hängt von der Proof-of-Work-Hash-Rate ab. Schätzungen für den Übergang finden Sie unter bordel.wtf und 797.io/themerge.
Sobald die Ausführungsschicht die TTD erreicht oder überschreitet, wird der nachfolgende Block von einem Beacon-Chain-Validierer erzeugt. Der Merge-Übergang gilt als abgeschlossen, sobald die Beacon Chain diesen Block abgeschlossen hat. Unter normalen Netzwerkbedingungen geschieht dies 2 Epochen (oder ~13 Minuten) nachdem der erste Post-TTD-Block erzeugt wurde!
Ein neues JSON-RPC-Block-Tag, finalisiert, gibt den letzten abgeschlossenen Block oder einen Fehler zurück, wenn kein solcher Post-Merge-Block vorhanden ist. Dieses Tag kann von Anwendungen verwendet werden, um zu überprüfen, ob The Merge abgeschlossen wurde. In ähnlicher Weise können Smart Contracts den DIFFICULTY-Opcode (0x44) (umbenannt in PREVRANDAO Post-Merge) abfragen, um festzustellen, ob The Merge stattgefunden hat. Wir empfehlen Infrastrukturanbietern, zusätzlich zum Abschlussstatus die allgemeine Netzwerkstabilität zu überwachen.
Client-Releases
Die folgenden Client-Releases unterstützen The Merge im Ethereum-Mainnet. Knotenoperatoren müssen sowohl einen Ausführungs- als auch einen Konsensschicht-Client ausführen, um während und nach The Merge im Netzwerk zu bleiben.
Bei der Auswahl des auszuführenden Clients sollten Validierer besonders auf die Risiken achten, die entstehen, wenn ein Mehrheitsclient sowohl auf EL als auch auf CL ausgeführt wird. Eine Erläuterung dieser Risiken und ihrer Folgen finden Sie hier. Eine Schätzung der aktuellen Verteilung von EL- und CL-Clients sowie Anleitungen zum Wechseln von einem Client zu einem anderen finden Sie hier.
Konsensschicht
Ausführungsschicht
Warnung: Geth-Version v1.10.22 enthält ein kritisches Datenbankproblem, verwenden Sie diese Version nicht, und wenn Sie bereits aktualisiert haben, aktualisieren Sie bitte so schnell wie möglich auf v1.10.23.
Upgrade-Spezifikationen
Konsenskritische Änderungen für The Merge werden an zwei Stellen spezifiziert:
Die Konsensschicht ändert sich unter dem Bellatrix-Verzeichnis des Consensus-Specs-Repository. Die Ausführungsschicht ändert sich unter der Paris-Spezifikation im Execution-Specs-Repository
Zusätzlich zu diesen beschreiben zwei weitere Spezifikationen, wie die Clients der Konsens- und Ausführungsschicht interagieren:
Die im Execution-APIs-Repository angegebene Engine-API wird für die Kommunikation zwischen der Konsens- und der Ausführungsschicht verwendet. Optimistic Sync, die im Sync-Ordner des Consensus-Specs-Repositorys angegeben ist, wird von der Konsensschicht zum Importieren von Blöcken als Ausführungsschicht verwendet Client synchronisiert, und um eine Teilansicht des Kopfs der Kette vom ersteren zum letzteren bereitzustellen
Merge-Bug-Bounty-Bonus
Alle fusionsbezogenen Kopfgelder für Schwachstellen haben bis zum 8. September einen 4-fachen Multiplikator erhalten. Kritische Fehler sind jetzt bis zu 1 Million USD wert.
Weitere Einzelheiten finden Sie im Bug-Bounty-Programm.
FAQ
Was soll ich als Knotenbetreiber tun?
Post-Merge, ein Ethereum Full Node ist die Kombination aus einem Consensus Layer (CL) Client, der die Proof-of-Stake Beacon Chain ausführt, und einem Execution Layer (EL) Client, der den Benutzerstatus verwaltet und die mit Transaktionen verbundenen Berechnungen ausführt . Der EL- und der CL-Client kommunizieren über einen authentifizierten Port unter Verwendung eines neuen Satzes von JSON-RPC-Methoden namens Engine API. Der EL- und der CL-Client authentifizieren sich gegenseitig mithilfe eines JWT-Geheimnisses. Knotenoperatoren sollten sich auf die Dokumentation ihrer Kunden beziehen, um Anweisungen zum Generieren und Konfigurieren dieses Werts zu erhalten.
Mit anderen Worten, wenn Sie bereits einen Knoten in der Beacon-Kette ausgeführt haben, müssen Sie jetzt auch einen Ausführungsschicht-Client ausführen. Wenn Sie einen Knoten im aktuellen Proof-of-Work-Netzwerk ausgeführt haben, müssen Sie in ähnlicher Weise einen Consensus-Layer-Client ausführen. Damit sie sicher kommunizieren können, muss jedem Client ein JWT-Token übergeben werden. Eine Aktualisierung des Abschnitts „Run a Node“ auf der Website ethereum.org geht ausführlicher auf diese Schritte ein.
Es muss betont werden, dass sie zwar beide Teil von Client-Releases auf Konsensebene sind, sich das Ausführen eines Beacon-Knotens jedoch vom Ausführen eines Validator-Clients unterscheidet. Staker müssen beide ausführen, Knotenbetreiber benötigen jedoch nur ersteres. In diesem Beitrag wird der Unterschied zwischen beiden Komponenten näher erläutert.
Beachten Sie außerdem, dass jede Ebene einen unabhängigen Satz von Peers verwaltet und ihre eigenen APIs verfügbar macht. Sowohl die Beacon- als auch die JSON-RPC-APIs funktionieren weiterhin wie erwartet.
Was muss ich als Staker tun?
Wie oben erläutert, müssen Validierer in der Beacon-Kette zusätzlich zu ihren Konsensschicht-Clients nach The Merge einen Ausführungsschicht-Client ausführen. Pre-Merge, dies wurde dringend empfohlen, aber einige Validatoren haben diese Funktionen an Drittanbieter ausgelagert. Dies war möglich, weil die einzigen Daten, die auf der Ausführungsebene erforderlich waren, Aktualisierungen des Depotvertrags waren.
Nach der Zusammenführung müssen Validierer sicherstellen, dass Benutzertransaktionen und Zustandsübergänge, die sie erstellen und bestätigen, gültig sind. Dazu muss jeder Beacon-Knoten mit einem Client der Ausführungsschicht gekoppelt werden. Beachten Sie, dass mehrere Validatoren immer noch mit einer einzigen Kombination aus Beacon-Knoten und Ausführungsschicht-Client gekoppelt werden können. Dies erweitert die Verantwortlichkeiten der Validatoren, gibt aber auch einem Validator, der einen Block vorschlägt, das Recht auf die damit verbundenen Transaktionsprioritätsgebühren (die derzeit an Miner gehen).
Während Validator-Belohnungen weiterhin auf der Beacon-Kette anfallen und ein nachfolgendes Netzwerk-Upgrade erfordern, um zurückgezogen zu werden, werden Transaktionsgebühren bezahlt, verbrannt und auf der Ausführungsebene verteilt. Validatoren können jede Ethereum-Adresse als Empfänger für Transaktionsgebühren angeben.
Stellen Sie nach der Aktualisierung Ihres Konsensus-Clients sicher, dass Sie den Gebührenempfänger als Teil Ihrer Validator-Client-Konfigurationen festlegen, um sicherzustellen, dass Transaktionsgebühren an eine von Ihnen kontrollierte Adresse gesendet werden. Wenn Sie über einen Drittanbieter gestockt haben, liegt es an Ihrem ausgewählten Anbieter, festzulegen, wie diese Gebühren verteilt werden.
Das Staking Launchpad verfügt über eine Merge Readiness Checklist, die Staker verwenden können, um sicherzustellen, dass sie jeden Schritt des Prozesses durchlaufen haben. EthStaker hat auch Validator Prep Workshops veranstaltet, weitere sind in Planung.
Staker, die in Vorbereitung auf den Proof-of-Stake-Übergang im Mainnet einen Validator auf einem Testnetz ausführen möchten, können dies auf Goerli (jetzt mit Prater fusioniert) tun, das auch über eine Staking-Launchpad-Instanz verfügt.
Warum ist das geschätzte Datum für die Terminal Total Difficulty so weit gefasst?
Die pro Block hinzugefügte inkrementelle Schwierigkeit hängt von der flüchtigen Netzwerk-Hash-Rate ab. Wenn mehr Hash-Rate dem Netzwerk beitritt, wird TTD früher erreicht. Ebenso wird TTD später erreicht, wenn die Hash-Rate das Netzwerk verlässt. Im Falle eines signifikanten Abfalls der Hash-Rate könnte ein TTD Override koordiniert werden, wie es bei Ropsten der Fall war.
Was sollte ich als Anwendungs- oder Werkzeugentwickler tun?
Wie in einem früheren Beitrag erklärt, wird The Merge nur minimale Auswirkungen auf eine Untergruppe von Verträgen haben, die auf Ethereum eingesetzt werden, von denen keiner brechen sollte. Darüber hinaus bleibt der Löwenanteil der Benutzer-API-Endpunkte stabil (es sei denn, Sie verwenden Proof-of-Work-spezifische Methoden wie eth_getWork).
Allerdings beinhalten die meisten Anwendungen auf Ethereum viel mehr als On-Chain-Verträge. Jetzt ist es an der Zeit sicherzustellen, dass Ihr Front-End-Code, Ihre Tools, Ihre Deployment-Pipeline und andere Off-Chain-Komponenten wie vorgesehen funktionieren. Wir empfehlen dringend, dass Entwickler einen vollständigen Test- und Bereitstellungszyklus auf Sepolia oder Goerli durchlaufen und alle Probleme mit Tools oder Abhängigkeiten den Betreuern dieser Projekte melden. Wenn Sie sich nicht sicher sind, wo Sie ein Problem öffnen sollen, verwenden Sie bitte dieses Repository.
Bitte beachten Sie außerdem, dass alle Testnetze außer Sepolia und Goerli nach der Zusammenführung veraltet sind. Wenn Sie ein Benutzer von Ropsten, Rinkeby oder Kiln sind, sollten Sie eine Migration zu Goerli oder Sepolia planen. Weitere Informationen dazu finden Sie hier.
Muss ich als Ethereum-Benutzer oder Ether-Inhaber etwas tun?
Egal, ob Sie Ethereum-Anwendungen in der Kette verwenden, Ether an einer Börse oder in einer selbstverwahrten Brieftasche halten, Sie müssen nichts tun. Wenn eine von Ihnen verwendete Anwendung, Börse oder Brieftasche zusätzliche Anweisungen oder Empfehlungen anbietet, sollten Sie überprüfen, ob diese tatsächlich von ihnen stammen. Achten Sie auf Betrug!
Muss ich als Miner irgendetwas tun?
Nein. Wenn Sie im Ethereum-Mainnet minen, sollten Sie sich darüber im Klaren sein, dass das Netzwerk nach The Merge vollständig unter Proof-of-Stake betrieben wird. Ab diesem Zeitpunkt ist das Mining im Netzwerk nicht mehr möglich.
Was passiert, wenn ich ein Miner oder Knotenbetreiber bin und nicht am Upgrade teilnehme?
Wenn Sie einen Ethereum-Client verwenden, der nicht auf die neueste Version (siehe oben) aktualisiert wurde, wird Ihr Client mit der Pre-Fork-Blockchain synchronisiert, sobald das Upgrade erfolgt.
Sie werden nach den alten Regeln in einer inkompatiblen Kette stecken bleiben und nicht in der Lage sein, Ether zu senden oder im Post-Merge-Ethereum-Netzwerk zu arbeiten.
Kann ich als Validator meinen Einsatz zurückziehen?
Nein. Der Merge ist das bisher komplizierteste Upgrade auf Ethereum. Um das Risiko von Netzwerkunterbrechungen zu minimieren, wurde ein minimaler Ansatz gewählt, der alle Nicht-Übergangsänderungen von diesem Upgrade ausschließt.
Auszahlungen aus der Beacon Chain werden wahrscheinlich im ersten Upgrade nach The Merge eingeführt. Spezifikationen sowohl für die Konsens- als auch für die Ausführungsebene sind in Arbeit.
Ich habe weitere Fragen, wo kann ich sie stellen?
Nehmen Sie am nächsten Merge Community Call am Freitag, den 9. September um 14:00 UTC an Client-Teamentwicklern, Mitgliedern von ETHStaker, Forschern und mehr teil!
Danke
Der Übergang von Ethereum zum Proof-of-Stake hat lange auf sich warten lassen. Vielen Dank an alle, die dazu beigetragen haben, alles zu recherchieren, zu spezifizieren, zu entwickeln, zu analysieren, zu testen, zu brechen, zu reparieren oder zu erklären, was uns zu The Merge geführt hat.
Es gab im Laufe der Jahre viel zu viele Mitwirkende, um sie hier aufzulisten, aber Sie wissen, wer Sie sind. Ohne euch alle im Basar hätten wir diese Kathedrale nicht gebaut.
wen zusammenführen? Sehr 🔜.
Danke an Joseph Schweitzer und Tomo Saito für das Titelbild zu diesem Beitrag!
