Was war der Merge?
Der Merge war die Zusammenführung der ursprünglichen Ausführungsschicht von Ethereum (das Mainnet, das seit der Genesis existiert) mit seiner neuen Proof-of-Stake-Konsensschicht, der Beacon Chain. Er beseitigte die Notwendigkeit für energieintensives Mining und ermöglichte es stattdessen, das Netzwerk mit gestakten ETH zu sichern. Es war ein wirklich aufregender Schritt bei der Verwirklichung der Vision von Ethereum – mehr Skalierbarkeit, Sicherheit und Nachhaltigkeit.
Anfänglich wurde die Beacon Chain getrennt vom eingeführt. Das Ethereum Mainnet – mit all seinen Konten, Guthaben, Smart Contracts und dem Blockchain-Zustand – wurde weiterhin durch Proof-of-Work gesichert, selbst während die Beacon Chain parallel mit Proof-of-Stake lief. Der Merge war der Zeitpunkt, an dem diese beiden Systeme endlich zusammenkamen und Proof-of-Work dauerhaft durch Proof-of-Stake ersetzt wurde.
Stellen Sie sich Ethereum als ein Raumschiff vor, das gestartet ist, bevor es ganz bereit für eine interstellare Reise war. Mit der Beacon Chain baute die Community einen neuen Antrieb und eine gehärtete Hülle. Nach umfangreichen Tests war es an der Zeit, den neuen Antrieb während des Fluges gegen den alten auszutauschen. Dadurch wurde der neue, effizientere Antrieb in das bestehende Schiff integriert, was es ihm ermöglichte, einige ernsthafte Lichtjahre zurückzulegen und es mit dem Universum aufzunehmen.
Zusammenführung mit dem Mainnet
Proof-of-Work sicherte das Ethereum Mainnet von der Genesis bis zum Merge. Dies ermöglichte es der Ethereum-Blockchain, an die wir alle gewöhnt sind, im Juli 2015 mit all ihren vertrauten Funktionen – Transaktionen, Smart Contracts, Konten usw. – ins Leben gerufen zu werden.
Während der gesamten Geschichte von Ethereum bereiteten sich die Entwickler auf einen eventuellen Übergang von Proof-of-Work zu Proof-of-Stake vor. Am 1. Dezember 2020 wurde die Beacon Chain als separate Blockchain zum Mainnet erstellt, die parallel lief.
Die Beacon Chain verarbeitete ursprünglich keine Mainnet-Transaktionen. Stattdessen erreichte sie einen Konsens über ihren eigenen Zustand, indem sie sich auf aktive Validatoren und deren Kontostände einigte. Nach umfangreichen Tests war es an der Zeit, dass die Beacon Chain einen Konsens über reale Daten erreichte. Nach dem Merge wurde die Beacon Chain zur Konsens-Engine für alle Netzwerkdaten, einschließlich Transaktionen der Ausführungsschicht und Kontostände.
Der Merge stellte den offiziellen Wechsel zur Nutzung der Beacon Chain als Engine der Blockproduktion dar. Mining ist nicht länger das Mittel zur Produktion gültiger Blöcke. Stattdessen haben die Proof-of-Stake-Validatoren diese Rolle übernommen und sind nun dafür verantwortlich, die Gültigkeit aller Transaktionen zu verarbeiten und Blöcke vorzuschlagen.
Beim Merge ging keine Historie verloren. Als das Mainnet mit der Beacon Chain zusammengeführt wurde, wurde auch die gesamte Transaktionshistorie von Ethereum zusammengeführt.
Benutzer und Inhaber
Der Merge hat für Inhaber/Benutzer nichts geändert.
Dies muss wiederholt werden: Als Benutzer oder Inhaber von ETH oder einem anderen digitalen Vermögenswert auf Ethereum sowie als Staker, der keinen Knoten betreibt, müssen Sie nichts mit Ihren Geldern oder Ihrer Wallet tun, um den Merge zu berücksichtigen. ETH ist einfach ETH. Es gibt kein „altes ETH“/„neues ETH“ oder „Eth1“/„Eth2“ und Wallets funktionieren nach dem Merge genau so wie davor – Leute, die Ihnen etwas anderes erzählen, sind wahrscheinlich Betrüger.
Trotz des Austauschs von Proof-of-Work blieb die gesamte Geschichte von Ethereum seit der Genesis intakt und wurde durch den Übergang zu Proof-of-Stake nicht verändert. Alle Gelder, die vor dem Merge in Ihrer Wallet gehalten wurden, sind auch nach dem Merge noch zugänglich. Ihrerseits ist keine Aktion für das Upgrade erforderlich.
Knotenbetreiber und Dapp-Entwickler
Zu den wichtigsten Aktionspunkten gehören:
- Führen Sie sowohl einen Konsens-Client als auch einen Ausführungsclient aus; Endpunkte von Drittanbietern zum Abrufen von Ausführungsdaten funktionieren seit dem Merge nicht mehr.
- Authentifizieren Sie sowohl Ausführungs- als auch Konsens-Clients mit einem gemeinsamen JWT-Geheimnis, damit sie sicher kommunizieren können.
- Legen Sie eine
fee recipient-Adresse fest, um Ihre verdienten Transaktionsgebühren-Trinkgelder/MEV zu erhalten.
Wenn Sie die ersten beiden oben genannten Punkte nicht abschließen, wird Ihr Knoten als „offline“ angesehen, bis beide Schichten synchronisiert und authentifiziert sind.
Wenn Sie keine fee recipient festlegen, kann sich Ihr Validator weiterhin wie gewohnt verhalten, aber Sie verpassen unverbrennte Gebühren-Trinkgelder und jeglichen MEV, den Sie sonst in Blöcken verdient hätten, die Ihr Validator vorschlägt.
Bis zum Merge reichte ein Ausführungsclient (wie Go Ethereum (Geth), Erigon, Besu oder Nethermind) aus, um Blöcke zu empfangen, ordnungsgemäß zu validieren und zu verbreiten, die vom Netzwerk weitergegeben wurden. Nach dem Merge hängt die Gültigkeit von Transaktionen, die in einer Ausführungs-Payload enthalten sind, nun auch von der Gültigkeit des „Konsens-Blocks“ ab, in dem sie enthalten ist.
Infolgedessen erfordert ein vollständiger Ethereum-Knoten nun sowohl einen Ausführungsclient als auch einen Konsens-Client. Diese beiden Clients arbeiten über eine neue Engine-API zusammen. Die Engine-API erfordert eine Authentifizierung mithilfe eines JWT-Geheimnisses, das beiden Clients zur Verfügung gestellt wird und eine sichere Kommunikation ermöglicht.
Zu den wichtigsten Aktionspunkten gehören:
- Installieren Sie zusätzlich zu einem Ausführungsclient einen Konsens-Client
- Authentifizieren Sie Ausführungs- und Konsens-Clients mit einem gemeinsamen JWT-Geheimnis, damit sie sicher miteinander kommunizieren können.
Wenn Sie die oben genannten Punkte nicht abschließen, wird Ihr Knoten als „offline“ angezeigt, bis beide Schichten synchronisiert und authentifiziert sind.
Der Merge brachte Änderungen am Konsens mit sich, was auch Änderungen in Bezug auf Folgendes beinhaltet:
- Blockstruktur
- Slot-/Block-Timing
- Opcode-Änderungen
- Quellen für Onchain-Zufälligkeit
- Konzept von Safe Head und endgültigen Blöcken
Weitere Informationen finden Sie in diesem Blogbeitrag von Tim Beiko darüber, wie sich der Merge auf die Anwendungsschicht von Ethereum auswirkt.
Der Merge und der Energieverbrauch
Der Merge markierte das Ende von Proof-of-Work für Ethereum und leitete die Ära eines nachhaltigeren, umweltfreundlicheren Ethereums ein. Der Energieverbrauch von Ethereum sank um schätzungsweise 99,95 %, was Ethereum zu einer grünen Blockchain macht. Erfahren Sie mehr über den Energieverbrauch von Ethereum.
Der Merge und die Skalierung
Der Merge bereitete auch die Bühne für weitere Skalierbarkeits-Upgrades, die unter Proof-of-Work nicht möglich waren, und brachte Ethereum der Erreichung der vollen Skalierung, Sicherheit und Nachhaltigkeit, auf die seine Roadmap hinarbeitet, einen Schritt näher.
Missverständnisse über den Merge
Es gibt zwei Arten von Ethereum-Knoten: Knoten, die Blöcke vorschlagen können, und Knoten, die dies nicht tun.
Knoten, die Blöcke vorschlagen, machen nur eine kleine Anzahl der gesamten Knoten auf Ethereum aus. Diese Kategorie umfasst Mining-Knoten unter Proof-of-Work (PoW) und Validator-Knoten unter Proof-of-Stake (PoS). Diese Kategorie erfordert den Einsatz wirtschaftlicher Ressourcen (wie GPU-Hash-Leistung bei Proof-of-Work oder gestakte ETH bei Proof-of-Stake) im Austausch für die Fähigkeit, gelegentlich den nächsten Block vorzuschlagen und Protokollbelohnungen zu verdienen.
Die anderen Knoten im Netzwerk (d. h. die Mehrheit) müssen keine wirtschaftlichen Ressourcen über einen handelsüblichen Computer mit 1-2 TB verfügbarem Speicherplatz und einer Internetverbindung hinaus einsetzen. Diese Knoten schlagen keine Blöcke vor, spielen aber dennoch eine entscheidende Rolle bei der Sicherung des Netzwerks, indem sie alle Blockvorschlagenden zur Rechenschaft ziehen, indem sie auf neue Blöcke warten und deren Gültigkeit bei Ankunft gemäß den Konsensregeln des Netzwerks überprüfen. Wenn der Block gültig ist, verbreitet der Knoten ihn weiter im Netzwerk. Wenn der Block aus irgendeinem Grund ungültig ist, ignoriert die Knoten-Software ihn als ungültig und stoppt seine Verbreitung.
Der Betrieb eines nicht blockproduzierenden Knotens ist für jeden unter beiden Konsensmechanismen (Proof-of-Work oder Proof-of-Stake) möglich; es wird allen Benutzern dringend empfohlen, wenn sie die Mittel dazu haben. Der Betrieb eines Knotens ist für Ethereum immens wertvoll und bietet jedem Einzelnen, der einen betreibt, zusätzliche Vorteile, wie verbesserte Sicherheit, Privatsphäre und Zensurresistenz.
Die Fähigkeit für jeden, seinen eigenen Knoten zu betreiben, ist absolut unerlässlich, um die Dezentralisierung des Ethereum-Netzwerks aufrechtzuerhalten.
Gas-Gebühren sind ein Produkt der Netzwerknachfrage im Verhältnis zur Kapazität des Netzwerks. Der Merge hat die Verwendung von Proof-of-Work eingestellt und ist für den Konsens zu Proof-of-Stake übergegangen, hat aber keine Parameter wesentlich geändert, die die Netzwerkkapazität oder den Transaktionsdurchsatz direkt beeinflussen.
Mit einer Rollup-zentrierten Roadmap konzentrieren sich die Bemühungen auf die Skalierung der Benutzeraktivität auf Layer 2, während das Layer 1 (L1) Mainnet als sichere dezentrale Abwicklungsschicht aktiviert wird, die für die Rollup-Datenspeicherung optimiert ist, um Rollup-Transaktionen exponentiell billiger zu machen. Der Übergang zu Proof-of-Stake ist eine entscheidende Voraussetzung, um dies zu verwirklichen. Mehr zu Gas und Gebühren.
Die „Geschwindigkeit“ einer Transaktion kann auf verschiedene Weise gemessen werden, einschließlich der Zeit bis zur Aufnahme in einen Block und der Zeit bis zur Endgültigkeit. Beides ändert sich leicht, aber nicht so, dass Benutzer es bemerken werden.
Historisch gesehen war es bei Proof-of-Work das Ziel, alle ~13,3 Sekunden einen neuen Block zu haben. Unter Proof-of-Stake treten Slots genau alle 12 Sekunden auf, von denen jeder eine Gelegenheit für einen Validator ist, einen Block zu veröffentlichen. Die meisten Slots haben Blöcke, aber nicht unbedingt alle (z. B. wenn ein Validator offline ist). Bei Proof-of-Stake werden Blöcke ~10 % häufiger produziert als bei Proof-of-Work. Dies war eine ziemlich unbedeutende Änderung und wird von Benutzern wahrscheinlich nicht bemerkt.
Proof-of-Stake führte das Konzept der Transaktions-Endgültigkeit ein, das es vorher nicht gab. Bei Proof-of-Work wird die Fähigkeit, einen Block rückgängig zu machen, mit jedem weiteren Block, der auf einer Transaktion gemint wird, exponentiell schwieriger, erreicht aber nie ganz null. Unter Proof-of-Stake werden Blöcke in Epochen gebündelt (Zeitspannen von 6,4 Minuten, die 32 Chancen für Blöcke enthalten), über die Validatoren abstimmen. Wenn eine Epoche endet, stimmen die Validatoren darüber ab, ob die Epoche als „gerechtfertigt“ betrachtet werden soll. Wenn die Validatoren zustimmen, die Epoche zu rechtfertigen, wird sie in der nächsten Epoche endgültig. Das Rückgängigmachen endgültiger Transaktionen ist wirtschaftlich nicht machbar, da es erforderlich machen würde, über ein Drittel der gesamten gestakten ETH zu beschaffen und zu verbrennen.
Anfänglich nach dem Merge konnten Staker nur auf Gebühren-Trinkgelder und MEV zugreifen, die als Ergebnis von Blockvorschlägen verdient wurden. Diese Belohnungen werden einem Nicht-Staking-Konto gutgeschrieben, das vom Validator kontrolliert wird (bekannt als Gebührenempfänger), und sind sofort verfügbar. Diese Belohnungen sind getrennt von Protokollbelohnungen für die Erfüllung von Validator-Pflichten.
Seit dem Shanghai/Capella-Netzwerk-Upgrade können Staker nun eine Abhebungsadresse festlegen, um automatische Auszahlungen von überschüssigem Staking-Guthaben (ETH über 32 aus Protokollbelohnungen) zu erhalten. Dieses Upgrade ermöglichte es einem Validator auch, sein gesamtes Guthaben beim Austritt aus dem Netzwerk freizuschalten und zurückzufordern.
Da das Shanghai/Capella-Upgrade Abhebungen ermöglichte, haben Validatoren einen Anreiz, ihr Staking-Guthaben über 32 ETH abzuheben, da diese Gelder nicht zur Rendite beitragen und ansonsten gesperrt sind. Abhängig von der APR (bestimmt durch die gesamten gestakten ETH) können sie einen Anreiz haben, mit ihrem Validator (oder ihren Validatoren) einen Austritt durchzuführen, um ihr gesamtes Guthaben zurückzufordern, oder möglicherweise noch mehr zu staken, indem sie ihre Belohnungen verwenden, um mehr Rendite zu erzielen.
Ein wichtiger Vorbehalt hierbei ist, dass vollständige Validator-Austritte durch das Protokoll ratenbegrenzt sind und nur eine bestimmte Anzahl von Validatoren pro Epoche (alle 6,4 Minuten) austreten darf. Dieses Limit schwankt je nach Anzahl der aktiven Validatoren, läuft aber darauf hinaus, dass an einem einzigen Tag etwa 0,33 % der gesamten gestakten ETH aus dem Netzwerk abgezogen werden können.
Dies verhindert einen Massenexodus von gestakten Geldern. Darüber hinaus verhindert es, dass ein potenzieller Angreifer mit Zugriff auf einen großen Teil der gesamten gestakten ETH ein Slashing-Vergehen begeht und alle betroffenen Validator-Guthaben in derselben Epoche abzieht/abhebt, bevor das Protokoll die Slashing-Strafe durchsetzen kann.
Die APR ist auch absichtlich dynamisch, was es einem Markt von Stakern ermöglicht, auszugleichen, wie viel sie bereit sind, sich für die Sicherung des Netzwerks bezahlen zu lassen. Wenn die Rate zu niedrig ist, werden Validatoren mit einer durch das Protokoll begrenzten Rate austreten. Allmählich wird dies die APR für alle verbleibenden erhöhen und wieder neue oder zurückkehrende Staker anziehen.
Was ist mit „Eth2“ passiert?
Der Begriff „Eth2“ wurde verworfen. Nach der Zusammenführung von „Eth1“ und „Eth2“ zu einer einzigen Chain besteht keine Notwendigkeit mehr, zwischen zwei Ethereum-Netzwerken zu unterscheiden; es gibt nur noch Ethereum.
Um Verwirrung zu vermeiden, hat die Community diese Begriffe aktualisiert:
- „Eth1“ ist jetzt die „Ausführungsschicht“, die Transaktionen und Ausführung handhabt.
- „Eth2“ ist jetzt die „Konsensschicht“, die den Proof-of-Stake-Konsens handhabt.
Diese Terminologie-Updates ändern nur die Namenskonventionen; dies ändert nichts an den Zielen oder der Roadmap von Ethereum.
Erfahren Sie mehr über die Umbenennung von „Eth2“ (opens in a new tab)
Beziehung zwischen Upgrades
Die Ethereum-Upgrades hängen alle in gewisser Weise zusammen. Lassen Sie uns also zusammenfassen, wie der Merge mit den anderen Upgrades zusammenhängt.
Der Merge und die Beacon Chain
Der Merge stellt die formelle Übernahme der Beacon Chain als neue Konsensschicht für die ursprüngliche Mainnet-Ausführungsschicht dar. Seit dem Merge werden Validatoren zugewiesen, um das Ethereum Mainnet zu sichern, und Mining auf Proof-of-Work ist kein gültiges Mittel zur Blockproduktion mehr.
Blöcke werden stattdessen von validierenden Knoten vorgeschlagen, die ETH gestakt haben, als Gegenleistung für das Recht, am Konsens teilzunehmen. Diese Upgrades bereiten die Bühne für zukünftige Skalierbarkeits-Upgrades, einschließlich Sharding.
Die Beacon ChainDer Merge und das Shanghai-Upgrade
Um den Fokus auf einen erfolgreichen Übergang zu Proof-of-Stake zu vereinfachen und zu maximieren, enthielt das Merge-Upgrade bestimmte erwartete Funktionen nicht, wie z. B. die Möglichkeit, gestakte ETH abzuheben. Diese Funktionalität wurde separat mit dem Shanghai/Capella-Upgrade aktiviert.
Für Neugierige: Erfahren Sie mehr darüber, was nach dem Merge passiert (opens in a new tab), präsentiert von Vitalik auf dem ETHGlobal-Event im April 2021.
Der Merge und Sharding
Ursprünglich war geplant, vor dem Merge an Sharding zu arbeiten, um die Skalierbarkeit anzugehen. Mit dem Boom von Layer-2-Skalierungslösungen verlagerte sich die Priorität jedoch darauf, zuerst Proof-of-Work gegen Proof-of-Stake auszutauschen.
Die Pläne für Sharding entwickeln sich rasant, aber angesichts des Aufstiegs und Erfolgs von Layer-2-Technologien zur Skalierung der Transaktionsausführung haben sich die Sharding-Pläne darauf verlagert, den optimalsten Weg zu finden, um die Last der Speicherung komprimierter Aufrufdaten von Rollup-Verträgen zu verteilen, was ein exponentielles Wachstum der Netzwerkkapazität ermöglicht. Dies wäre ohne den vorherigen Übergang zu Proof-of-Stake nicht möglich.
Sharding