Ein Leitfaden für Anfänger zur Ethereum-Zensur

Liebe bankenlose Nation,

Die Regulierungsbehörden sind hinter der Kryptowährung her.

Aber DeFi ist in Ordnung, weil es dezentralisiert ist, richtig?

Ähm... nein. Leider gibt es immer noch zu viele zentralisierte Vektoren.

Und wenn die Aufsichtsbehörden zuschlagen, werden sie genau darauf abzielen.

Wenn wir ein Ethereum wollen, das funktioniert, müssen wir zuerst die Schwächen von DeFi verstehen.

Wir haben letzten Monat einen Podcast mit Justin Drake gemacht, in dem wir dies ausführlich beschrieben haben. (📺 S chauen Sie ihn sich hier an!)

Der heutige Newsletter ist eine Zusammenfassung dieses Podcasts zu einem 101 Leitfaden zum Verständnis der Zensurdynamik in Ethereum.

Donovan fasst alle zentralisierten Chokepoints zusammen und zeigt dann, wie Ethereum den Weg in eine zensurresistente Zukunft ebnet.

Zeit, mit dem Aufbau zu beginnen.

- Bankloses Team

Am 8. August 2022 hat das US-Finanzministerium Tornado Cash sanktioniert.

Jeder weiß, dass Aufsichtsbehörden Kryptowährungen hassen, aber die Sanktionen haben DeFi überrascht. Es handelte sich um einen noch nie dagewesenen Versuch amerikanischer Regulierungsbehörden, Krypto offiziell anzugreifen.

In gewisser Weise waren die Sanktionen gegen Tornado Cash ein Segen in der Verkleidung. Der behördliche Schock erinnerte DeFi an seine Grundprinzipien und eröffnete die Überprüfung jedes zentralisierten Engpasses in der dezentralisierten Finanzlandschaft.

Überraschung, Überraschung: Dezentralisierung ist tatsächlich wichtig.

Jede zentralisierte Abkürzung, die Sie nehmen, kann und wird gegen Sie verwendet werden.

Das Thema Zensur ist schwer zu verfolgen. Der Versuch, die Bedenken im Zusammenhang mit der Ethereum-Zentralisierung zu verstehen, erfordert einige technische Kenntnisse, und das Meer des Krypto-Jargons ist unmöglich zu durchwaten.

Dieser Artikel ist ein Versuch, alle Zensur-Bedenken zu Ethereum der letzten Monate zu entmystifizieren und sie in leicht verständliche Begriffe für jeden Krypto-Bürger (oder sogar Hasser!) zu destillieren.

Ich lege alle wichtigen Zentralisierungsvektoren des Ethereum-Protokolls dar und gehe kurz auf die verschiedenen Markt- und technischen Lösungen ein, an denen Unternehmer und Entwickler arbeiten.

⛓️ Eine kurze Zusammenfassung der Ethereum-Lieferkette

Ethereum, wie es ursprünglich konzipiert war, umfasste theoretisch nur zwei Akteure: einen Nutzer, der seinen eigenen Knotenpunkt betreibt, der Transaktionen über das Peer-to-Peer-Netzwerk an Block-Validatoren sendet, die einen Block erstellen und die Transaktion aufnehmen.

Blockchain-Validatoren (wir nennen sie Miner in PoW, Staker in PoS) sollten neutrale Teilnehmer sein, die Blöcke validieren.

In der Praxis ist dieser Prozess jedoch viel komplexer. Validierer haben einen perversen Anreiz, Blöcke an Suchende zu verkaufen, die Arbitrage-Bots einsetzen. Dies führt zu höheren Transaktionskosten und einer Überlastung der Blockchain für durchschnittliche Nutzer - ein Phänomen, das als maximal extrahierbarer Wert (MEV) bekannt ist. Der MEV hat sich in den letzten zwei Jahren auf Ethereum auf 675 Millionen Dollar belaufen(geschätzte 6,7 Millionen Dollar auf Cosmos).

Bei Ethereum nach dem Merge ist die allgemeine Transaktionsreihenfolge wie folgt:

⚠️ Beachten Sie, dass die Begriffe Validierer und Antragsteller in diesem Artikel synonym verwendet werden.

Zentralisierungsvektoren gibt es bei jedem Schritt in dieser Transaktionsreihenfolge.

Betrachten wir sie der Reihe nach, beginnend mit dem Frontend.

💁‍♂️ 1. Frontend-Schnittstellen

Sie wollen etwas ETH kaufen. Sie gehen zu uniswap.com, wo Sie eine hübsch gestaltete, schlichte, rosa-weiße Benutzeroberfläche erwartet, die Ihnen die Navigation durch Ihren Handel erleichtert. Sie verbinden MetaMask, wählen Ihren Liquiditätspool und klicken auf "Senden", um Ihren Handel auszuführen. Wir halten diesen einfachen Prozess für selbstverständlich, aber es gibt bereits viele Zentralisierungsbedrohungen, die auf diesen Intermediären auftauchen.

