Gate Ventures Research Institute: Detaillierte Analyse von MEV, Licht in den dunklen Wald bringen (Teil 2)

Weiterführende Literatur: Gate Ventures Research Institute: Detaillierte Analyse von MEV, Licht in den dunklen Wald bringen (Teil 1)

MEV-Minderungs-Erkundungsrichtung

In der Vergangenheit wurde die PBS-Lösung innerhalb des Ethereum-Ökosystems an Flashbots ausgelagert, das auf die Untersuchung des MEV-Problems von Ethereum spezialisiert ist und in der letzten Runde eine Bewertung von $1 Milliarden aufweist. Da Relayer jedoch keinen wirtschaftlichen Nutzen hat und die Realisierung von Relay hohe technische und wirtschaftliche Hürden erfordert, hat Blocknative die Forschung und Entwicklung dieses Track-Projekts aufgegeben. Um die Probleme der Dezentralisierung und der fehlenden wirtschaftlichen Anreize zu lösen, erwägt Ethereum auch, Verbesserungen auf e-PBS-Protokollebene zu verwenden, um die Existenz von Relayer basierend auf dem Drittanbieterprotokoll mevboost zu vermeiden.

MEV scheint derzeit ein Problem zu sein, das nicht gut gelöst werden kann, da es im Wesentlichen das unvermeidliche Produkt der zunehmenden Komplexität des Ökosystems und der Informationsasymmetrie innerhalb des Benutzerzeitraums ist. Für den dunklen Wald von Ethereum, insbesondere unter dem Einfluss der Hacker-Idee von Erlaubnisfreiheit und Zensurresistenz, kann Ethereum MEV nicht auf einmal auf Protokollebene überprüfen und verbessern. Dies ist unmöglich und wird nicht passieren. Im Ethereum-Ökosystem werden mehr Anstrengungen unternommen, um die negativen externen Effekte von MEV zu verringern und seine positiven externen Effekte zu verbessern. Viele Projekte, Community-Mitglieder, Entwickler und VCs erkunden einige Wege, die einen Versuch wert sind, was viele potenzielle Möglichkeiten mit sich gebracht hat. Als Nächstes werden wir kurz einige Versuche zur Abschwächung negativer externer Effekte vorstellen. Im Allgemeinen gehen alle Versuche in drei Richtungen: Protokollebene, Anwendungsebene und Auktionsmechanismus.

SUVAE

SUAVE (Single Unifying Auction for Value Expression) wurde von Flashbots vorgeschlagen, um die negativen externen Effekte von MEV zu verbessern. Ebenso greift es nicht auf die Lösung von MEV zurück, sondern führt MEV dazu, dezentralisiert und transparent zu werden.

SUAVE-Kettenarchitektur, Quelle: Flashbots

Es erstellt eine neue Blockchain SUAVE mit einer integrierten MEVM-virtuellen Maschine, die EVM-Smart Contracts ausführen kann. Gleichzeitig können die unterstützenden Entwicklertools die Entwicklung von MEV-Smart Contracts auf Basis der EVM-virtuellen Maschine unterstützen. Dadurch kann jede heute zentralisierte MEV-Infrastruktur in Smart Contracts auf dezentralen Blockchains umgewandelt werden. Dies senkt die Schwelle für die Erstellung neuer MEV-Anwendungen erheblich, maximiert den Wettbewerb zwischen verschiedenen Mechanismen und bringt Dezentralisierung und Transparenz. Schließlich hilft es, das Zentralisierungsproblem der MEV-Industriekette zu zerstreuen, indem zentralisierte Infrastrukturen (Builder, Relayer, zentralisiertes RFQ-Routing usw.) als Smart Contracts auf dezentralen Blockchains programmiert werden können.

Rollup-Transaktionslieferkette, Quelle: dba:

