EIP-8105: Ethereums neues verschlüsseltes Mempool-Design

EIP-8105 — der Universal Enshrined Encrypted Mempool — ist Ethereums bislang ehrgeizigster Versuch, ein Problem zu lösen, das gewöhnlichen Nutzern Hunderte Millionen gekostet hat: MEV-Bots, die Transaktionen lesen, bevor sie in einem Block landen. Der Vorschlag führt einen flexiblen, schema-agnostischen verschlüsselten Mempool ein, der Transaktionsdaten bis nach der Aufnahme verbirgt, und beeinflusst nach wie vor leise, wie Ethereum-Entwickler über den Upgrade-Pfad für 2027 nachdenken.

Das $60-Millionen-Problem, das EIP-8105 lösen will

Sandwich-Angriffe kosten Ethereum-Nutzer schätzungsweise $60 Millionen pro Jahr, wie aus den von EigenPhi on-chain erfassten MEV-Sandwich-Angriffen hervorgeht. Die Mechanik ist einfach und brutal: MEV-Bots überwachen den öffentlichen Mempool, erkennen einen ausstehenden Swap oder Trade, platzieren ihre eigene Transaktion davor und danach und kassieren die Differenz. Das Opfer zahlt einen schlechteren Preis. Der Bot verdient. Das Netzwerk schaut weg.

Das ist keine neue Beschwerde. Ethereum-Forscher kreisen mindestens seit 2019 um dieses Problem, mit Dutzenden von Vorschlägen, die auf Protokollebene versucht und wieder verworfen wurden. Das Kernproblem: Transaktionen, die an Ethereums Mempool gesendet werden, sind vollständig transparent, bevor ein Block Builder sie überhaupt anfasst — und genau dieses Zeitfenster brauchen MEV-Bots.

Frühere Forschungsarbeiten untersuchten auf Threshold-Verschlüsselung basierende Vorschläge wie Shutter, Batched Threshold Encryption und Flash Freezing Flash Boys. Jeder hatte seine Berechtigung, aber keiner schaffte den Sprung von der Forschung zum fest verankerten Protokoll-Feature. EIP-8105 verfolgt einen anderen Ansatz: Statt sich für ein Verschlüsselungsverfahren zu entscheiden und darauf zu setzen, ist der Vorschlag so konzipiert, dass er mit jedem von ihnen funktioniert.

Was ist EIP-8105 und wie funktioniert der verschlüsselte Mempool?

Eine schema-agnostische Architektur, an die sich jeder Key Provider anbinden kann

Das Design des verschlüsselten Mempools im Kern von EIP-8105 lässt sich am besten über sein zentrales Merkmal verstehen: Schema-Agnostik. Anstatt eine bestimmte kryptografische Methode fest zu codieren, schafft der Vorschlag ein registry-basiertes System, das mehrere Verschlüsselungstechnologien nebeneinander bestehen lässt. Unterstützte Ansätze umfassen Threshold-Verschlüsselung, MPC-Komitees, TEEs (Trusted Execution Environments), Delay-Verschlüsselung und vollständig homomorphe Verschlüsselung.

Auf der Ausführungsebene bildet ein neuer Systemvertrag namens Key Provider Registry das infrastrukturelle Rückgrat. Jedes Ethereum-Konto kann sich als Key Provider in diesem Registry registrieren, sich zu einer Verschlüsselungsmethode verpflichten und mit der Ausgabe und späteren Offenlegung von Entschlüsselungsschlüsseln beginnen. Die Flexibilität ist beabsichtigt — kein einzelnes kryptografisches Primitiv dominiert, und das System kann sich weiterentwickeln, wenn die kryptografische Forschung reift.

EIP-8105 führt zwei neue Transaktionstypen im Rahmen von EIP-2718 ein. Typ 0x05 ist die verschlüsselte Transaktion — ein Umschlag, der eine verborgene Nutzlast zusammen mit einem öffentlichen Abschnitt enthält, der die Envelope-Nonce, den Gas-Betrag, Gas-Preisparameter, die Key-Provider-ID, die Schlüssel-ID und eine Signatur umfasst. Typ 0x06 ist die entschlüsselte Transaktion, die erzeugt wird, sobald der Key Provider den Entschlüsselungsschlüssel offenlegt. Diese Zwei-Typen-Struktur ist nicht kosmetisch: Sie stellt sicher, dass das Netzwerk Gas-Zahlungen verarbeiten und die Aufnahme validieren kann, noch bevor die eigentliche Transaktionsabsicht bekannt ist.