⚠️🛑 Die Bedrohung durch Zensur

Die Realität der Frontend-Schnittstellen vieler Dapps ist heute, dass sie zentralisiert sind. Die kurze Geschichte von Web3 hat gezeigt, dass DeFi die Tür öffnet, wenn Regulierungsbehörden anklopfen. Dies geschah, als Balancer einen 20-Millionen-Dollar-Liquiditätspool in seinem Frontend versteckte, oder als Uniswap Labs schnell Dutzende von synthetischen Derivat-Token in seinem Frontend auslistete, um eine Prüfung durch die SEC zu vermeiden. MetaMask und Infura haben dasselbe getan, um Wallet-Adressen im Einklang mit den Tornado Cash-Sanktionen zu blockieren.

Das Frontend zu umgehen, ist nur die Spitze des Eisbergs. Die von uns verwendeten Dapps sind auf RPC-Knoten (Server) angewiesen, um die Absichten der Benutzer zu kommunizieren. Nodes sind ein Verbindungspunkt - man kann sie sich als API vorstellen - der auf Informationen zugreift, kommuniziert und Transaktionen auf der Blockchain ausführt.

In einer idealen Welt würde jeder seine eigenen Nodes betreiben. Aber wie Signal-Gründer Moxie Marlinspike einmal in einer Kritik an Web3 ansprach, betreiben die meisten Leute keine eigenen Nodes, was eine Abhängigkeit von zentralisierten Node-Service-Providern wie Infura und Alchemy schafft. Sie haben das Leben in DeFi sehr viel einfacher gemacht, aber wie Sie wissen, gibt es Kompromisse. Da eine Vielzahl von Dapps wie Uniswap und Metamask wiederum auf Infura angewiesen sind, um Nodes zu betreiben, hat sich auf dieser Seite ein bedeutender Zentralisierungsvektor herausgebildet.

Ein zentralisiertes Unternehmen wie Infura würde, wenn es ins Visier der Regulierungsbehörden geriete, große Störungen bei Ethereum verursachen. Dies geschah, als Infura im März iranische IP-Adressen sperrte, um den politischen Sanktionen der USA nachzukommen. Es gibt auch technische Gründe, warum zentralisierte Knotenanbieter problematisch sind. Ethereum erlebte einen solchen Netzwerkausfall im November 2020, als viele Dapps unbrauchbar wurden, nachdem die Mainnet-API von Infura ausfiel, weil ihr Geth-Client nicht auf dem neuesten Stand war.

Schließlich müssen die Nodes irgendwo gehostet werden. In der Realität werden viele Ethereum-Knoten bei zentralisierten Cloud-Anbietern wie AWS, Hetzner und Google Cloud gehostet (wie auch bei Solana und Bitcoin). Der Zentralisierungsvektor ist hier offensichtlich: Cloud-Anbieter können den Serverbetrieb willkürlich einstellen. Die Community wurde im August genau daran erinnert, als Hetzner klarstellte, dass der Betrieb von Ethereum-Knoten auf seinen Servern einen Verstoß gegen seine Nutzungsbedingungen darstellt.

So viele Zentralisierungsvektoren, und wir sind noch nicht einmal beim Mempool angelangt.

Was tun?

💡 Lösung #1

Die Frontend-Zentralisierung ist ein Problem, aber ein relativ kleines. Dies ist dem aufkeimenden DeFi-Middleware-Ökosystem zu verdanken, das es uns ermöglicht, zensierte Frontends auf verschiedene Weise durch alternative Orte zu umgehen. Beispiele sind Portfolio-Tracker wie Zapper und Zerion, Krypto-Wallets mit integrierten "Swapping"-Funktionen, DeFi-Aggregatoren wie 1inch und Paraswap. Sie ermöglichen Ihnen den Zugang zu Dapps, ohne dass Sie diese direkt besuchen müssen. Die meisten Dapps wie Uniswap haben sich außerdem dazu verpflichtet, den Code ihrer Frontends offenzulegen, so dass jeder Einzelne oder sogar eine spezialisierte DAO das Frontend nachbauen kann.

