Einleitung

In diesem Beitrag stellen wir MEV Steuern vor, einen Mechanismus, mit dem beliebige Anwendungen ihre eigenen MEV erfassen können.

Dieser Mechanismus könnte heute auf OP Stack L2s wie OP Mainnet, Base und Blast angewendet werden, da die Blockvorschlager auf diesen Chains einer Reihe von Regeln folgen, die wir als kompetitive Prioritätsreihenfolge bezeichnen.

Um eine MEV Steuer auf eine dieser Ketten zu implementieren, 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 pro 1 US-Dollar Prioritätsgebühr berechnet, sie 99% des wettbewerbsfähigen MEV für diese Transaktion erfassen kann.

MEV Steuern sind eine einfache Technik, die einen großen Gestaltungsraum eröffnet. Sie können sich vorstellen, dass sie es jeder Anwendung in der Kette ermöglichen, ihre eigene benutzerdefinierte MEV Auktion durchzuführen, ohne eine eigene Offchain-Infrastruktur zu benötigen, indem Sie sich einfach in eine einzige gemeinsame Auktion einklinken, die vom Blockvorschlager ausgeführt wird.

Wir zeigen, wie MEV Steuern genutzt werden könnten, um drei große Probleme in der MEV Forschung zu lösen:

• Dezentrale Börse (DEX) Router, die den vom Swapper erhaltenen Preis optimieren
• Automatisierte Market Maker (AMMs), die das Loss-vs-Rebalancing (LVR) von Liquiditätsanbietern minimieren
• Wallets, die es ihren Nutzern ermöglichen, alle "Backrunning"-MEV zu erfassen, die durch ihre Transaktionen entstehen

Aber es gibt einen Haken. MEV Steuern funktionieren nur, wenn Blockvorschlagsteller strikt die Regeln der wettbewerbsorientierten Prioritätsreihenfolge befolgen, zu denen die Sortierung von Transaktionen nach Prioritätsgebühr gehört, ohne sie zu zensieren, zu beäugen oder zu verzögern. Wenn Blockvorschlagsteller 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 die Blockbildung von einer kompetitiven Builder-Auktion dominiert wird, die die Einnahmen für den Vorschlagenden maximiert.

Dennoch deutet die Macht und Flexibilität der MEV darauf hin, dass die Prioritätsbestellung die richtige Wahl für Plattformen sein könnte, die sie heute anbieten können. Und die relative Einfachheit der kompetitiven Prioritätsreihenfolge deutet darauf hin, dass es einen gangbaren Weg geben könnte, sie dezentral durchzusetzen, ohne einem einzigen Sequenzer vertrauen zu müssen. Wir hoffen, dass dieser Beitrag zur weiteren Arbeit an diesem Problem motiviert.

Prioritätsreihenfolge

Wenn jemand eine Transaktion auf einem Ethereum L1 oder L2 sendet, gibt er eine Prioritätsgebühr an, die er an den Blockvorschlager zahlt.1 Sie können sich vorstellen, dass dies als priorityFeePerGas angegeben wird, eine Zahl, die mit dem in der Transaktion verwendeten Gas multipliziert wird, um builderPriorityFee zu erhalten - die Gesamtzahlung in ETH. 2

Es gibt keine Regel in der Ethereum Protokoll, dass Transaktionen in einem Block gierig nach absteigender PrioritätFeePerGas sortiert werden müssen. Dies ist jedoch eine beliebte Methode, um Blöcke zu erstellen – zum Beispiel ist es der Standardalgorithmus, der von Sequenzern von OP Stack-Ketten sowie von geth und reth verwendet wird. Die Prioritätsbestellung ermöglicht es Transaktoren nicht nur, die Dringlichkeit ihrer Transaktionen effizient auszudrücken, sondern leitet auch bestimmte Arten von MEVs auf natürliche Weise an den Blockvorschlager weiter.

Dies geschieht, weil die Prioritätsreihenfolge den Wettbewerb um MEV in eine Prioritäts-Gas Auktion verwandelt. Wenn es eine Möglichkeit gibt, von der Interaktion mit der Kette zu profitieren, z. B. durch Arbitrage eines AMM gegen eine zentralisierte Börse, konkurrieren die Suchenden, um diese Gelegenheit zuerst zu beanspruchen. Wenn die Kette die Prioritätsreihenfolge verwendet, um die Aufnahme und Reihenfolge von Transaktionen zu bestimmen, konkurrieren die Suchenden, indem sie hohe Prioritätsgebühren für ihre Transaktionen festlegen.

In einem wettbewerbsorientierten Szenario, in dem risikofreie Gewinne bis zu Null konkurrieren, sollte der gewinnende Suchende am Ende den vollen Betrag an MEV an Prioritätsgebühren zahlen. 3 Wenn also 100 ETH Gewinn aus der Interaktion mit einem Vertrag erzielt werden können, wird für die erste Transaktion, die ihn beansprucht, eine Prioritätsgebühr von 100 ETH festgelegt. (Wir besprechen einige Vorbehalte dazu im Abschnitt Einschränkungen).

