Ethereums Übergang zum Einsatz von Anteil – die Zusammenführung – liegt in der Nähe: Devnets werden aufgestanden, die Spezifikationen werden fertiggestellt und die Öffentlichkeitsarbeit hat ernsthaft begonnen. Die Zusammenführung hat so konzipiert, dass Ethereum Endbenutzer, intelligente Verträge und DApps tätig hat. Das heißt, es gibt einige geringfügige Änderungen, die hervorgehoben werden sollten. Bevor wir uns mit ihnen befassen, finden Sie hier einige Links, um einen Kontext über die Gesamt -Merge -Architektur bereitzustellen:
Der Rest dieses Beitrags geht davon aus, dass der Leser mit dem oben genannten vertraut ist. Für diejenigen, die noch tiefer graben möchten, sind hier die vollständigen Spezifikationen für die Zusammenführung verfügbar:
Blockstruktur
Nach der Zusammenführung gibt es im Netzwerk keinen Nachweis von Arbeitsblöcken mehr. Stattdessen wird der frühere Inhalt des Nachweises von Arbeitsblöcken zu einem Bestandteil der in der Beacon -Kette erzeugten Blöcke. Sie können sich dann die Beacon -Kette als neuer Beweis für die Einsatzkonsensschicht von Ethereum vorstellen und den vorherigen Nachweis der Arbeitskonsensschicht ersetzen. Beacon -Kettenblöcke werden enthalten ExecutionPayloadsdie das Post-Merge-Äquivalent von Blöcken für den aktuellen Nachweis der Arbeitskette sind. Das Bild unten zeigt diese Beziehung:
Für Endbenutzer und Anwendungsentwickler sind diese ExecutionPayloads dort passieren Interaktionen mit Ethereum. Transaktionen auf dieser Ebene werden weiterhin von Clients der Ausführungsschicht (Besu, Erigon, Geth, Nethermind usw.) verarbeitet. Glücklicherweise führt der Zusammenschluss aufgrund der Stabilität der Ausführungsschicht nur minimale Bruchänderungen vor.
Bergbau- und Ommer -Blockfelder
Nach dem Merge werden mehrere Felder, die zuvor im Nachweis der Arbeitsblock-Header enthalten sind, ungenutzt, da sie für den Beweis für den Anteil irrelevant sind. Um die Störung der Werkzeuge und die Infrastruktur zu minimieren, werden diese Felder auf 0 oder die äquivalente der Datenstruktur festgelegt, anstatt vollständig aus der Datenstruktur entfernt zu werden. Die vollständigen Änderungen an Blockfeldern finden Sie in EIP-3675.
| Feld | Konstanter Wert | Kommentar |
|---|---|---|
| in Fortschritten | [] | RLP([]) = 0xc0 |
| Housershash | 0x1dcc4de8dec75d7aab85B567B6CCD41AD312451B948A7413F0A142FD40D49347 | = Keccak256(RLP([])) |
| Schwierigkeit | 0 | |
| Nonce | 0x00000000000000 |
Weil der Nachweis des Pfahls nicht auf natürliche Weise Ommer (auch bekannt als Onkel -Blöcke) wie den Nachweis der Arbeit produziert, die Liste dieser in jedem Block (in Fortschritten) wird leer und der Hash dieser Liste ((Housershash) wird der RLP-kodierte Hash einer leeren Liste. Ähnlich, weil Schwierigkeit Und Nonce sind Merkmale des Arbeitsnachweises, auf die diese festgelegt werden 0während sie ihre Byte-Größe-Werte respektieren.
OnkelEin weiteres Bergbaufeld wird nicht auf 0 gesetzt, sondern enthalten stattdessen den Randao-Wert der Beacon Chain. Weitere dazu unten.
Blockhash & SCHWIERIGKEIT Opcodes ändert sich
Post-Merge, die Blockhash Opcode wird weiterhin zur Verwendung verfügbar sein. Angesichts der Tatsache, dass es jedoch nicht mehr durch den Nachweis des Hashing -Prozesses geschmiedet wird, wird die von diesem Opcode bereitgestellte Pseudorandomness viel schwächer sein.
In Bezug auf die SCHWIERIGKEIT Opcode (0x44) wird aktualisiert und umbenannt in Prevrandao. Nach dem Merge wird die Ausgabe des von der Beacon-Kette bereitgestellten Zufälligkeitsbeacon zurückgegeben. Dieser Opcode wird somit eine stärkere, wenn noch noch voreingenommene Quelle der Zufälligkeit für Anwendungsentwickler sein, die sie verwenden können als Blockhash.
Der Wert ausgesetzt von Prevrandao wird in der aufbewahrt ExecutionPayload Wo OnkelEin Wert, der mit dem Nachweis der Arbeitsberechnung verbunden ist, wurde gespeichert. Die Nutzlast Onkel Feld wird auch umbenannt Prevrandao.
Hier ist eine Illustration, wie die SCHWIERIGKEIT & Prevrandao Opcodes arbeiten vor und nach dem Merge:
Pre-Merge sehen wir das 0x44 Opcode gibt die zurück Schwierigkeit Feld im Blockkopf. Post-Merge, der Opcode, umbenannt auf Prevrandaozeigt auf das zuvor enthaltene Headerfeld Onkel und speichert jetzt die Prevrandao Wert aus dem Staat der Beacon Chain.
Diese Änderung, formalisiert in EIP-4399Bietet auch Anwendungen für On-Kette eine Möglichkeit, zu beurteilen, ob die Zusammenführung stattgefunden hat. Aus dem EIP:
Darüber hinaus ermöglichen Änderungen, die dieses EIP vorgeschlagen haben, intelligente Verträge, um festzustellen, ob das Upgrade auf das POS bereits stattgefunden hat. Dies kann durch Analyse des Rückgabewerts der von der durchgeführt werden SCHWIERIGKEIT Opcode. Ein Wert größer als 2 ** 64 zeigt an, dass die Transaktion im POS -Block ausgeführt wird.
Zeit blockieren
Die Zusammenführung wirkt sich auf die durchschnittliche Blockzeit von Ethereum aus. Derzeit sind die Blöcke im Nachweis der Arbeit alle ~ 13 Sekunden mit einer angemessenen Abweichung in den tatsächlichen Blockzeiten einher. Im Nachweis des Einsatzes kommen Blöcke genau in jede 12 Sekunden vor, außer wenn ein Steckplatz entweder wegen eines Validators offline ist oder weil er keinen Zeitblock einreicht. In der Praxis geschieht dies derzeit in <1% der Slots.
Dies impliziert eine ~ 1 Sekunden -Verringerung der durchschnittlichen Blockzeiten im Netzwerk. Intelligente Verträge, bei denen eine bestimmte durchschnittliche Blockzeit in ihren Berechnungen angenommen wird, müssen dies berücksichtigen.
Finalisierte Blöcke und sicherer Kopf
Im Nachweis der Arbeit besteht immer das Potenzial für Reorgs. Anwendungen warten normalerweise, bis mehrere Blöcke auf einem neuen Kopf abgebaut werden, bevor er als unwahrscheinlich aus der kanonischen Kette oder “bestätigt” behandelt wird. Nach der Zusammenführung haben wir stattdessen die Konzepte von abgeschlossen Blöcke und sicherer Kopf auf der Ausführungsschicht ausgesetzt. Diese Blöcke können zuverlässig als der “bestätigte” Nachweis von Arbeitsblöcken verwendet werden, erfordern jedoch eine Verschiebung im Verständnis, um korrekt zu verwenden.
Ein endgültiger Block ist einer, der durch> 2/3 der Validatoren als kanonisch akzeptiert wurde. Um einen widersprüchlichen Block zu schaffen, müsste ein Angreifer mindestens 1/3 des gesamten Äthers verbrennen. Während die Anpassungsbeträge variieren können, wird ein solcher Angriff immer erwartet, dass der Angreifer Millionen von ETH kostet.
A sicherer Kopf Block ist einer, der gewesen ist gerechtfertigt von der Beacon -Kette, was bedeutet, dass> 2/3 der Validatoren ihr bestätigt haben. Unter normalen Netzwerkbedingungen erwarten wir, dass es in die kanonische Kette aufgenommen und schließlich abgeschlossen ist. Damit dieser Block nicht Teil der kanonischen Kette ist, müsste eine Mehrheit der Validatoren zusammenarbeiten, um das Netzwerk anzugreifen, oder das Netzwerk müsste extreme Latenzniveaus bei der Blockausbreitung aufweisen. Post-Merge, Ausführungsschicht-APIs (z. B. JSON RPC), enthüllt die sicherer Kopf mit a sicher Etikett.
Finalisierte Blöcke werden auch über JSON RPC über einen neuen freigelegt abgeschlossen Flagge. Diese können dann als stärkerer Ersatz für den Nachweis von Arbeitsbestätigungen dienen. Die folgende Tabelle fasst dies zusammen:
| Blocktyp | Konsensmechanismus | JSON RPC | Bedingungen für Reorg |
|---|---|---|---|
| Kopf | Arbeitsprobe | letzte | Zu erwarten, muss mit Vorsicht verwendet werden. |
| sicherer Kopf | Beweis des Pfahls | sicher | Möglicherweise erfordert entweder eine große Netzwerkverzögerung oder einen Angriff im Netzwerk. |
| bestätigt | Arbeitsprobe | N / A | Es ist unwahrscheinlich, dass ein Großteil des Hashrate eine konkurrierende Tiefenkette von Bestätigungen abgibt. |
| abgeschlossen | Beweis des Pfahls | abgeschlossen | Extrem unwahrscheinlich muss> 2/3 Validatoren eine konkurrierende Kette abschließen, sodass mindestens 1/3 abgeschnitten werden muss. |
Hinweis: Die JSON -RPC -Spezifikation steht noch in aktiver Entwicklung. Benennungsänderungen sollten weiterhin zu erwarten sind.
Nächste Schritte
Wir hoffen, dass dieser Beitrag Anwendungsentwickler hilft, sich auf den mit Spannung erwarteten Übergang zum Beweis für die Beteiligung vorzubereiten. In den nächsten Wochen wird ein langlebiges TestNet durch die breitere Community zum Testen zur Verfügung gestellt. Es gibt auch eine bevorstehende Gemeinschaftsanruf zusammenführen Für Infrastruktur-, Werkzeug- und Anwendungsentwickler stellen Sie Fragen und hören Sie die neuesten technischen Updates zur Zusammenführung. Wir sehen uns dort 👋🏻 👋🏻
Vielen Dank an Mikhail Kalinin, Danny Ryan und Matt Garnett für die Überprüfung der Entwürfe dieses Beitrags.
