Priorität ist alles, was du brauchst

Einführung

In diesem Beitrag stellen wir MEV-Steuern vor, ein Mechanismus, den beliebige Anwendungen nutzen können, um ihre eigenen MEV zu erfassen.

Dieser Mechanismus könnte heute auf OP Stack L2s wie OP Mainnet, Base und Blast verwendet werden, da die Blockvorschläge auf diesen Ketten einer Reihe von Regeln folgen, die wir als wettbewerbliche Prioritätsreihenfolge bezeichnen.

Um eine MEV-Steuer auf einer dieser Chains umzusetzen, erhebt ein Smart Contract eine Gebühr, die eine Funktion der Prioritätsgebühr der Transaktion ist. Wir zeigen, dass, wenn eine Anwendung den Suchenden eine MEV-Steuer von (sagen wir) 99 US-Dollar für jeden 1 US-Dollar Prioritätsgebühr berechnet, sie 99% des Wettbewerbs-MEV für diese Transaktion erfassen kann.

MEV-Steuern sind eine einfache Technik, die einen umfangreichen Gestaltungsspielraum eröffnet. Sie können sie sich vorstellen, dass sie es ermöglichen, dass jede Anwendung in der Kette ihre eigene benutzerdefinierte MEV-Auktion durchführt, ohne dass sie eine eigene Off-Chain-Infrastruktur benötigt, einfach indem sie sich in eine einzige gemeinsame Auktion einhängt, die vom Blockvorschlagenden durchgeführt wird.

Wir zeigen, wie MEV-Steuern zur Lösung von drei Hauptproblemen in der MEV-Forschung eingesetzt werden könnten:

• Dezentralisierte Austausch (DEX) Router, die den Preis optimieren, den der Tauscher erhält
• Automatisierte Marktgestalter (AMMs), die den Verlust vs. Wiederherstellung (LVR) minimieren, den Liquiditätsanbietern erfahren.
• Wallets, die es ihren Nutzern ermöglichen, jegliches durch ihre Transaktionen erzeugtes „Backrunning“ MEV zu erfassen

Aber es gibt einen Haken. MEV-Steuern funktionieren nur, wenn Block-Proposer sich strikt an die Regeln der Wettbewerbs-Prioritätsreihenfolge halten, zu denen das Sortieren von Transaktionen nach Prioritätsgebühr ohne Zensur, Ausspähen oder Verzögerung gehört. Wenn Block-Proposer von diesen Regeln abweichen, können sie MEV-Steuern umgehen, um den Wert für sich selbst zu erfassen. Heute hängen MEV-Steuern daher davon ab, L2-Sequenzern zu vertrauen und würden wahrscheinlich überhaupt nicht auf Ethereum L1 funktionieren, wo der Blockaufbau von einem dominiert wird.wettbewerbsfähige Bauherrenausschreibungdas den Umsatz für den Antragsteller maximiert.

Dennoch legen die Macht und Flexibilität der MEV-Steuern nahe, dass die Prioritätsreihenfolge die richtige Wahl für Plattformen sein könnte, die sie heute bereitstellen können. Und die relative Einfachheit der Wettbewerbsprioritätsreihenfolge legt nahe, dass es einen gangbaren Weg geben könnte, sie auf dezentrale Weise durchzusetzen, ohne einem einzelnen Sequenzer vertrauen zu müssen. Wir hoffen, dass dieser Beitrag weitere Arbeiten an diesem Problem anregt.

Prioritätsbestellung

Wenn jemand eine Transaktion auf einem Ethereum L1 oder L2 sendet, geben sie eine Prioritätsgebühr an, die sie dem Blockvorschlagenden zahlen.1Sie können sich vorstellen, dass dies als priorityFeePerGas festgelegt ist, eine Zahl, die mit dem im Transaktionsvorgang verwendeten Gas multipliziert wird, um builderPriorityFee zu erhalten - die Gesamtzahlung in ETH.2

Im Ethereum-Protokoll gibt es keine Regel, dass Transaktionen in einem Block gierig nach absteigender priorityFeePerGas geordnet sein müssen. Dies ist jedoch eine beliebte Methode zum Blockieren von Blöcken - zum Beispiel ist dies der Standardalgorithmus, den Sequenzer von Gate.com verwenden.OP-StackKetten sowie geth und reth. Die Prioritätsreihenfolge ermöglicht es den Transaktoren nicht nur, die Dringlichkeit ihrer Transaktionen effizient auszudrücken, sondern leitet auch auf natürliche Weise bestimmte Arten von MEV zum Blockvorschlagenden weiter.

Das geschieht, weil die Prioritätsreihenfolge den Wettbewerb um MEV in einePrioritäts-Gasauktion. Wenn es eine Gelegenheit gibt, von der Interaktion mit der Kette zu profitieren, z. B. durch Arbitrage eines AMM gegen eine zentrale Börse, konkurrieren Suchende darum, diese Gelegenheit als Erste zu nutzen. Wenn die Kette eine Prioritätsreihenfolge verwendet, um die Transaktionseinschluss und -reihenfolge zu bestimmen, konkurrieren die Suchenden, indem sie hohe Prioritätsgebühren für ihre Transaktionen festlegen.

In einem Wettbewerbsszenario, in dem risikofreie Gewinne bis auf null konkurrieren, sollte der siegreiche Suchende am Ende den vollen Betrag des MEV in Prioritätsgebühren zahlen.3Wenn also ein Gewinn von 100 ETH bei der Interaktion mit einem Vertrag erzielt werden kann, wird die erste Transaktion zur Beanspruchung eine Prioritätsgebühr von 100 ETH festlegen. (Wir besprechen einige Einschränkungen in diesem Abschnitt).