MEV Steuern

Angenommen, ein Smart Contract möchte die MEV jeder Transaktion erfassen, die mit ihm interagiert. Es gibt eine umfangreiche Bibliothek von Forschungsergebnissen zu verschiedenen anwendungsspezifischen Möglichkeiten, wie Smart Contracts versuchen könnten, ihren eigenen MEV zu erfassen.

Aber tatsächlich müssen wir nicht unbedingt etwas über die Anwendung wissen. Wenn wir wissen, dass der Block durch kompetitive Prioritätsbestellung erstellt wird, dann haben wir ein universelles Signal für die Höhe des MEV in der Transaktion: die Prioritätsgebühr.

Wir schlagen vor, dass der Smart Contract die Prioritätsgebühr der Transaktion betrachten und seine eigene Gebühr als eine steigende Funktion der Transaktion erheben kann. Zum Beispiel könnte der Vertrag verlangen, dass derjenige, der ihn aufruft, applicationPriorityFee = 99 * proposerPriorityFee in ETH an den Vertrag überträgt. 4

Diese neue Gebühr wird von dem Suchenden bezahlt, der die Transaktion sendet, und wirkt sich daher auf das Verhalten dieses Suchenden aus. Wenn es 100 MEV in einer Verkaufschance gibt, wird die Gewinnertransaktion 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 Blockvorschlagsteller und 99 ETH an den Smart Contract). Jede höhere Prioritätsgebühr würde die Transaktion unrentabel machen. Jede niedrigere Prioritätsgebühr würde dazu führen, dass die Chance an einen Wettbewerber verloren geht, der eine höhere Gebühr festlegt. Dies bedeutet, dass der Smart Contract 99% des MEV in der Transaktion erfasst hat.

Wir nennen diese zusätzliche Gebühr, die durch den Smart Contract erhoben wird, eine MEV Steuer. MEV Steuern ermöglichen es einer Anwendung, die Prioritätsbestellung zu ihrem eigenen Vorteil zu entführen, so dass sie MEV für ihre Benutzer zurückerobern kann, anstatt sie an den Blockvorschlager weiterzugeben.

Wenn diese Gebühr in Abhängigkeit von priorityFeePerGas ausreichend schnell ansteigt, fällt dem Antragsteller nur ein vernachlässigbarer Betrag an MEV an. Da priorityFeePerGas in wei (ein Milliardstel eines Milliardstels einer ETH) lautet, haben wir viel Präzision, mit der wir arbeiten können. Zum Beispiel, so Long wie die MEV Steuer so empfindlich ist, dass eine priorityFeePerGas von 50.000 zu einer unerschwinglich hohen Steuer führen würde, dann würde die Gesamtzahlung an den Antragsteller weniger als $ 0,01 betragen. 5

Es gibt jedoch einen wichtigen Vorbehalt. Wie im Abschnitt Einschränkungen erläutert, funktionieren MEV Steuern nur, wenn Blockvorschlagsteller bestimmte Regeln befolgen - was wir "wettbewerbsfähige Prioritätsreihenfolge" nennen - anstatt von diesen Regeln in Order abzuweichen, um ihre eigenen Einnahmen zu maximieren. Die Durchsetzung dieser Regeln auf vertrauenslose Weise ist ein offenes Problem.

Single-application MEV capture

Hier skizzieren wir, wie auf einer Chain, die garantiert eine wettbewerbsfähige Prioritätsbestellung für die Blockbildung verwendet, MEV Steuern verwendet werden könnten, um drei wichtige Probleme in der MEV zu entschärfen: DEX Schnittstellen die Handelsausführung für Swapper verbessern zu lassen, AMMs die Arbitrageverluste für ihre LPs zu reduzieren und Wallets die Möglichkeit zu geben, MEV Leckagen für ihre Benutzer zu reduzieren, indem sie das Recht verkaufen, den Benutzer zurückzulaufen.

DEX Router

In absichtsbasierten DEX-Routing-Protokollen wie UniswapX und 1inch Fusion unterschreibt ein Benutzer (Alice) eine Tauschabsicht, und die Suchenden konkurrieren darum, diese Absicht zum bestmöglichen Preis für Alice weiterzuleiten oder zu erfüllen.

Aktuelle Versionen von UniswapX verwenden zwei Mechanismen, um diesen Wettbewerb durchzuführen: eine niederländische Auktion, bei der sich Alices Limitpreis im Laufe der Zeit ändert, bis ein Suchender ihn ausfüllt, und eine anfängliche Offchain-Request-for-Quote (RFQ)-Auktion, um den Startpreis dieser niederländischen Auktion festzulegen.

