Miner Extractable Value (MEV) und programmierbares Geld: Das Gute, das Schlechte und das Hässliche
Blockstream Research

Miner Extractable Value (MEV) und programmierbares Geld: Das Gute, das Schlechte und das Hässliche

Kiara Bickers
Kiara Bickers

Das Kernstück des Sicherheitsmodells von Bitcoin basiert auf dieser grundlegenden Spieltheorie – Miner, bewaffnet mit ihren digitalen Spitzhacken, sind unermüdlich auf der Jagd nach Profit. Und es ist diese Jagd, die das Netzwerk sicher hält. Einfaches Standard-Mining beinhaltet das Produzieren von Blöcken, um die Blockbelohnungen und Transaktionsgebühren zu verdienen, aber haben Sie jemals darüber nachgedacht, dass Miner möglicherweise andere Wege haben, um Wert aus der Blockchain zu extrahieren, jenseits dieses Standard-Mining-Prozesses? Gibt es andere Wege, auf denen Miner ihre einzigartige Position als Validatoren nutzen können, um auf der Blockchain Profit zu machen?

Was ist MEV?

In Proof-of-Work-Systemen beschreibt der Begriff „Miner Extractable Value“ (MEV) die Gewinne, die Miner durch Manipulation der Priorisierung, des Ausschlusses, der Neuanordnung oder Veränderung von Transaktionen in den Blöcken, die sie minen, erzielen können. Seit dem Upgrade von Ethereum auf Ethereum 2.0, das das Netzwerk auf Proof-of-Stake umstellte, hat das Konzept von MEV einen neuen Namen angenommen und wird nun in Proof-of-Stake-Systemen als „Maximal Extractable Value“ bezeichnet. In diesem Kontext sind es die Blockvorschläger statt der Miner – die Validatoren – die die Möglichkeit haben, diesen Wert zu extrahieren.

Miner (oder Validatoren in Ethereum) spielen eine besondere Rolle in diesen Netzwerken, indem sie Transaktionen in Blöcken bestätigen. Ihre Position versetzt sie einen Schritt vor andere Benutzer und ermöglicht es ihnen, die endgültige Reihenfolge der Transaktionen in der Kette zu bestimmen. In einem Block werden Transaktionen typischerweise nach den höchsten Gebühren angeordnet, aber gelegentlich eröffnen sich Möglichkeiten, die es den Minern ermöglichen, zusätzlichen Profit zu erzielen, indem sie die Reihenfolge der Transaktionen strategisch zu ihrem eigenen Vorteil ändern.

Vielleicht denken Sie, was schadet es, wenn Miner ein wenig zusätzlichen Profit abgreifen? Die Bedenken tauchen erst auf, wenn einige dieser Miner, die mit fortschrittlicheren Analysefähigkeiten und leistungsfähigeren Computern ausgestattet sind, MEV-Profitchancen effektiver erkennen und ausnutzen können als andere.

Diese Chancen sind möglicherweise nicht immer leicht zu erkennen, aber je mehr Wert durch die Analyse der Kette extrahiert werden kann, desto stärker wird der Anreiz für Forschungsteams, die mit Bots ausgestattet sind, diese Arbeit zu erledigen. Im Laufe der Zeit schafft dieser Unterschied in der Profitabilität der Miner einen Trend zur Zentralisierung innerhalb des Netzwerks. Letztendlich untergräbt dies das Grundprinzip der Blockchain: Dezentralisierung.

Dies ist genau das Szenario, das die Bitcoin-Entwicklergemeinschaft verhindern will, wenn sie darüber nachdenkt, wie sie mehr Expressivität in Bitcoin erreichen wollen.

Warum wollen wir programmierbares Geld?

Historisch gesehen hat Bitcoin mit relativ einfachen Smart Contracts operiert. Dieses Modell hat jedoch Schwierigkeiten mit selbst mäßig komplexen Transaktionen. Bitcoin Script kann nur Authentifizierungsdaten validieren, es hat nicht die Fähigkeit, Geschwindigkeitsbegrenzungen für Transaktionen festzulegen oder Zieladressen für Bitcoins zu definieren, weil Bitcoin Script keinen Zugriff auf Transaktionsdaten hat.

