Der vorliegende Entwurf beschreibt ein neuartiges Konzept für einen verschlüsselten Mempool auf Ethereum, das auf Schwellenwert-identitätsbasierter Verschlüsselung (Threshold IBE) beruht und bewusst auf die komplexe Batch-Entschlüsselung verzichtet. Durch die Einführung einer deterministischen Drei-Block-Pipeline (Bₙ → Bₙ₊₁ → Bₙ₊₂) soll die Gefahr toxischer Formen von Maximal Extractable Value (MEV) – insbesondere Frontrunning und Sandwich-Angriffe – reduziert werden, während gleichzeitig der kryptografische Lösungsraum für Enshrined-Mempools erweitert wird.

Problemstellung: MEV und die Notwendigkeit verschlüsselter Mempools

MEV-Angriffe entziehen Nutzern jährlich Milliardenwerte. Schätzungen aus dem Jahr 2025 (Quelle S3) quantifizieren den kumulierten Verlust auf 1,1 bis 3 Milliarden USD. Klassische Mempools exponieren Transaktionen sofort, was Angreifern die Möglichkeit gibt, Transaktionen zu front-run oder zu sandwichen, bevor deren Inhalt öffentlich wird. Ein verschlüsselter Mempool soll genau diesen Informationsfluss verbergen, bis die Transaktion sicher in einem Block finalisiert ist.

Drei-Block-Pipeline mit Threshold-IBE

Der Kern des Vorschlags besteht aus einer festen Verzögerung von zwei Blöcken (je 12 Sekunden, insgesamt 24 Sekunden – Quelle S1). Die Pipeline funktioniert wie folgt:

Ablauf der Blöcke Bₙ, Bₙ₊₁ und Bₙ₊₂

• Bₙ: Ein Transaktionsticket vom Typ 0x05 („Sealed Ticket“) wird on-chain aufgenommen (EIP-8184, Jahr 2026). Das Ticket bindet die spätere Verschlüsselungs-Identität an den Blockhash von Bₙ, was Replay-Angriffe über Reorg-Grenzen hinweg verhindert.
• Bₙ₊₁: Das Payload Timeliness Committee (PTC) prüft, ob die verschlüsselte Payload fristgerecht im P2P-Netz verfügbar war. Das Ergebnis wird in einem Bitfield festgehalten, das die spätere Freigabe des De-Schlüssel-Shares autorisiert.
• Bₙ₊₂: Das Threshold-IBE-Komitee veröffentlicht die erforderlichen Schlüssel-Shares. Die zuvor verschlüsselten Transaktionen werden entschlüsselt und in der festgelegten Reihenfolge oberhalb des Blocks (Top-of-Block) ausgeführt.

Durch die Bindung an den Blockhash wird jede verschlüsselte Transaktion eindeutig einem einzigen Fork zugeordnet – ein Reorg macht die Transaktion ungültig.

Verbindung zu bestehenden EIPs (LUCID und Universal Enshrined Mempool)

Der Entwurf baut auf der Architektur von EIP-8184 (LUCID) auf, das bereits einen neuen Transaktionstyp für Ticket-basierte Commit-Reveal-Mempools definiert. Im Gegensatz zu LUCID verzichtet das hier vorgestellte Modell jedoch auf zwingende Batch-Entschlüsselungsprimitiven, wodurch es besser zu den Zielen von EIP-8105 (Universal Enshrined Mempool) passt, das einen protokollintegrierten Mempool ohne feste Bindung an eine einzelne kryptografische Implementierung anstrebt.

Kryptografische Herausforderungen und Post-Quantum-Perspektive

Bestehende batched-Threshold-Systeme erfordern strenge kryptografische Annahmen, für die bislang kaum praxistaugliche Post-Quantum-Verfahren existieren. Gitterbasierte (lattice-based) IBE-Verfahren, etwa auf Basis von Learning With Errors (LWE), bieten theoretisch Quanten-Sicherheit, verursachen jedoch bei Schwellenwert-Setups enorme Schlüssel- und Signaturgrößen sowie hohen Kommunikations-Overhead.

Kommunikations- und Latenz-Kennzahlen

