Autor: Dan Robinson,Dave White
Zusammengestellt von: Joyce, BlockBeats
In diesem Artikel stellen wir die MEV-Steuer vor, die ist ein Mechanismus, mit dem jede Anwendung ihr eigenes MEV erfassen kann. Dieser Mechanismus ist jetzt auf OP Stack L2 wie OP Mainnet, Base und Blast verfügbar, da Blockvorschlager in diesen Ketten einer Reihe von Regeln folgen, die wir Wettbewerbspriorisierung nennen.
Um einer der Ketten eine MEV-Steuer aufzuerlegen, erhebt der Smart Contract eine Gebühr, die eine Funktion der Transaktionsprioritätsgebühr ist. Wenn eine Anwendung für jeden Dollar an Sucherprioritätsgebühren eine MEV-Steuer in Höhe von 99 US-Dollar erhebt, erfasst sie 99 % des wettbewerbsfähigen MEV für diese Transaktion.
MEV-Steuer ist eine einfache Technik, die einen riesigen Gestaltungsspielraum eröffnet. Man kann sie sich so vorstellen, dass jede Anwendung in der Kette ihre eigene benutzerdefinierte MEV-Auktion ohne eigene Off-Chain-Infrastruktur durchführen kann, indem sie einfach eine Verbindung zu einer einzigen gemeinsamen Auktion herstellt, die vom Blockantragsteller durchgeführt wird.
Wir veranschaulichen, wie MEV-Steuern zur Lösung von drei Hauptproblemen in der MEV-Forschung eingesetzt werden können:
Dezentrale Exchange (DEX)-Router, die den Preis, den Exchanger erhalten, optimieren
Automatisch Market Maker (AMM) , Minimierung von Verlusten und Rebalancing (LVR) bei Liquiditätsanbietern;
Wallets, die es Benutzern ermöglichen, alle durch ihre Transaktionen erzeugten „Hintergrund-MEV“ zu erfassen; Die MEV-Steuer funktioniert nur, wenn Blockantragsteller sich strikt an die Wettbewerbspriorisierungsregeln halten, zu denen auch die Anordnung von Transaktionen nach Prioritätsgebühren gehört, ohne dass Transaktionen zensiert, beschnüffelt oder verzögert werden. Wenn Blockantragsteller von diesen Regeln abweichen, können sie die MEV-Steuer umgehen und einen Mehrwert für sich erzielen. Daher sind MEV-Steuern heute auf vertrauenswürdige L2-Antragsteller angewiesen und funktionieren möglicherweise überhaupt nicht auf Ethereum L1, wo der Blockbau von wettbewerbsorientierten Builder-Auktionen dominiert wird, die das Einkommen der Angebotsperson maximieren.
Dennoch legen die Leistungsfähigkeit und Flexibilität der MEV-Besteuerung nahe, dass die Priorisierung möglicherweise die richtige Wahl für Plattformen ist, die diesen Service derzeit anbieten können. Die relative Einfachheit der Wettbewerbspriorisierung legt nahe, dass es möglicherweise eine praktikable Möglichkeit gibt, sie dezentral durchzusetzen, ohne einem einzelnen Sequenzer vertrauen zu müssen. Wir hoffen, dass dieser Artikel weitere Forschung zu diesem Thema anregen wird.
Wenn jemand eine Transaktion auf Ethereum L1 oder L2 sendet, weist er eine Prioritätsgebühr zu und zahlt diese an den Blockvorschlager. Sie können sich vorstellen, dass dies als „priorityFeePerGas“ angegeben wird, eine Zahl multipliziert mit dem in der Transaktion verwendeten Gas, um die „builderPriorityFee“ zu erhalten – die Gesamtzahlung in ETH.
Im Ethereum-Protokoll ist nicht vorgesehen, dass Transaktionen in einem Block gierig nach PrioritätFeePerGas in absteigender Reihenfolge sortiert werden müssen. Es handelt sich jedoch um eine beliebte Methode zum Bauen von Blöcken – zum Beispiel ist es der Orderer der OP-Stack-Kette und der von Geth und Reth verwendete Standardalgorithmus. Durch die Priorisierung können Händler nicht nur die Dringlichkeit ihrer Transaktionen effektiv zum Ausdruck bringen, sondern geben natürlich auch bestimmte Arten von MEV an Blockantragsteller weiter.
Dies geschieht, weil die Priorisierung den Wettbewerb um MEV in eine Prioritätsauktion für Gas verwandelt. Wenn sich Gelegenheiten ergeben, von Interaktionen mit einer Kette zu profitieren, wie z. B. Arbitrage mit zentralisierten Börsen über AMMs, wetteifern die Suchenden darum, die Ersten zu sein, die dies tun. Wenn die Kette die Einbeziehung und Reihenfolge von Transaktionen mithilfe der Priorisierung bestimmt, konkurrieren die Suchenden, indem sie Gebühren mit hoher Priorität für ihre Transaktionen festlegen.
In einem Wettbewerbsszenario mit null risikofreiem Gewinnwettbewerb sollte der erfolgreiche Suchende letztendlich die volle MEV-Prioritätsgebühr zahlen. Wenn also durch die Interaktion mit dem Vertrag ein Gewinn von 100 ETH erzielt werden kann, wird für die erste Transaktion, die diesen Gewinn beansprucht, eine Prioritätsgebühr von 100 ETH festgelegt. (Einige Vorbehalte besprechen wir im Abschnitt „Einschränkungen“).
Angenommen, ein Smart Contract möchte MEV aus jeder Transaktion erfassen, mit der er interagiert. Es gibt zahlreiche Untersuchungen zu verschiedenen anwendungsspezifischen Möglichkeiten, mit denen Smart Contracts versuchen können, ihren eigenen MEV zu erfassen.
Aber tatsächlich müssen wir nicht unbedingt etwas über die App wissen. Wenn wir wissen, dass der Block durch kompetitive Priorisierung aufgebaut wurde, dann haben wir ein universelles Signal über die Höhe des MEV in der Transaktion: die Prioritätsgebühr.
Wir schlagen vor, dass ein intelligenter Vertrag die Prioritätsgebühr einer Transaktion berücksichtigen und eine eigene Gebühr als eine inkrementelle Funktion davon erheben könnte. Der Vertrag kann beispielsweise verlangen, dass der Anrufer applicationPriorityFee = 99 *proposerPriorityFee in ETH an den Vertrag überträgt.
Diese neue Gebühr wird von dem Suchenden bezahlt, der die Transaktion gesendet hat, und wirkt sich daher auf das Verhalten dieses Suchenden aus. Wenn die Gelegenheit 100 MEV beträgt, wird die Gewinnertransaktion jetzt nur eine Prioritätsgebühr von 1 ETH festlegen, da dies zu einer Gesamtauszahlung von 100 ETH führt (1 ETH an den Blockvorschlager und 99 ETH an den Smart Contract). Jede Gebühr mit höherer Priorität macht die Transaktion unrentabel; jede Gebühr mit niedrigerer Priorität führt dazu, dass Wettbewerbern, die höhere Gebühren festlegen, Chancen entgehen. Das bedeutet, dass der Smart Contract 99 % des MEV der Transaktion erfasst hat.
Wir nennen diese durch den Smart Contract erhobene zusätzliche Gebühr die MEV-Steuer. Die MEV-Steuer ermöglicht es einer Anwendung, die Priorisierung zu ihrem eigenen Vorteil zu missbrauchen, sodass sie MEV für ihre Benutzer zurückgewinnen kann, anstatt es an blockierende Antragsteller weiterzugeben.
Wenn die Gebühr als Funktion der Prioritätsgebühr pro Gas schnell genug wächst, erhält der Antragsteller nur einen vernachlässigbaren MEV. Da PriorityFeePerGas in Wei (Milliardstel von 1 ETH) angegeben ist, müssen wir mit großer Präzision umgehen. Solange beispielsweise die MEV-Steuer so sensibel ist, dass eine PriorityFeePerGas von 50.000 zu einer überhöhten Steuer führen würde, würde der an den Antragsteller gezahlte Gesamtbetrag weniger als 0,01 US-Dollar betragen. (5)
Es gibt jedoch einen wichtigen Vorbehalt. Wie im Abschnitt „Einschränkungen“ erläutert, funktionieren MEV-Steuern nur, wenn Blockantragsteller bestimmte Regeln befolgen (was wir „Wettbewerbspriorisierung“ nennen) und nicht von diesen Regeln abweichen, um ihre eigenen Einnahmen zu maximieren. Die vertrauenslose Durchsetzung dieser Regeln ist eine offene Frage.
Hier skizzieren wir, wie MEV-Steuern verwendet werden können, um drei wichtige Probleme in MEV auf Ketten zu mildern, die den Blockaufbau unter Verwendung konkurrierender Prioritäten garantieren: Lassen Sie DEX-Schnittstellen die Handelsausführung durch Börsen verbessern und AMMs ermöglichen um Arbitrageverluste auf ihrem LP zu reduzieren und es Wallets zu ermöglichen, den MEV-Lecks der Benutzer durch den Verkauf ihrer Reverse-Run-Rechte zu reduzieren.
In absichtsbasierten DEX-Routing-Protokollen wie UniswapX und 1inch Fusion unterzeichnet ein Benutzer (Alice) eine Austauschabsicht und Suchende konkurrieren darum, Alice zum besten Preis weiterzuleiten oder diese Absicht zu erfüllen.
Die aktuelle Version von UniswapX nutzt zwei Mechanismen zum Wettbewerb: eine niederländische Auktion, bei der sich Alices Grenzpreis im Laufe der Zeit ändert, bis die Suchenden ihn ausfüllen; und eine anfängliche Off-Chain-Request-for-Quotation-Auktion (RFQ), bei der er festgelegt wird der Startpreis für eine niederländische Auktion.
Auf einer Plattform, die eine Wettbewerbspriorisierung garantiert, kann UniswapX diese Mechanismen durch einen einzigen Mechanismus ersetzen: die MEV-Steuer. Dies geschieht dadurch, dass Benutzer Aufträge unterzeichnen können, die jeder sofort ausführen kann, wobei der Ausführungspreis jedoch abhängig von der Priorität des Handels festgelegt wird.
Wenn Alice beispielsweise einen UniswapX-Auftrag zum Verkauf von 1 ETH hat, kann sie den Ausführungspreis des Auftrags als MinimumPrice + (0,01 $ * PriorityFeePerGas) definieren. MinimumPrice ist wahrscheinlich ein fester Wert, von dem sie erwartet, dass er deutlich unter dem aktuellen Preis liegt.
Suchende konkurrieren darum, Alices Bestellung zu erfüllen, indem sie Transaktionen einreichen. Die Bestellung wird unabhängig davon, welches Geschäft die höchste Prioritätsgebühr hat, ausgeführt und nicht wiederhergestellt. Dies sollte garantieren, dass der Tauscher den besten Preis erhält, den der Suchende finden kann. (Einige Ausnahmen werden im Abschnitt „Einschränkungen“ besprochen.)
Wenn Alices Mindestpreis 3.000 US-Dollar beträgt und der aktuelle ETH-Preis 3.500 US-Dollar beträgt, beträgt die PriorityFeePerGas in der Gewinnertransaktion etwa 50.000. (Beachten Sie, dass bei einer Transaktion, die 200.000 Gas kostet, dies dazu führen würde, dass nur ~10 Milliarden Wei (~0,000035 $) an den Blockantragsteller gezahlt werden.)
Im Vergleich zum bestehenden Mechanismus, der in UniswapX verwendet wird, hat dies einige potenzielle Vorteile.
Bestellungen mit MEV-Steuer können schneller und zu einem besseren Preis ausgeführt werden als Bestellungen mit Dutch Auction. Wie in diesem Artikel besprochen, verlieren niederländische On-Chain-Auktionen aufgrund von Preisänderungen zwischen Blöcken einen gewissen Wert an MEV und können viele Blöcke in Anspruch nehmen. Im Gegensatz dazu können Aufträge, die MEV-Steuern verwenden, oft im nächsten Block ausgeführt werden und dabei den größten Teil des MEV erfassen.
Im Gegensatz zu Off-Chain-RFQs werden Auktionen für Bestellungen mit MEV-Steuer automatisch durchgeführt, wenn On-Chain-Transaktionen ausgeführt werden. Dies bedeutet, dass sich der erfolgreiche Bieter garantiert nur dann zur Ausführung der Bestellung verpflichtet, wenn die On-Chain-Transaktion erfolgreich ist. Dies kann es für On-Chain-Liquidität wie AMMs einfacher machen, mit Off-Chain-Liquidität zu konkurrieren, was bedeutet, dass UniswapX als effizienterer Router für Multi-Pool-Systeme wie Uniswap v4 dienen kann.
Typischerweise verlieren AMMs an Wert an Arbitrageure, die auf der Grundlage veralteter Preise an der Spitze von Blöcken handeln, wie im Dokument „Verluste und Neuausrichtung“ erläutert. Wir können die MEV-Steuer nutzen, damit AMM MEV erfasst. Der Einfachheit halber werden wir diskutieren, wie AMM ohne zentralisierte Liquidität funktionieren kann. (Wenn Sie daran interessiert sind, wie Sie diese Art von Problem durch die Bündelung von Liquidität lösen können, wird Sorella in Kürze eine Lösung veröffentlichen.)
AMM kann MEV erfassen, indem es eine zusätzliche Gebühr als Funktion der Transaktionsprioritätsgebühren erhebt, wodurch es Auktionen ermöglicht Recht darauf, der Erste zu sein, der einen Block handelt. Es gibt verschiedene Möglichkeiten, diese Gebühr zu berechnen und zu bewerten. Wir werden eines diskutieren, das wohl neutral ist – in Einheiten der Poolliquidität, sqrt(xy). Der Gewinner-Trade wird derjenige sein, der die Liquidität des Pools am meisten erhöht.
Wenn die erste Transaktion im Pool in einem Block ausgeführt wird, kann der Pool die Bedingung (a als eine Konstante) erzwingen, anstatt die Bedingung x_end * y_end > x_start * y_start:
x_end * y_end > (sqrt(x_start * y_start) + a*priorityFeePerGas)^2
Diese Formel wird Arbitrage-Händlern einen Anreiz bieten, zum wahren Preis zu handeln, und nach diesem Handel sollte der mittlere Preis im Pool der wahre Preis sein.
Nach dem ersten Handel kann der Handel wie bei Uniswap v2 mit festen Swap-Gebühren fortgesetzt werden. Uninformierte Händler, die im Pool handeln möchten, ohne die zusätzliche MEV-Steuer zu zahlen, erhalten eine niedrigere Prioritätsgebühr.
Es gibt viele andere Möglichkeiten, eine MEV-Steuer auf AMMs einzuführen, die unterschiedliche Auswirkungen haben werden. Beispielsweise könnte eine MEV-Steuer auf die Eingabe- oder Ausgabe-Tokens eines Swaps lauten, den Prozentsatz der von einem Pool erhobenen Swap-Gebühren beeinflussen oder den Mindestpreis für Benutzertransaktionen bestimmen. Wir glauben, dass dies ein interessanter Designraum ist, der es wert ist, erkundet zu werden.
Die obige Beschreibung zeigt, wie bestimmte Anwendungen so gestaltet werden können, dass MEV-Leckagen vermieden werden. Was aber, wenn ein Wallet den Nutzern dabei helfen möchte, den MEV zu erfassen, den sie aus jeder Transaktion erstellen, die sie mit einer beliebigen Anwendung interagieren, selbst solchen, die keine MEV-Steuern enthalten?
Wenn Alice beispielsweise große Transaktionen auf AMM durchführt, schafft sie manchmal Arbitragemöglichkeiten für „Backrunner“, um den Preis nach unten zu ziehen. Dies würde normalerweise an MEV weitergegeben, nicht an Alice.
MEV-Share und MEVBlocker sind zwei Protokolle, die es Benutzern ermöglichen, MEV aus Transaktionen zu erfassen, sie sind jedoch auf komplexe Off-Chain-Auktionssysteme angewiesen. Der Order Flow Auction Design Space beschreibt einige andere Lösungen.
MEV-Steuer in Kombination mit einer absichtsbasierten Smart-Contract-Wallet ermöglicht es uns, ein alternatives System zur Erfassung von MEV zu entwickeln, das im Hintergrund für Alice läuft. Gehen Sie davon aus, dass Alice keine Transaktion für die Transaktion auf dem AMM erstellt, sondern stattdessen eine Absicht unterzeichnet, die jeder an Alices Smart-Contract-Wallet übermitteln kann, damit diese diese Aktion ausführt. Alices Smart-Contract-Wallet erhebt eine MEV-Steuer von jedem, der die Transaktion einreicht, und die Steuer wird an Alice gezahlt.
Suchende, die Alices Absicht übermitteln, haben das ausschließliche Recht, sie zu entfernen, da sie dies automatisch innerhalb derselben Transaktion tun können. Wenn also die Suche wettbewerbsorientiert ist, sollten alle Gewinne von Alice über die MEV-Steuer an Alice fließen.
Bitte beachten Sie, dass dieses System Benutzer nicht unbedingt vor Angriffen mit Transaktionen von Front-Running-Benutzern schützt, da Transaktionen von Front-Running-Benutzern möglicherweise die Zahlung von MEV-Steuern an diesen Benutzer vermeiden können. Dieses Problem (und einige mögliche Abhilfemaßnahmen) werden im Abschnitt „Einschränkungen“ weiter unten ausführlicher erläutert. Dennoch könnte dies zumindest eine Verbesserung gegenüber Systemen sein, die einen gemeinsamen Speicherpool verwenden, ohne dass Abhilfemaßnahmen erforderlich sind.
Zusätzlich zu diesen Beispielen könnten weitere potenzielle Verwendungszwecke für die MEV-Steuer fast alles umfassen, was derzeit Off-Chain- oder niederländische Auktionen verwendet, wie zum Beispiel:
Orakel erfassen die Orakel, die sie verwenden Erstellen Sie Protokolle mit maschinenextrahierbarem Wert, wie z. B. Oval;
Refinanzierungsauktionen für NFT-Hypothekenprotokolle wie Blend;
Die obige Lösung ist darauf ausgelegt, MEV-Interaktionen mit einer einzigen Anwendung zu erfassen. Aber manchmal können Suchende möglicherweise einen größeren Nutzen daraus ziehen, wenn sie mit mehreren Anwendungen in derselben Transaktion interagieren.
Was aber, wenn die Transaktion des Suchenden mit zwei Anwendungen interagiert, die MEV-Steuer verwenden? Was wäre zum Beispiel, wenn es einen gewissen MEV gibt, der nur erfasst werden kann, indem eine der oben genannten MEV-steuerpflichtigen UniswapX-Bestellungen gegen einen MEV-steuerpflichtigen AMM ausgeführt wird?
In diesem Fall hängt der relative Betrag des überschüssigen MEV, der von jeder Anwendung erfasst wird, davon ab, wie diese Anwendungen ihre MEV-Steuern festlegen. Wenn der als MEV-Steuer erfasste Wert app_i durch die Funktion tax_i(priority) angegeben wird, kann die Priorität der gewinnenden Transaktion durch Lösen der Priorität in der folgenden Gleichung bestimmt werden:
tax_1(priorityPerGas) + tax_2(priorityPerGas) = Gesamt-MEV
(Technisch gesehen könnten wir ein drittes Element zu „priorityPerGas * gas“ hinzufügen. Wird verwendet, um die an den Blockantragsteller gezahlte Prioritätsgebühr zu berücksichtigen, aber wir werden das ignorieren, unter normalen Umständen funktioniert es wahrscheinlich. Vernachlässigt)
In Im einfachen Fall, in dem die MEV-Steuer linear mit der PrioritätPerGas zusammenhängt (also tax_1(priorityPerGas) = a_1 * PriorityPerGas), können Sie nach dem MEV-Anteil suchen, den jede Anwendung erhält:
a_1 * PriorityPerGas + a_2 * PriorityPerGas = MEV
priorityPerGas = MEV/(a_1 + a_2)
tax_1(priorityPerGas) = (a_1/(a_1+a_2))*MEV
tax_2(priorityPerGas) = (a_2/(a_1+a_2))*MEV
Apps stehen vor einem Kompromiss, wenn sie ihre eigene MEV-Steuer festlegen: Eine höhere Steuer gibt ihnen einen größeren Anteil am app-übergreifenden MEV, wenn sie auftritt. Das bedeutet jedoch, dass, wenn es eine konkurrierende Möglichkeit gibt, sie zu extrahieren, möglicherweise etwas anwendungsübergreifendes MEV fehlt . Wenn es beispielsweise einen AMM gibt, der auf jede Transaktion eine MEV-Steuer erhebt, ist es wahrscheinlicher, dass der UniswapX-Auftrag mit MEV-Steuer von einem anderen AMM oder Off-Chain-Füller ausgeführt wird.
In vielen Fällen kann es zu einem Gleichgewicht kommen, bei dem zwei Anwendungen ihre MEV-Steuern so gestalten, dass sie den MEV so teilen, dass ihre jeweiligen Gewinne maximiert werden. Beispielsweise möchte ein MEV-Steuer-AMM möglicherweise den Wert eines einzelnen informierten Händlers am oberen Ende des Blocks erfassen, dann aber anderen Händlern und Anwendungen (einschließlich Anwendungen, die die MEV-Steuer verwenden) Liquidität zu einem niedrigeren festen Satz zur Verfügung stellen. kosten. In diesem Fall könnte der AMM eine relativ niedrige MEV-Steuer festlegen (z. B. 0,00001 $ * PriorityFeePerGas), sodass der Arbitrage-Handel (falls vorhanden) früh im Block stattfindet, und dann keine MEV-Steuer auf nachfolgende Transaktionen im Block erheben. Anwendungen wie UniswapX, die mit AMMs interagieren möchten, können eine höhere MEV-Steuer festlegen (z. B. 0,01 $ * PriorityFeePerGas), um sicherzustellen, dass ihre Transaktionen einbezogen werden, nachdem der Pool bereits arbitriert wurde. Angesichts dieser relativen Steuern würde der AMM, selbst wenn die UniswapX-Bestellung nur 1 MEV und 50.000 MEV enthielte, am Ende zuerst arbitriert werden.
Wir glauben, dass dies ein umfassender Designraum ist, der zukünftiger Forschung würdig ist.
Die MEV-Steuer weist einige Komplexitäten und Nachteile auf, die unserer Meinung nach interessante Bereiche für zukünftige Forschung sind.
Die MEV-Steuer ist für Monopolblock-Antragsteller nicht anreizkompatibel. Sie funktionieren nur, wenn gleiche Wettbewerbsbedingungen für die Einbeziehung von Transaktionen bestehen. Dies ist nur dann der Fall, wenn die Blockvorschlagsregeln den sogenannten „Wettbewerbspriorisierungsregeln“ folgen, anstatt ihre eigenen Einnahmen zu maximieren. Eine informelle Liste vorgeschlagener Regeln, einschließlich, aber nicht beschränkt auf die folgenden:
Priorisieren. Transaktionen innerhalb des Blocks müssen nach PriorityFeePerGas in absteigender Reihenfolge sortiert werden.
Widerstehen Sie der Zensur. Wenn der Blockvorschlager während des Blocks die Transaktion t1 empfängt und der Block nicht voll ist oder eine Transaktion t2 enthält, wie z. B. t2.priorityFeePerGas < t1.priorityFeePerGas, muss der Block die Transaktion t1 enthalten.
Privatsphäre vor der Transaktion. Blockantragsteller müssen Transaktionen über einen privaten Endpunkt akzeptieren und dürfen diese Transaktionen nicht mit anderen teilen, bevor sie sie an einen Block senden, oder den Inhalt dieser Transaktionen als Eingabe für die Erstellung ihrer eigenen Transaktionen verwenden.
Keine abschließende Bewertung. Blockantragsteller müssen eine klare Blockzeit festlegen. Vor diesem Zeitpunkt akzeptieren sie keine Transaktionsanfragen mehr.
Verstöße gegen eine oder mehrere dieser Eigenschaften können die Wirksamkeit der MEV-Steuer beeinträchtigen. Blockantragsteller, die gegen die Zensur verstoßen, können die meisten MEV-Steuern vermeiden, indem sie konkurrierende Transaktionen ausschließen und Transaktionen mit Null-Priorität einreichen, die sich selbst ausnutzen. Blockantragsteller, die die Privatsphäre vor der Transaktion verletzen, können MEV von anderen Transaktionen stehlen oder sich ihre Prioritätsgebühren ansehen, um genau zu wissen, wie hoch sie ihre Gebühren festlegen müssen, während Blockantragsteller, die in der Lage sind, Transaktionen später als andere einzureichen, Free'Finally sehen werden Wenn Sie die Gelegenheit zu einem höheren Preis als andere erhalten möchten, kann beides zu Problemen bei der nachteiligen Auswahl führen, die letztlich den Wettbewerb behindern.
Leider ist das erste Attribut zwar in der Durchsetzung der Vereinbarungsebene leicht verfügbar, setzt jedoch andere Eigenschaften durch auf vertrauenswürdige Weise ist eine offene Frage
In Ermangelung einer Durchsetzung auf der Protokollebene muss einem einzelnen Sequenzer, der sich zu diesen Regeln verpflichtet, vertraut werden, dass er nicht von diesen Regeln abweicht, und wenn der Antragsteller die Blockkonstruktion an einen Wettbewerber auslagert Bei einer umsatzmaximierenden Auktion (z. B. MEV-Boost von Ethereum L1) folgen die Blöcke ihnen möglicherweise nicht.
Diese Probleme können von einem einzigen vertrauenswürdigen Besteller gelöst werden. Sie können auch durch dezentrale Mechanismen gelöst werden, die eine Kombination aus Konsens, Kryptografie und/oder einer vertrauenswürdigen Ausführungsumgebung verwenden, wie z. B. Angstrom von Sorella, SUAVE von Flashbots, führerlose Auktionen oder Multiplizität.
Eine Ausnahme vom normalen Betrieb der MEV-Steuer tritt auf, wenn ein Block vollständig gefüllt ist. In diesem Fall muss der Blockantragsteller möglicherweise Transaktionen mit niedrigerer Priorität aufgeben, anstatt sie einfach in den Block aufzunehmen. Da für Transaktionen, die mit MEV-Steueranwendungen interagieren, möglicherweise sehr niedrige Prioritätsgebühren anfallen, werden diese Anwendungen möglicherweise von Anwendungen verdrängt, die keine MEV-Steuern verwenden oder sehr niedrige MEV-Steuern haben. In einer Kette, die einen Mechanismus wie EIP-1559 verwendet, um eine separate Grundgebühr festzulegen, sollte es jedoch relativ selten vorkommen, dass Blöcke vollständig gefüllt sind. Da bestimmte Transaktionen verzögert werden müssen, wenn ein Block voll ist, könnte es außerdem sinnvoll sein, Transaktionen mit geringerer Dringlichkeit durch die Festlegung einer höheren MEV-Steuer zu verzögern.
Die MEV-Steuer basiert tatsächlich auf Einzelblockauktionen, bei denen jedes „Gebot“ eine Transaktion ist. Ein Nachteil dieser Auktionen besteht darin, dass fehlgeschlagene Gebote oft dazu führen, dass wiederhergestellte Transaktionen in die Kette aufgenommen werden, wodurch einige Grundgebühren anfallen und es zu einer Überlastung der Kette kommt.
Wenn der Sortierer fehlgeschlagene Transaktionen vollständig ausschließen könnte, würde dies dieses Problem lindern, obwohl dies selbst mit einem zentralisierten Sortierer schwierig zu erreichen ist. (Es hält sich auch nicht strikt an die oben erwähnten zensurresistenten Eigenschaften, obwohl diese Definition angepasst werden kann.) Anspruchsvollere Sequenzierer könnten diesen Prozess optimieren, indem sie es Transaktionen ermöglichen, anzugeben, an welchen umkämpften Auktionen sie teilnehmen, wodurch der Sequenzierer über ausreichende Informationen verfügt um nachfolgende Transaktionen zu überspringen, von denen bekannt ist, dass sie fehlschlagen werden.
MEV-Steuer funktioniert nur, wenn es Konkurrenz unter den Suchenden gibt, was bedeutet, dass die Möglichkeit bis zu einem gewissen Grad bekannt sein muss. Bei Anwendungen wie AMM, bei denen Chancen in der Kette sichtbar sind, sollte dies natürlich passieren. Bei Anwendungen wie absichtsbasiertem Routing oder Hintergrundauktionen bedeutet dies jedoch, dass die Anwendung möglicherweise die Absicht des Benutzers mit dem Suchenden teilen muss.
In einigen Fällen kann der vorübergehende Verlust der Privatsphäre, der durch die Verbreitung von Benutzerabsichten verursacht wird, bevor diese realisiert werden, zu einem Wertverlust in einer Weise führen, den die MEV-Steuer nicht ausgleichen kann.
Angenommen, Alice möchte Token mit geringer Liquidität mithilfe des oben beschriebenen Backend-Auktionsprotokolls kaufen. Sie veröffentlicht die unterzeichnete Absicht des Smart Contract Wallets, den Token auf dem AMM zu kaufen und legt eine bestimmte Slippage-Toleranz fest. Ein Suchender kann in einem Handel mit hoher Priorität konkurrieren, um den Preis dieses Tokens bis zu seiner Slippage-Toleranz zu erhöhen, ohne die Bestellung des Benutzers auszuführen. Gewinner Bob kann dann Alices Absichten auf eine nicht wettbewerbsorientierte Weise erfüllen, indem er sie in eine Transaktion mit niedriger Priorität einbezieht und sie rückwärts abwickelt, wodurch Alices Transaktion eingeklemmt wird und ihr einen schlechteren Preis beschert wird, während sie gleichzeitig ihrer MEV-Steuer entgeht. Ähnliche Probleme können beim Kauf von NFTs auftreten.
Es ist zu beachten, dass ein solcher Angriff für Bob riskant ist, da er keine Atomizität zwischen dem Kauf des Tokens und dem Verkauf an Alice garantieren kann. Ein naiver Bob könnte in die Falle des „Klammerns und Zerreißens“ tappen: Alice verkündet zunächst ihre Absicht, einen wertlosen Token von sich selbst zu kaufen, und Bob kauft den Token, um ihre Transaktion zu flankieren, doch bevor Bob die Flankierung abschließt, zieht Alice ihre Absicht zurück .
Apps können dies auch abmildern, indem sie die Gruppe der Sucher, mit denen sie ihre Absichten teilen, einschränken und deren Verhalten überwachen, wie dies bei vielen bestehenden Orderflow-Auktionen der Fall ist.
Es ist auch möglich, die MEV-Steuer mit datenschutzbewussten Builder-Funktionen zu kombinieren, wie sie sich Flashbots für das SUAVE-Design vorgestellt haben.
Wenn Alice schließlich entscheidet, dass die Kosten für die Weitergabe der Absicht die Vorteile der Konkurrenzsuche überwiegen, kann sie die Transaktion selbst erstellen und direkt an den Block übermitteln. Wie oben erwähnt, würde eine ideale Implementierung der Wettbewerbspriorisierung den Blockantragstellern Privatsphäre vor der Transaktion bieten.
Prioritätsgasauktion. Das Flash Boys 2.0-Papier, das den Begriff „Miner Extractable Value“ geprägt hat, untersucht einige der Dynamiken der Priorisierung in dezentralen Blockchains. In dem Papier heißt es, dass Ethereum-Miner (als das Netzwerk Proof-of-Work nutzte) Transaktionen bereits Priorität einräumten und dass Arbitrageure sich auf dieses Verhalten stützten, um an „Prioritäts-Gasauktionen“ teilzunehmen, bei denen sie um das Recht auf Aufnahme in die erste Zone boten Blöcke, was dazu führt, dass der Großteil der von dezentralen Börsen arbitrierten MEV im Besitz von Bergleuten ist.
Wer zuerst kommt, mahlt zuerst. Einige Versuche, MEV durch Transaktionsordnungsregeln zu mildern, wie z. B. Themis oder der aktuelle Orderer von Arbitrum One (7), konzentrieren sich auf die Durchsetzung einer anderen Ordnungsregel: „Wer zuerst kommt, mahlt zuerst“ (manchmal auch „Fair Ordering“ genannt), bei der Blockvorschlager Transaktionen in sortieren müssen befehlen, sie zu sehen.
Priorisierung verfolgt einen anderen Ansatz: Transaktionen, die innerhalb einer bestimmten Zeit eingehen, werden gleich behandelt und nach ihrer erklärten Priorität sortiert.
Wer zuerst kommt, mahlt zuerst. Es ist schwierig, es in einer echten Netzwerkumgebung mit mehreren Validatoren zu implementieren oder gar zu definieren. Selbst mit einem einzigen vertrauenswürdigen Sequenzer kann es zu verschwenderischen Latenzkonflikten und Spam kommen. Schließlich könnte eine MEV-Steuer in der Lage sein, bestimmte Arten von MEV zu eliminieren, die nach dem Prinzip „Wer zuerst kommt, mahlt zuerst“ nicht eliminiert werden können, wie z. B. Arbitragegewinne aus diskreten „Sprüngen“ der Vermögenspreise. Die potenziellen Vorteile der Prioritätsbestellung gegenüber der Reihenfolge „Wer zuerst kommt, mahlt zuerst“ hängen in gewissem Maße mit den Vorteilen des zeitdiskreten Austauschs gegenüber dem zeitkontinuierlichen Austausch zusammen, die in Budish, Cramton, Shim (2015) diskutiert werden.
Während die Priorisierung standardmäßig Wert an MEV zu verlieren scheint, zeigt dieser Beitrag, wie Sie Ihre Anwendung so gestalten, dass sie diesen wiedererlangt.
Kostenbeteiligung. Blast ist Ethereum L2 und teilt sich einen Teil der Prioritäts- und Grundgebühren mit den Smart Contracts, auf die bei Transaktionen zugegriffen wird.
Die MEV-Steuer ermöglicht etwas Ähnliches (zumindest für vorrangige Gebühren), kann jedoch auf der Anwendungsebene in jeder Kette mithilfe der Wettbewerbspriorisierung implementiert werden, ohne dass eine besondere Unterstützung für die Gebührenteilung erforderlich ist. Sie ermöglichen es Anwendungen auch, ihre eigene Steuer als benutzerdefinierte Funktion der Prioritätsgebühr zu definieren, was eine größere Flexibilität bietet und möglicherweise die Zusammensetzbarkeit MEV-fähiger Anwendungen verbessert.
Vertrauenslose Lösung. Dieser Artikel konzentriert sich auf die Beweggründe für Plattformen, Wettbewerbspriorisierungen zu nutzen, und auf Möglichkeiten, die Plattform auszunutzen, und nicht darauf, wie man sie auf vertrauenswürdige Weise durchsetzen kann.
Jede der anderen für die Wettbewerbspriorisierung erforderlichen Eigenschaften wurde bereits ausführlich diskutiert. Beispielsweise diskutieren die Autoren in Fox, Pai, Resnick (2023) die Schwachstellen von On-Chain-Auktionen bei fehlendem Zensurwiderstand und beschreiben das Design zensurresistenter Auktionen unter Verwendung mehrerer gleichzeitiger Antragsteller. Sie schlugen jedoch keine bestimmte Reihenfolge der Transaktionen vor.
Es gibt weitere Untersuchungen zum Aufbau vertrauensminimierender Blockbildungsmechanismen, darunter SUAVE von Flashbots, Angstrom von Sorella, Leaderless Auctions, der dezentrale Timeboost von Espresso und Offchain Labs sowie die erzwungene Einbeziehung öffentlicher Transaktionen durch Péter Szilági.
Wir hoffen, dass dieser Artikel L2 dazu ermutigt, die Verwendung von Priorisierung in Betracht zu ziehen (standardmäßig vom OP-Stack unterstützt), und Anwendungen dazu ermutigt, MEV-Steuern auszuprobieren, sofern dies unterstützt wird. Wir hoffen auch, dass es weitere Forschungen zu vertrauensminimierenden Wettbewerbspriorisierungsprotokollen auf L1 und L2 anregt.
Das obige ist der detaillierte Inhalt vonNeuer Artikel von Paradigm: MEV-Besteuerung und -Priorisierung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
![[Web-Frontend] Node.js-Schnellstart](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
