EIP-7732 (ePBS): wie sich die Blockproduktion bei Ethereum ändert und wie der Stand ist

Einen Ethereum-Block vorzuschlagen und seinen Inhalt zu erstellen, kann heute Aufgabe verschiedener Teilnehmer sein: Das Protokoll bestimmt in jedem Slot den Validator, der den Block vorschlägt, die Transaktionen und ihre Reihenfolge kann jedoch ein spezialisierter Builder vorbereiten, der nicht Teil des Protokolls ist. Die Verbindung zwischen beiden erfolgt heute über externe Software:MEV-Boostermöglicht es dem Validator, Blöcke aus einem Markt von Buildern zu beziehen, und Intermediäre, sogenannte Relays, bündeln diese Angebote und wählen dasjenige aus, das dem Proposer am meisten zahlt. Diese Rollentrennung wird als PBS (Proposer-Builder Separation) bezeichnet, und der Austausch beruht auf Vertrauen in das Relay.

EIP-7732, ePBS genannt (Enshrined Proposer-Builder Separation), verankert diesen Austausch in den Konsensregeln: Der Proposer nimmt ein signiertes Commitment des Builders auf, der Builder legt den Inhalt anschließend offen, und das Protokoll garantiert die Zahlung an den Proposer, auch wenn der Builder seine Zusage nicht erfüllt. Stand 8. November 2026 befindet sich der Vorschlag weiterhin im Status Last Call und ist Teil von Glamsterdam, einem Upgrade, das nur im Testnetz Sepolia aktiv ist; die Aktivierung auf Hoodi wurde verschoben, ein Mainnet-Termin steht nicht fest. Für Betreiber von Validatoren oder Infrastruktur ist jetzt der Zeitpunkt, den Mechanismus zu verstehen und zu testen, nicht, auf ein Datum hin zu planen.

Wer heute einen Ethereum-Block erstellt und was außerhalb des Protokolls liegt

Die Motivation des Vorschlags geht von einem Austausch aus, der sich nach den aktuellen Regeln nicht vertrauenslos abwickeln lässt. Der Proposer will keinen Block signieren, ohne zu wissen, wie viel er erhält, und der Builder will seinen Inhalt nicht vor der Signatur herausgeben, weil der Proposer seine Transaktionen kopieren könnte. Außerhalb des Protokolls löst dieses Problem ein Dritter, der den Inhalt verwahrt, bis die Signatur vorliegt. EIP-7732 löst es innerhalb des Protokolls: Laut ihrem Text ermöglicht sie einen fairen, vertrauenslosen Austausch zwischen Proposer und Builder und macht eine vertrauenswürdige Middleware zur Delegation der Blockerstellung überflüssig.

Die Änderung betrifft außerdem die Validierung eines Blocks. Der Vorschlag entkoppelt nach eigener Formulierung die Validierung der Ausführung von der Validierung des Konsenses, sowohl logisch als auch zeitlich. Heute trifft ein Block mitsamt seinem Ausführungsinhalt ein, und die Validatoren müssen alles im ersten Abschnitt des Slots prüfen; mit ePBS kommt zuerst der Konsensblock, und die Ausführung wird danach validiert.

Gebot, Offenlegung und Timeliness Committee: der Block in zwei Schritten

Mit EIP-7732 enthält der Block der Beacon Chain keinen Execution Payload mehr. Er enthält stattdessen ein signiertes Gebot eines Builders (SignedExecutionPayloadBid), das sich auf den Hash des Ausführungsblocks, die Wurzel seiner Execution Requests und den Betrag festlegt, den er dem Proposer zahlt. Sobald dieser Konsensblock im Netzwerk verbreitet ist, legt der Builder den vollständigen Payload in einem signierten Umschlag (SignedExecutionPayloadEnvelope) offen.