Zwei Blöcke, eine Enthüllung: So führt EIP-8105 Transaktionen aus

EIP-8105 arbeitet mit einem zweistufigen Ausführungsablauf. Im ersten Schritt wird ein verschlüsselter Transaktionsumschlag in einen Block aufgenommen — die Nutzlast bleibt verborgen. Key Provider beobachten die Chain nach Transaktionen, die auf ihre Schlüssel-IDs verweisen. Sobald der Block Builder die Ausführungsnutzlast veröffentlicht, gibt der zuständige Key Provider entweder den Entschlüsselungsschlüssel frei oder stellt eine Zurückhaltungsmitteilung aus. Das Timing ist hier entscheidend.

Ein Gremium namens Payload Timeliness Committee (PTC) überwacht, ob Entschlüsselungsschlüssel planmäßig veröffentlicht werden. Das PTC validiert jeden Schlüssel und bestätigt dessen Vorhandensein oder Fehlen. Gelingt die Entschlüsselung, wird die resultierende Klartexttransaktion am Anfang des nächsten Blocks ausgeführt. Fehlt der Schlüssel, wird er zurückgehalten oder schlägt die Entschlüsselung aus irgendeinem Grund fehl, bleibt der verschlüsselte Umschlag enthalten — und die Transaktionsgebühr wird dennoch erhoben — aber die Nutzlast wird komplett übersprungen. Nutzer zahlen in jedem Fall. Diese Designentscheidung verhindert Spam, ohne die Verfügbarkeit zu beeinträchtigen.

Auch die Blockstruktur selbst wird durchgesetzt. Entschlüsselte Transaktionen müssen am Anfang eines Blocks stehen. Klartexttransaktionen kommen in die Mitte. Verschlüsselte Transaktionen stehen am Ende. Diese Reihenfolge ist nicht willkürlich — sie schließt ein spezifisches Zeitfenster, in dem MEV-Bots sich andernfalls zwischen den Moment der Entschlüsselung und den Moment der Ausführung schieben könnten.

Beseitigt EIP-8105 tatsächlich MEV?

Nicht vollständig — und die Autoren des Vorschlags behaupten das auch nicht. Frühere Key Provider im Block behalten eine eingeschränkte Fähigkeit, MEV aus späteren Transaktionen zu extrahieren, indem sie den Zeitpunkt der Offenlegung ihrer Entschlüsselungsschlüssel wählen. Ein Key Provider könnte theoretisch beobachten, wie entschlüsselte Transaktionen aussehen, sobald sie bestätigt sind, und seinen eigenen Schlüssel zurückhalten, um eine günstigere Reihenfolge zu erzeugen.

EIP-8105 versucht dem mit einem Trust-Graph-System zu begegnen: Key Provider können andere vertrauenswürdige Anbieter benennen, und Transaktionen werden gemäß den resultierenden Vertrauensbeziehungen geordnet. Das ist ein Patch für eine verbleibende Schwachstelle, keine vollständige Lösung. Eine ehrliche Analyse zeigt: Dies ist ein schwieriges Problem — der Vorschlag reduziert die MEV-Angriffsfläche drastisch, bringt sie aber nicht auf null.

Für Ethereums kurzfristigen Zeitplan bedeutsamer ist, wo EIP-8105 auf der Roadmap steht. Der Vorschlag soll voraussichtlich nicht mehr den ersten Hard Fork 2027 anführen. Er bleibt ein offener Entwurf. Doch verschlüsselte Mempools stehen definitiv auf Ethereums offizieller Agenda, und die Architektur von EIP-8105 — insbesondere das Key Provider Registry und der schema-agnostische Ansatz — prägt aktiv das Denken der breiteren Forschungsgemeinschaft darüber, welcher Vorschlag letztlich fest im Protokoll verankert werden soll. Dass es ein offener Entwurf ist, heißt nicht, dass er tot ist. Manchmal sind es die Vorschläge, die am längsten brauchen, die am Ende am meisten bedeuten.