Um zensierte Frontends zu umgehen, werden auch dezentrale Speicheranbieter wie IPFS verwendet, um Frontend-Domains mit statischen Inhalten zu hosten. Für Frontends mit dynamischen Inhalten (soziale Medien) werden dezentralisierte Indizierungsprotokolle wie The Graph verwendet, um Daten über Blockchains und Dapps hinweg durch eine einheitliche Abfragesprache abzufragen. Und bei zensierten Domains bieten dezentrale Domain-Services wie ENS eine zensurresistente Möglichkeit, Domains zu hosten, indem sie auf Ethereum-Smart Contracts aufbauen. Dies steht im Gegensatz zu den meisten heutigen Websites, die auf zentralisierten DNS-Servern gespeichert sind und daher der Beschlagnahmung von Domainnamen oder der Sperrung von IP-Adressen unterliegen.

Zusammengenommen bilden diese dezentralen Infrastrukturprotokolle die grundlegenden Bausteine einer dezentralen Web3-Wirtschaft für DeFi-Frontends.

💡 Lösung #2

Die wichtigste technische Lösung für das Problem der Zentralisierung von Knotenpunkten sind Light Clients. Der Ethereum Altair Hard Fork hat den Weg dafür geebnet. Diese ultraleichten Clients ermöglichen es uns, unsere eigene souveräne, native Version von Ethereum auf unseren eigenen Computern, Mobilgeräten oder Webbrowsern zu erstellen, an die wir Transaktionen senden und Anfragen an jeden Full Node stellen können, der Light Client-Anfragen akzeptiert. Auf diese Weise können Dapps Transaktionen erleichtern, anstatt einen zentralisierten RPC-Endpunkt wie Infura oder Alchemy aufzurufen.

Light-Clients versuchen nicht, die gesamte Beacon-Kette oder das Validator-Set abzurufen. Das wäre sehr rechenintensiv - daher auch der Name "Light"! Sie synchronisieren einfach die Block-Header, indem sie die Peer-Knoten kennen. Der Schlüssel ist, dass dieser Prozess vertrauensvoll durch zufällig zugewiesene Gruppen von Validatoren (Sync Committees) durchgeführt wird. Beacon-Chain-PoS-Light-Clients sind auch wesentlich einfacher zu bauen als PoW-Light-Clients. Mit nur wenigen nicht-zensierenden Vollknoten, die diese Anfragen beantworten, werden Probleme der Knotenzentralisierung entschärft. Weitere Informationen zu Light-Clients finden Sie hier.

💡 Lösung #3

Sofern wir uns auf externe Knotenanbieter verlassen wollen, gibt es dezentrale Alternativen wie Pocket Network oder Ankr, die den Bedarf an Infura minimieren.

Erinnern wir uns daran, dass das Problem hier der fehlende Anreiz für die Menschen ist, ihre eigenen Nodes zu betreiben. Diese RPC-Knotenanbieter schaffen wirtschaftliche Anreize dafür. Bei Pocket Network zum Beispiel setzen Knotenanbieter POKT ein, um Blockchain-Knoten zu betreiben und Daten zwischen verschiedenen Blockchains weiterzuleiten und Dapps zu bedienen, die On-Chain-Daten anfordern. In diesem erlaubnisfreien Markt verdienen sie umso mehr POKT, je mehr Relays sie bedienen. Auf der Nachfrageseite setzen Nutzer/Apps ebenfalls POKT ein und können damit Relays im Netzwerk anfordern. Es ist zu beachten, dass es in diesen Projekten selbst Zentralisierungspunkte gibt, aber es gibt eine Roadmap, um diese zu beseitigen.

💡 Lösung #4

Das Knoten-Hosting-Problem ist ein Zentralisierungsrisiko, das ständig überwacht werden muss, aber aufgrund der niedrigen Ausstiegsbarrieren keine große Bedrohung darstellt. Wenn AWS beschließt, das Knoten-Hosting auf seinen Cloud-Servern einzuschränken, können die Knotenbetreiber problemlos auf einen anderen Cloud-Server umziehen, ohne irgendwo eingesperrt zu sein. Dank der Merge ist die Einrichtung eines eigenen Knotens mit DIY-Hardware (Raspberry Pi) und Plug & Play-Lösungen (Avado) heute noch einfacher.

📡 2. Suchende

Nachdem Benutzertransaktionen erfolgreich eingereicht wurden, gelangen sie in den mempool, kurz für "memory pool". Der Mempool ist eine Datenbank mit ausstehenden Transaktionen, die von Nutzern wie dir und mir eingereicht wurden, manchmal auch als Ethereums "dunkler Wald 🌳" bezeichnet. Hier beginnen die MEV-Spiele.

Sobald sich Transaktionen im Mempool befinden, beginnen die Suchenden, den Dark Forest nach profitablen MEV-Möglichkeiten zu durchsuchen. Bei den Suchenden handelt es sich in der Regel um große Institutionen und Eigenhandelsabteilungen, die Arbitrage-Bots einsetzen, manchmal aber auch um Einzelpersonen. Sie zahlen hohe Gasgebühren, damit die Validierer ihre Transaktionsaufträge annehmen, anstatt sie über den öffentlichen Pool abzuwickeln.