Ein etwas separates Problem ist, dass die Arbeit mit und das Schreiben von Bitcoin-Smart-Contracts für Benutzer, die die Sicherheitsanforderungen nicht vollständig verstehen, schwierig sein kann. Ein vorgeschlagenes Feature, bekannt als "Vaults", zielt darauf ab, einige dieser Schwierigkeiten zu lösen, indem zeitgesperrte Bedingungen für Transaktionen eingeführt werden. Im Wesentlichen könnten Vaults als"Notausgang" dienen, der es Benutzern ermöglicht, ihre Mittel im Falle kompromittierter privater Schlüssel wiederherzustellen. Aber solche Features sind nur mit mehr Expressivität möglich.

Ethereum ist weithin bekannt für seine hoch ausdrucksstarken Scripting-Fähigkeiten, hat aber auch mit dem Problem von MEV zu kämpfen. Die meisten Benutzer gehen davon aus, dass Bitcoin kein MEV hat, im krassen Gegensatz zu Ethereum, das als wildes Terrain dafür angesehen wird. Aber ist dies die ganze Geschichte?

Führen expressivere Smart Contracts zwangsläufig zu mehr MEV-Szenarien?

Es gibt mehrere Faktoren, die zu MEV beitragen: (1) Mempool-Transparenz, (2) Smart Contract-Transparenz und (3) Smart Contract-Expressivität. Jeder dieser Faktoren öffnet neue Kanäle für MEV; wir werden jeden hier überprüfen.

Bitcoin as Open-Source Money

Das Schlechte: (1) Mempool-Transparenz

Wie der Mempool von Bitcoin sind die Mempools der meisten Blockchains vollständig transparent, offen und sichtbar, sodass jeder sehen kann, welche Transaktionen ausstehen, bevor sie validiert und in einem Block bestätigt werden. Bitcoin-Blöcke brauchen typischerweise etwa 10 Minuten, um gefunden zu werden, was den Minern theoretisch dieselbe Zeit gibt, um Vorteile zu nutzen und vorzugreifen.

In der Praxis ist dies bei Bitcoin aus mehreren Gründen keine Quelle für MEV: (1) Bitcoin-Transaktionen sind einfach genug, dass keine Miner einen signifikanten Analysevorteil gegenüber anderen Minern haben, und (2) Bitcoin-Transaktionen führen in der Regel keine Multi-Asset-Transaktionen wie Swaps oder offene Trades aus, die ausgenutzt werden könnten (front run).

Im Gegensatz dazu hat Ethereum einige der komplexesten Multi-Asset-Transaktionen auf öffentlichen dezentralen Börsen (DEXs). Offiziell beträgt die Blockzeit bei Ethereum 15 Sekunden, aber in Zeiten voller Mempools kann die erforderliche Gasgebühr für die sofortige Aufnahme in einen Block leicht Hunderte von Dollar überschreiten. Infolgedessen warten Transaktionen mit niedrigeren Gebühren Minuten oder sogar Stunden, bevor sie in einen Block aufgenommen werden. Dies kann das Zeitfenster für diese bösartigen Front-Running-Möglichkeiten verlängern, die auf Ethereum aufgrund des erheblichen Werts, der in Layer-2-Token gebunden ist, bereits häufiger vorkommen.

Das Schlechte: (2) Smart Contract-Transparenz

Bei Bitcoin sind „Smart Contracts“ der einfache Sperr- und Entsperrmechanismus, der in Bitcoin Script enthalten ist. Die Transaktionswerte, Sender- und Empfängerdetails sind alle öffentlich auf der Blockchain sichtbar. Während diese vollständige und nackte Transparenz aus Sicht des Datenschutzes nicht ideal ist, ist sie Teil der Art und Weise, wie Bitcoin es allen Teilnehmern im Netzwerk ermöglicht, den Status der Blockchain zu überprüfen. Jeder Beobachter kann diese Vertragsdetails analysieren, was potenziell die Tür zu bestimmten MEV-bezogenen Strategien öffnet.

