Der zunehmende Einfluss von Miner-Extractable Value (MEV) auf Ethereum erfordert neue Mechanismen, um die Privatsphäre und Fairness von Transaktionen zu schützen. Encrypted Mempools bieten genau das: Sie verhindern, dass Market-Making-Nutzer durch Front-Running oder andere MEV-Angriffe benachteiligt werden. Der vorliegende Artikel beschreibt ein konkretes Design, das Threshold Identity-Based Encryption (Threshold IBE) nutzt, um einen verschlüsselten Mempool zu realisieren, und erklärt, warum dieses Konzept trotz offener Herausforderungen einen wichtigen Schritt nach vorne darstellt.

Warum verschlüsselte Mempools wichtig sind

Auf Ethereum können Angreifer die Reihenfolge von Transaktionen ausnutzen, um Gewinn aus Preis-Differenzen zu schlagen. Durch die Verschlüsselung von Transaktionsinhalten im Mempool wird verhindert, dass ein Builder die Ausführungsreihenfolge anhand des Klartexts bestimmt. Damit wird die Integrität des Marktplatzes geschützt und die Nutzer-Privatsphäre gewahrt.

Grundlegendes Design – Drei Phasen des Transaktionszyklus

Der Lifecycle von verschlüsselten Transaktionen wird in drei klar getrennte Phasen aufgeteilt. Diese Faktorisierung sorgt für Vorzeit- und Konsensbindung und übertrifft damit frühere Entwürfe wie LUCID.

Planungsphase – Ticket-Einreichung

• Der Absender legt ein Ticket in den Mempool, das einen kryptografischen Identifier (Blockhash) reserviert.
• Das Ticket garantiert, dass ein Konsens über die Reservierung aufgebaut wird.
• Ein Ticket kostet 0,02 ETH (Blockhash-Identitätsgebühr, 2026, Quelle S3).

Vertrauensphase – Chiffrat-Publikation

• Nach Aufnahme des Tickets in Block Bₙ wird das verschlüsselte Transaktions-Chiffrat veröffentlicht.
• Der Payload-Timeliness-Committee (PTC) aus EIP-7732 (ePBS) sorgt für eine dezentrale und robuste Entscheidung über die Verfügbarkeit des Chiffrats, bevor die Entschlüsselung aktiviert wird.
• Ein zusätzlicher Konsens-Round (Block Bₙ₊₁ ) legt ein Bitfield fest, das angibt, welche Tickets tatsächlich entschlüsselt werden dürfen.

Ausführungsphase – Klartext-Integration

• Im Block Bₙ₊₂ wird der rekonstruierte Schlüssel veröffentlicht und der Klartext-Transaktionsinhalt top-of-block eingefügt.
• Die Reihenfolge richtet sich nach der Ticket-Reihenfolge aus der Planungsphase, sodass Builder die Reihenfolge nicht anhand des Chiffrats manipulieren können.

Kryptografische Grundlagen – Threshold IBE und Blockhash-Identität

Threshold IBE kombiniert Identity-Based Encryption (IBE) mit einem Schwellenwert-Entschlüsselungsmechanismus. Die Identität wird durch den Blockhash der Ticket-Transaktion definiert, wodurch jede verschlüsselte Nachricht an einen konkreten Fork gebunden ist.

• Schwellenwert für die Rekonstruktion: t = floor(N/2) + 1 (2023, Quelle S3).
• Einige Validatoren ( N ) halten Schlüssel-Shares; mindestens t Shares müssen zusammenkommen, um den Entschlüsselungsschlüssel zu erzeugen.
• Durch die Blockhash-Identität wird verhindert, dass ein Schlüssel nach einem Reorg missbraucht wird – der Schlüssel wird nur für den Block freigegeben, den das Konsens-Committee unterstützt.

Verknüpfung mit ePBS und PTC für Schadensprophylaxe

Die Integration des Payload-Timeliness-Committees (PTC) aus EIP-7732 (ePBS) sorgt für eine dezentrale und robuste Entscheidung über die Verfügbarkeit des Chiffrats, bevor die Entschlüsselung aktiviert wird.

• Der PTC liefert ein binäres Ergebnis ( valid/invalid ) zur Frage, ob das Chiffrat den Konsens erreicht hat (2026, Quelle S3).
• Ein Bitfield im Block Bₙ₊₁ bindet die Entscheidung an die Fork-Choice-Regel, sodass ein Builder bei Erreichen des Quorums verpflichtet ist, die Transaktion einzuschließen.
• Durch diese Verknüpfung wird die Angriffsfläche reduziert und die Robustheit gegenüber Netzwerk- und Verfügbarkeitsproblemen erhöht.

Leistungs- und Sicherheitsaspekte

Performance-Probleme durch zusätzliche Konsensrunde

Jede verschlüsselte Transaktion verlängert den Zyklus um zwei Blöcke. In extremen Anwendungsszenarien kann dies das System verlangsamen. Der zusätzliche Konsens-Round ist jedoch notwendig, um die Bindung an den Konsens sicherzustellen und Builder-Manipulationen zu verhindern.

Quantensicherheit

Der aktuelle Stand der post-quantum-Forschung liefert noch keine sicheren Threshold-IBE-Schemata, die auf Gitter-Kryptografie basieren. Deshalb besteht ein erhöhtes Risiko, dass zukünftige Quantencomputer die Sicherheit des Designs gefährden könnten.

Statistiken und Kennzahlen

• Transaktionsphasenanzahl im TIBE-Design: 3 (2026).
• Schwellenwertgröße: floor(N/2) + 1 (2023, Quelle S3).
• Jährlich von MEV betroffene Ethereum-Transaktionen: 4 000 000 (2025, Quelle S1).

FAQ

Wieso muss der Blockhash des Tickets genutzt werden?Der Blockhash dient als deterministische Identität, die die Transaktion an einen konkreten Block bindet und gleichzeitig vor Reorg-Attacken schützt.Wie kann der PTC verhindern, dass ein Builder selektiv Transaktionen ausschließt?Durch die Verknüpfung mit der Fork-Choice-Regel ist ein Builder bei Erreichen des PTC-Quorums verpflichtet, die Transaktion in den Block zu integrieren.

Fazit

Das vorgestellte Design für einen Ethereum-verseuchten Mempool nutzt Threshold IBE, um Transaktionen in drei logisch getrennte Phasen zu faktorisieren und dabei die Privatsphäre sowie die Fairness der Ausführung zu gewährleisten. Die Kombination aus Blockhash-Identität, einem klar definierten Schwellenwert ( t = floor(N/2) + 1 ) und der Integration des ePBS-PTC reduziert die Angriffsfläche und stärkt die dezentrale Entscheidungsfindung. Gleichzeitig führt das Modell zu einem zweiblockigen Verzögerungs- und Konsens-Overhead, der in Hochlast-Szenarien die Performance beeinträchtigen kann, und es bleibt offen, ob post-quantum-sichere Threshold-IBE-Schemata in absehbarer Zeit verfügbar sein werden. Trotz dieser offenen Punkte liefert das Konzept einen wichtigen Baustein für zukünftige Forschungen und mögliche Implementierungen, die Encrypted Mempools ohne Batch-Decryption ermöglichen.