An dieser Stelle sei darauf hingewiesen, dass MEV zwar in der Regel als etwas ausschließlich Schlechtes dargestellt wird, es aber auch gute MEV gibt. Ein DeFi-Protokoll, das die Sicherheiten eines Kreditgebers inmitten volatiler Krypto-Preisschwankungen schnell liquidieren muss, möchte eine hohe Gasgebühr zahlen, um sicherzustellen, dass seine Transaktion schnell ausgeführt wird. Würden Blockchains nach dem Prinzip "Wer zuerst kommt, mahlt zuerst" konzipiert, gäbe es bei DeFi außerordentliche Ineffizienzen. Die Suchenden spielen eine wichtige Rolle, um solche Ineffizienzen auszugleichen und effiziente Blöcke zu erstellen.

Auf der schlechten MEV-Seite sind die Suchenden zwar nicht per se ein Zentralisierungsrisiko, aber sie spielen eine Rolle bei der Ermöglichung eines riesigen Zentralisierungsvektors , indem sie sich mit den Blockbauern absprechen. Ihre Rolle in der Protokollschicht besteht darin, Transaktionen zu bündeln und sie an die Blockersteller auf der nächsten Stufe des Dark Forest weiterzuleiten.

🏗️ 3. Blockersteller und Validierer/Proposer

Vor der Proposer-Builder-Trennung (PBS)

In Ethereum vor dem Merge wurde die Blockbildung von einer einzigen Einheit durchgeführt: den Minern. Dies gab den Minern die Möglichkeit, aus DEX-Arbitrage und Liquidationen Kapital zu schlagen, indem sie zwischen Transaktionen im Mempool unterscheiden konnten.

Mit der Zeit wurde das Problem immer schlimmer. Suchende und Schürfer begannen, sich in einem Untergrundmarkt abzusprechen, um die Transaktionen so effizient wie möglich auszuwählen und ihre eigenen MEV-Gewinne zu maximieren. Dies führte schließlich dazu, dass die Fixkosten eines Miners in die Höhe getrieben wurden, da große Mining-Pool-Betreiber, die über das nötige Kapital verfügen, um komplexe Algorithmen zu betreiben, den kleinen Miner übertrafen - so entstand das, was wir als MEV kennen. Der gesamte MEV, der in den letzten zwei Jahren aus Ethereum gewonnen wurde, belief sich auf ~675 Millionen Dollar!

Die Probleme des Zentralisierungsrisikos sind hier zweifach: Erstens schadet es den Ethereum-Nutzern, die am Ende länger warten oder mehr für ihre Transaktionen bezahlen müssen; zweitens sind gut kapitalisierte Block-Validierer aufgrund des politischen Drucks in einer viel besseren Position, um zu zensieren.

Als Antwort darauf entwickeln die Ethereum-Entwickler eine protokollinterne Lösung, die als Proposer-Builder-Separation (PBS) bekannt ist. Wie der Name schon sagt, teilt PBS die Rolle des Validierers in zwei separate Rollen auf:

1. Proposer (d. h. Validierer, die 32 ETH einsetzen und Blöcke bauen)
2. Block-Builder

Unter PBS konkurrieren die Block-Builder miteinander, um aggregierte, geordnete Listen von Transaktionen von Suchenden zu erstellen. Diese Transaktionsbündel werden so optimiert, dass sie die MEV-Gebühren des Blockbauers maximieren, die dann an den Blockproposer weitergegeben werden. Für die Anbieter besteht ein Anreiz, die Transaktionen mit den höchsten Gebühren für sich selbst auszuwählen, um Blöcke zu erstellen und sie an das Netzwerk zu senden, damit sie in die Kette aufgenommen werden.

Der Sinn von PBS ist es, die zentralisierte Macht der Blockproposer vor Zensur zu schützen, da derjenige, der den Block erstellt, nicht die gleiche Person ist, die die Transaktionen auswählt, die in den Block aufgenommen werden sollen. Wie Vitalik in Endgame beschreibt, zielt PBS darauf ab, die Dezentralisierung der Validierer zu maximieren.

Aber PBS ist technisch komplex und wird erst in einigen Jahren fertig sein (vielleicht in 2-8 Jahren!). Die gute Nachricht ist, dass in der Zwischenzeit Zwischenlösungen für die Zentralisierung der Prüfer gefunden wurden.

