Wie kann das Oracle MEV (OEV)-Problem mithilfe von Marktmechanismen gelöst werden?

Hinweis: Der Originaltext wurde aus einem Tweet von über 2.000 Wörtern auf dem offiziellen Twitter von Geek web3 über das OEV-Problem und seine Lösung zusammengestellt. Da dieses Thema besonders spannend ist, haben wir es in einem kurzen Artikel für Sie zusammengestellt.

Was ist OEV (Oracle MEV)

Einfach ausgedrückt: Wenn der Oracle-Betreiber eine Diskrepanz zwischen den Off-Chain- und On-Chain-Preisdaten überwacht, kann der Betreiber eine Transaktion initiieren und den vom On-Chain-Orakel wahrgenommenen Preis aktualisieren. Wenn eine Transaktion stattfindet, die den Preis des Orakels ändern kann, bedeutet dies oft die Generierung von MEV. Wir nennen dies MEV, das vom Orakel OEV (Oracle Extractable Value) abhängt.

Die Existenz von OEV hat zu einer Umverteilung von Werten zwischen verschiedenen Interessengruppen geführt, und API3 behauptet, einen Auktionsmechanismus zu verwenden, um die OEV-Umverteilung so vernünftig wie möglich zu gestalten (über Marktmechanismen zugeteilt) und zu versuchen, schnellere und kostengünstigere Preisaktualisierungen zu erzielen.

Es wird allgemein angenommen, dass die Generierung und Extraktion von OEV eine Teilmenge des MEV-Problems ist. Hier stellen wir kurz vor, wie OEV generiert wird. Die Hauptgründe liegen in den folgenden zwei Aspekten:

1. Das DeFi-System verwendet Orakel, um Preise zu erhalten und Liquidation und andere Logik basierend auf den Orakelpreisen auszuführen. Und die Liquidation von Vermögenswerten deutet oft darauf hin, dass es eine große Gewinnspanne gibt.

2. Es gibt ein fein abgestuftes Problem im Oracle-Update. Erst wenn es eine gewisse Abweichung zwischen den Off-Chain- und On-Chain-Preisen gibt, werden die On-Chain-Daten aktualisiert, die in Form einer Transaktion dargestellt werden.

Die Generierung von OEV bedeutet für Liquiditätsanbieter einen Wertverlust. Einige Daten zeigen, dass es basierend auf den beiden oben genannten Aspekten drei Möglichkeiten gibt, OEV zu generieren:

Frontrunning: Wenn OEV-Suchende überwachen, dass eine Oracle-Preisaktualisierungstransaktion im Transaktionspool angezeigt wird, können sie ihre eigenen Transaktionen vor dieser Transaktion einfügen, um die Vorteile der Preisaktualisierung zu nutzen. Dies ist der traditionellste Front-Running-Trade.

Arbitrage: Da die On-Chain-Preisaktualisierung der Oracle-Maschine von der Differenz zwischen dem On-Chain-Preis und dem Off-Chain-Preis abhängt, bedeutet dies, dass die Notierung der Oracle-Maschine mit der Notierung anderer Systeme inkonsistent sein kann und zu diesem Zeitpunkt Arbitrage-Raum entsteht.

Liquidationen: Die Preisaktualisierung des Orakels löst die Liquidation einer Reihe von Kreditpositionen aus, und der Liquidator kann während des Liquidationsprozesses eine große Menge an Liquidationseinnahmen erzielen.

Die Gewinne, die mit Frontrunning- und Arbitrage-Methoden abgehoben werden, sind eigentlich die Verluste des Liquiditätsanbieters. Was die Vorteile aus der Liquidation betrifft, so wirkt sie sich einerseits auf die Interessen des Kreditnehmers aus, da der Kreditnehmer während des Liquidationsprozesses einen erheblichen Teil der Mittel verlieren wird, und andererseits erhält der Kreditgeber aufgrund der Verzögerung des vom Orakel abgegebenen Angebots schließlich den Wert der Sicherheiten, der möglicherweise niedriger ist als erwartet. Daher wird der Rückzug von OEV in jedem Fall Verluste für das entsprechende Defi-Protokoll in Bezug auf das Verwahrungsvermögen mit sich bringen.

Der Extraktionsprozess von OEV ist im Wesentlichen Frontrunning

Für die Extraktion von OEV überwacht der Suchende die "Oracle Data Update Instructions" im Speicherpool, bündelt die Oracle Data Update Transaction Instructions mit den von ihm über die MEV-Infrastruktur initiierten Transaktionsanweisungen und führt sie schließlich aus, um Gewinne zu erzielen.

Natürlich müssen die Suchenden bei Arbitrage- und Clearing-Transaktionen nur die Abweichung zwischen dem On-Chain-Preis und dem Off-Chain-Preis überwachen und schließlich sicherstellen, dass die von ihnen initiierten Transaktionen zuerst auf der Chain über die MEV-Infrastruktur ausgeführt werden.