Auf einer Plattform, die eine wettbewerbsfähige Prioritätsbestellung garantiert, könnte UniswapX diese durch einen einzigen Mechanismus ersetzen: eine MEV. Dies könnte implementiert werden, indem der Benutzer eine Order unterzeichnet, die sofort von jedem ausgeführt werden kann, jedoch mit einem Ausführungspreis, der in Abhängigkeit von der Priorität der Transaktion festgelegt wird.

Wenn Alice beispielsweise eine UniswapX Order hat, um 1 ETH zu verkaufen, könnte sie den Ausführungspreis der Order auf minimumPrice + ($0.01 * priorityFeePerGas) definieren. minimumPrice könnte ein fester Wert sein, von dem sie erwartet, dass er deutlich niedriger ist als der aktuelle Preis.

Die Suchenden würden konkurrieren, um Alices Order zu erfüllen, indem sie Transaktionen einreichen. Welche Transaktion die höchste Prioritätsgebühr hat und nicht rückgängig gemacht wird, würde die Order erfüllen, was garantieren sollte, dass der Swapper den besten Preis erhält, den Suchende finden können. (Einige Ausnahmen hiervon werden im Abschnitt Einschränkungen erläutert.)

Wenn der Mindestpreis von Alice 3.000 USD beträgt und der aktuelle Preis von ETH 3.500 USD beträgt, würde priorityFeePerGas in der Gewinnertransaktion 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 USD - an den Blockvorschlager führt.)

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

Bestellungen, die MEV Steuern verwenden, könnten schneller und zu einem besseren Preis abgeschlossen werden als Bestellungen, die niederländische Auktionen verwenden. Wie in dieses Artikels erläutert, verlieren niederländische Onchain-Auktionen aufgrund von Preisbewegungen zwischen den Blöcken einen gewissen Wert an MEV und können viele Blöcke in Anspruch nehmen. Im Gegensatz dazu könnten Aufträge, die MEV Steuern verwenden, in der Regel im nächsten Block abgeschlossen werden, während die überwiegende Mehrheit ihrer MEV erfasst wird.

Im Gegensatz zu einer Offchain-Anfrage würde die Auktion zur Erfüllung einer Order, die MEV Steuern verwendet, atomar mit Transaktionsausführung auf der Blockchain erfolgen. Dies bedeutet, dass einem erfolgreichen Bieter garantiert werden kann, dass er nur dann verpflichtet ist, die Order auszuführen, wenn seine Onchain-Transaktion erfolgreich ist. Das könnte es für Onchain-Liquidität wie AMMs einfacher machen, mit Offchain-Liquidität zu konkurrieren, was bedeutet, dass UniswapX als noch effektiverer Router für Multi-Pool-Systeme wie Uniswap v4 dienen könnte.

AMMs

Normalerweise verlieren AMMs Wert an Arbitrageure, die gegen veraltete Preise an der Spitze des Blocks handeln, wie in den loss-vs-rebalancing papers erläutert. Wir können MEV Steuern verwenden, um AMMs dazu zu bringen, diese MEV zu erfassen. Der Einfachheit halber werden wir besprechen, wie dies bei einem AMM ohne konzentrierte Liquidität funktionieren könnte. (Wenn Sie daran interessiert sind, wie diese Art von Problem mit konzentrierter Liquidität gelöst werden könnte, Sorella wird bald eine Lösung veröffentlichen.)

Ein AMM kann MEV erfassen, indem er eine zusätzliche Gebühr in Abhängigkeit von der Prioritätsgebühr für die Transaktion erhebt, so dass es das Recht, zuerst im Block zu handeln, versteigern kann. Es gibt viele Möglichkeiten, diese Gebühr zu berechnen und zu benennen. Wir werden eine wohl neutrale Frage diskutieren – die Bezeichnung in Einheiten der Pool-Liquiditä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 kann der Pool die Bedingung erzwingen, anstatt die Bedingung x_end y_end > x_start y_start zu erzwingen (mit einer Konstante):

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

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

Nach dieser ersten Transaktion könnten Trades wie auf Uniswap v2 funktionieren, mit festen Swap-Gebühren. Uninformierte Transaktionen, die im 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 ein AMM zu implementieren, die unterschiedliche Auswirkungen hätten. Zum Beispiel könnten MEV-Steuern im Input- oder Output-Token des MEV des Swaps denominiert sein, könnten den vom Pool angewendeten Prozentsatz der Swap-Gebühren beeinflussen oder den Mindestpreis des Handels des Nutzers bestimmen. Wir denken, dass dies ein interessanter Designbereich ist, den es zu erkunden gilt.

Backrunning-Auktionen

Die obigen Beschreibungen zeigen, wie bestimmte Anwendungen entworfen werden können, um MEV zu vermeiden. Was ist jedoch, wenn eine Wallet versuchen möchte, ihren Benutzern zu helfen, die MEV zu erfassen, die sie aus beliebigen Transaktionen erstellen, die mit einer beliebigen Anwendung interagieren, auch mit solchen, die keine MEV Steuern enthalten?