Zum einen werden die Validierer im Rahmen der Zusammenführung nach dem Zufallsprinzip ausgewählt, um in jedem Slot als Blockproposer aufzutreten. Dies ist anders als bei PoW vor dem Merge, wo alle Miner beim Lösen von mathematischen Rätseln konkurrieren, um neue Transaktionen zu validieren. Nachdem einer der ~420K Validierer auf Ethereum zufällig als Block Proposer ausgewählt wurde, wird ein weiteres Komitee von Validierern zufällig ausgewählt, um eine Bestätigung (Abstimmung) über die Gültigkeit des vorgeschlagenen Blocks abzugeben. Diese doppelte Schicht von Zufallsauswahlen dient dazu, die Zentralisierung der Validatoren auf Ethereum zu begrenzen, wodurch es für Angreifer schwieriger wird, das Netzwerk zu zensieren oder zu stören.

Zweitens sind Unternehmen wie Flashbots 🤖 eingesprungen, um PBS künstlich zu erzeugen. Flashbots hat einen Software-Client entwickelt(MEV-Geth für PoW-Ethereum, MEV-Boost für PoS-Ethereum), den Validierer einfach in ihren Konsens-Client einbauen und auf ihren Nodes ausführen können. Damit wird die Aufgabe der Blockbildung an eine spezialisierte Builder-Rolle ausgelagert(Trennung von Proposer und Builder!).

Warum Flashbots verwenden? Validatoren tun dies, weil es für sie profitabler ist, Belohnungen zu setzen. Die Software von Flashbots verteilt den MEV-Wert gleichmäßiger zwischen Proposern und Buildern, anstatt ihn zwischen großen Mining-Pools und Suchern aufzuteilen. Flashbots verhindert diese Insider-Kollusion zwischen Suchenden und Schürfern, indem es einen transparenten, offenen Markt für die Preisfindung schafft. Hasu zufolge hat der Einsatz von MEV-Boost die Post-Merge-Belohnungen für Validierer um 135 % erhöht.

Beachten Sie, dass MEV-Boost optional ist und dass Validierer weiterhin selbst Blöcke auf ihren Ausführungsclients erstellen können.

In der PBS-Ära

PBS beseitigt die Zentralisierungskraft von großen Validierern. Aber auch nach der Entwicklung von PBS sind wir noch nicht im gelobten Land der Dezentralisierung angekommen. Zentralisierungsvektoren werden auch in einer Post-PBS-Welt noch existieren, wenn auch in abgeschwächter Form. Der Rest dieses Abschnitts beschreibt kurz die verschiedenen Zensurbedrohungen, mit denen Ethereum konfrontiert ist, und die entsprechenden Lösungen, die in Arbeit sind.

⚠️🛑 Zensurbedrohung Nr. 1

Während PBS frühere Zentralisierungsprobleme entschärft, führt es auch neue Zentralisierungsvektoren auf der Ebene der Builder ein, indem es ihnen die Möglichkeit gibt, Transaktionen zu zensieren. Durch die Schaffung einer spezialisierten Builder-Rolle können Builder in der Lage sein, zu hohe Gebote für Blöcke abzugeben und bestimmte Transaktionen auszuschließen.

💡 Lösung 1

Die erste Lösung ist eine Zensur-Widerstandsliste (crList) oder das, was auch als "hybrides PBS" bezeichnet wird. Angenommen, wir vermuten, dass Bauherren versuchen, Transaktionen zu zensieren. Wir wissen das, weil die Blöcke, die sie für die Antragsteller gebaut haben, nicht voll sind, und es gibt zulässige Transaktionen, die im Mempool darauf warten, aufgenommen zu werden.

Mit einer crList können die Antragsteller die Bauunternehmen zwingen, den leeren Blockspace voll auszunutzen, ohne dass die Antragsteller die Reihenfolge der einzubeziehenden Transaktionen vorschreiben können: "Hey Bauherren, bitte füllt euren leeren Block auf oder meine ausgewählten Transaktionen werden aufgenommen."

Ein Builder, der darauf besteht, Transaktionen zu zensieren und die crList eines Proposers zu ignorieren, wird mit einer Ablehnung des Blocks durch die Attestoren konfrontiert(Attestoren sind zufällig ausgewählte Validatoren, die über den Kopf der kanonischen Kette abstimmen, nachdem die vorschlagenden Validatoren einen Block vorgeschlagen haben). Kurz gesagt, crLists ist ein indirekter Mechanismus, der es Vorschlägern ermöglicht, einen zentralisierten Blockbildungsmarkt in Schach zu halten, ohne den eigentlichen Zweck von PBS zu vereiteln(Dezentralisierung der Vorschläger!).

💡 Lösung #2

Aber wenn die Anbieter den Bauunternehmen vorschreiben können, Transaktionen einzubeziehen, was ist dann, wenn sie sich mit den Bauunternehmen absprechen und ihnen vorschreiben, dies nicht zu tun? Dies führt uns zu der zweiten Lösung, die in Arbeit ist: MEV-Glättung. Genauso wie crLists die Bauherren in Schach hält, hält die MEV-Glättung die Antragsteller in Schach, indem sie ihnen ihren Ermessensspielraum nimmt.