Aber die Bitcoin-Skriptsprache ist von Natur aus ziemlich begrenzt, sie konzentriert sich hauptsächlich auf die grundlegenden Funktionen des Sendens und Empfangens von Geldern und der Validierung von Transaktionen mit Signaturen oder Hashlocks. Diese Einfachheit begrenzt die Möglichkeiten für MEV-Strategien auf Bitcoin, wodurch solche Chancen im Vergleich zu anderen Ketten relativ selten sind.

Plattformen wie Ethereum, Solana und Cardano haben ebenfalls vollständig transparente Smart Contracts, aber sie unterscheiden sich von Bitcoin durch ihre hochkomplexen und ausdrucksstarken Skriptsprachen. Ihre Turing-vollständigen Systeme machen es theoretisch möglich, nahezu jede rechnerische Aufgabe auszuführen, was Folgendes umfasst: selbstausführende Verträge, Integration von Echtzeitdaten durch Orakel, dezentrale Anwendungen (dApps), Layer-2-Token, Swaps innerhalb von DEXs und automatisierte Market Maker (AMMs). Diese kommen zusammen, um ein reiches Umfeld für MEV-Möglichkeiten zu fördern. Auf Zero-Knowledge-Proof-basierte Systeme wie STARKex könnten theoretisch einige dieser Probleme vermeiden, aber dieser Kompromiss würde mit anderen Komplexitäten einhergehen.

Das Hässliche: (3) Smart Contract-Ausdruckskraft

Die MEV-Möglichkeiten sind auf einigen Ketten so lukrativ, dass es „MEV-Handelsfirmen“ gibt, die monatlich „hohe fünfstellige, mittlere sechsstellige“ Gewinne erzielen. Dieser Trend ist so prominent geworden, dass es öffentliche Dashboards gibt, die profitable Möglichkeiten auf Ethereum und Solana scannen. Ihre Rentabilität wird durch die Ausführung des ganzen Spektrums von MEV-Strategien generiert: Front-Running, Sandwich-Handel, Token-Arbitrage, Back-Running und Liquidationen, um nur einige zu nennen. Jede Strategie nutzt eine andere Smart Contract-Dynamik für Profit.

Einige dieser MEV-Strategien gelten sowohl für Layer-1 als auch für Layer-2.

  1. Generalisiertes Front-Running: Bots scannen den Mempool nach profitablen Transaktionen und führen dann die ursprüngliche Transaktion vorzeitig für einen Profit aus.
  2. Sandwich-Handel: Der Angreifer platziert Bestellungen sowohl vor als auch nach einer großen Transaktion, um die Asset-Preise zu manipulieren und Profit zu erzielen. Diese Strategie nutzt die vorhersehbare Preisbewegung, die durch die große Transaktion verursacht wird.

Dann sind bestimmte Strategien einzigartig für Layer-2-Token und Smart Contracts.

  1. Arbitrage über verschiedene DEXs: Bots nutzen Preisunterschiede für dasselbe Asset auf verschiedenen DEXs, indem sie niedrig auf einer kaufen und hoch auf einer anderen verkaufen.
  2. Back-Running in DeFi-Bonding-Kurven: MEV-Bots nutzen vorhersehbare Preisanstiege in DeFi-Bonding-Kurven, indem sie Transaktionen unmittelbar nach großen platzieren, während Aufwärtstrends kaufen und für Profit verkaufen.
  3. DeFi-Liquidationen: MEV-Bots erkennen Chancen in DeFi-Krediten, bei denen die Sicherheitenwerte unter die festgelegten Schwellenwerte fallen, und ermöglichen es Validatoren, ihre Transaktionen zu priorisieren, um die liquidierten Sicherheiten zu niedrigeren Preisen zu kaufen.