Wenn Alice beispielsweise eine große Transaktion mit einem AMM durchführt, schafft sie manchmal eine Arbitragemöglichkeit für "Backrunner", um den Preis zurückzubewegen. Dies wird normalerweise an MEV durchgesickert, anstatt an Alice zu gehen.

MEV-Share und MEVBlocker sind zwei Protokolle, die es den Nutzern ermöglichen, MEV aus ihren Transaktionen zu erfassen, aber sie basieren auf einem komplexen Offchain-Auktionssystem. Der Orderflow Auction Design Space beschreibt einige andere Lösungen.

MEV Steuern, kombiniert mit einer absichtsbasierten Smart Contract Wallet, könnten es uns ermöglichen, ein alternatives System zu konstruieren, um rücklaufende MEV für Alice zu erfassen. Angenommen, Alice signiert eine Absicht, die jeder an Alices Smart-Contract-Wallet übermitteln kann, anstatt eine Transaktion zu erstellen, die auf dem AMM gehandelt wird, um sie dazu zu veranlassen, diese Aktion auszuführen. Alices Smart-Contract-Wallet berechnet demjenigen, der diese Transaktion einreicht, eine MEV Steuer, die an Alice gezahlt wird.

Der Suchende, der Alices Absicht übermittelt, hat das ausschließliche Recht, sie zurückzuverfolgen, da er dies atomar in derselben Transaktion tun kann. Wenn die Suche wettbewerbsfähig ist, sollte der gesamte Gewinn aus dem Backrunning von Alice Alice durch ihre MEV Tax zufließ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 die Zahlung einer MEV an diesen Benutzer vermeiden kann. 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

Zusätzlich zu diesen Beispielen könnten andere potenzielle Verwendungszwecke von MEV Steuern fast alles umfassen, was derzeit eine Offchain- oder niederländische Auktion verwendet, wie zum Beispiel:

• Protokolle für Orakel, um den von ihnen erzeugten extrahierbaren Oracle-Wert zu erfassen, z. B. Oval
• Refinanzierungsauktionen in NFT-besicherten Kreditprotokollen wie Blend
• Lending Protokoll Liquidationen, die leak less höher als bei niederländischen Auktionen

Anwendungsübergreifende MEV-Erfassung

Die oben genannten Lösungen sind so konzipiert, dass sie die MEV aus der Interaktion mit einer einzelnen Anwendung erfassen. Aber manchmal kann es für einen Suchenden möglich sein, noch mehr Wert zu erzielen, indem er mit mehreren Anwendungen in derselben Transaktion interagiert.

Wenn nur eine dieser Anwendungen eine MEV Steuer hat, sollten alle 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 Steuern verwenden? Was ist zum Beispiel, wenn es einen MEV gibt, der nur durch das Ausführen einer der oben beschriebenen MEV besteuerten UniswapX-Orders gegen einen MEV besteuerten AMM erfasst werden kann?

In diesem Fall wird der relative Betrag des überschüssigen MEV, der von jeder Anwendung erfasst wird, dadurch bestimmt, wie diese Anwendungen ihre MEV Steuern festlegen. Wenn der Wert, den app_i als MEV Steuer berechnet, durch die Funktion tax_i(Priorität) gegeben ist, dann kann die Priorität der gewinnenden Transaktion bestimmt werden, indem die Priorität in dieser Gleichung aufgelöst wird:

tax_1(priorityPerGas) + tax_2(priorityPerGas) = gesamter MEV

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

Im einfachen Fall MEV Steuern, die linear in priorityPerGas sind (also tax_1(priorityPerGas) = a_1 * priorityPerGas), können Sie den Anteil der MEV auflösen, die von jeder Anwendung empfangen werden:

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

Wenn eine Anwendung ihre eigene MEV festlegt, steht sie vor einem Kompromiss: Höhere Steuern ermöglichen es ihr, einen größeren Anteil der anwendungsübergreifenden MEV zu erfassen, wenn sie auftritt, bedeuten jedoch, dass sie einen anwendungsübergreifenden MEV verpassen könnte, wenn es konkurrierende Möglichkeiten gibt, sie zu extrahieren. Wenn es beispielsweise ein AMM gibt, das für jeden Handel eine MEV Steuer erhebt, dann ist es wahrscheinlicher, dass eine MEV Tax UniswapX Order von einem anderen AMM oder einem Offchain-Füller erfüllt wird.