Die Idee dabei ist, die Bescheiniger aufzufordern, den Markt für die Erstellung von Blöcken zu beobachten, insbesondere die mit den Blöcken verbundenen Gebührengebote, und dann nur die Blöcke mit den höchsten Geboten der Antragsteller zu bescheinigen. Wenn Antragsteller nicht die profitabelsten Blöcke vorschlagen, die bereits für sie gebaut wurden, ist irgendetwas nicht in Ordnung, also fragen die Bescheiniger: "Hey Antragsteller, hasst du es einfach, Geld zu verdienen, oder versuchst du zu zensieren?"

Die MEV-Glättung zielt darauf ab, die MEV-Gewinne für alle Antragsteller auszugleichen und einen vollkommen effizienten Markt zu schaffen, der den Antragstellern den Anreiz nimmt, eine diskriminierende Zensur auszuüben.

💡 Lösung #3

Die dritte Lösung ist die Verwendung von verschlüsselten Mempools. Während crLists gegen Builder und MEV-Smoothing gegen Proposers wirken, sind verschlüsselte Mempools so konzipiert, dass sie beiden entgegenwirken. Dieser Mechanismus ist einfach zu verstehen: Er verschlüsselt den Inhalt der Transaktionen eines Benutzers und die Sende-/Empfangsadressen, bevor er in den Mempool gelangt, und wird erst entschlüsselt, wenn er auf der Kette ist. Dies macht es für Akteure schwierig, zu zensieren oder MEV-Extraktionstechniken wie Transaktions-Frontrunning anzuwenden. Damit entfällt die Notwendigkeit für private Mempools wie Flashbots Protect. Die verschlüsselte Mempool-Technologie ist etwas, mit dem die Cosmos-Entwickler, Flashbots und datenschutzorientierte Ketten wie Aztec ebenfalls experimentieren.

💡 Lösung #4

Die vierte und letzte Lösung ist diejenige, auf die wir uns am wenigsten verlassen wollen, die aber ein Nice-to-have ist: altruistisches Self-Building, bei dem die Antragsteller sich einfach entscheiden, ihre eigenen Blöcke zu bauen, anstatt sie an einen Builder auszulagern. Der Vorteil dabei ist, dass Ethereum auch mit einer kleinen Minderheit von ~10% altruistischer Bauherren weiterlaufen kann.

Der offensichtliche Nachteil ist, dass dies den wirtschaftlichen Anreizen zuwiderläuft - erinnern Sie sich daran, dass die Validierer MEV-Boost verwenden wollen, weil es mehr Gebühren generiert. Aus diesem Grund ist die Förderung einer Kultur des Widerstands gegen Zensur und die Erhaltung der Dezentralisierung auf der sozialen Ebene sehr wichtig.

⚠️🛑 Zensurbedrohung #2

Um heute als Ethereum-Validator teilzunehmen, muss man 32 ETH in einen Deposit-Vertrag investieren und zwei Software-Clients betreiben: einen Execution-Client(zur Ausführung von Transaktionen) und einen Consensus-Client(zur Erzielung eines Konsenses über neu erzeugte Blöcke). Die Gefahr besteht heute darin, dass zu viele Validatoren denselben Ausführungsclient Geth verwenden.

Dies erhöht das Risiko eines Netzwerkausfalls, wenn ein Client mit einem Fehler gefunden oder angegriffen wird. Dies ist keine theoretische Spekulation, wie der Shanghai-DOS-Angriff von 2016 gezeigt hat, bei dem Angreifer den Geth-Client dazu brachten, die Verarbeitung zu verlangsamen. Bei Ethereum nach dem Merge ist eine Mehrheit von ⅔ der eingesetzten ETH erforderlich, damit eine Transaktion abgeschlossen werden kann. Wenn ein dominanter Client ausfällt, könnte das Ethereum-Netzwerk vorübergehend zum Stillstand kommen (oder schlimmer noch: gespalten werden) - daher ist es von entscheidender Bedeutung, dass ein bestimmter Client auf nicht mehr als ⅔ der Validator-Knoten läuft!

Das Problem der Client-Konzentration ist so akut, dass selbst die führenden Unternehmen mit der höchsten Client-Nutzung wie Prysmatic Labs den Knoten-Validierern empfehlen, "ihre Konkurrenten zu nutzen". Denn wenn Ethereum untergeht, ist das ein Verlust für alle.

💡 Die Lösung