• Kommunikationsaufwand in batched Verfahren (Bormet et al., 2025): 48 Bytes pro Validierungspartei (Quelle S2).
• Verschlüsselungslatenz pro Transaktion im Referenz-Setup (Bormet et al., 2025): 8,5 ms (Quelle S2).
• Aggregierte Kommunikationsgröße pro Validierungspartei im Batched-Benchmark: ebenfalls 48 Bytes (Jahr 2025, Quelle S2).
• Pipeline-Verzögerung bis zur Transaktionsausführung: 24 Sekunden (zwei Slots, Jahr 2026, Quelle S1).

Der Verzicht auf Batch-Entschlüsselung reduziert die mathematischen Restriktionen signifikant und eröffnet damit einen realistischeren Pfad für die Integration von LWE-basierten, quantenresistenten Schemen.

Risiken und Gegenmaßnahmen

Der Ansatz ist nicht risikofrei. Zwei zentrale Gegenpunkte werden im Entwurf diskutiert:

Erhöhte Latenz und Economic Reaction Gap

• Die feste Verzögerung von 24 Sekunden schützt vor Frontrunning, kann jedoch adaptive Marktreaktionen behindern. In volatilen DeFi-Märkten (z. B. Perpetual Funding Rates) führt dies zu temporären Fehlpreisungen, weil Arbitrageure nicht sofort reagieren können.

Bedrohung der Dynamic Availability bei Schlüsselverweigerung

• Falls das Schwellenwert-Komitee die Offenlegung von Schlüssel-Shares verweigert oder die Validator-Beteiligung unter den Schwellenwert t sinkt, greift ein Circuit-Breaker. Dieser blockiert neue Tickets und kann bereits eingereichte Transaktionen ungültig machen – ein potenzieller Ausfallfall, der jedoch durch das Design bewusst akzeptiert und mitigiert wird.

Häufig gestellte Fragen (FAQ)

• Warum genügt einfaches Threshold IBE, wenn auf Batching verzichtet wird? Der Absender verschlüsselt die Transaktion erst, nachdem das Ticket in Block Bₙ enthalten ist. Die Ziel-Identität (der Blockhash von Bₙ) ist bereits fest, sodass das Komitee nur einen einzigen Identitätsschlüssel ableiten muss, anstatt zur Laufzeit eine Menge von Chiffraten zu koordinieren.
• Welche Rolle spielt das Payload Timeliness Committee (PTC)? Das PTC, aus dem ePBS-Design stammend, votiert darüber, ob die verschlüsselte Payload fristgerecht im P2P-Netz vorlag. Die Proposer von Bₙ₊₁ werden durch diese Stimmen gezwungen, das Bitfield etxseen objektiv zu setzen, bevor Schlüssel offengelegt werden.

Fazit

Der vorgestellte Drei-Block-Ansatz demonstriert, wie ein verschlüsselter Mempool auf Ethereum realisiert werden kann, ohne auf die schwer zu erfüllenden Anforderungen einer Batch-Entschlüsselung zurückgreifen zu müssen. Durch die Bindung an den Blockhash, die klare Trennung von Ticket-Erstellung, PTC-Abstimmung und Schlüssel-Freigabe entsteht ein robustes Sicherheitsmodell, das sowohl Replay-Angriffe als auch klassische MEV-Strategien wirksam abschwächt. Gleichzeitig eröffnet das Weglassen des Batch-Schrittes einen praktikablen Pfad für die Integration post-quantum-resistenter, gitterbasierter IBE-Schemen. Die unvermeidbare Latenz von 24 Sekunden und das Risiko einer Schlüssel-Verweigerung stellen wirtschaftliche und Verfügbarkeits-Trade-offs dar, die jedoch durch das Circuit-Breaker-Mechanismus und die bewusste Akzeptanz von Ausnahme-Fehlerfällen gemindert werden. Insgesamt positioniert sich das Konzept klar innerhalb der aktuellen Ethereum-Standardisierungs-Roadmap (EIP-8184 (LUCID) und EIP-8105) und liefert einen fundierten Ausgangspunkt für zukünftige Forschung und Implementierung verschlüsselter, quantenresistenter Mempools.