MEV Steuern

Angenommen, ein Smart Contract möchte den MEV aus jeder Transaktion einfangen, die mit ihm interagiert. Es gibt eine umfangreiche Bibliothek an Forschung zu verschiedenen anwendungsspezifischen Wegen, wie Smart Contracts versuchen könnten, ihren eigenen MEV einzufangen.

Aber tatsächlich müssen wir nicht unbedingt etwas über die Anwendung wissen. Wenn wir wissen, dass der Block durch eine konkurrierende Prioritätsreihenfolge erstellt wird, haben wir ein universelles Signal für die Menge an MEV in der Transaktion: die Prioritätsgebühr.

Wir schlagen vor, dass der Smart Contract die Prioritätsgebühr der Transaktion überprüfen und seine eigene Gebühr als eine Funktion davon erheben kann. Zum Beispiel könnte der Vertrag verlangen, dass derjenige, der ihn aufruft, eine Anwendungs-Prioritätsgebühr von 99 * Antragsteller-Prioritätsgebühr in ETH an den Vertrag überweisen muss.4

Diese neue Gebühr wird vom Suchenden, der die Transaktion sendet, bezahlt, daher beeinflusst sie das Verhalten dieses Suchenden. Wenn es sich bei einer Gelegenheit um 100 MEV handelt, wird die gewinnende Transaktion jetzt nur noch eine Prioritätsgebühr von 1 ETH festlegen, da dies zu einer Gesamtzahlung von 100 ETH führt (1 ETH an den Blockstellenanbieter und 99 ETH an den Smart Contract). Eine höhere Prioritätsgebühr würde die Transaktion unrentabel machen; eine niedrigere Prioritätsgebühr würde dazu führen, dass die Gelegenheit an einen Konkurrenten verloren geht, der eine höhere Gebühr festgelegt hat. Das bedeutet, dass der Smart Contract 99% des MEV in der Transaktion erfasst hat.

Wir nennen diese zusätzliche Gebühr, die vom Smart Contract erhoben wird, eine MEV-Steuer. MEV-Steuer ermöglicht es einer Anwendung, die Prioritätsreihenfolge zu kapern, um ihren eigenen Vorteil zu erlangen, und ermöglicht es ihr, MEV für ihre Benutzer zurückzugewinnen, anstatt es dem Blockvorschlagenden zu überlassen.

Wenn diese Gebühr ausreichend schnell als Funktion von priorityFeePerGas steigt, dann wird nur eine vernachlässigbare Menge an MEV dem Antragsteller zufallen. Da priorityFeePerGas in Wei (einem Milliardstel eines Billionstel eines ETH) denominiert ist, haben wir viel Präzision zur Verfügung. Zum Beispiel, solange die MEV-Steuer empfindlich genug ist, dass ein priorityFeePerGas von 50.000 zu einer unerschwinglich hohen Steuer führen würde, wäre die Gesamtzahlung an den Antragsteller weniger als $0.01.5

Es gibt jedoch einen wichtigen Vorbehalt. Wie im Abschnitt "Einschränkungen" erläutert, funktionieren MEV-Steuer nur, wenn Blockvorschläger bestimmte Regeln befolgen - was wir als "wettbewerbsfähige Prioritätsreihenfolge" bezeichnen - anstatt von diesen Regeln abzuweichen, um ihren eigenen Umsatz zu maximieren. Diese Regeln auf vertrauenswürdige Weise durchzusetzen, ist ein offenes Problem.

Einzelanwendungs-MEV-Erfassung

Hier skizzieren wir, wie auf einer Chain, die garantiert wettbewerbsorientierte Prioritätsreihenfolge für Blockaufbau verwendet, MEV-Steuer verwendet werden könnte, um drei wichtige Probleme bei MEV zu mildern: DEX-Schnittstellen ermöglichen eine Verbesserung der Handelsausführung für Swapper, AMMs ermöglichen eine Verringerung von Verlusten durch Arbitrage für ihre LPs, und Wallets ermöglichen eine Verringerung von MEV-Lecks für ihre Benutzer, indem sie das Recht verkaufen, den Benutzer rückwirkend zu verfolgen.

DEX-Router

In Intent-Based DEX-Routing-Protokollen wie UniswapXund1inch Fusion, ein Benutzer (Alice) gibt eine Absicht zum Tauschen an, und Suchende konkurrieren, um diese Absicht zum besten möglichen Preis für Alice zu leiten oder zu erfüllen.

Aktuelle Versionen von Gate.com verwenden zwei Mechanismen, um diesen Wettbewerb durchzuführen: eine holländische Auktion, bei der der Limitpreis von Alice im Laufe der Zeit variiert, bis ein Sucher ihn ausfüllt, und eine anfängliche Offchain-Anfrage für Angebote (RFQ) Auktion, um den Startpreis dieser holländischen Auktion festzulegen.

Auf einer Plattform, die eine wettbewerbsfähige Prioritätsreihenfolge garantiert, könnte UniswapX diese durch einen einzigen Mechanismus ersetzen: eine MEV-Steuer. Dies könnte umgesetzt werden, indem der Benutzer eine Order unterschreibt, die von jedem sofort ausgeführt werden kann, jedoch zu einem Ausführungspreis, der als Funktion der Priorität der Transaktion festgelegt ist.

Zum Beispiel, wenn Alice eine UniswapX-Bestellung zum Verkauf von 1 ETH hat, könnte sie den Ausführungspreis der Bestellung definieren als minimumPrice + ($0,01 * priorityFeePerGas). minimumPrice könnte ein fester Wert sein, den sie erwartet, der deutlich niedriger als der aktuelle Preis ist.

Die Suchenden würden um die Erfüllung von Alice's Bestellung konkurrieren, indem sie Transaktionen einreichen. Die Transaktion mit der höchsten Prioritätsgebühr und ohne Rückgängigmachung würde die Bestellung ausführen, was garantieren sollte, dass der Tauscher den besten Preis erhält, den die Suchenden finden können. (Einige Ausnahmen hiervon werden im Abschnitt Einschränkungen erörtert.)

Wenn der Mindestpreis von Alice 3.000 $ beträgt und der aktuelle Preis von ETH 3.500 $ beträgt, würde die priorityFeePerGas in der gewinnenden Transaktion etwa 50.000 betragen. (Beachten Sie, dass bei einer Transaktion, die 200.000 Gas kostet, dies zu einer Zahlung von nur etwa 10 Milliarden Wei - etwa 0,000035 $ - an den Blockvorschlagenden führt.)

Dies hat einige potenzielle Vorteile gegenüber den bestehenden Mechanismen, die in UniswapX verwendet werden.

Aufträge, die MEV-Steuer verwenden, könnten schneller und zu einem besseren Preis abgeschlossen werden als Aufträge, die niederländische Auktionen verwenden. Wie bereits diskutiert in dieses Papier, Onchain Dutch Auctions lassen aufgrund von Preisbewegungen zwischen Blöcken einige Werte an MEV durchsickern und können viele Blöcke dauern, um abgeschlossen zu werden. Im Gegensatz dazu könnten Aufträge, die MEV-Steuern verwenden, in der Regel im nächsten Block abgeschlossen werden, während sie die überwiegende Mehrheit ihres MEV erfassen.

Anders als bei einem Offchain-RFQ würde die Auktion zur Ausführung eines Auftrags, die MEV-Steuern verwendet, atomar mit der Transaktionsausführung Onchain erfolgen. Das bedeutet, dass ein erfolgreicher Bieter garantieren könnte, dass er nur verpflichtet ist, den Auftrag auszuführen, wenn seine Onchain-Transaktion erfolgreich ist. Das könnte es einfacher machen, dass Onchain-Liquidität wie AMMs mit Offchain-Liquidität konkurrieren kann, was bedeutet, dass UniswapX als noch effektiverer Router für Multi-Pool-Systeme wie Uniswap v4 dienen könnte.

AMMs

Normalerweise geben AMMs Arbitrageuren, die gegen veraltete Preise am Anfang des Blocks handeln, Wert ab, wie in dem besprochenen Fall.Verlust vs. NeugewichtungPapiere. Wir können MEV-Steuer verwenden, um AMMs zu erfassen, die MEV erfassen. Um die Dinge einfach zu halten, werden wir besprechen, wie dies auf einem AMM ohne konzentrierte Liquidität funktionieren könnte. (Wenn Sie daran interessiert sind, wie dieses Problem mit konzentrierter Liquidität gelöst werden könnte,Sorellawird bald eine Lösung veröffentlichen.)

Ein AMM kann MEV erfassen, indem es eine zusätzliche Gebühr als Funktion der Prioritätsgebühr für die Transaktion erhebt, die es ihm ermöglicht, das Recht auf den ersten Handel im Block zu versteigern. Es gibt viele Möglichkeiten, diese Gebühr zu berechnen und zu denominieren. Wir werden eine möglicherweise neutrale Methode diskutieren - die Denominierung in Einheiten der Poolliquidität, sqrt(xy). Die gewinnende Transaktion wäre diejenige, die die Liquidität des Pools am meisten erhöht.

Beim Ausführen der ersten Transaktion in einem Pool in einem Block wird anstelle der Bedingung x_end durchgesetzt y_end > x_starty_start, der Pool könnte die Bedingung erzwingen (mit a als irgendeiner Konstante):

x_end y_end > (sqrt(x_start(y_start) + a*priorityFeePerGas)^2

Diese Formel würde den Arbitrage-Händler dazu anreizen, zum wahren Preis zu handeln, und nach diesem Handel sollte der Mittelpunktswert im Pool der wahre Preis sein.6

Nach dieser ersten Transaktion könnten Trades so funktionieren wie auf Uniswap v2, mit festen Tauschgebühren. Uninformierte Transaktionen, die auf dem Pool handeln möchten, ohne eine zusätzliche MEV-Steuer zu zahlen, würden eine niedrige Prioritätsgebühr festlegen.

Es gibt viele andere Möglichkeiten, MEV-Steuern auf einer AMM umzusetzen, die unterschiedliche Auswirkungen hätten. Zum Beispiel könnten MEV-Steuern in der Eingabe- oder Ausgabetoken des Swaps denominiert sein, den Swap-Gebührenprozentsatz beeinflussen, der vom Pool angewendet wird, oder den Mindestpreis des Handels des Benutzers bestimmen. Wir denken, dass dies ein interessanter Gestaltungsraum ist, den es zu erkunden gilt.

Backrunning-Auktionen

Die obigen Beschreibungen zeigen, wie bestimmte Anwendungen entworfen werden könnten, um das Auslaufen von MEV zu vermeiden. Was aber, wenn eine Brieftasche versuchen möchte, ihren Benutzern zu helfen, das MEV einzufangen, das sie aus beliebigen Transaktionen erzeugen, die mit einer beliebigen Anwendung interagieren, auch solchen, die keine MEV-Steuern enthalten?

Zum Beispiel, wenn Alice eine große Transaktion auf einem AMM tätigt, schafft sie manchmal eine Arbitragemöglichkeit für „Backrunner“, um den Preis zurückzubewegen. Dies wird normalerweise an MEV durchgesickert, anstatt zu Alice zu gehen.

MEV-Anteil und MEVBlockersind zwei Protokolle, die es Benutzern ermöglichen, MEV aus ihren Transaktionen zu erfassen, aber sie verlassen sich auf ein komplexes Off-Chain-Auktionsystem.Der Orderflow-Auktions-Designraumbeschreibt einige andere Lösungen.

MEV-Steuer, wenn sie mit einer absichtsbasierten Smart Contract-Brieftasche kombiniert wird, könnte es uns ermöglichen, ein alternatives System zur Erfassung von MEV-Backrunning für Alice zu konstruieren. Angenommen, anstatt eine Transaktion zu erstellen, die auf dem AMM handelt, unterzeichnet Alice eine Absicht, die jeder bei Alice's Smart Contract-Brieftasche einreichen kann, um sie dazu zu veranlassen, diese Aktion auszuführen. Alice's Smart Contract-Brieftasche berechnet der Person, die diese Transaktion einreicht, eine MEV-Steuer, die an Alice gezahlt wird.

Der Suchende, der Alice's Absicht einreicht, wird das ausschließliche Recht haben, sie rückläufig zu verfolgen, da er dies atomar in derselben Transaktion tun kann. Wenn die Suche also wettbewerbsfähig ist, sollte der gesamte Gewinn aus dem Rücksuchen von Alice durch ihre MEV-Steuer an Alice fließen.

Beachten Sie, dass dieses System Benutzer möglicherweise nicht unbedingt vor Angriffen schützt, die Frontrunning-Benutzertransaktionen beinhalten, da eine Transaktion, die einen Benutzer frontruns durchführt, möglicherweise in der Lage ist, die Zahlung einer MEV-Steuer an diesen Benutzer zu vermeiden. Dieses Problem (und einige mögliche Abhilfemaßnahmen dafür) wird im Abschnitt "Einschränkungen" weiter unten ausführlicher erläutert. Nichtsdestotrotz könnte dies zumindest eine Verbesserung gegenüber Systemen sein, die öffentliche Mempools ohne Abhilfemaßnahmen verwenden.

Andere Anwendungsfälle

Neben diesen Beispielen könnten andere potenzielle Anwendungen von MEV-Steuern fast alles umfassen, was derzeit eine Off-Chain- oder niederländische Auktion verwendet, wie zum Beispiel:

• Protokolle für Orakel, um den von ihnen erstellten Orakel-Extraktionswert zu erfassen, wie Oval
• Refinanzierungsauktionen in NFT-besicherten Kreditprotokollen wie Mischung
• Kreditprotokoll-Liquidationen, die Weniger Wertverlustals niederländische Auktionen

MEV-Erfassung über Anwendungen hinweg

Die obigen Lösungen sind darauf ausgelegt, die MEV beim Interagieren mit einer einzelnen Anwendung zu erfassen. Manchmal ist es jedoch möglich, dass ein Sucher noch mehr Wert erfassen kann, indem er mit mehreren Anwendungen in derselben Transaktion interagiert.

Wenn nur eine dieser Anwendungen eine MEV-Steuer hat, sollte die gesamte MEV aus der Transaktion an die Anwendung mit der MEV-Steuer gehen, unabhängig davon, wie hoch oder niedrig diese MEV-Steuer ist.

Aber was ist, wenn die Transaktion eines Suchenden mit zwei Anwendungen interagiert, die MEV-Gebühren verwenden? Was ist, wenn zum Beispiel ein Teil des MEV nur erfasst werden kann, indem eine der oben beschriebenen MEV-besteuerten UniswapX-Orders gegen einen MEV-besteuerten AMM ausgeführt wird?

In diesem Fall wird der relative Betrag an überschüssigem MEV, der von jeder Anwendung erfasst wird, durch die Art und Weise bestimmt, wie diese Anwendungen ihre MEV-Steuern festlegen. Wenn der Wert app_i als MEV-Steuer erhebt, die durch die Funktion tax_i(Priorität) gegeben ist, dann kann die Priorität der gewinnenden Transaktion bestimmt werden, indem man die Priorität in dieser Gleichung löst:

Steuer_1(Priorität pro Gas) + Steuer_2(Priorität pro Gas) = Gesamt MEV

(Technisch gesehen könnten wir einen dritten Begriff für priorityPerGas * gasUsed hinzufügen, um die Prioritätsgebühr für den Blockvorschlagenden zu berücksichtigen, aber wir werden das ignorieren, da es unter normalen Bedingungen wahrscheinlich vernachlässigbar sein wird, wie in Anhang A diskutiert.)

Im einfachen Fall von MEV-Steuer, die linear in priorityPerGas ist (also tax_1(priorityPerGas) = a_1 * priorityPerGas), können Sie den Anteil an MEV lösen, den jede Anwendung erhält:

a_1 priorityPerGas + a_2priorityPerGas = MEV

priorityPerGas = MEV/(a_1 + a_2)

steuer_1(PrioritätProGas) = (a_1/(a_1+a_2))*MEV

tax_2(priorityPerGas) = (a_2/(a_1+a_2))*MEV

Bei der Festlegung ihrer eigenen MEV-Steuer steht eine Anwendung vor einem Dilemma - höhere Steuern ermöglichen es ihr, einen größeren Anteil am MEV zwischen Anwendungen zu erfassen, wenn es auftritt, bedeuten aber, dass sie möglicherweise auf einige MEV zwischen Anwendungen verzichten müssen, wenn es konkurrierende Möglichkeiten gibt, ihn zu extrahieren. Zum Beispiel, wenn es eine AMM gibt, die bei jedem Handel eine MEV-Steuer erhebt, könnte ein MEV-steuerpflichtiger UniswapX-Auftrag eher von einer anderen AMM oder einem externen Füller ausgeführt werden.

In vielen Fällen kann es ein Gleichgewicht geben, in dem zwei Anwendungen ihre MEV-Steuer so gestalten, dass sie MEV auf eine Weise teilen, die das Wohlergehen jedes einzelnen maximiert. Zum Beispiel würde eine MEV-Steuer-AMM wahrscheinlich Wert von einem einzigen informierten Händler in der Nähe des oberen Teils des Blocks erfassen wollen, würde dann aber Liquidität für andere Händler und Anwendungen (einschließlich solcher, die MEV-Steuern verwenden) mit einer niedrigen Festgebühr bereitstellen wollen. In diesem Fall wird die AMM wahrscheinlich eine relativ niedrige MEV-Steuer (sagen wir $0,00001) festlegen.priorityFeePerGas), damit die Arbitrage-Transaktion (falls vorhanden) früh im Block stattfindet, und dann keine MEV-Steuer auf nachfolgende Transaktionen im Block erheben. Anwendungen wie UniswapX, die mit dem AMM interagieren möchten, können eine viel höhere MEV-Steuer festlegen (sagen wir $0.01 priorityFeePerGas), um sicherzustellen, dass ihre Transaktionen nach dem Arbitrage des Pools bereits enthalten sind. Mit diesen relativen Steuern würde das AMM zuerst arbitriert werden, auch wenn nur $1 MEV darauf und $50,000 MEV in einer UniswapX-Bestellung wären.

