Ethereum plant Block-in-Blobs-Upgrade für Validatoren

Ethereum-Forscher diskutieren ein neues Upgrade namens Block-in-Blobs -- formal vorgeschlagen als EIP-8142 --, das die Art und Weise, wie Validatoren Execution-Daten verarbeiten, grundlegend umstrukturieren würde. Vollständige Block-Payloads sollen in Blobs kodiert werden, anstatt dass Validatoren sie separat herunterladen und speichern müssen. Sollte der Vorschlag die Forschungsphase überstehen und in ein künftiges Hard Fork einfliessen, könnte er die Hardware- und Bandbreitenanforderungen für die Zehntausende von Validatoren, die das Netzwerk am Laufen halten, spürbar reduzieren.

Was ist EIP-8142 und warum ist es wichtig?

Block-in-Blobs erklärt: Was der Vorschlag konkret bewirkt

Die Kernidee hinter EIP-8142 ist verblüffend einfach: Man nimmt den Execution-Payload -- das Datenpaket, das Validatoren mitteilt, was in jedem Block passiert ist -- und kodiert ihn direkt in Blobs, anstatt ihn als eigenständige Struktur zu übertragen. Validatoren würden dann Zustandsübergänge allein anhand der Blob-Daten bestätigen, ohne den vollständigen Execution-Payload separat abrufen zu müssen. Diese einzelne architektonische Änderung würde, sofern sie wie geplant funktioniert, einen erheblichen Teil der Datenlast eliminieren, die Validatoren derzeit tragen.

Derzeit muss jeder Ethereum-Validator Execution-Payloads für jeden Block herunterladen, verarbeiten und temporär speichern. In der Summe -- über Hunderttausende von Validatoren hinweg -- summiert sich diese Redundanz schnell. Die Forscher hinter EIP-8142 argumentieren, dass das aktuelle Modell unnötig ressourcenintensiv ist, insbesondere da Ethereum immer stärker auf eine Rollup-zentrierte Zukunft setzt, in der Blob-Speicher bereits den Grossteil der Datenverfügbarkeit für Layer-2-Lösungen übernimmt.

Der Vorschlag existiert nicht im luftleeren Raum. Er ist ein direkter Nachfolger der Blob-Architektur, die Ethereum mit dem Dencun-Upgrade im März 2024 eingeführt hat. Dieses Upgrade -- geregelt durch EIP-4844 -- brachte Blob-tragende Transaktionen als günstigere Datenverfügbarkeitsschicht für Rollups. Block-in-Blobs nimmt dieselbe Infrastruktur und wendet sie nach innen an -- Blobs werden nicht nur für Layer-2-Daten genutzt, sondern auch für die eigenen Block-Daten der Execution-Schicht.

Der Block-in-Blobs-Vorschlag kodiert Execution-Payload-Daten in Blobs, sodass Validatoren keine vollständigen Execution-Payloads mehr herunterladen müssen, um den Zustandsübergang zu verifizieren.

Das Validator-Datenproblem, das Ethereum noch nicht vollständig gelöst hat

Hier ist der Aspekt, der zu wenig Beachtung findet: Ethereums Validator-Set ist riesig. Einen Solo-Validator zu betreiben erfordert ständige Synchronisation mit dem Netzwerk, die Verarbeitung von Attestierungen und die kontinuierliche Handhabung von Execution-Daten. Die Hardware-Anforderungen steigen stetig -- nicht dramatisch, aber genug, dass die Ethereum Foundation und die Core-Forscher wiederholt betont haben, Solo-Staking zugänglich halten zu wollen, ohne Server-Hardware vorauszusetzen.

Block-in-Blobs zielt genau auf diesen Druckpunkt ab. Indem Execution-Payload-Daten durch die Blob-Pipeline geleitet werden, könnten Validatoren auf die Blob-Verarbeitung setzen -- einen nach Dencun bereits optimierten Pfad -- anstatt parallel einen schwereren Execution-Daten-Download zu betreiben. Der Effizienzgewinn ist keine theoretische Spekulation; er ergibt sich logisch aus der Art und Weise, wie Blob-Daten heute bereits auf Ethereum-Nodes verarbeitet werden.

Nennen wir es beim Namen: Es ist ein Eingeständnis, dass die aktuelle Architektur nicht für die heutige Validator-Skalierung konzipiert wurde. Der Merge stellte Ethereum 2022 von Proof-of-Work auf Proof-of-Stake um. Dencun erweiterte 2024 die Blob-Kapazität. Doch keines der beiden Upgrades ging das grundlegende Datenübertragungsmodell für Execution-Payloads an. EIP-8142 ist das nächste Puzzleteil -- die Forscher arbeiten rückwärts von der bereits vorhandenen Blob-Infrastruktur und fragen, warum die Execution-Schicht sie nicht nutzt.