In vielen Fällen kann es ein Gleichgewicht geben, in dem zwei Anwendungen ihre MEV Steuern so gestalten, Order MEV so zu teilen, dass ihr Wohlergehen maximiert wird. Zum Beispiel würde ein MEV Tax AMM wahrscheinlich Wert von einem einzelnen informierten Händler in der Nähe der Spitze des Blocks erfassen wollen, würde dann aber anderen Händlern und Anwendungen (einschließlich solcher, die MEV Steuern verwenden) Liquidität mit einer niedrigen festen Gebühr zur Verfügung stellen wollen. In diesem Fall wird der AMM wahrscheinlich eine relativ niedrige MEV Steuer festlegen (z. B. $ 0,00001 priorityFeePerGas), so dass die Arbitragetransaktion (falls vorhanden) früh im Block stattfindet und dann keine MEV Steuer auf nachfolgende Transaktionen im Block berechnet. Anwendungen wie UniswapX, die mit dem AMM interagieren möchten, können eine viel höhere MEV Steuer festlegen (z. B. 0,01 $ priorityFeePerGas), um sicherzustellen, dass ihre Transaktionen einbezogen werden, nachdem der Pool bereits arbitriert wurde. Mit diesen relativen Steuern würde der AMM zuerst arbed werden, selbst wenn es nur $ 1 MEV und $ 50.000 MEV in einem UniswapX Order gäbe.

Wir sind der Meinung, dass dies ein breiter Designbereich ist, der es wert ist, in Zukunft untersucht zu werden.

Einschränkungen

MEV Steuern haben einige Komplikationen und Nachteile. Wir denken, dass jeder dieser Bereiche ein interessanter Bereich für zukünftige Forschung ist.

Anreizinkompatibilität

MEV Steuern sind für einen monopolistischen Blockvorschlager nicht anreizkompatibel. Sie funktionieren nur, wenn es einen fairen Wettbewerb um die Aufnahme von Transaktionen gibt, was nur möglich ist, wenn der Blockvorschlagsteller Regeln befolgt, die wir als "kompetitive Prioritätsreihenfolge" bezeichnen, anstatt seine eigenen Einnahmen zu maximieren. Informell und nicht erschöpfend schlagen wir vor, dass diese Regeln Folgendes umfassen sollten:

• Vorrangige Reihenfolge. Transaktionen innerhalb eines Blocks müssen in absteigender Order von priorityFeePerGas sortiert werden.
• Zensur-Widerstand. Wenn der Blockvorschlager während des Blocks eine Transaktion t1 empfängt und der Block entweder nicht voll ist oder eine Transaktion t2 enthält, so dass t2.priorityFeePerGas < t1.priorityFeePerGas ist, muss der Block die Transaktion t1 enthalten.
• Datenschutz vor der Transaktion. Der Blockvorschlagsteller muss Transaktionen über einen privaten Endpunkt akzeptieren und darf solche Transaktionen nicht mit anderen teilen, bevor er sich für den Block festlegt, oder den Inhalt dieser Transaktionen als Eingabe für die Erstellung seiner eigenen Transaktionen verwenden.
• Kein letzter Blick. Der Blockvorschlagsteller muss eine bestimmte Zeit festlegen, vor der er Transaktionen von irgendjemandem akzeptiert und nach der er keine Transaktionen von irgendjemandem mehr akzeptiert.

Wenn eine oder mehrere dieser Eigenschaften verletzt werden, kann dies die Wirksamkeit der MEV Steuern schwächen. Ein Blockvorschlagsteller, der gegen den Widerstand der Zensur verstößt, 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 selbst nutzt. Ein Blockvorschlagsteller, der die Privatsphäre vor der Transaktion verletzt, könnte MEV von anderen Transaktionen stehlen oder einen Blick auf ihre Prioritätsgebühren werfen, um genau zu wissen, wie hoch er seine eigenen festlegen muss, während einer, der in der Lage ist, Transaktionen später als jeder andere einzureichen, einen freien "letzten Blick" darauf hätte, ob er andere für eine Gelegenheit überbieten soll. Beides könnte zu nachteiligen Selektionsproblemen führen, die letztlich den Wettbewerb behindern.

Während die erste Eigenschaft auf der Protokollschicht leicht durchzusetzen wäre, ist die Durchsetzung der anderen Eigenschaften leider ein offenes Problem.

In Ermangelung einer Durchsetzung auf der Protokollschicht muss man einem einzelnen Sequenzer, der sich zu diesen Regeln verpflichtet, vertrauen können, dass er nicht von ihnen abweicht, und wenn die Antragsteller die Blockbildung an eine wettbewerbsfähige umsatzmaximierende Auktion auslagern (wie z. B. Ethereum L1s MEV-Boost), werden die Blöcke ihnen wahrscheinlich nicht folgen.

Diese Probleme können mit einem einzigen vertrauenswürdigen Sequenzer "gelöst" werden, der sich verpflichtet, die konkurrierende Prioritätsreihenfolge für die Blockerstellung zu verwenden. Sie können auch mit einem dezentralen Mechanismus gelöst werden, der eine Kombination aus Konsens, Kryptographie und/oder vertrauenswürdigen Ausführungsumgebungen verwendet, wie z. B. Sorellas Angstström, Flashbots' SUAVE, Leaderless Auctions oder Multiplicity.

Vollständige Blöcke