Unabhängig von dem Prozess, der von den Suchenden verwendet wird, können wir sehen, dass die Vorteile von OEV zwischen der MEV-Infrastruktur und den Suchenden von OEV verteilt sind und die Protokolle, die den OEV-Wert "erfassen", nicht die Vorteile erhalten, die sie verdienen. (Einigen Daten zufolge hat das OEV-Problem zuvor dazu geführt, dass fast 10% der Gewinne der GMX-Plattform weggenommen wurden)

Um dieses Problem zu lösen, hat GMX, das einen großen Teil des OEV-Wertes beigetragen hat und eine On-Chain-Derivate-Handelsplattform ist, eine einfache und grobe Methode gewählt: Lassen Sie einige von ihnen selbst benannte Personen den OEV-Wert erfassen und geben Sie dann den OEV-Wert so weit wie möglich an die GMX-Plattform zurück.

In diesem Zusammenhang hat GMX Rook und Whitelist eingeführt. Einfach ausgedrückt wird das Oracle-Update von GMX über Rook ausgeführt, und Rook wird eine OEV-Extraktionsoperation auf der Grundlage der aktuellen Marktbedingungen durchführen, um die OEV auf dem Markt zu erhalten. 80% dieser OEV werden in das GMX-Protokoll zurückgeführt.

Zusammenfassend lässt sich sagen, dass GMX Rooks das Recht gibt, das Orakel über die Whitelist zu aktualisieren, OEV über Rook zu extrahieren, um zu vermeiden, dass es von anderen Suchenden extrahiert wird, und gleichzeitig 80% des OEV an das GMX-System zurückzugeben. Diese Routine ist eigentlich ein bisschen simpel und grob.

Der OEV-Auktionsmechanismus auf der Grundlage von Marktgeboten

Bevor wir das von API3 vorgeschlagene und in den letzten Tagen viel diskutierte OEV-Auktionsschema vorstellen, stellen wir zunächst kurz das Funktionsprinzip der Oracle-Maschine von API3 vor. Der Kern von API3 wird als Airnode-Protokoll bezeichnet. Dieses Protokoll ermöglicht es API-Dienstanbietern, ihre Web2-APIs direkt in Web3-Orakel zu verpacken.

Einfach ausgedrückt verlangt das Airnode-Protokoll, dass der API-Dienstanbieter seinen eigenen privaten Schlüssel verwendet, um alle veröffentlichten Daten zu signieren. Benutzer können jederzeit die neuesten Daten und deren Signatur vom Airnode-Protokolldienstanbieter abrufen und sie dann im On-Chain-Orakel veröffentlichen, um die Daten zu aktualisieren.

Für API-Dienstanbieter erfordert das Verpacken ihrer Web2-API-Dienste als Blockchain-Orakel eigentlich nur das Hinzufügen eines Private-Key-Signaturlinks. Ein großer Teil der Infrastruktur des API-Service-Providers kann direkt wiederverwendet werden, was die Schwelle für API-Unternehmen, in den Bereich der Oracle-Maschinen einzusteigen, erheblich senkt.

Basierend auf dem Airnode-Protokoll verwendet API3 ein Auktionsschema, das dem von Flashbot ähnelt, aber auf das Oracle-System ausgerichtet ist, um eine vernünftige Verteilung der OEV zu erreichen und gleichzeitig die Aktualisierungsfrequenz des Orakels in der Kette weiter zu erhöhen. Die folgende Abbildung zeigt das OEV-Schema von API3:

API3 ermöglicht es jedem, die in seinem Orakelvertrag aufgezeichneten Daten durch Gebote aktiv zu aktualisieren, und führt den OEV-Relay-Knoten als Kern des gesamten OEV-Auktionsprozesses ein. OEV Relay sammelt Daten in jedem Oracle-Netzwerkknoten und gibt sie an den Suchenden zurück. Der Suchende verwendet es dann, um die im API3-Orakel aufgezeichneten Daten zu aktualisieren, und nutzt die Gelegenheit, MEV-Transaktionen zu bündeln.

Die Existenz von OEV Relay bringt die folgenden zwei Vorteile mit sich:

1. Stellen Sie den Suchenden alle Daten auf einheitliche Weise zur Verfügung und reduzieren Sie die Anzahl der Suchenden, die nur mit Oracle-Knoten interagieren.

2. Schützen Sie einen einzelnen Oracle-Knoten im Netzwerk und verhindern Sie, dass ein einzelner Oracle-Knoten durch DoS-Angriffe von Suchern angegriffen wird.

Suchende können aggregierte Oracle-Netzwerk-Angebotsdaten und -Signaturen innerhalb von OEV Relay abrufen. Wenn Suchende der Meinung sind, dass das aktuelle Angebot des Oracle-Netzwerks ihnen helfen kann, bestimmte OEV-Extraktionsvorgänge abzuschließen, werden sie ein Angebot an OEV Relay abgeben.