Ein Payload Timeliness Committee (PTC) mit 512 Mitgliedern, gebildet aus den Komitees des jeweiligen Slots, attestiert, ob der Payload rechtzeitig offengelegt wurde und ob seine Blob-Daten verfügbar waren. Dieses Komitee prüft Signaturen und den Blockhash, validiert aber nicht die vollständige Ausführung. Die Validierung wird verteilt: Dem nächsten Proposer steht die zweite Hälfte des Slots zur Verfügung, von der Payload-Frist bei 50% bis zum Ende, und die Attester haben bis zur Attestierungsfrist des folgenden Slots Zeit, bei 25% dieses Slots. Für dieFork-Choice-Regel hängt die Frage, ob der vorherige Payload als aufgenommen gilt, nicht vom Gewicht der Attestierungen ab, sondern von einem Tie-Breaker-Kriterium, in das die Stimmen des Komitees eingehen, mit einer Schwelle von mehr als der Hälfte seiner Mitglieder.

Der Vorschlag streicht keine Prüfung der Ausführungsregeln: Er ändert, wann und von wem sie vorgenommen wird. Ein Betreiber kann das Eintreffen des Konsensblocks nicht mehr als Beleg dafür werten, dass der Inhalt gültig ist, denn es handelt sich um zwei verschiedene Nachrichten, die zu unterschiedlichen Zeitpunkten eintreffen.

Wenn der Builder den Payload nicht offenlegt: leerer Slot, bezahlter Proposer

Nehmen wir einen hypothetischen Slot an, in dem der Proposer das höchste Gebot wählt, es in seinen Block aufnimmt und diesen rechtzeitig veröffentlicht, der Builder den Payload aber nicht offenlegt. Laut Spezifikation wird der Konsensblock in die Chain aufgenommen und der Slot als „Empty“ eingestuft: Es gibt einen Block der Beacon Chain, aber nicht den zugesagten Payload, sodass die Transaktionen, die dieser Builder angeordnet hatte, in diesem Slot nicht ausgeführt werden.

Der Proposer wird trotzdem bezahlt. Der Gebotsbetrag wird bei der Verarbeitung des Blocks als ausstehende Zahlung zulasten des Guthabens des Builders auf der Beacon Chain verbucht, und ein Gebot ist nur gültig, wenn dieses Guthaben die Mindesteinlage, seine übrigen ausstehenden Zahlungen und den Betrag selbst deckt. Kommt der Payload nie an, wird daraus beim Epochenübergang ein Withdrawal, sofern der Block Attestierungen aus demselben Slot von mindestens 6/10 des aktiven Guthabens pro Slot erhalten hat. Der nächste Block verarbeitet dagegen keine neuen Withdrawals und enthält keine Execution Requests des Parent-Blocks, weil dieser keinen Payload hat. Für den Betreiber bedeutet das: Ein leerer Slot, weil der Builder den Payload zurückhält, ist für seine Vergütung kein verlorener Slot, wohl aber eine Lücke in der Ausführung, die seine Monitoring-Tools von einem eigenen Fehler unterscheiden müssen.

Der Fall hat eine Grenze, die der Vorschlag selbst in seinen Sicherheitsüberlegungen einräumt, das Problem der kostenlosen Option (Free Option): Ein ökonomisch rationaler, aber böswilliger Builder kann seinen Payload zurückhalten, wenn es sich für ihn lohnt, etwa wenn sich der Wert seines Inhalts zwischen Gebot und Offenlegung ändert und ihn der Verlust des Gebotsbetrags weniger kostet als die Veröffentlichung. Den ehrlichen Builder schützt die Spezifikation hingegen: Veröffentlicht der Proposer den Block mit seinem Gebot zu spät, ist der Builder nicht zur Offenlegung verpflichtet, und ihm wird nichts berechnet. Für das Netzwerk kostet jede Zurückhaltung einen Slot ohne Transaktionen; der Vorschlag nennt variable Strafen für Nichtaufnahme als mögliche Abhilfe, diese sind jedoch nicht Teil des aktuellen Designs.

Builder mit eigener Einlage und Self-Building

Der Vorschlag macht Builder zu Teilnehmern des Protokolls mit eigenem Register, getrennt vom Validator-Set. Sie können ab 1 ETH einzahlen und treten über zwei System-Contracts auf der Ausführungsschicht ein oder aus, mit Requests, die das Gebot in seiner Wurzel festschreibt und die angewendet werden, wenn der nächste Block den Payload verarbeitet. Withdrawals werden auf der Beacon Chain sofort abgezogen, der nächste Payload muss genau diese Withdrawals enthalten, und Zahlungen an Builder werden zuerst verarbeitet.

