Da das MEV-Problem von der Grundursache her schwer zu lösen ist, sind faire Wettbewerbsmaßnahmen die einzige Möglichkeit, Sicherheitsrisiken zu vermeiden. Nach der Fusion von Ethereum startete Flashbots MEV-Boost, das den PBS-Mechanismus (Proposer-Builder Separation) nutzt, um die Möglichkeiten für Validatoren zur direkten Teilnahme zu verringern, um die Fairness zu wahren und den Skaleneffekt großer Pfandpools auf die MEV-Extraktion zu verringern in MEV-Aktivitäten und Umwandlung der MEV-Stakeholder-Vielfalt. Derzeit liegt der Anteil der MEV-Boost-Blöcke bei über 90 %.
Mit der weit verbreiteten Einführung von MEV-Boost machte sich die Ethereum-Community Sorgen über die Sicherheitsrisiken, die durch die Verwendung dieses Drittanbieterdienstes entstehen könnten. Daher wurde die Idee geboren, PBS innerhalb des Ethereum-Protokolls zu implementieren ePBS (Enshrined Proposer-Builder Separation). Kürzlich wurde ePBS eine offizielle EIP-Nummer zugewiesen: EIP-7732. EIP-7732 ist eine Änderung der Konsensschicht, ohne dass Änderungen an der Ausführungsschicht erforderlich sind. Der Kern besteht darin, die Ausführungsüberprüfung logisch und zeitlich von der Konsensüberprüfung zu trennen und die Ausführungsüberprüfung aufzuschieben, bis die Konsensüberprüfung abgeschlossen ist.
EIP-7732 wird vorgeschlagen. Neben der Lösung des Problems, dass Verifizierer beim Erstellen von Ausführungsnutzlasten auf Dritte (wie MEV-Boost) angewiesen sind, zielt es auch darauf ab, die Effizienz im Verifizierungsprozess zu optimieren. Aktuelle Validatoren müssen in sehr kurzer Zeit (innerhalb von 4 Sekunden) den gesamten Konsens vervollständigen und Zustandsübergangsfunktionen ausführen, was extrem hohe Anforderungen an Rechenressourcen und Netzwerkbandbreite stellt. Während dieses Zeitfensters müssen Validatoren eine große Menge an Transaktionsinformationen überprüfen und bestätigen und den Status der Blockchain aktualisieren, was nicht nur den Rechenaufwand eines einzelnen Knotens erhöht, sondern auch die Möglichkeit von Fehlern erhöht. Durch die Trennung von Ausführungsüberprüfung und Konsensüberprüfung wird sichergestellt, dass Knoten innerhalb des kritischen 4-Sekunden-Fensters nur relativ wenige Aufgaben erledigen müssen, wodurch der Rechenaufwand reduziert und die Netzwerkausbreitung beschleunigt wird.
EIP-7732 schafft eine neue Rolle „Builder“, die eine neue optionale Verantwortung des Validators darstellt, der über genügend Mittel verfügt, um sich an der Beacon-Kette zu beteiligen, und über die Fähigkeit verfügt führt Blockbauaufgaben aus und kann Baumeister werden. Der Bauunternehmer ist für den Bau und die Abgabe von Zusagen zur Ausführung der Nutzlast verantwortlich. Validatoren können nun die Ausführung von Nutzlasten an Builder auslagern und sich dabei mehr auf Aufgaben auf Konsensebene konzentrieren.
Execution Payload ist der Kernteil des Blocks und enthält alle Transaktions- und Statusänderungsinformationen. Der Prozess zum Erstellen einer Ausführungsnutzlast umfasst das Auswählen von Transaktionen aus dem Speicherpool, das Sortieren von Transaktionen, das Ausführen von Transaktionen nacheinander und das Packen aller Informationen, um eine Ausführungsnutzlast zu bilden.
Um diese Trennung zu erreichen, entfernt EIP-7732 das ExecutionPayload-Feld, das alle Daten im Zusammenhang mit der Transaktionsausführung enthält, wie z. B. Transaktionsliste und Zustandsübergangsergebnisse. Durch das Entfernen dieses Felds wird die Erstellung und Überprüfung des Ausführungsinhalts von der Erstellung und Überprüfung des Beacon-Blocks getrennt. Als Alternative führt EIP-7732 eine neue Datenstruktur ein, SignedExecutionPayloadHeader, die das Versprechen des Builders über eine Ausführungsnutzlast enthält, die in Zukunft bekannt gegeben wird.
Aufgaben des Builders: Der Builder ist für die Erstellung der Ausführungsnutzlast und die Generierung eines Versprechens verantwortlich, das die Ausführungsnutzlast offenlegt. Das Versprechen ist in einer SignedExecutionPayloadHeader-Datenstruktur gekapselt, die einen Hash der Ausführungsnutzlast und eine digitale Signatur dieses Hashs enthält, um die Unveränderlichkeit der Daten und die Überprüfung der Herkunft sicherzustellen. Dieses Versprechen gibt an, dass der Builder die gesamte Ausführungsnutzlast zu einem bestimmten Zeitpunkt in der Zukunft offenlegen wird, und gibt einen Betrag an, der an den Beacon-Block-Vorschlagsgeber zu zahlen ist, um den Beacon-Block-Vorschlagsgeber zu motivieren, dieses Versprechen aufzunehmen.
Die Aufgaben des Beacon-Block-Proposer: Der Beacon-Block-Proposer (Validator) arbeitet mit dem Builder zusammen und muss sich beim Erstellen eines neuen Beacon-Blocks nicht direkt um die Ausführungsdetails der Transaktion kümmern, sondern beinhaltet die vom Builder bereitgestellte Verpflichtung. und dann den gesamten Beacon-Block an das Ethereum-Netzwerk senden, um einen Konsens zu erzielen. Die ausschließliche Einbeziehung von Verpflichtungen verringert die Belastung des Netzwerks und beschleunigt die Verbreitung von Beacon-Blöcken und den Konsensüberprüfungsprozess. Nachdem die Zusage des Bauherrn verarbeitet wurde, wird das Trinkgeld in der Zusage vom Beacon-Kettensaldo des Bauherrn abgezogen und dem Antragsteller des Beacon-Blocks gutgeschrieben. Nachdem ein Beacon-Block-Vorschlagsgeber erfolgreich einen Beacon-Block mit einer Zusage gesendet hat, muss der Builder die gesamte Ausführungsnutzlast innerhalb eines bestimmten Zeitfensters offenlegen.
PTC-Verifizierung: Um zu überwachen, ob Bauherren öffentliche Nutzlasten rechtzeitig ausführen, bildet eine Gruppe von Validatoren, die zufällig vom Beacon Chain-Netzwerk ausgewählt werden, das Payload Timeliness Committee (PTC). Der PTC ist dafür verantwortlich, zu prüfen, ob der Builder innerhalb des angegebenen Zeitfensters eine Ausführungsnutzlast bereitgestellt hat, die dem Versprechen entspricht. Wenn der Bauunternehmer die Offenlegung nicht rechtzeitig und korrekt versäumt, wird PTC ein negatives Ergebnis veröffentlichen und dem Bauunternehmer eine Strafe in Form einer Reduzierung des Einsatzes auferlegen. Wenn die PTC-Verifizierung erfolgreich ist, wird die vollständige Überprüfung der Ausführungsnutzlast zurückgestellt, um im nächsten Beacon-Block separat verarbeitet zu werden, d. h. die verzögerte Überprüfung.
Darüber hinaus führt der Vorschlag auch Regulierungsregeln und einen neuen Strafmechanismus für PTC ein, um die Strenge und Fairness des gesamten Verifizierungsprozesses sicherzustellen. Gleichzeitig wurde aufgrund der Trennung von Ausführungsnutzlasten und Beacon-Blöcken auch die Fork-Auswahllogik angepasst, um sie an den neuen Verifizierungsprozess anzupassen. Es wird erwartet, dass diese Änderungen die Sicherheit und Effizienz des Netzwerks erheblich verbessern. Durch eine Reihe von Designs verbessert EIP-7732 die Verarbeitungseffizienz von Ethereum und reduziert die Netzwerklatenz.
Das obige ist der detaillierte Inhalt vonWie optimiert EIP-7732 (ePBS) den Blockverifizierungsprozess?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