Die Komplexität von Verträgen trägt erheblich zu den Herausforderungen im Zusammenhang mit MEV bei.

  1. Re-Entrancy-Angriffe: Diese Angriffe nutzen Schwachstellen in der Smart Contract-Logik aus, sodass Angreifer eine Funktion wiederholt aufrufen können, bevor die erste Ausführung abgeschlossen ist, um mehrfach Gelder zu extrahieren. Im Kontext von MEV können qualifizierte Personen erheblich von diesen profitieren, insbesondere in Verträgen mit erheblichen Geldern.
  2. Interagierende Verträge und globaler Zustand: Auf Plattformen wie Ethereum können Smart Contracts interagieren, was zu Kettenreaktionen über mehrere Verträge von einer einzigen Transaktion aus führen kann. Diese Interkonnektivität ermöglicht komplexe MEV-Strategien, bei denen eine Transaktion in einem Vertrag einen anderen beeinflussen kann und eine Kettenreaktion von Profitmöglichkeiten bietet.

Ein Teil des Problems hier ist, dass der Gesamtwert, der durch Token und dApps auf Layer-2 erstellt wird, oft den Wert des nativen Assets der Blockchain auf Layer-1 übersteigt, wodurch der Anreiz der Validatoren untergraben wird, Transaktionen rein auf der Grundlage von Gebühren auszuwählen und zu bestätigen.

Noch schlimmer ist, dass viele dieser Möglichkeiten nicht strikt auf Netzwerkvalidatoren beschränkt sind. Andere Netzwerkteilnehmer mit MEV-Scannern können um diese gleichen Möglichkeiten konkurrieren, was zu Netzwerkkongestion, steigenden Gasgebühren und höheren Transaktionskosten führt. Dieses Szenario schafft eine negative Externalität für das Netzwerk und seine Benutzer, die alle von den höheren Transaktionskosten betroffen sind, da die Kette weniger effizient und teurer im Betrieb wird. MEV in DeFi ist so häufig, dass Benutzer es fast als unsichtbare Steuer für alle im Netzwerk akzeptiert haben.

Entstehen diese MEV-Möglichkeiten natürlicherweise als Nebenprodukt der hoch ausdrucksstarken Smart Contracts, oder gibt es einen alternativen Weg zum Traum vom voll programmierbaren Geld?

Kurz gesagt, wenn man Protokolle mit hoch ausdrucksstarken Smart Contracts und Layer-2-Token vermeidet, können Benutzer einige dieser Risiken vermeiden, indem sie Protokolle verwenden, die vertrauliche Transaktionen unterstützen, wie Liquid, die Transaktionsdetails verbergen. Aber im Gegensatz zu diesen Plattformen mit ausdrucksstärkeren Skriptsprachen fehlt Bitcoin die Fähigkeit, Dinge zu tun, die man von programmierbarem Geld erwarten würde.

Das Gute: Kompromisse beim programmierbaren Geld

Wenn wir die Entwicklung von Smart Contracts auf Bitcoin in Betracht ziehen, haben wir die Wahl zwischen (1) die Komplexität off-chain zu verschieben, (2) vorsichtig eng oder begrenzt Covenant-Funktionalitäten zu integrieren oder (3) den Weg der vollen Ausdruckskraft zu beschreiten. Lassen Sie uns einige der Vorschläge aus jeder dieser Optionen erkunden.

(1) Eine neue Struktur für Off-Chain-Verträge: ANYPREVOUT

Off-Chain-Lösungen wie das Lightning Network zielen darauf ab, die Skalierbarkeit und Funktionalität von Bitcoin zu verbessern, ohne die Blockchain zu belasten, und die Transaktionen schnell und die Gebühren niedrig zu halten. Das klingt bisher alles gut.

SIGHASH_ANYPREVOUT (APO) ist ein Vorschlag für eine neue Art von öffentlichem Schlüssel, der bestimmte Anpassungen an einer Transaktion auch nach deren Signierung ermöglicht. Es vereinfacht, wie Transaktionen aktualisiert werden, indem es Transaktionen ermöglicht, sich leichter auf vorherige (UTXOs) zu beziehen, was Lightning Network-Kanäle schneller, billiger, sicherer und unkomplizierter macht, insbesondere bei der Streitschlichtung.