Wir glauben, dass dies ein breiter Gestaltungsraum ist, der einer zukünftigen Untersuchung wert ist.

Einschränkungen

MEV-Steuern haben einige Komplikationen und Nachteile. Wir denken, dass jeder dieser Punkte ein interessantes Forschungsgebiet für die Zukunft ist.

Anreizinkompatibilität

MEV-Steuern sind nicht anreizkompatibel für einen monopolistischen Blockvorschlagenden. Sie funktionieren nur, wenn es einen fairen Wettbewerb um die Transaktionseinschluss gibt, was nur passiert, wenn der Blockvorschlagende Regeln befolgt, die wir als „wettbewerbsorientierte Prioritätsreihenfolge“ bezeichnen, anstatt ihren eigenen Umsatz zu maximieren. Informell und nicht erschöpfend schlagen wir vor, dass diese Regeln Folgendes beinhalten sollten:

• Prioritätsreihenfolge. Transaktionen innerhalb eines Blocks müssen in absteigender Reihenfolge von priorityFeePerGas geordnet sein.
• Zensurresistenz. Wenn der Blockvorschlag eine Transaktion t1 während des Blocks empfängt und der Block entweder nicht voll ist oder einige Transaktionen t2 enthält, so dass t2.priorityFeePerGas < t1.priorityFeePerGas, muss der Block die Transaktion t1 enthalten.
• Vor-Transaktions-Privatsphäre. Der Blockvorschlagende muss Transaktionen über einen privaten Endpunkt akzeptieren und darf solche Transaktionen nicht mit anderen teilen, bevor er sich dem Block verpflichtet, oder den Inhalt dieser Transaktionen als Eingabe für den Aufbau eigener Transaktionen verwenden.
• Kein letzter Blick. Der Blockvorschlagende muss eine bestimmte Zeit blockTime festlegen, bevor er Transaktionen von jedermann akzeptiert, und nach der er keine Transaktionen von irgendjemandem akzeptiert.

Wenn eine oder mehrere dieser Eigenschaften verletzt werden, kann dies die Wirksamkeit von MEV-Steuer schwächen. Ein Blockvorschlag, der die Zensurresistenz verletzt, kann die meisten MEV-Steuern vermeiden, indem er konkurrierende Transaktionen ausschließt und eine Null-Prioritäts-Transaktion einreicht, die die Gelegenheit für sich nutzt. Ein Blockvorschlag, der die Vor-Transaktions-Privatsphäre verletzt, könnte MEV von anderen Transaktionen stehlen oder deren Prioritätsgebühren ausspionieren, um genau zu wissen, wie hoch es die eigenen setzen muss, während einer, der Transaktionen später als alle anderen einreichen kann, einen kostenlosen „letzten Blick“ darauf hätte, ob er andere überbieten soll, was entweder zu Problemen der ungünstigen Auswahl führen könnte, die letztendlich den Wettbewerb entmutigen.

Leider wäre es zwar einfach, die erste Eigenschaft auf Protokollebene durchzusetzen, aber die anderen Eigenschaften vertrauenswürdig durchzusetzen, ist ein offenes Problem.

In Abwesenheit von Durchsetzung auf Protokollebene muss einem einzelnen Sequenzer, der sich zu diesen Regeln verpflichtet, vertraut werden, nicht davon abzuweichen, und wenn Vorschlagende den Blockaufbau an eine wettbewerbsfähige, ertragsmaximierende Auktion auslagern (wie z. B. Ethereum L1’sMEV-Boost) , Blöcke werden ihnen wahrscheinlich nicht folgen.

Diese Probleme können mit einem einzigen vertrauenswürdigen Sequenzer, der sich zu einer Verwendung von wettbewerbsfähiger Priorität beim Blockaufbau verpflichtet, "gelöst" werden. Sie können auch mit einem dezentralen Mechanismus unter Verwendung einer Kombination von Konsens, Kryptografie und/oder vertrauenswürdigen Ausführungsumgebungen wie Sorellas Angstrom, Flashbots SUAVE gelöst werden.Führerlose Auktionen, oder Vielfalt.

Volle Blöcke

Eine Ausnahme von der normalen Funktion von MEV-Steuerungen tritt auf, wenn die Blöcke vollständig gefüllt sind. In diesem Fall müssen die Blockvorschläger möglicherweise Transaktionen mit geringerer Priorität auslassen, anstatt sie einfach spät im Block einzuschließen. Da Transaktionen, die mit MEV-besteuerten Anwendungen interagieren, wahrscheinlich extrem niedrige Prioritätsgebühren haben, besteht die Wahrscheinlichkeit, dass diese Anwendungen von Anwendungen, die keine MEV-Steuern verwenden, oder von solchen, die extrem niedrige MEV-Steuern haben, verdrängt werden. In einer Kette, die einen EIP-1559-ähnlichen Mechanismus zur Festlegung einer separaten Grundgebühr verwendet, dürfte es jedoch relativ selten sein, dass die Blöcke vollständig gefüllt sind. Darüber hinaus, da einige Transaktionen verzögert werden müssen, wenn die Blöcke voll sind, könnte es ein vernünftiges Ergebnis sein, Transaktionen, die eine geringere Dringlichkeit ausdrücken, durch die Festlegung höherer MEV-Steuern zu verzögern.

Stornierte Transaktionen

MEV-Steuern beruhen effektiv auf Ein-Block-Auktionen, bei denen jedes „Gebot“ eine Transaktion ist. Ein Nachteil dieser Auktionen besteht darin, dass verlorene Gebote in der Regel dazu führen, dass rückgängig gemachte Transaktionen auf der Chain enthalten sind, einen bestimmten Basisgebühr zahlen und die Chain verstopfen.

Wenn ein Sequenzer fehlgeschlagene Transaktionen vollständig ausschließen kann, würde dies dieses Problem lindern, obwohl dies selbst mit einem zentralisierten Sequenzer schwer zu implementieren sein kann. (Es würde auch nicht streng die oben beschriebene Eigenschaft der Zensurresistenz befolgen, obwohl diese Definition angepasst werden könnte.) Ein ausgefeilterer Sequenzer könnte diesen Prozess optimieren, indem er Transaktionen ermöglicht, anzugeben, an welchen umstrittenen Auktionen sie teilnehmen, und dem Sequenzer genügend Informationen gibt, um nachfolgende Transaktionen zu überspringen, von denen er weiß, dass sie fehlschlagen würden.

Offenlegung von Benutzerabsichten

MEV-Steuern funktionieren nur, wenn es Wettbewerb unter den Suchenden gibt, was bedeutet, dass die Gelegenheit irgendwie weit verbreitet sein muss. Für Anwendungen wie AMMs, wo die Gelegenheit auf der Kette sichtbar ist, sollte das natürlich geschehen. Aber für Anwendungen wie Intent-basiertes Routing oder Backrunning-Auktionen bedeutet das, dass die Anwendung die Absicht des Benutzers möglicherweise mit den Suchenden teilen muss.

In einigen Fällen kann der vorübergehende Verlust der Privatsphäre durch die Veröffentlichung der Absicht des Benutzers, bevor sie erfüllt ist, auf eine Weise Wert verlieren, die durch eine MEV-Steuer nicht wiedererlangt werden kann.

Beispielsweise möchte Alice möglicherweise einen Token mit geringer Liquidität über das oben beschriebene Backrunning-Auktionsprotokoll erwerben. Sie veröffentlicht eine signierte Absicht für ihr Smart-Vertrags-Wallet, diesen Token an einer AMM zu erwerben, wobei sie eine bestimmte Schlupftoleranz festlegt. Suchende könnten sich darum bemühen, den Preis dieses Tokens auf ihre Schlupftoleranz in einer Hochprioritätstransaktion zu treiben, ohne den Auftrag des Benutzers auszufüllen. Der Gewinner, Bob, könnte dann nicht wettbewerbsfähig die Absicht von Alice erfüllen, indem er sie in einer Niedrigprioritätstransaktion einschließt und backrunnt, wodurch Alice's Handel eingeschlossen wird und ihr einen schlechteren Preis bietet, während sie ihre MEV-Steuer umgeht. Ein ähnliches Problem könnte bei Käufen von NFTs auftreten.

Beachten Sie, dass ein solcher Angriff für Bob riskant wäre, da er keine Atomarität zwischen dem Kauf des Tokens und dem Verkauf an Alice garantieren könnte. Ein unerfahrener Bob könnte Opfer einer „Sandwich-Ripping“-Falle werden, bei der Alice die Absicht veröffentlicht, einen wertlosen Token von sich selbst zu kaufen, was dazu führt, dass Bob ihn in Erwartung des Sandwichens ihres Handels kauft, aber Alice ihre Absicht widerruft, bevor Bob das Sandwich abschließen kann.