Eine Ausnahme vom normalen Betrieb MEV Steuern tritt auf, wenn die Blöcke vollständig voll sind. In diesem Fall müssen Blockvorschlager möglicherweise Transaktionen mit niedrigerer Priorität auslassen, anstatt sie einfach spät in den Block aufzunehmen. Da Transaktionen, die mit MEV besteuerten Anwendungen interagieren, wahrscheinlich extrem niedrige Prioritätsgebühren haben, werden diese Anwendungen wahrscheinlich von Anwendungen verdrängt, die keine MEV Steuern verwenden, oder solchen, die extrem niedrige MEV Steuern haben. In einer Kette, die einen EIP-1559-ähnlichen Mechanismus verwendet, um eine separate Basisgebühr festzulegen, sollte es jedoch relativ selten vorkommen, dass Blöcke vollständig voll sind. Angesichts der Tatsache, dass einige Transaktionen verzögert werden müssen, wenn die Blöcke voll sind, kann die Verzögerung von Transaktionen, die eine geringere Dringlichkeit durch die Festlegung höherer MEV ausdrücken, ein angemessenes Ergebnis sein.

Rückgängig gemachte Transaktionen

MEV Steuern beruhen effektiv auf Single-Block-Auktionen, bei denen jedes "Gebot" eine Transaktion ist. Ein Nachteil dieser Auktionen ist, dass verlorene Gebote in der Regel dazu führen, dass rückgängig gemachte Transaktionen in die Blockchain aufgenommen werden, eine Grundgebühr gezahlt werden und die Kette überlastet wird.

Wenn ein Sequenzer fehlgeschlagene Transaktionen vollständig ausschließen kann, würde dies dieses Problem lindern, obwohl dies selbst mit einem zentralisierten Sequenzer schwierig zu implementieren sein kann. (Es würde auch nicht strikt der oben beschriebenen Zensur-Widerstand-Eigenschaft gehorchen, obwohl diese Definition angepasst werden könnte.) Ein ausgefeilterer Sequenzer kann diesen Prozess möglicherweise optimieren, indem er es Transaktionen ermöglicht, anzugeben, an welchen umstrittenen Auktionen sie teilnehmen, und dem Sequenzer genügend Informationen zur Verfügung stellt, um nachfolgende Transaktionen zu überspringen, von denen er weiß, dass sie fehlschlagen würden.

Das Durchsickern von Nutzerabsichten

MEV Steuern funktioniert nur, wenn es einen Wettbewerb unter den Suchenden gibt, was bedeutet, dass die Möglichkeit einigermaßen bekannt sein muss. Für Anwendungen wie AMMs, bei denen die Möglichkeit auf der Blockchain sichtbar ist, sollte dies auf natürliche Weise geschehen. Bei Anwendungen wie absichtsbasiertem Routing oder Backrunning-Auktionen bedeutet dies jedoch, dass die Anwendung möglicherweise die Absicht des Benutzers mit Suchenden teilen muss.

In einigen Fällen kann die vorübergehende Privatsphäre, die durch die Übertragung der Absicht des Benutzers verloren geht, bevor sie erfüllt ist, Wert in einer Weise verlieren, die nicht durch eine MEV zurückgewonnen werden kann.

Angenommen, Alice möchte ein Token mit geringer Liquidität mit dem oben beschriebenen Protokoll der Backrunning-Auktion kaufen. Sie veröffentlicht eine unterzeichnete Absicht für ihre Smart-Contract-Wallet, dieses Token auf einem AMM zu kaufen, und legt eine gewisse Schlupftoleranz fest. Suchende könnten versuchen, den Preis dieses Tokens in einer Transaktion mit hoher Priorität auf ihre Slippage-Toleranz zu drücken, ohne die Order des Benutzers auszuführen. Der Gewinner, Bob, könnte dann Alices Absicht nicht wettbewerbsfähig erfüllen, indem er sie in eine Transaktion mit niedriger Priorität einbezieht und zurückläuft, wodurch Alices Handel eingeklemmt und ihr ein schlechterer Preis gegeben wird, während sie ihre MEV Steuer umgeht. Ein ähnliches Problem könnte beim Kauf von NFTs auftreten.

Beachten Sie, dass ein solcher Angriff für Bob riskant wäre, da er nicht in der Lage wäre, die Unteilbarkeit zwischen dem Kauf des Tokens und dem Verkauf an Alice zu garantieren. Ein naiver Bob könnte Opfer einer "Sandwich-Ripping"-Falle fallen, in der Alice die Absicht veröffentlicht, ein wertloses Token von sich selbst zu kaufen, was Bob dazu veranlasst, es in Falle zu kaufen, um ihren Handel zu verkaufen, aber Alice widerruft ihre Absicht, bevor Bob das Sandwich abschließen kann.

Anwendungen können dies möglicherweise auch abmildern, indem sie die Gruppe der Suchenden, mit denen sie Absichten teilen, einschränken und ihr Verhalten überwachen, wie es bei vielen bestehenden Orderflow-Auktionen der Fall ist.