Im Hintergrund ist APO ein neuer vorgeschlagener Typ von Sighash-Flag. Jede Bitcoin-Transaktion muss eine Signatur haben, um ihre Legitimität zu beweisen. Beim Erstellen dieser Signatur verwenden Sie ein "Sighash-Flag", um zu bestimmen, welche Teile der Transaktion Sie signieren. Mit APO würde ein Absender alle Ausgaben und keine Eingaben signieren, um die Ausgaben der Transaktion zu verpflichten, aber nicht speziell, von welcher Transaktion die Gelder kommen werden.

APO ermöglicht Eltoo, was es den Benutzern erlaubt, vorab signierte Transaktionen off-chain auszutauschen. Allerdings könnte APO unbeabsichtigt MEV einführen, indem es Transaktionen umsortierbar macht. Sobald Sie eine Signatur zulassen, die den Transaktionsgraphen bindet, haben Sie die Möglichkeit, Transaktionen auszutauschen. Eingaben können ausgetauscht werden, solange die neuen Eingaben noch mit der Signatur kompatibel sind.

(2) Covenants: CAT + CSFS und CTV

Covenants würden den Benutzern erlauben, zu kontrollieren, wohin Coins gehen können, indem sie Geschwindigkeitsbegrenzungen auferlegen oder bestimmte Ziele für Coins in einer Transaktion festlegen. Es gibt zwei verschiedene Kategorien von Covenants: rekursive und nicht-rekursive.

Rekursive Covenants erlauben es Coins, kontinuierlich zu Covenants desselben Typs zurückzukehren.

Nicht-rekursive Covenants beschränken diese Kontrolle auf die nächste Transaktion und erfordern, dass der gesamte zukünftige Pfad der Coins im Voraus definiert wird.

CAT + CSFS ist ein Covenant-Vorschlag, der es Skripten ermöglicht, bestimmte Teile einer zukünftigen Transaktion zu konstruieren oder zu definieren. CHECKSIGFROMSTACK (CSFS) überprüft eine Signatur gegen die Daten, die OP_CAT konstruiert hat. Durch die Verwendung von CSFS, um zu verlangen, dass die Signatur mit einem dynamisch konstruierten Format von OP_CAT übereinstimmt, können wir definieren, wie diese UTXOs in der Zukunft ausgegeben werden können und ein rekursives Covenant erstellen, wenn auch etwas umständlich.

OP_CHECKTEMPLATEVERIFY (CTV) ist eine Möglichkeit, nicht-rekursive Covenants zu erstellen. Anstatt spezifische Teile einer Transaktion zu definieren und zu überprüfen, beschränkt CTV, wie Gelder ausgegeben werden können, ohne die genaue nächste Adresse festzulegen, an die sie gehen müssen. Es definiert eine „Vorlage“, die die nächste Transaktion bestätigen muss.

Ein Risiko bei rekursiven Covenants könnte darin bestehen, ein Szenario zu schaffen, in dem Coins einem Satz von Regeln folgen müssen, der sich wiederholt, ohne eine Möglichkeit, herauszukommen. Ein weiteres Risiko besteht darin, dass, weil Covenants transparent und selbstausführend sind, sie Bitcoin einigen der MEV-Strategien öffnen könnten, die wir auf anderen Ketten sehen.

Was ist die gute Nachricht hier?

Die gute Nachricht ist, dass all diese Vorschläge mehr Expressivität einführen!

Nun, was ist die maximale Menge an Expressivität, die wir bekommen können?

(3) Volle Expressivität: Simplicity

Simplicity ist eine blockchain-basierte Programmiersprache, die sich von anderen Skriptsprachen dadurch unterscheidet, dass sie sehr niedrigstufig ist. Es ist keine Sprache über Bitcoin Script oder ein neuer Opcode, es ist eine Alternative dazu. Theoretisch ist es möglich, alle Covenant-Vorschläge innerhalb von Simplicity zu implementieren und viele der anderen Verträge, die Cypherpunks von programmierbarem Geld erwarten, aber mit weniger der negativen Externalitäten von Ethereum.