Anwendungen können dies auch durch die Begrenzung des Sucher-Sets, mit dem sie Absichten teilen, und die Überwachung ihres Verhaltens, wie es viele bestehende Orderflow-Auktionen tun, möglicherweise mildern.

Es ist möglicherweise auch möglich, MEV-Steuern mit datenschutzbewussten Builder-Funktionen zu kombinieren, wie sie in den Entwürfen von Flashbots für Gate vorgesehen sind.ELEGANT.

Schließlich, in Fällen, in denen Alice entscheidet, dass die Kosten für die Weitergabe ihrer Absicht den Nutzen der Wettbewerbssuche überwiegen, könnte sie eine Transaktion selbst erstellen und direkt in den Block einreichen. Wie oben diskutiert, würde eine ideale Umsetzung der Wettbewerbs-Prioritätsreihenfolge eine vorherige Transaktions-Privatsphäre vor dem Block-Proposer bieten.

Diskussion und Vorarbeit

Prioritätsgasauktionen. Einige der Dynamiken der Prioritätsreihenfolge in dezentralen Blockchains wurden untersucht im Flash Boys 2.0Das Papier, das den Begriff "Miner Extractable Value" geprägt hat, beobachtete, dass Ethereum-Miner (als dieses Netzwerk den Proof-of-Work verwendete) bereits Transaktionen nach Priorität ordneten und dass Arbitrageure sich auf dieses Verhalten verließen, um an "Priority Gas Auctions" teilzunehmen, bei denen sie um das Recht konkurrierten, als Erste in einen Block aufgenommen zu werden. Dies führte dazu, dass ein Großteil des MEV aus dezentralen Exchange-Arbitragegeschäften den Minern zugutekam.

First come, first served. Einige Versuche zur MEV-Minderung durch Transaktionsreihenfolgeregeln, wie zum Beispiel ThemisoderArbitrum Ones aktueller Sequenzer,7Ich habe mich darauf konzentriert, eine andere Bestellregel durchzusetzen, nämlich das Prinzip wer zuerst kommt, mahlt zuerst (manchmal auch als "faire Reihenfolge" bezeichnet), bei dem Block-Vorschläger die Transaktionen in der Reihenfolge ordnen müssen, in der sie diese sehen.

Prioritätsbestellung verfolgt einen anderen Ansatz - sie behandelt Transaktionen, die innerhalb eines bestimmten Zeitraums eintreffen, gleich und ordnet sie stattdessen nach ihrer deklarierten Priorität.

Das Prinzip 'Wer zuerst kommt, mahlt zuerst' ist schwierig durchzusetzen oder sogar in einer realen Netzwerkumgebung mit mehr als einem Validator zu definieren. Es kann auch zu verschwenderischen Latenzrennen und Spam führen, selbst mit einem einzigen vertrauenswürdigen Sequenzer. Schließlich können MEV-Steuerbeträge bestimmte Arten von MEV eliminieren, die die 'Wer zuerst kommt, mahlt zuerst'-Reihenfolge nicht kann, wie Arbitragegewinne aus diskontinuierlichen 'Sprüngen' in den Vermögenspreisen. Die potenziellen Vorteile der Priorisierungsreihenfolge gegenüber der 'Wer zuerst kommt, mahlt zuerst'-Reihenfolge stehen in gewisser Weise im Zusammenhang mit den Vorteilen von diskreten Zeitabläufen gegenüber kontinuierlichen Zeitabläufen, die im Kontext der Diskussion über Börsen mit diskreter Zeit besprochen wurden.Budish, Cramton, Shim (2015).

In der Zwischenzeit, während die Prioritätsreihenfolge standardmäßig dazu neigt, MEV-Wert zu verlieren, zeigt dieser Beitrag, wie Anwendungen entworfen werden können, um ihn wiederzugewinnen.

Gebührenbeteiligung. Blast, eine Ethereum L2,Aktienein Teil sowohl der Prioritäts- als auch der Basisgebühren mit den Smart Contracts, die bei einer Transaktion zugegriffen werden.

MEV-Steuern ermöglichen etwas Ähnliches (zumindest für Prioritätsgebühren), können jedoch auf der Anwendungsebene in jeder Chain implementiert werden, die eine wettbewerbsfähige Prioritätsreihenfolge verwendet, ohne spezielle Unterstützung für Gebührenaufteilung. Sie ermöglichen es Anwendungen auch, ihre eigenen Steuern als benutzerdefinierte Funktionen der Prioritätsgebühr zu definieren, was mehr Flexibilität und möglicherweise eine größere Zusammensetzbarkeit von MEV-bewussten Anwendungen ermöglicht.

Vertrauenslose Lösungen. Dieser Beitrag konzentriert sich auf die Motivation für Plattformen, wettbewerbsfähige Prioritätsreihenfolge zu verwenden - und Möglichkeiten, Plattformen, die dies tun, zu nutzen - anstatt darüber zu diskutieren, wie man es vertrauenslos durchsetzt.