Wie Block-in-Blobs in die übergeordnete Ethereum-Roadmap passt

Ethereums Roadmap verläuft auf mehreren parallelen Spuren -- The Surge (Skalierung durch Rollups), The Verge (zustandslose Clients), The Purge (Reduzierung historischer Datenaufblähung) und The Splurge (diverse Verbesserungen). Block-in-Blobs lässt sich nicht eindeutig einer Kategorie zuordnen, teilt aber die DNA sowohl von The Purge als auch von The Verge. Die Reduzierung dessen, was Validatoren herunterladen müssen, ist ein zentrales Verge-Ziel; die Eliminierung redundanter Datenübertragung überschneidet sich mit den Purge-Zielen.

Der Vorschlag knüpft auch an Ethereums langfristige Vision zustandsloser Clients an. Zustandslose Clients würden es Nodes ermöglichen, Blöcke zu verifizieren, ohne den vollständigen Zustand vorzuhalten -- eine massive Reduzierung der Speicheranforderungen. Block-in-Blobs ist ein Schritt in diese Richtung: Validatoren sollten keine Execution-Payloads herunterladen müssen, die sie stattdessen aus Blob-Commitments rekonstruieren oder verifizieren könnten. Die Forscher bauen im Grunde eine Brücke zwischen der heutigen Validator-Architektur und dem schlankeren, modularen Design, auf das Ethereum zusteuert.

Zentrale technische Auswirkungen bei einer möglichen Umsetzung von EIP-8142:

Nichts davon wird garantiert ausgeliefert. Ethereums EIP-Prozess ist bewusst bedächtig -- Vorschläge durchlaufen Forschung, Community-Debatte, Implementierung durch Client-Teams und Tests, bevor sie in die Nähe eines Mainnet-Hard-Forks gelangen. EIP-8142 befindet sich derzeit in der Forschungs- und Entwurfsphase, was bedeutet, dass der Weg vom Vorschlag zur Aktivierung lang ist. Die Forscher, die ihn vorantreiben, sind jedoch anerkannte Stimmen in der Ethereum-Entwickler-Community, und die zugrundeliegende Logik ist stichhaltig.

• Validatoren müssen keine vollständigen Execution-Payloads mehr herunterladen -- nur Blob-Daten werden für die Zustandsverifizierung benötigt
• Die Blob-Infrastruktur aus EIP-4844 (Dencun) wird für die Effizienz der Execution-Schicht umgenutzt
• Hardware-Anforderungen für Solo-Staking könnten sich stabilisieren oder sinken, wenn der Bandbreitenbedarf zurückgeht
• Eine zustandslose Client-Architektur wird mit leichteren Validator-Datenmodellen realistischer
• Kein bestätigter Hard-Fork-Zeitplan -- Stand April 2026 noch in früher Forschungsphase

Sollte Ethereum-Halter das wirklich interessieren?

Klare Antwort: Ja -- aber nicht als kurzfristiger Preiskatalysator. EIP-8142 wird diese Woche keine Rallye auslösen. Was es repräsentiert, ist die anhaltende Vitalität und Ambition von Ethereums Forschungs- und Entwicklungskultur. Die Fähigkeit der Foundation, kontinuierlich bedeutsame Upgrades zu liefern -- vom Merge über Dencun bis hin zu dem, was als Nächstes kommt --, ist ein zentraler Bestandteil der Bull-These für ETH-Halter, die jahrelang geduldig auf den versprochenen Weg zur Skalierbarkeit gewartet haben.

Es gibt auch einen Aspekt der Validator-Ökonomie. Niedrigere Hardware- und Bandbreitenanforderungen für Validatoren bedeuten, dass die Hürde für Solo-Staking handhabbar bleibt. Mehr Solo-Staker bedeuten weniger Konzentration der Validator-Macht in grossen Staking-Pools -- was für Ethereums Dezentralisierungsnarrativ wichtig ist, insbesondere da Liquid-Staking-Protokolle wie Lido weiterhin signifikante Anteile am gestakten ETH halten. Ein gesünderes, breiter verteiltes Validator-Set stärkt das langfristige Sicherheitsmodell des Netzwerks.

Die skeptische Lesart: Dies ist ein Forschungsvorschlag, kein ausgeliefertes Feature. Ethereums Entwicklungstempo ist notorisch langsam -- die Philosophie des "schnell vorangehen, ohne etwas kaputtzumachen" bedeutet, dass Vorschläge wie dieser jahrelang in der Schwebe hängen können, bevor ein Konsens erreicht wird. Die Community war geduldig, doch die Kluft zwischen "Forscher untersuchen dies" und "das ist live auf dem Mainnet" bleibt gross. EIP-8142 ist vielversprechend. Es ist nicht unmittelbar bevorstehend.