What Is the Simplicity Smart Contracting Language?

Simplicity hält sich an das Designprinzip von Bitcoin von selbstenthaltenen Transaktionen, wobei Programme keinen Zugriff auf Informationen außerhalb der Transaktion haben. Entwickelt für maximale Ausdruckskraft und Sicherheit, unterstützt Simplicity formale Verifikation und statische Analyse, was den Benutzern zuverlässigere Smart Contracts bietet.

Hier ist ein Vergleich von Simplicity mit Simfony (Simplicitys Frontend) mit Blick auf: (1) Bitcoin-Covenant-Vorschlägen und (2) Skriptsprachen auf anderen Blockchains:

Die Covenant-Vorschläge auf Bitcoin Script, obwohl viel einfacher als Simplicity, fehlen die Ausdruckskraft, um die Gebührenabschätzung in Script zu handhaben, da Bitcoin keine arithmetischen Funktionen hat. Es gibt keine Möglichkeit zu multiplizieren oder zu dividieren, keine Bedingungscodes oder Stapelmanipulations-Operationen; es ist auch sehr schwierig, eine vernünftige Gebühr abzuschätzen, die mit einem bestimmten Vertrag oder Covenant verbunden sein sollte. Benutzer enden mit Spaghetticode, wobei 80% ihrer Vertragslogik sich darauf konzentrieren, zu bestimmen, wie ihre Gebührensätze sein sollten. Dies macht diese Covenant-Verträge super kompliziert und schwer verständlich.

Das EVM hat Schleifenstrukturen, die die statische Analyse der Gebühren sehr schwierig machen. Mit Script oder Simplicity können Sie einfach jeden Opcode zählen oder die Kosten jeder Funktion rekursiv addieren. Weil Simplicity ein formales Modell hat, können Sie formal über das Programmverhalten nachdenken. Dies können Sie mit Script nicht tun, obwohl Sie eine statische Analyse der Ressourcennutzung durchführen können.

Simplicity würde den Benutzern den höchsten Grad an Expressivität bieten, zusammen mit anderen wertvollen Funktionen wie statischer Analyse und formaler Verifikation. Benutzer werden motiviert, aber nicht eingeschränkt, Smart Contracts zu erstellen, die MEV-resistent sind. Darüber hinaus könnte die Kombination verschiedener Verträge zusammen MEV erzeugen, auch wenn sie es einzeln nicht tun. Dies stellt einen grundlegenden Kompromiss dar.

How Simplicity’s Jets and Combinators Enable CTV and APO

Die Idee, die Funktionalität von Smart Contracts bei Bitcoin weiterzuentwickeln, ist zweifellos vielversprechend und aufregend. Aber es ist wichtig zu erkennen, dass all diese Vorschläge ein gewisses Maß an MEV-Risiko tragen – wenn auch wahrscheinlich nicht in dem Ausmaß, das wir auf anderen Ketten sehen. Wenn wir darüber nachdenken, mehr programmierbares Geld zu Bitcoin zu bringen, gibt es Fragen, die wir uns stellen müssen:

Können wir ein Protokoll ohne MEV-Risiko aufbauen oder ist dies ein unerreichbares Ideal?

  • Angesichts der inhärenten Risiken von MEV in vielen Vorschlägen, welches Maß an MEV-Risiko ist akzeptabel?
  • Und schließlich, was stellt den einfachsten Vorschlag dar, der den größten Grad an Ausdruckskraft bietet?

Jeder Vorschlag hat seine eigenen Vor- und Nachteile. Unabhängig davon, welchen Weg wir einschlagen, sollten wir immer darauf abzielen, die Sicherheit zu priorisieren und das Prinzip der Dezentralisierung aufrechtzuerhalten.

Für detaillierte Updates und weitere Informationen, verfolgen Sie den Blockstream Research 𝕏-Feed.

Hinweis: Dieser Artikel wurde ursprünglich in Bitcoin Magazine veröffentlicht und kann hier gelesen werden.

If you have specific preferences, please, mark the topic(s) you would like to read: