Geschrieben von: Tia, Techub News
Der Prozess zur Lösung des MEV-Problems besteht eigentlich darin, die Regeln für die Zuweisung von Blockraum neu zu schreiben. Ich glaube, dass MEV nicht mehr jedem unbekannt ist, aber wenn Sie wissen möchten, worüber einige Governance-Vorschläge von Ethereum MEV sprechen, müssen Sie möglicherweise noch einige Hintergrundinformationen ergänzen. Daher hat dieser Artikel eine Reihe von Fragen zur Governance geklärt von MEV seit der Umstellung von Ethereum auf PoS. Ich hoffe, Ihnen einige Hintergrundinformationen liefern zu können.
PBS (Proposer Builder Separation)
Vor der Ethereum-Fusion bestand die Lösung von MEV in der Verwendung von MEV-Geth, einem von Flashbots entwickelten modifizierten Go-Ethereum-Client. Die Kernidee besteht darin, den Bergleuten zu ermöglichen, sich auf ihre Arbeit – den Bergbau – zu konzentrieren, anstatt sich am MEV-Wettbewerb zu beteiligen, und so mögliche Umstrukturierungsprobleme zu vermeiden. Der Mechanismus von MEV-Geth ist sehr einfach. Es handelt sich um eine marktorientierte Lösung, d. Durch diesen ausgeklügelten marktorientierten Mechanismus können alle Parteien Vorteile erzielen und gleichzeitig bestimmte Einschränkungen schaffen. Obwohl der Suchende einen Teil des Gewinns mit den Minern teilen muss, erhält er im Gegenzug eine sicherere Garantie gegen Diebstahl durch die Miner. Wenn Sucher, die Haupteinnahmequelle, in der Falle sitzen, werden auch Miner passiv anfangen, MEV-Geth zu nutzen, und werden durch den Mechanismus von MEV-Geth weiter eingeschränkt. MEV-Geth führt eine Whitelist von Minern. Nur Miner auf der Whitelist können Suchpakete erhalten. Indem den Minern Reputationsbeschränkungen auferlegt werden und Miner, die Suchergebnisse stehlen, von der Whitelist entfernt werden, kann verhindert werden, dass Miner den MEV-Gewinn des Suchers stehlen.
Da sich die Blockgenerierungsmethode jedoch nach der Fusion dahingehend ändert, dass Antragsteller zufällig aus Validatoren ausgewählt werden, um Blöcke vorzuschlagen, ist die Reputationsbeschränkungsmethode, mit der Antragsteller daran gehindert werden sollen, MEV zu schnappen, nicht mehr durchführbar.
Eine mögliche Lösung besteht darin, den Blockinhalt für Validatoren unsichtbar zu machen. Eine weitere Verbesserung in dieser Denkrichtung ist PBS (Proposer Builder Seperatioin, Proposer Builder Seperatioin). PBS zerlegt die Verantwortlichkeiten des Prüfers des Antragstellers weiter in Blockbau und Blockvorschläge und lagert die komplexen Baurechte, die möglicherweise mit dem Wettbewerb um Interessen verbunden sind, an den Bauherrn aus. Auf diese Weise wird die Arbeit des Antragstellers sehr einfach und es müssen nur Blöcke vorgeschlagen werden basierend auf dem Gewinn des Bauherrn aus der Einreichung des Blocks.
Ursprünglich wollte Ethereum PBS während der Zusammenführung in das Protokoll einbetten, aufgrund der potenziellen Komplexität wurde dieser Prozess jedoch auf Eis gelegt, wodurch MEV-Boost die Möglichkeit erhielt, in PBS einzugreifen. Derzeit wird PBS durch MEV-Boost implementiert, das von Flashbots entwickelt wurde. Neben dem Bauherrn und dem Antragsteller gibt es auch eine sehr wichtige Rolle – den Vermittler. Der Builder sendet den Block nicht direkt an den Antragsteller, sondern über ein drittes Rollen-Relay.
Denn es gibt noch andere Probleme, die gelöst werden müssen, beispielsweise wie sichergestellt werden kann, dass der Bauunternehmer den Antragsteller bezahlt und ihm am Ende den Blockinhalt offenlegt, um zu vermeiden, dass der Antragsteller für die Einreichung eines leeren Blocks bestraft wird B. sicherstellen, dass der vom Builder-Block übermittelte Bereich definitiv in die Beacon-Kette usw. aufgenommen wird. Diese Fragen des Schutzes der Rechte und Interessen von Bauherrn und Antragstellern werden hauptsächlich durch Relais umgesetzt.
Der Builder sendet die Blöcke an das Relay, und dann sortiert das Relay die Blöcke nach dem Gewinn, der mit jedem Block erzielt werden kann, und sendet dann den Blockheader mit dem höchsten Gewinn an den Antragsteller, um sicherzustellen, dass der Antragsteller dies nicht tut für den Blockinhalt sichtbar. Das Relay wird dem Antragsteller den vollständigen Block erst offenlegen, wenn der Antragsteller sich zum Blockvorschlag verpflichtet (den Blockheader signiert). Das vom Bauunternehmer an den Antragsteller gezahlte Honorar erfordert außerdem die Hilfe eines Relais, um die Fertigstellung sicherzustellen. Die an den Antragsteller gezahlte Transaktion ist im übermittelten Block enthalten. Da der Antragsteller den Inhalt des Blocks jedoch nicht sehen kann, muss sie vorab noch vom Relay bestätigt werden.
In-Protokoll & Out-Protokoll
Um am durch MEV-Boost aufgebauten Markt teilzunehmen, müssen Validatoren ein MEV-Boost-Programm eines Drittanbieters ausführen, das nicht zu Ethereum gehört, während sie gleichzeitig den Ethereum-Konsens-Client und den Ausführungs-Client ausführen. Das ist die Magie des derzeit laufenden PBS, das es Dritten außerhalb des Protokolls ermöglicht, sich an der Gestaltung von Regeln für die Konsensbildung von Ethereum zu beteiligen. Aus Eigentümersicht ist das unglaublich.
Dies löste auch Überlegungen zur „Glaubwürdigkeit“ des Protokollmechanismus aus, wie die Glaubwürdigkeit gestärkt wird und wie sie durch andere Mechanismen untergraben wird. MEV-Boost ist ein gutes Beispiel, da es Situationen geben kann, in denen externe Protokolle Änderungen an bestehenden Mechanismen vornehmen. Wenn das Protokoll selbst ins Hintertreffen gerät, können solche Änderungen von außen aufkeimen. Das Aufkeimen externer Mechanismen muss der aktuellen Marktnachfrage gerecht werden, aber ob der externe Mechanismus glaubwürdig ist und ob er konsequent darauf ausgelegt ist, die Entstehung von Potenzial zu verhindern Probleme und sogar externe Mechanismen, die das Abkommen untergraben könnten, sind noch nicht bekannt.
Zentralisiertes Relais
Der am meisten kritisierte Aspekt von MEV-Boost ist sein zentralisierter Relaismarkt. Dieses Setup führt jedoch zu Vertrauensproblemen. Bauherren müssen darauf vertrauen, dass das Relais ihr MEV nicht stiehlt. Antragsteller müssen außerdem darauf vertrauen, dass die Blockheader, die sie vom Relay erhalten und signieren, gültig sind. Trotz ihrer wichtigen Rolle gibt es jedoch keinen finanziellen Anreiz für Relais, und ihr Betrieb ist mit erheblichen Kosten verbunden. Letztes Jahr gab es 11 Relays, die das Ethereum-Netzwerk unterstützten, aber heute bieten nur noch 9 Relays Dienste an.
Es ist erwähnenswert, dass für Relays kein Zugriff erforderlich ist. Relays wie Eden leiten nur ihre eigenen Builder weiter. Es gibt auch Relays wie bloXroute, die behaupten, Transaktionen im Zusammenhang mit Front-Running- und Sandwich-Angriffen herauszufiltern. Teilweise verfügt die Staffel auch über bestimmte Regelsetzungsrechte.
Die Daten stammen vom Rated Network
Darüber hinaus kann aus Sicht der Lebendigkeit aufgrund der Existenz eines Relais keine Bestätigung auf atomarer Ebene zwischen dem Erbauer und dem Antragsteller erfolgen. Wenn der Antragsteller eine Verpflichtung zum Blockheader unterzeichnet und der Builder auch den Nutzlastinhalt bereitstellt, das Relay den Inhalt jedoch nicht rechtzeitig übermittelt (ob böswillig oder nicht), erleiden der Builder und der Antragsteller Verluste.
ePBS: Einkapselung von PBS in Ethereum
Ob es darum geht, das Problem der Relay-Zentralisierung zu lösen oder Teile außerhalb des Protokolls in das Protokoll zu verschieben, die Kapselung von PBS in Ethereums ePBS scheint zu einem Muss geworden zu sein. Derzeit ist ePBS kein zur Diskussion stehender Vorschlag mehr, und der Ethereum-EIP-Herausgeber hat ihm eine Nummer zugewiesen – EIP-7732.
ePBS bietet Antragstellern und Bauherren eine vertrauenswürdige Infrastruktur für die Auslagerung von Blockbaurechten. Die Rolle des Builders, die ursprünglich außerhalb des Protokolls lag, wurde in das Protokoll aufgenommen, das heißt, eine weitere Rolle des Builders wird unter den Validatoren aufgeteilt. Der Builder muss als Validator auch das Versprechen in Ethereum erfüllen. Da die Verantwortlichkeiten des ursprünglichen Antragstellers der Konsensschicht aufgeteilt wurden, erfordert die Vervollständigung von ePBS Änderungen an der Konsensschicht. Unter anderem ist der Builder für die Erstellung der Ausführungsnutzlast (die endgültige Liste der im Block auszuführenden Transaktionen) verantwortlich. Die Verantwortung des Antragstellers besteht darin, Beacon-Blöcke vorzuschlagen. Der spezifische Prozess ist wie folgt:
Nachdem Sie wissen, dass er als Antragsteller ausgewählt wurde, erstellen und senden Sie die Einschlussliste (IL, d. h. die Transaktionen, die in diesem Slot enthalten sein müssen).
Die Builder senden den Block-Hash mit der Ausführungsnutzlast und der Verpflichtung „SignedExecutionPayloadHeader“, die bereit ist, den Antragsteller an den Antragsteller zu zahlen (die Ausführungsnutzlast muss die IL erfüllen).
Der Antragsteller wählt einen der von den Buildern gesendeten „SignedExecutionPayloadHeader“ aus, um ihn einzuschließen (normalerweise den mit dem höchsten an den Antragsteller gezahlten Preis). Und senden Sie den vorgeschlagenen Beacon-Block „SignedBeaconBlock“.
Zeugen nehmen Zeugenaussagen wahr
Aggregatoren übermitteln Attestierungsaggregate; Builder senden gleichzeitig Ausführungsnutzlasten
PTC (Payload Timeliness Committee, in jedem Slot werden 512 Validatoren als PTC-Mitglieder ausgewählt) prüft, ob der Builder die Ausführungsnutzlast rechtzeitig offenlegt und sendet das Ergebnis
Auch ePBS hat vom Zeitpunkt seines Vorschlags bis zur endgültigen Erlangung der EIP-Nummer viele Diskussionen durchlaufen. Ursprünglich wurde PBS am 21. Juni von Vitalik vorgeschlagen und vier Monate später wurde die Single-Slot-Lösung verbessert. Erst am 23. Juli wurde die Idee von PTC offiziell vorgeschlagen .
PEPC (Protokollgestützte Verpflichtungen des Anbieters)
Natürlich gibt es auch diejenigen, die mit ePBS nicht einverstanden sind und stattdessen auf andere Lösungen hoffen. PEPC ist so. ePBS bettet eine bestimmte Regel in das Protokoll ein, aber hier bei PEPC verkauft der Antragsteller programmierbare Blockkonstruktionsrechte.
PEPC wurde im Oktober 2022 von Barnabe vorgeschlagen. Barnabe ist der Ansicht, dass, wenn der PBS-Mechanismus innerhalb des Protokolls implementiert werden soll, die Implementierung eines allgemeinen Mechanismus für die vertrauenswürdige Signalübertragung in Betracht gezogen werden sollte, anstatt einen spezifischen vertrauenswürdigen Signalmechanismus zu implementieren (z. B. wenn ich gebeten werde, einen Block zu erstellen). gib dir xx ETH zurück).
Genau wie der Name PEPC (Protocol-Enforced Proposer Commitments) gibt es einige Mechanismen, um sicherzustellen, dass die Rechte und Interessen von Bauherren und Antragstellern durch die vom Antragsteller innerhalb des Protokolls eingereichten Verpflichtungen erfüllt werden. Diese Verpflichtungen können in der Kette überprüft werden, hauptsächlich durch Operationscodes „BEACONROOT“ zu erreichen. Dabei handelt es sich um einen allgemeineren Mechanismus, mit dem alle Blockbaurechte oder nur ein Teil der Blöcke ausgelagert werden können. Das heißt, der Anbieter verkauft programmierbare Blockbaurechte.
Zusammenfassung
Das Obige ist eine kurze Einführung in PBS, ePBS und PEPC. Aus Sicht des Protokolldesigns ist es nicht nur notwendig, einen Marktmechanismus zur Umverteilung von MEV zu entwerfen, sondern auch zu überlegen, wie Validatoren stärker dezentralisiert und die Zensurresistenz verbessert werden können. Darüber hinaus gibt es viele Kompromisse bei der Gestaltung des Protokolls. Nehmen wir als Beispiel ePBS, das eine EIP-Nummer erhalten hat. Obwohl das Design von ePBS das Problem der zentralen Weiterleitung löst, hat die Schlüsselrolle einer Drittpartei außerhalb der Vereinbarung wirklich nur negative Auswirkungen? Aus Sicht des Builder-Zahlungsmechanismus ist die Verwendung von Relay besser als der ePBS-Mechanismus, da es sich bei ePBS um einen Prepaid-Mechanismus handelt. Wenn der Builder einen Super-High-Profit-Block verpackt, kann er dem Antragsteller keine hohen Beträge zur Verfügung stellen der Prepaid-Mechanismus.