Beachten Sie, dass die Zensurdrohungen hier nicht nur für Solo-Staker gelten, sondern auch für zentralisierte Knotenanbieter wie Infura und Alchemy oder dezentrale Knotenanbieter wie Pocket Network. Zu den Lösungen, die Ethereum-Entwickler implementiert haben, gehören verschiedene Bestrafungen, um den Einsatz inaktiver Validierer zu verringern, wie der Inactivity Leak Mechanism. In der heutigen Beacon-Kette gibt es auch Anti-Korrelations-Strafen, die fehlbare Validierer härter bestrafen , wenn sie alle auf demselben Client versagen. Dadurch wird eine Multi-Client-Kultur gefördert und gleichzeitig werden die Validierer dazu angehalten, bei der Wahl eines Clients nicht nur die technischen Risiken, sondern auch wirtschaftliche Anreize zu berücksichtigen.

⚠️🛑 Zensurbedrohung #3

Schließlich wäre es nachlässig, eine weitere, oft erwähnte Zensurbedrohung auf der Ebene der Validierer nicht zu erwähnen: die Konzentration von ETH in Staking-Diensten. Die beiden größten Anteile gehören den Liquid Staking-Protokollen, die ~37% aller eingesetzten ETH kontrollieren, und ~31% von CEXs. Dies stellt ein ernsthaftes Problem dar, da jedes Unternehmen, das mehr als 33 % aller ETH besitzt, Angriffe mit doppelten Ausgaben durchführen kann.

💡 Die Lösung

Hier gibt es keine einfachen Lösungen, aber es gibt Gründe, optimistisch zu sein. Zum einen kontrolliert Lido zwar unverhältnismäßig hohe 30 % der eingesetzten ETH, existiert aber nicht als eine einzige Einheit und hat keinen direkten Einfluss auf die Blockbildung. Lidos ETH-Kriegskasse wird an 28 Knotenbetreiber weitergegeben, die sie über Zehntausende von Knoten einsetzen, wodurch jede Art von einseitigem Netzwerkangriff verhindert wird.

Dezentralisierungs-Maxis werden sich mit 28 Knotenbetreibern nicht sehr wohl fühlen, was immer noch viel zu wenig ist, wenn man bedenkt, was auf dem Spiel steht(das Ethereum-Netzwerk!). Eine technische Lösung, die die ETH-Konzentration angehen könnte, ist die Distributed Validator Technology (DVT), auch bekannt als Secret Shared Validator Technology, ein Bereich, den die Ethereum Foundation seit 2019 aktiv erforscht. Das Unternehmen, das die Entwicklung von DVT anführt, ist RockX, ein institutioneller Blockchain-Knotenanbieter und einer der 28 Knotenbetreiber von Lido.

DVT ist ein Open-Source-Protokoll, das die operativen Aktivitäten von Knotenoperationen zwischen verschiedenen Validierern dezentralisiert, anstatt von einem einzigen. Es nutzt Multi-Party-Computational-Prozesse (MPC), um sicherzustellen, dass Knoten von mehreren Validierern gemeinsam betrieben werden können, da private Schlüssel "geteilt" werden. Daher hat kein einzelner Akteur vollen Zugriff auf den privaten Schlüssel, der zum Signieren von Nachrichten benötigt wird. Dies ermöglicht es den Validierern auch, im Falle einer Störung der Infrastruktur für einen anderen Validierer einzuspringen.

Während liquide Staking-Protokolle, die zu viel ETH halten, äußerst besorgniserregend sind, lohnt es sich, eine kontrafaktische Welt zu betrachten, in der die Lido DAO nicht existiert. In dieser Welt würde ETH bei politisch noch anfälligeren Einrichtungen wie Coinbase und Kraken eingesetzt, die bereits eine große Menge an ETH halten - eine Situation, die weit schlimmer wäre als der Status quo.

🔌 4. Relayers

Relayer fungieren im MEV-Boost-Modell als zwischengeschaltete "Broker", die zwischen Antragstellern und Buildern sitzen und von jedermann leicht gegründet werden können. Relayers sind ein einzigartiger Zentralisierungsvektor, der aus dem Versuch der Flashbots, MEV zu lösen, entstanden ist. Um die Bedrohung durch die Zensur zu verstehen, muss man zuerst verstehen, warum Relayers überhaupt im Spiel sind.

Erinnern wir uns daran, dass der Grund für die Aufteilung der Validator-Rolle in einen Proposer und einen Builder unter PBS darin bestand, die Zensurbefugnisse der Validatoren einzuschränken und ein Szenario zu verhindern, in dem eine Entität(z.B. Coinbase oder Lido), die eine riesige Menge an eingesetzter ETH besitzt, willkürlich entscheiden könnte, was auf die Kette kommt.