Es könnte auch möglich sein, MEV Steuern mit datenschutzfreundlichen Builder-Funktionen zu kombinieren, wie sie in den Designs von Flashbots für SUAVE vorgesehen sind.

In Fällen, in denen Alice zu dem Schluss kommt, dass die Kosten für die Weitergabe ihrer Absicht den Nutzen der kompetitiven Suche überwiegen, könnte sie schließlich selbst eine Transaktion erstellen und diese direkt in den Block einreichen. Wie oben erörtert, würde eine ideale Implementierung der kompetitiven Prioritätsbestellung die Privatsphäre vor der Transaktion vor dem Blockvorschlager gewährleisten.

Diskussion und vorherige Arbeiten

Vorrang Gas Auktionen. Einige der Dynamiken der Prioritätsreihenfolge in dezentralen Blockchains wurden in der Flash Boys 2.0 Paper untersucht, die den Begriff "Miner extractable Value" prägte. In diesem Papier wurde festgestellt, dass Ethereum Miner (als dieses Netzwerk Proof-of-Work verwendete) bereits Transaktionen nach Priorität bestellten und dass Arbitrageure sich auf dieses Verhalten verließen, um an "vorrangigen Gasauktionen" teilzunehmen, bei denen sie für das Recht boten, zuerst in einen Block aufgenommen zu werden, was dazu führte, dass ein Großteil der MEV aus dezentraler Börse den Minern zufiel.

Wer zuerst kommt, mahlt zuerst. Einige Versuche, MEV durch Regeln für die Transaktionsreihenfolge zu entschärfen, wie z. B. Themis oder Arbitrum One's current sequencer,7 haben sich darauf konzentriert, eine andere Reihenfolgeregel durchzusetzen, wer zuerst kommt, mahlt zuerst (manchmal auch als "faire Reihenfolge" bezeichnet), bei der Blockvorschlagsteller Order Transaktionen in der Order, in der sie sie sehen.

Bei der Prioritätsreihenfolge wird ein anderer Ansatz verfolgt: Transaktionen, die innerhalb eines bestimmten Zeitraums eingehen, werden gleich behandelt und stattdessen nach ihrer deklarierten Priorität sortiert.

Wer zuerst kommt, mahlt zuerst, ist in einer realen Netzwerkumgebung mit mehr als einem Validator schwer durchzusetzen oder gar zu definieren. Es kann auch zu verschwenderischen Latenzzeiten und Spam führen, selbst mit einem einzigen vertrauenswürdigen Sequenzer. Schließlich könnten MEV Steuern in der Lage sein, bestimmte Arten von MEV zu eliminieren, die nach dem Prinzip "Wer zuerst kommt, mahlt zuerst" nicht möglich sind, wie z. B. Arbitragegewinne aus diskontinuierlichen "Sprüngen" bei den Vermögenspreisen. Die potenziellen Vorteile der Prioritätsbestellung gegenüber der Bestellung nach dem Prinzip "Wer zuerst kommt, mahlt zuerst" hängen in gewisser Weise mit den Vorteilen des zeitdiskreten Austauschs gegenüber dem zeitkontinuierlichen Austausch zusammen, die in Budish, Cramton, Shim (2015) diskutiert werden.

In der Zwischenzeit, während die Prioritätsreihenfolge standardmäßig Wert an MEV zu verlieren scheint, zeigt dieser Beitrag, wie Anwendungen entworfen werden können, um ihn zurückzuerobern.

Gebührenteilung. Blast, ein Ethereum L2, teilt sich einen Teil der Prioritäts- und Grundgebühren mit dem Smart Contracts, auf das in einer Transaktion zugegriffen wird.

MEV Steuern erlauben etwas Ähnliches (zumindest für Prioritätsgebühren), können aber auf der Anwendungsebene in jeder Kette implementiert werden, die eine wettbewerbsfähige Prioritätsbestellung verwendet, ohne besondere Unterstützung für die Gebührenaufteilung. Sie ermöglichen es Anwendungen auch, ihre eigenen Steuern als benutzerdefinierte Funktionen der Prioritätsgebühr zu definieren, was mehr Flexibilität bietet und möglicherweise zu einer besseren Zusammenstellung von MEV-fähigen Anwendungen führt.

Vertrauenslose Lösungen. Dieser Beitrag konzentriert sich auf die Motivation von Plattformen, die kompetitive Prioritätsreihenfolge zu nutzen – und auf Möglichkeiten, die Vorteile von Plattformen zu nutzen, die dies tun –, anstatt darüber zu diskutieren, wie man sie vertrauenslos durchsetzen kann.