Wenn der Suchende während des Gebotsprozesses das höchste Gebot abgibt, gibt OEV Relay eine Meta-TX zurück, die signiert wurde und direkt in die Kette hochgeladen werden kann, um den Preis der Orakelmaschine in der Kette zu aktualisieren. Suchende können diese Preisaktualisierungstransaktion mit anderen Transaktionen in der Kette bündeln und ausführen, um OEV-Einnahmen zu erzielen. Da die Preisaktualisierungstransaktion zu diesem Zeitpunkt auch in der Kette verpackt ist, wird auch der Preis des Orakels in der Kette aktualisiert.

Wir können sehen, dass ein Effekt der Unterstützung von OEV-Auktionen darin besteht, hochfrequente Aktualisierungen der On-Chain-Oracle-Preise zu erreichen. Nehmen wir die AAPL/USD-Datenquelle als Beispiel: Wenn die Off-Chain- und On-Chain-Preise vor einer OEV-Auktion um 1 % abweichen, führt diese große Abweichung dazu, dass das Orakel die On-Chain-Preise aktiv aktualisiert.

Aber wenn die Orakelmaschine der Außenwelt erlaubt, ihr nach Eröffnung der OEV-Auktion Anweisungen zur Datenaktualisierung zu übermitteln, könnten die Suchenden denken, dass der Preisunterschied von 0,1 % zwischen den On-Chain- und Off-Chain-Preisen enorme OEV-Vorteile bringen kann. Dies wird die Suchenden dazu veranlassen, die Meta-TX für die Preisaktualisierung zu verwenden, wenn der Preisunterschied 0,1 % beträgt, und die Transaktionsorder in die Kette hochzuladen.

Dadurch werden Aktualisierungen der AAPL/USD-Datenquelle beschleunigt, ohne dass zusätzliche Oracle-Aktualisierungskosten für Anwendungen anfallen, die dieses Orakel verwenden.

Daher werden die Kosten für die Aktualisierung der Oracle-Daten an die OEV-Werterfassungsprogramme weitergegeben, und das OEV-Relay von API3 kann hohe Gebotsgebühren von OEV-Spielern erhalten und diese Gebühren dann an das Defi-Protokoll zurückgeben, das den OEV-Wert erfasst.

Es ist absehbar, dass mit der Expansion des OEV-Marktes die Sucher hart um den Auktionspreis konkurrieren werden, was dazu führt, dass der größte Teil (sogar 95%) des OEV-Wertes an das API3-Protokoll übertragen wird. Nachdem das API3-Protokoll diesen Teil der OEV-Einnahmen erhalten hat, differenziert es die Quelle des OEV-Werts und gibt ihn an das Defi-Protokoll zurück, in dem der OEV-Wert erfasst wurde.

Es sollte auch beachtet werden, dass API3 zu Versicherungszwecken automatisch Datenaktualisierungsvorgänge durchführt, wenn der Unterschied zwischen On-Chain-Daten und Off-Chain-Daten groß ist, vorausgesetzt, dass kein OEV-Auktionator die im API3-Vertrag aufgezeichneten Daten aktiv aktualisiert hat.

Zusammenfassung

Basierend auf dem Airnode-Protokoll und inspiriert von Flashbot hat API3 eine OEV-Auktionslösung entwickelt, die folgende Vorteile mit sich bringt:

Führen Sie den größten Teil des OEV an Protokolle zurück, die Oracle-Preis-Feeds verwenden, um feinere Preisaktualisierungen bereitzustellen. Protokollplattformen, die Oracle Price Feeds verwenden, müssen keine hohen Kosten für detailliertere Datenaktualisierungen zahlen. Diese Kosten werden an die OEV-Spitzenreiter weitergegeben, die über Auktionen mitbieten.

Im Vergleich zur spezialisierten Lösung von GMX ist die Lösung von API3 vielseitiger. Darüber hinaus muss der Benutzer des API3-Orakels nur eine Wallet-Adresse angeben, und das API3-Protokoll überträgt automatisch OEV-Einnahmen in diese Wallet, was die Umverteilung von OEV bequemer macht.

Verzichtserklärung:

1. Dieser Artikel ist ein Nachdruck von [PANews], Alle Urheberrechte liegen beim ursprünglichen Autor [Geek Web3]. Wenn es Einwände gegen diesen Nachdruck gibt, wenden Sie sich bitte an das Gate Learn-Team , das sich umgehend darum kümmern wird.
2. Haftungsausschluss: Die in diesem Artikel geäußerten Ansichten und Meinungen sind ausschließlich die des Autors und stellen keine Anlageberatung dar.
3. Übersetzungen des Artikels in andere Sprachen werden vom Gate Learn-Team durchgeführt. Sofern nicht anders angegeben, ist das Kopieren, Verbreiten oder Plagiieren der übersetzten Artikel verboten.