Enshrined Proposer-Builder Separation (ePBS), formalisiert in EIP-7732, verlagert die Blockauktions- und Verifikationsmechanismen von externen Relays auf die Konsensebene von Ethereum. Dieser Schritt verändert zentrale Parameter wie Dezentralisierung, Latenzspielräume, MEV-Märkte und die Skalierbarkeit des Netzwerks (Execution Pipelining). Im Folgenden werden die wichtigsten technischen Änderungen, die aktuellen Marktbedingungen und die daraus resultierenden Risiken systematisch dargestellt.

Wie MEV-Boost heute funktioniert

Der aktuelle MEV-Boost-Mechanismus ermöglicht den Bau von ca. 85-90 % aller Ethereum-Blöcke über externe, vertrauensbasierte Relays. Der Ablauf lässt sich in vier Schritte zusammenfassen:

• Builder senden Gebote an einen Relay.
• Der Proposer fordert das aktuelle Höchstgebot beim Relay an.
• Der Proposer unterschreibt das Gewinnergebot und beendet damit die Auktion.
• Der Relay veröffentlicht den Block im Namen des Proposers.

Dieses Modell beruht auf einem vertrauenswürdigen Drittanbieter, der sowohl die korrekte Blockpublikation als auch die genaue Bezahlung des Proposers sicherstellt.

Kerndesign von ePBS (EIP-7732)

ePBS trennt die Ausführungs- von der Konsens-Validierung zeitlich und logisch. Die wichtigsten Neuerungen laut EIP-7732 sind:

• Payload-Timeliness Committee (PTC): Ein spezielles Komitee von 512 Validatoren (Quelle S2) prüft ausschließlich die Verfügbarkeit und Rechtzeitigkeit des Execution Payloads, nicht dessen inhaltliche Gültigkeit.
• Staked Builder Deposit: Ein Mindest-Deposit von 1 ETH (Jahr 2024, Quelle S2) ist erforderlich, um als Builder im Konsens-Layer registriert zu werden.
• Erweitertes Validierungsfenster: Das Zeitfenster für die Ausführungsvalidierung wird von etwa 2-4 Sekunden auf bis zu 9-12 Sekunden pro Slot verlängert, weil die vollständige Validierung erst im nachfolgenden Slot zwingend erforderlich ist (Formalisierung im Gloas-Design).
• Trustless vs. Trusted Payments: Das Protokoll unterstützt sowohl trustless Payments (automatischer Abzug vom Builder-Balance im Konsens-Layer) als auch trusted Payments (klassische On-Chain-Transaktion vom Builder zum Proposer).

Durch diese Änderungen wird die Auktion von einem externen Relay-Service in das Protokoll selbst verlagert. Protokollseitig wird das externe Relay also vollständig ersetzt, während ökonomisch weiterhin aggregierende Vermittler existieren können.

Marktkonzentration im Builder-Ökosystem

Die aktuelle Marktstruktur ist stark von wenigen großen Buildern dominiert. Empirische Kennzahlen belegen diese Konzentration:

• MEV-Boost-Adoptionsrate: 86,3 % aller Ethereum-Blöcke (Jahr 2026, Quelle S1).
• Herfindahl-Hirschman-Index (HHI) für den Builder-Markt: ~3892 (Jahr 2025, Quelle S3), ein Wert, der extreme Konzentration anzeigt.
• Marktanteil des führenden Builders „Titan“: 46,5 % (Jahr 2025, Quelle S3).

Diese Zahlen belegen, dass die Pfadabhängigkeit von MEV-Boost durch die Dominanz weniger Top-Builder (z. B. Titan, Rsync, Beaverbuild) erklärt wird. Selbst nach Einführung von ePBS ist zu erwarten, dass etablierte Beziehungen („Trusted Payments“) weiter bestehen.

Slot-Deadlines und das Free-Option-Problem

Durch die neue Slot-Anatomie entstehen mehrere Deadlines:

1. Veröffentlichung des Beacon-Blocks zu Slot-Start.
2. Attestations-Committee stimmt drei Sekunden später über den Beacon-Block ab.
3. Der Builder muss das Execution Payload bis zum Zeitpunkt t₁ veröffentlichen, sobald er ausreichend Attestations-Weight sieht.
4. Das PTC prüft die Verfügbarkeit von Payload und Blobs bei t₂ (drei Sekunden nach t₁ ).

Das Free-Option-Problem entsteht, weil Builder bis kurz vor der PTC-Frist (t = 6 s bzw. t = 9 s) das Payload zurückhalten oder verfallen lassen können. In Phasen hoher Marktvolatilität könnten Builder bewusst Slots leer lassen, was zu verpassten Transaktionen und erhöhten Netzwerklatenzen führt (Quelle: Counterpoints-Risks).