SUAVE kann als dezentrale Sortier- und Absichtserkennungsmaschine verwendet werden, um dem Antragsteller in der Kette zu übermitteln, und schließlich Ethereum als Abwicklungsebene verwenden. Der Ausführungsknoten wird außerhalb der Kette ausgeführt, wobei eine vertrauenswürdige Ausführungsumgebung oder eine Zero-Knowledge-Proof-Technologie verwendet wird. Benutzer können Absichtstransaktionen verwenden, die Transaktion zur Analyse an SUAVE übergeben und transparente MEV maximieren, um MEV-Auktionen zwischen Smart Contracts durchzuführen, sodass negative externe Effekte durch transparente Marktmechanismen effektiv gemildert werden können. Gleichzeitig ist laut Paradigms Anwendungssteuerartikel beispielsweise die Erhebung von Anwendungssteuern auf das Verhalten von MEV-Bots auch besser für die Implementierung auf SUAVE geeignet. Und Paradigm ist zufällig der Berater und Investor dieses Projekts.

OFA

Nehmen wir OFA (Order Flow Auction) als Beispiel, um uns die Verbesserungen des Auktionsmechanismus anzusehen.

OFA-Auktionsmechanismus, Quelle: Pionierforschung

1. Der Auftragsinitiator (Wallet/Anwendung) sendet den Auftrag an OFA, und OFA gibt selektiv einige Informationen weiter, darunter den Auftragswert usw. Dies ist ein Designbereich.

2. Bieter geben Gebote ab, holen die entsprechenden Informationen ein und schlagen einen Preis vor, der für diesen Auftragsfluss gezahlt werden kann. Anschließend führen die Bieter für diesen Auftragsfluss einen MEV durch.

3. Dieser Teil des privaten Auftragsflusses ist nur für Bieter sichtbar. Nach der Einführung des Marktwettbewerbs kann MEV transparenter gestaltet und Benutzerverluste minimiert werden.

Derzeit werden in der Branche viele Projekte entwickelt, die auf dem OFA-Auktionsmechanismus basieren. Der allgemeine Betriebsmechanismus und der Prozess sind sehr ähnlich. Der Unterschied liegt in den Details und Implementierungsmethoden der vier Kernkomponenten.

Verschlüsselung privater Handelspools

OFA ähnelt dem Aufbau eines privaten Transaktionspools, aber diese Benutzeraufträge können nur von Bietern extrahiert werden, die nach einem bestimmten Auktionsmechanismus gewinnen, und die Auktionsgebühr wird an den Auftragsinhaber zurückgegeben. Tatsächlich gibt es unter dieser Architektur im Rahmen des Auktionsmechanismus immer noch eine gewisse MEV-Extraktion. Der Memory Privacy Pool hofft, das Vertraulichkeitsproblem der Sucher zu lösen, da Sucher die Hauptteilnehmer an MEV sind. Daher können die Aufträge nur über den Privacy Transaction Pool nur von Relayern und Blockbuildern gesehen werden. Unter anderem bedeutet Verschlüsselung, dass Benutzertransaktionen möglicherweise mehr Gas bezahlen müssen, was an sich optional sein sollte. Derzeit gibt es mehrere Verschlüsselungsmethoden, die es wert sind, untersucht zu werden.

1. Multi-Party-Computation (MPC): Mehrere Parteien verwenden MPC, wodurch Transaktionsdetails vor mehreren Parteien verborgen werden. MPC kann auch beim gemeinsam genutzten Sortierer angewendet werden, um die zentrale Leistung eines einzelnen Sortierknotens zu verteilen.

2. Überprüfbare Verzögerungsfunktion VDF: Die Berechnung dieser Funktion dauert eine bestimmte Zeit T. Sobald die Berechnung abgeschlossen ist, kann ihre Richtigkeit schnell überprüft werden. Durch die Verwendung von VDF kann die Transaktionsreihenfolge auf eine serielle Ausführung geändert werden. Dies führt jedoch in vielen Benutzerumgebungen zu einer sehr schlechten Erfahrung. Die Verzögerungszeit T ist ein Wert im Rahmen eines Kompromisses.