Es gab bereits erhebliche Diskussionen zu den anderen für die Wettbewerbsprioritäten erforderlichen Eigenschaften. Zum Beispiel in Fox, Pai, Resnick (2023), die Autoren diskutieren Schwachstellen bei Onchain-Auktionen in Abwesenheit von Zensurresistenz und beschreiben ein Design für eine zensurresistente Auktion unter Verwendung mehrerer gleichzeitiger Anbieter. Sie schlagen jedoch keine spezifische Reihenfolge für Transaktionen vor.

Es gab weitere Forschungen zum Aufbau von Mechanismen für vertrauensminimierte Blockbildung, darunter Flashbots'sSUAVE, Sorella's Angstrom, Führerlose Auktionen, Espresso und Offchain Labs’ @espressosys/Espresso-Systeme-und-Offchain-Labs-ver%C3%B6ffentlichen-R-D-Roadmap-f%C3%BCr-dezentralisierten Timeboost-5d0007dff66d"> dezentralisierten Timeboost undvorgeschriebene öffentliche Transaktionseinschlussvon Péter Szilági.

Fazit

Wir hoffen, dass dieser Beitrag L2s dazu ermutigt, die Prioritätsreihenfolge in Betracht zu ziehen (wie standardmäßig im OP Stack unterstützt) und Anwendungen dazu inspiriert, MEV-Steuern auszuprobieren, wo sie unterstützt werden.

Wir hoffen auch, dass es weitere Forschungen zu Protokollen zur vertrauensminimierten Prioritätsreihenfolge im Wettbewerb auf L1 und L2 anregt. Wenn Sie an einer Zusammenarbeit bei diesem Problem interessiert sind und dies vor dem Donnerstag, 6. Juni lesen, können Sie sich immer noch um ein TLDR-Stipendium bewerben, um daran zu arbeiten MEV-resistente L2-Sequenzermit Dan. Oder zögern Sie nicht, einfach Kontakt aufzunehmen dan@paradigm.xyzunddave@paradigm.xyzmit Ideen!

Fußnoten

1. In diesem Beitrag verwenden wir den Begriff "Antragsteller" für den Akteur oder den Prozess, der bestimmt, welche Transaktionen in einem bestimmten Block enthalten sind. Auf Ethereum L2s wird diese Rolle in der Regel von einem "Sequenzer" übernommen. Auf Ethereum L1 wird sie von einem spezifischen Ethereum-Validierer namens Antragsteller ausgefüllt, obwohl der Antragsteller oft die Aufgabe der Blockerstellung an eine Wettbewerbsauktion auslagert, an der "Relayer" und "Builder" teilnehmen. Die Details zur Aufteilung dieser Verantwortlichkeiten sind nicht Gegenstand dieses Beitrags.↩
2. Die Prioritätsgebühr pro Gas wird in der Transaktion tatsächlich nicht explizit angegeben, kann aber darin berechnet werden. Die Transaktion gibt einen Gaspreis an, aber Ethereum berechnet auch eine Grundgebühr, die aus dem Gaspreis entnommen und verbrannt wird. Die Grundgebühr sollte für die Zwecke von MEV-Steuer ignoriert werden, da sie nicht unter der Kontrolle des Transaktors steht. Die Prioritätsgebühr pro Gas – der Preis für den Teil der Transaktionsgebühr, der an den Blockvorschlagenden geht – kann in Solidity als priorityGasPrice = tx.gasprice - block.basefee berechnet werden.↩
3. Alternativ könnten wir einfach 'MEV' definieren, um jeglichen Sucher-Gewinn auszuschließen und nur auf den Wert zu verweisen, der dem Validator zugute käme.↩
4. Beachten Sie, dass proposerPriorityFee—gleich priorityFeePerGas mal der insgesamt verwendeten Gasmenge in der Transaktion—tatsächlich nicht während des Vertrags berechnet werden kann, da es keine Möglichkeit gibt zu wissen, wie viel Gas die Transaktion letztendlich verbrauchen wird. Dies spielt jedoch im Allgemeinen keine Rolle, da wir nur eine obere Grenze dafür benötigen. Zur Sicherheit könnten Sie priorityFeePerGas mit 30 Millionen multiplizieren—dem aktuellen maximalen Gaswert in einem Ethereum-Block. Eine Überschätzung dieses Werts bedeutet einfach, dass die MEV-Steuer einen noch größeren Prozentsatz an MEV erfasst.↩
5. Vorausgesetzt, eine Transaktion kann nicht mehr als 30 Millionen Gas betragen, würde eine priorityFeePerGas von 50.000 zu einer Gaszahlung von 1500 Gwei führen - etwa 0,006 $ bei einem ETH-Preis von 4000 $. ↩
6. Im Falle, dass priorityFeePerGas so eingestellt ist, dass der Gewinn des Arbitrageurs null ist, sollte der gewinnmaximierende Arbitragehandel demselben Handel am Gate entsprechen Funktionsmaximierende AMM. Dies zu beweisen, bleibt dem Leser als Übung überlassen. ↩
7. Arbitrum hat diskutiertersetzt dies durch eine Form der Priorisierung namens Timeboost, die jedoch zum Zeitpunkt dieser Schriftstellerei noch nicht in Produktion gegangen ist.

Haftungsausschluss：

1. Dieser Artikel wurde aus [ wieder abgedrucktParadigma], Alle Urheberrechte liegen beim ursprünglichen Autor [Dan Robinson, Dave White]. Wenn es Einwände gegen diesen Nachdruck gibt, kontaktieren Sie bitte Gate LearnTeam, und sie werden es umgehend bearbeiten.
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, Verteilen oder Plagiieren der übersetzten Artikel untersagt.