Auswirkungen auf Dezentralisierung und Latenz

ePBS reduziert die Abhängigkeit von externen Relays, schafft jedoch ein neues, kleineres Komitee (PTC) von 512 Validatoren, das die Payload-Verfügbarkeit bestätigt. Diese Reduktion kann die Latenz für die Payload-Veröffentlichung verringern, weil das PTC nur ein binäres Ja/Nein-Signal liefert. Gleichzeitig erhöht das erweiterte Zeitfenster für die vollständige Ausführungsvalidierung das Risiko von Reorgs, da die endgültige State-Transition erst im nachfolgenden Slot erfolgt.

Die Kombination aus kürzerer kritischer Latenz und längerem Validierungsfenster unterstützt das sogenannte Execution Pipelining, das die Skalierbarkeit des Netzwerks bei wachsendem Blob- und Transaktionsvolumen verbessert.

Risiken für Zentralisierung und Zensurresistenz

Obwohl ePBS die technische Rolle von Relays eliminiert, löst es das Problem der Builder-Zentralisierung nicht. Der hohe HHI-Wert und die Marktanteile der Top-Builder zeigen, dass ein Oligopol bestehen bleibt. Ergänzende Mechanismen wie Inclusion Lists (FOCIL) werden weiterhin benötigt, um Zensurresistenz zu gewährleisten.

Ein weiteres Risiko liegt in der möglichen Nicht-Publikation von Payloads durch Builder, die das Free-Option-Problem ausnutzen. Die Community diskutiert bereits Gegenmaßnahmen wie aggressive Circuit-Breaking-Mechanismen und Deny-Listing von nicht-kooperativen Buildern (Quelle: Counterpoints-Risks).

FAQ zu ePBS

Ersetzt ePBS (EIP-7732) externe Relays vollständig?

Protokollseitig ja: Die Validierung und Zahlungen werden auf Konsensebene abgewickelt. Ökonomisch können Relays jedoch als aggregierende Vermittler und vertrauenswürdige Endpunkte weiter bestehen.

Warum prüft das PTC nicht die Gültigkeit der Transaktionen?

Um die Konsens-Deadlines zu entlasten. Das PTC bestätigt lediglich die rechtzeitige Bereitstellung der Daten; die vollständige Ausführung und State-Transition erfolgt im Zeitfenster des Folgeslots (Execution Pipelining).

Zusammenfassung der wichtigsten Erkenntnisse

• ePBS verlagert Blockauktions- und Verifikationsmechanismen von externen Relays auf die Konsensebene.
• Das Payload-Timeliness Committee (512 Validatoren) prüft nur Verfügbarkeit, nicht inhaltliche Gültigkeit.
• Der Mindest-Builder-Stake beträgt 1 ETH, wodurch ein leichter Eintritts-Barrierenkontext entsteht.
• Durch das erweiterte Validierungsfenster (bis zu 12 s) wird Execution Pipelining ermöglicht, was die Skalierbarkeit erhöht.
• Der aktuelle Builder-Markt ist stark konzentriert (HHI ~3892, Titan-Marktanteil 46,5 %).
• Das Free-Option-Problem birgt das Risiko, dass Builder bei hoher Volatilität Payloads zurückhalten und Slots leer lassen.
• Dezentralisierung wird nicht automatisch verbessert; zusätzliche Schutzmechanismen bleiben nötig.

Fazit

Enshrined Proposer-Builder Separation (ePBS) stellt einen bedeutenden architektonischen Wandel dar, indem es die Blockauktion von externen Relays in den Konsens-Layer integriert und damit die Latenz für Payload-Verfügbarkeit reduziert. Gleichzeitig erweitert das Design das Zeitfenster für die vollständige Ausführungsvalidierung, was die Skalierbarkeit durch Execution Pipelining stärkt. Die Marktanalyse zeigt jedoch, dass die bestehende Konzentration im Builder-Ökosystem – gemessen an einer MEV-Boost-Adoptionsrate von 86,3 % und einem HHI von ~3892 – wahrscheinlich auch nach ePBS fortbestehen wird. Das Free-Option-Problem stellt ein konkretes Risiko für die Block-Inklusion in volatilen Marktphasen dar und erfordert zusätzliche Governance- und Sicherheitsmechanismen. Insgesamt bietet ePBS klare technische Vorteile, lässt aber zentrale ökonomische Fragen zur Dezentralisierung und Zensurresistenz offen, die durch ergänzende Protokoll- und Markt-Designs adressiert werden müssen.