3. Schwellenwertverschlüsselung TSS: Ermöglicht mehreren Teilnehmern, am Ver- und Entschlüsselungsprozess teilzunehmen, ohne dass ein einzelner Teilnehmer den vollständigen Schlüssel besitzen muss. Schwellenwertverschlüsselung kann Front-Running-Angriffe wirksam verhindern, indem sie den Transaktionsinhalt verschlüsselt, um zu verhindern, dass Angreifer die Transaktionsdetails sehen, bevor die Transaktion bestätigt wird. Im Vergleich zu MPC ist TSS einfacher und besser für die Generierung einzelner Signaturen und privater Schlüssel geeignet. Shutter Network verwendet TSS, wodurch Validierer Transaktionen sortieren und verpacken können, ohne den Transaktionsinhalt zu kennen, wodurch MEV-Angriffe verhindert werden.

4. Der Zero-Knowledge-Proof ZKP kann die Richtigkeit von Informationen überprüfen, ohne bestimmte Informationen zu veröffentlichen. Derzeit wird seine Entwicklung hauptsächlich durch die Entwicklung von Hardware beeinflusst, die teuer ist und deren Kommerzialisierung Zeit in Anspruch nimmt. Automata Network hat ein Datenschutz-Relay-Netzwerk namens Conveyor vorgeschlagen, das Multi-Party-Computing (MPC) und Zero-Knowledge-Proof verwendet, um die Transaktionsvertraulichkeit zu schützen und es Prüfern gleichzeitig zu ermöglichen, die erforderlichen Berechnungen durchzuführen.

Vergleich von Verschlüsselungsverfahren für private Handelspools, Quelle: Flashbots

Es gibt viele optionale Verschlüsselungsalgorithmen für private Transaktionspools, darunter MPC, TSS, VDF, ZKP usw., aber jeder Verschlüsselungsalgorithmus hat seine Nachteile, die Entwickler abwägen müssen. Zu den explorativen Projekten gehören unter anderem Shutter Network, das den TSS-Algorithmus verwendet, und Automate Network, das MPC und ZKP zur Lösung von MEV verwendet, die es wert sind, beachtet zu werden.

Ausführungstickets

Execution Tickets ist eine Lösung für MEV, die Justin beim Columbia Cryptoeconomics Workshop vorgeschlagen hat. Es ist eine Verbesserung auf Konsensebene und umfasst drei Schritte:

1. Es wird ein Ticketmarkt vorgeschlagen, auf dem Personen, die Tickets erwerben, die Qualifikation erwerben können, zu einem bestimmten Zeitpunkt in der Zukunft Ausführungsblöcke vorzuschlagen. Durch den dynamischen Preismechanismus können die Anzahl der im Umlauf befindlichen Tickets und der Preis des bestehenden Angebots in Echtzeit angepasst werden. Der spezifische Slot für jedes Ticket wird ebenfalls zufällig ausgewählt.

2. Es unterteilt Blöcke in zwei Typen: Ausführung und Vorschlag. Die Blockvorschlaggeber werden nach dem Zufallsprinzip ausgewählt und um für die Blockausführung in Frage zu kommen, ist ein Ticket erforderlich.

3. Der Ticketinhaber des Ausführungsblocks hat das Recht, den Ausführungsblock innerhalb des zugewiesenen Zeitraums vorzuschlagen und die entsprechenden Belohnungen der Ausführungsebene zu erhalten (EL-Belohnungen = TX-Gebühren + MEV). Der Vorschlagende des Ausführungsblocks muss eine Hypothek bereitstellen, um sicherzustellen, dass er den Ausführungsblock im zugewiesenen Slot generiert. Wenn er doppelt ausgibt oder offline geht, wird die Hypothek konfisziert.

Slots sind in Ausführungsrunden und Beacon-Runden (Konsensrunden) unterteilt. Wenn ein Ticket zerstört wird, wird das entsprechende ETH zerstört, was den Deflationsdruck von ETH erhöht. Da der Ausführungsblock und der Konsensblock zufällig ausgewählt werden, erhöht dies die Möglichkeit einer Absprache zwischen den beiden erheblich. Das Problem ist:

1. Dieser Mechanismus führt jedoch zum Problem mehrerer MEVs, d. h. dem Kauf von Ausführungstickets für mehrere aufeinanderfolgende Blöcke, was den Gewinn von MEV erhöhen kann, um die Kosten für den Ticketkauf auszugleichen. Daher erfordert dieser Mechanismus ein gutes Design der Ticketpreisänderungsfunktion.

2. Dieser Mechanismus löst das Problem der MEV-Sandwich-Angriffe der Benutzer noch immer nicht, sondern gleicht die Verluste der Benutzer lediglich durch die Deflation des gesamten Netzwerks aus.

e-PBS

Tatsächlich hat Ethereum nach Merge kein PBS implementiert, d. h. sowohl Builder als auch Block-Vorschlagssteller müssen aus Validierern auswählen. Um jedoch den wirtschaftlichen Nutzen des Netzwerks zu maximieren, wird MEV-Boost als PBS-Protokolllösung eines Drittanbieters verwendet, das derzeit einen Marktanteil von 90% Relayer hat.

e-PBS (enshrined PBS) ist Ethereums Lösung für den Umgang mit der Vertrauens-Middleware, die von MEV-Boost Relay als Drittanbieter erstellt wurde. Es integriert PBS in die Konsensebene und verlässt sich nicht mehr auf Flashbosts, einen Drittanbieter, der eine Out-of-Protocol-Lösung bereitstellt. Der Vorschlag trägt den Codenamen EIP-7732. Das Ziel dieses Protokolls besteht darin, der Ethereum-Protokollschicht die Implementierung einer vertrauensminimierten PBS-Lösung zu ermöglichen, die überwiegende Mehrheit der MEVs durch Mechanismen innerhalb des Ethereum-Protokolls zu erfassen und die erfassten MEVs auf eine Weise an die Teilnehmer zu verteilen, die die Vorteile des Ethereum-Protokolls maximiert. Das e-PBS ähnelt dem Workflow, den wir im Abschnitt PBS erwähnt haben, aber seine Besonderheit besteht darin, dass die Relayer-Rolle eliminiert wird und das Angebot des Builders an den Proposer in den Code der Konsensebene geschrieben wird.

ePBS-Ausführungsflussdiagramm, Quelle: Abonnieren

Die obige Abbildung zeigt den Slot-N-Prozess unter dem ePBS-Mechanismus:

1. Blockübertragung: Bei t = 0 schlägt der ausgewählte POS-Validator einen Konsensschichtblock (CL) für Slot N vor, der das Auktionsblockgebot des Builders enthält, jedoch keine Ausführungsverbindlichkeiten.

2. Beweisfrist: Zum Zeitpunkt t=t1 wählt das Komitee den richtigen Block gemäß den Fork-Regeln aus und beweist ihn.

3. Gesamtbeweis und Payload-Ausbreitung: Bei t = t 2 wird der Gesamtbeweis von Slot N zur Überprüfung gesendet. Gleichzeitig veröffentlicht der Ersteller seine ExecutionPayload, um eine vollständige Version des Blocks zu erstellen.

4. PTC-Abstimmungsübertragung: t = t 3, PTC ist dafür verantwortlich, zu überwachen, ob die Builders Payload gemäß den Regeln ausgeführt wird, und zu beurteilen, ob ihr Zeitpunkt gültig ist.

5. Bei t=t4 ist es entscheidend, ob der Antragsteller des nächsten Blocks den Block von SlotN als leeren Block oder als korrekt erstellten vollen Block ansieht, was eine Beurteilung durch den Antragsteller des nächsten Blocks auf Grundlage der Abstimmung und des Beweises von PTC erfordert.