Damit PBS funktioniert, müssen die Antragsteller über den Inhalt der Blöcke, die sie von den Buildern erhalten, im Unklaren sein. Andernfalls wären die Antragsteller in der Lage, zwischen Blöcken zu unterscheiden, die ihrer Meinung nach auf der Kette sein sollten, und wir stünden wieder am Anfang vor PBS.

An dieser Stelle kommen die Relayers im Rahmen des MEV-Boost-Modells der Flashbots ins Spiel. Der Relayer sendet den Block an ein verstecktes Treuhandkonto und gibt nur den Preis an jeden Anbieter weiter, der Payloads von diesem Relay akzeptiert.

Erst nachdem sich ein Antragsteller verpflichtet hat, einen Blockkopf zu unterzeichnen und das Gebot zu akzeptieren, wird der Blockinhalt offengelegt. Auf diese Weise hat ein Anbieter, der Tornado Cash-Transaktionen zensieren möchte, keine andere Wahl, als den Block weiterhin auf der Kette anzubieten, da er bereits dafür bezahlt hat, oder er wird zerschlagen, wenn er versucht, zwei Blöcke gleichzeitig anzubieten.

⚠️🛑 Die Bedrohung durch die Zensur

Was aber, wenn der Vermittler selbst zensieren will? Das führt uns zum Kern des Zentralisierungsrisikos auf der Ebene der Vermittlungsstellen. Heute zensieren 58% aller weitergegebenen Blöcke auf Ethereum Tornado Cash-Transaktionen, d.h. sie sind OFAC-konform. Der Großteil - 80% - dieser 58% kommt von Flashbots' Relay (siehe Bild unten).

Beachten Sie, dass es viele andere Validatoren gibt, die immer noch Blöcke mit Tornado Cash-Transaktionen akzeptieren, so dass es sich hier eher um eine "weiche" Zensur handelt, die sich in einer Verzögerung von ein paar Minuten äußert, als um eine "harte" Form der Zensur. Solange die Relayers eine nicht-zensierende Minderheit haben, wird dieses Problem eher eine Unannehmlichkeit für die Nutzer bleiben, als dass wir es traditionell als "Zensur" bezeichnen würden. Nichtsdestotrotz ist dies ein Problem, das in den letzten Monaten zu einer weit verbreiteten Besorgnis über die Zensur von Ethereum geführt hat(siehe hier für mehr).

💡 Die Lösung

Die offensichtliche Lösung besteht darin, eine größere Vielfalt an Relayern zu fördern. Validierer sind in der Regel mit mehreren Relayern gleichzeitig verbunden. Wie oben zu sehen ist, gibt es drei von sieben Relays(BloXroute und Manifold), die Tornado Cash-Transaktionen nicht zensieren. Da Relays eine erlaubnisfreie Einheit sind, ist es für jeden einfach, ein eigenes zu gründen(Flashbots selbst hat sein eigenes Relay in gutem Glauben als Open Source zur Verfügung gestellt). Die Einstiegshürden für die Gründung eines nicht-zensierenden Relays sind niedrig, was bedeutet, dass dieser Zentralisierungsvektor viel weniger schwerwiegend ist als , wenn er sich auf der Validator-Ebene befände, wo es viel kostspieliger wäre, unehrliche/unangemessene Akteure abzuschrecken.

Die gute Nachricht ist, dass Relayers auf lange Sicht ein temporärer Zensurvektor sind. Wenn PBS formell im Protokoll verankert ist, werden Relayers nicht mehr benötigt, da die Bauherren eine Verbindung zu den Antragstellern herstellen werden.

🦇🔊 Abschließend...

Da haben Sie es also. Die gesamte MEV-Lieferkette und was wir dagegen tun. Fügen Sie in den Kommentaren gerne hinzu, was ich übersehen habe.

Beachten Sie, dass dieser Artikel nur weiche Formen der Zensur behandelt, die in der Regel auf eine Verzögerung der Blockeinbindung in Sekunden/Minuten hinauslaufen.

Der Artikel erhebt keinen Anspruch auf Vollständigkeit - ich habe viele weitere Middleware-Protokolle wie Orakel, Sidechains und Roll-ups ausgelassen, die ihre eigenen Zentralisierungsvektoren enthalten. Harte Formen der Zensur wie 51%-Angriffe und die technischen und sozialen Lösungen dafür wurden ebenfalls ausgelassen.

Handlungsschritte

• 📖 Lesen Sie Davids The Ethereum Watershed darüber, wie sich MEV auf Ethereum auswirkt
• 📖 Lesen Sie Jon Charbonneaus Artikel darüber, was man gegen Zensur in Ethereum tun kann
• 📺Schauen Sie sich den Podcast mit Justin Drake zum Thema Ethereum-Zensuran