Der Proposer ist nicht verpflichtet, einen externen Builder zu nutzen. Er kann ein über das Peer-to-Peer-Netzwerk empfangenes Gebot wählen, es auf anderem Weg beziehen oder den Payload selbst erstellen; in diesem Fall verwendet er den Index BUILDER_INDEX_SELF_BUILD. Ein privat betriebener Validator, der heute seine Blöcke selbst erstellt, muss mit ePBS sein Modell nicht ändern, sein Client wird allerdings dem neuen Ablauf mit zwei Nachrichten folgen müssen.

Status von EIP-7732 im November 2026: Last Call, Glamsterdam ohne Mainnet-Termin

Die Termine des Vorschlags und des Upgrades, das ihn enthält, sind getrennte Sachverhalte; so legt es der Prozess fest, der beschrieben ist inEIP-1. Der Status einer EIP misst ihre Reife als Spezifikation; die Aktivierung hängt davon ab, dass die Client-Teams für jedes Netzwerk eine Epoche festlegen.

Glamsterdam kombiniert Amsterdam, das Upgrade der Ausführungsschicht, und Gloas, das Upgrade der Konsensschicht, und umfasst lautAnkündigung der Ethereum Foundation18 EIPs, darunter EIP-7732 und die Block-Level Access Lists aus EIP-7928. DieVerschiebung des Hoodi-Terminswurde beschlossen, um zu untersuchen, wie EIP-8037, das die Gaskosten für die Erzeugung von State erhöht, mit Smart Contracts im Mainnet interagiert. Diese Mitteilung legt keinen Mainnet-Termin fest und verlangt von Nutzern und ETH-Haltern keine Maßnahmen. Laut derHistorie des Repositorys wurde der Text von EIP-7732 zuletzt am 20. Oktober aktualisiert, um ihn an die Konsensspezifikation anzupassen; Implementierungen und Tools sollten daher mit dieser Version abgeglichen werden und nicht mit älteren Zusammenfassungen.

ePBS beseitigt das Vertrauen in das Relay; die Konzentration der Builder bleibt offen

Was EIP-7732 löst, ist klar umrissen: Der Proposer muss keinem Intermediär mehr vertrauen, um für einen Block bezahlt zu werden, den er nicht gesehen hat, weil die Zahlung durch die Konsensregeln garantiert ist, und die Validierung der Ausführung konzentriert sich nicht mehr auf den ersten Abschnitt des Slots. Für Validator-Betreiber bedeutet das eine externe Abhängigkeit weniger im kritischen Pfad jedes Blocks, den sie vorschlagen, und der Teil des Austauschs, der heute auf dem Relay beruht, geht in die Regeln über, die ihr eigener Client ausführt.

Was der Vorschlag nicht löst, ist die Frage, wer die Blöcke baut. Er begrenzt weder, wie viele Builder miteinander konkurrieren, noch, wie viel Inhalt jeder von ihnen kontrolliert, und sein Text trifft keine Aussage zu Nutzergebühren. Er führt zudem ein neues Verhalten ein, die kostenlose Option, deren Auswirkung auf leere Slots sich erst messen lässt, wenn sie im Mainnet läuft. Um die tatsächliche Wirkung zu beurteilen, wird man nach der Aktivierung die Beteiligung und Konzentration der Builder sowie die Häufigkeit leerer Slots beobachten müssen; bis dahin finden Betreiber die relevanten Informationen in Sepolia und in den Release Notes ihrer Clients.

Bei Metlabs verfolgen wir Protokolländerungen im Rahmen unserer Arbeit im BereichBlockchain-Infrastrukturund der Entwicklung aufEthereum. Wenn Sie Nodes oder Validatoren betreiben und die Tests für Glamsterdam vorbereiten möchten,erzählen Sie uns davonwelche Clients Sie einsetzen und wie Sie Ihre Blöcke derzeit überwachen.