Es ist wichtig zu beachten, dass der Builder, um sicherzustellen, dass er die Blocklast innerhalb eines Slots rechtzeitig übermitteln kann (unter Ethereum 2.0 muss auch sichergestellt werden, dass das Validierungskomitee innerhalb eines bestimmten Zeitraums abstimmt und Blöcke vorschlägt), im PBS auf Protokollebene immer noch dazu neigt, den Payload-Inhalt später zu veröffentlichen, damit mehr Möglichkeiten bestehen, MEV zu finden. Daher wird im Protokoll das PTC (Payload-Timeliness Committee) eingeführt. Wie der Name schon sagt, handelt es sich dabei um einen Überwachungsmechanismus für Payload-Builder. Das PTC kann den Builder aus wirtschaftlicher Sicht dazu anregen, die Payload rechtzeitig zu veröffentlichen, um die Sicherheit von Ethereum zu gewährleisten. Wenn die Payload des Builders als nicht rechtzeitig definiert wird, kann der Builder die Belohnung für die entsprechende Ausführungslast nicht erhalten.

Blockanalysediagramm, Quelle: Abonnieren

Daher muss in ePBS ein vollständiger Block aus zwei Teilen zusammengesetzt werden. Einer ist ein leerer CL-Block, der vom Antragsteller am Anfang des Slots erstellt wird. Er enthält den Execution Payload Header und das Builder Bid, aber der spezifische Payload-Inhalt ist vorübergehend leer. Erst in der Phase der Proof-Aggregation und Blockausbreitung, d. h. nachdem der PTC die Gültigkeit der Payload erkannt hat, wird sie in den Block eingebaut, um einen vollständigen Block (Full Block) zu bilden.

Im Allgemeinen kann EIP-7732 ePBS Folgendes lösen:

1. Ein transparentes Blockauktionssystem ohne die Notwendigkeit einer vertrauenswürdigen Drittpartei.

2. Durch die Trennung der Konsensschicht und der Ausführungsschicht wird die Rechenlast der Validierer verringert und so die Effizienz und Geschwindigkeit des Netzwerks verbessert.

3. Validierer können sich sofort auf die Validierung des Konsenses konzentrieren und die Validierung der Ausführungslast auf einen späteren Zeitpunkt verschieben. Die Einführung zusätzlicher Zeitfenster und Abstimmungsmechanismen gewährleistet den effizienten Betrieb und die Fairness des Systems und lässt gleichzeitig mehr Zeit für die Verarbeitung der Ausführungslast.

Dennoch wurden einige Fragen zur Diskussion gestellt:

1. Im Wesentlichen ersetzt dies lediglich die Arbeit von Dritt-Relayern in der Vergangenheit, um Dezentralisierung und Transparenz im Blockvorschlagsprozess zu erreichen, löst das Problem der schlechten MEV-Erfahrung der Benutzer jedoch nicht grundlegend.

2. Dieses Upgrade ist eine Änderung der Konsensschicht und nicht abwärtskompatibel. Wenn sich das Mechanismusdesign von ePBS in der Praxis als fehlschlägt, werden nachfolgende Patches schwierig.

3. Angenommen, in einem Slot veröffentlicht der Antragsteller einen Block, aber der Builder verzögert aus irgendeinem Grund die Veröffentlichung der Ausführungsnutzlast. Zu diesem Zeitpunkt können einige Validierer auf Grundlage des Blocks des Antragstellers verifizieren, während andere auf die Ausführungsnutzlast des Builders warten, was zu einer Aufspaltung des Netzwerks führt. Eine solche Aufspaltung erhöht die Instabilität und die Wartungskosten des Netzwerks.

4. Wenn ein Antragsteller absichtlich einen Block kurz vor dem Nachweistermin veröffentlicht, kann dies dazu führen, dass einige Prüfer den Block sehen, während andere Prüfer den Block nicht sehen. Dann wird das Verhalten des Antragstellers von N+1-Slots unvorhersehbar, was die Möglichkeit von On-Chain-Forks erheblich erhöht.

PEPC

Gleichzeitig hat EigenLayer auch einige Lösungen vorgeschlagen, darunter die AVS-Komponente PEPC (Protocol-Enforced Proposer Commitments), um das MEV-Problem zu lösen. Diese Komponente soll auch das Vertrauensproblem der Dritt-Middleware Relayer lösen. Es wird hauptsächlich erwartet, dass der Proposer beim Senden des CL-Blocks eine PEPC-Signatur anhängen kann, um ein Commit durchzuführen. Der Builder überprüft den PEPC des Proposers, bevor er die Ladung ausführt, wodurch ein Vertrauensmechanismus in das Protokoll eingeführt wird. Durch den integrierten Vertrauensmechanismus kann auch das potenzielle Vertrauensproblem von Relayer als Drittpartei gelöst werden.

Verweise

MEVM, SUAVE Centauri und darüber hinaus: https://writings.flashbots.net/mevm-suave-centauri-and-beyond

Blockchains, MEV und das Rucksackproblem: eine Einführung: https://arxiv.org/html/2403.19077v1

《ENTWICKLUNG DES MEV-ÖKOSYSTEMS VON ETHEREUM 1.0》

Die Zukunft von MEV von Blockchain Capital

FRP-18: Kryptografische Ansätze für vollständigen Mempool-Datenschutz durch Flashbots

《Hinrichtungsscheine》: https://ethresear.ch/t/execution-tickets/17944

Payload-Timeliness Committee (PTC) – ein ePBS-Design: https://ethresear.ch/t/payload-timeliness-committee-ptc-an-epbs-design/16054

Haftungsausschluss:

Der obige Inhalt dient nur als Referenz und sollte nicht als Beratung angesehen werden. Bitte holen Sie immer professionellen Rat ein, bevor Sie eine Investition tätigen.

Über Gate Ventures

Gate Ventures ist der Risikokapitalzweig von Gate.io und konzentriert sich auf Investitionen in dezentrale Infrastrukturen, Ökosysteme und Anwendungen, die die Welt im Zeitalter des Web 3.0 neu gestalten werden. Gate Ventures arbeitet mit globalen Branchenführern zusammen, um Teams und Startups mit innovativem Denken und Fähigkeiten auszustatten, um soziale und finanzielle Interaktionsmodelle neu zu definieren.

Offizielle Website: https://ventures.gate.io/ Twitter: https://x.com/gate_ventures Mittel: https://medium.com/gate_ventures

Dieser Artikel stammt aus dem Internet: Gate Ventures Research Institute: Detaillierte Analyse von MEV, Licht in den dunklen Wald bringen (Teil 2)

Verbunden: Coinbase 2024 Q3 Ausblick: Aufwärtstrend ist offensichtlich und Krypto-Korrelation nimmt ab

Originalautor: Crypto, Distilled Originalübersetzung: Vernacular Blockchain Coinbase hat gerade seinen Cryptocurrency Outlook für das dritte Quartal 2024 veröffentlicht. Es ist ein ziemlich umfangreicher Bericht, und @DistilledCrypto hat alle 60 Seiten gelesen und die 10 wichtigsten Erkenntnisse, die Sie kennen müssen, unten zusammengefasst. 1. MVRV und Markttrends Wenn MVRV über seinem 365-Tage-Durchschnitt liegt, deutet dies darauf hin, dass sich der Markt in einem starken Aufwärtstrend befindet. Rückzüge, wenn MVRV Unterstützung hat, sind normalerweise Kaufgelegenheiten. Derzeit ist MVRV von der Unterstützung abgeprallt, was zeigt, dass der Aufwärtstrend noch intakt ist. 2. Bitcoin-ROI von Zyklustiefs Bitcoin hat vier Marktzyklen abgeschlossen, jeweils mit Bullen- und Bärenphasen. In diesem Zyklus ist Bitcoin seit seinem Tief im November 2022 um etwa 400% gestiegen. Dieser Zyklus ähnelt dem von 2018 bis 2022, als Bitcoin stieg…