Die einzelnen anderen Eigenschaften, die für eine wettbewerbsorientierte Prioritätsbestellung erforderlich sind, wurden im Vorfeld ausführlich erörtert. In Fox, Pai, Resnick (2023) diskutieren die Autoren beispielsweise Schwachstellen in Onchain-Auktionen in Abwesenheit von Widerstand gegen Zensur und beschreiben ein Design für eine zensurresistente Auktion mit mehreren gleichzeitigen Antragstellern. Sie schlagen jedoch keine bestimmte Reihenfolge für Transaktionen vor.

Es gab weitere Forschungen zur Konstruktion von Mechanismen für die vertrauensminimierte Blockbildung, darunter Flashbots' SUAVE, Sorella's Angstström, Leaderless Auctions, Espresso und Offchain Labs' @espressosys/espresso-systems-and-offchain-labs-release-r-d-roadmap-for-decentralized-timeboost-5d0007dff66d">decentralized Timeboost, und mandatierte Einbeziehung öffentlicher Transaktionen durch Péter Szilági.

Fazit

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

Wir hoffen auch, dass dies die weitere Erforschung von Protokollen für vertrauensminimierte Wettbewerbsprioritätsbestellungen sowohl auf L1 als auch auf L2 motiviert. Wenn Sie daran interessiert sind, an diesem Problem mitzuarbeiten, und dies vor Donnerstag, dem 6. Juni, lesen, können Sie sich immer noch für ein TLDR-Stipendium bewerben, um mit Dan an MEV-resistenten L2-Sequenzern zu arbeiten. Oder wenden Sie sich einfach an dan@paradigm.xyz und dave@paradigm.xyz mit Ideen!

Fußnoten

1. In diesem Beitrag verwenden wir "proposer", um uns auf den Akteur oder Prozess zu beziehen, der bestimmt, welche Transaktionen in einem bestimmten Block enthalten sind. Auf Ethereum L2s wird diese Rolle typischerweise von einem "Sequenzer" ausgefüllt. Auf Ethereum L1 wird es von einem bestimmten Ethereum Validator gefüllt, der als Proposer bezeichnet wird, obwohl der Vorschlagende oft die Aufgabe, den Block zu erstellen, an einer wettbewerbsfähigen Auktion auslagert, an der "Relayer" und "Builder" teilnehmen. Die Details, wie diese Verantwortlichkeiten aufgeteilt sind, würden den Rahmen dieses Beitrags sprengen. ↩
2. Die Prioritätsgebühr pro Gas ist in der Transaktion nicht explizit angegeben, kann aber in ihr berechnet werden. Die Transaktion gibt einen Gaspreis an, aber Ethereum erhebt auch eine Grundgebühr, die vom Gaspreis abgezogen und verbrannt wird. Die Grundgebühr sollte für die Zwecke der MEV-Steuern ignoriert werden, da sie nicht unter der Kontrolle des MEV steht. Die Prioritätsgebühr pro Gas – der Preis für den Teil der Transaktionsgebühr, der an den Blockvorschlager geht – kann in Solidity als priorityGasPrice = tx.gasprice - block.basefee berechnet werden. ↩
3. Alternativ könnten wir einfach "MEV" definieren, um jeden Suchergewinn auszuschließen und uns nur auf den Wert zu beziehen, der an den Validator gehen würde. ↩
4. Beachten Sie, dass proposerPriorityFee – gleich priorityFeePerGas multipliziert mit dem gesamten in der Transaktion verwendeten Gas – während des Vertrags nicht berechnet werden kann, da es keine Möglichkeit gibt zu wissen, wie viel Gas die Transaktion am Ende verbrauchen wird. Dies spielt jedoch im Allgemeinen keine Rolle, da wir nur eine Obergrenze dafür benötigen. Um sicher zu gehen, könnten Sie priorityFeePerGas mit 30 Millionen multiplizieren - das aktuelle maximale Gas in einem Ethereum-Block. Eine Überschätzung dieses Wertes bedeutet lediglich, dass die MEV Steuer einen noch größeren Prozentsatz der MEV erfasst. ↩
5. Unter der Annahme, dass eine Transaktion nicht mehr als 30 Millionen Gas betragen kann, würde eine priorityFeePerGas von 50.000 zu einer Gas Zahlung von 1500 gwei führen – etwa 0,006 US-Dollar bei einem ETH Preis von 4000 US-Dollar. ↩
6. In dem Fall, in dem priorityFeePerGas so festgelegt ist, dass der Gewinn des Arbitrageur Null ist, sollte der gewinnmaximierende Arbitrage-Trade dem gleichen Handel auf dem funktionsmaximierenden AMM entsprechen. Dies zu beweisen, bleibt dem Leser als Übung überlassen. ↩
7. Arbitrum hat diskutiert, dies durch eine Form der Prioritätsreihenfolge namens Timeboost zu ersetzen, aber das wurde zum Zeitpunkt des Schreibens noch nicht in Produktion genommen. ↩

Haftungsausschluss:

1. Dieser Artikel ist ein Nachdruck von [paradigm]. Alle Urheberrechte liegen beim ursprünglichen Autor [Dan Robinson & Dave White]. 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.