Ethereum EIP-4844 – Blob-Transaktionen und günstigere Rollups

Wer verstehen will, warum viele Ethereum-Layer-2s nach dem Dencun-Upgrade günstiger wurden, landet schnell bei EIP-4844. Der Vorschlag führt Blob-Transaktionen ein: einen neuen Datentyp, der speziell für Rollups gedacht ist, nicht dauerhaft im Ausführungszustand landet und deshalb günstiger bereitgestellt werden kann.

Was ist EIP-4844 und warum war es für Rollups nötig?

EIP-4844 ist eine Skalierungsänderung für Ethereum, die vor allem Rollups entlastet. Der Vorschlag schafft einen separaten, günstigeren Datenpfad für Transaktionsdaten, die zwar veröffentlicht und verifiziert, aber nicht für immer im normalen Ethereum-Zustand gespeichert werden müssen.

Vor EIP-4844 mussten viele Layer-2-Netzwerke ihre komprimierten Transaktionsdaten als Calldata auf Ethereum schreiben. Calldata ist robust und direkt im Ethereum-Kontext verfügbar, aber gerade für Rollups teuer, weil große Datenmengen auf Layer-1 veröffentlicht werden müssen. Das betraf sowohl Optimistic Rollups als auch ZK-Rollups, auch wenn ihre Beweismechanismen unterschiedlich arbeiten.

Die Grundidee hinter Rollups bleibt unverändert: Transaktionen werden außerhalb von Ethereum gebündelt, anschließend werden Zustandsupdates und die dafür nötigen Daten auf Layer-1 verankert. Dieser Datenanker ist zentral, weil Nutzer und Prüfer den korrekten Zustand nur nachvollziehen können, wenn die Eingabedaten zugänglich sind. Genau an dieser Stelle setzt EIP-4844 an, indem es Datenverfügbarkeit günstiger macht, ohne Rollups in eine vollständig neue Architektur zu zwingen.

Anzeige

Technisch wird EIP-4844 oft als Proto-Danksharding bezeichnet. Das „Proto“ ist wichtig: Es handelt sich nicht um das vollständige Danksharding-Zielbild, sondern um einen Zwischenschritt. Ethereum führt damit neue Mechanismen für temporär verfügbare Daten und einen eigenen Gebührenmarkt ein, sammelt operative Erfahrung und verbessert bereits heute die Wirtschaftlichkeit von Rollups.

Für die Einordnung hilft der Vergleich mit optimistischen Rollups und mit Zero-Knowledge-Rollups: Beide brauchen publizierte Daten, damit Ethereum als Sicherheitsanker funktionieren kann. EIP-4844 reduziert also nicht primär Rechenkosten, sondern vor allem die Kosten für Datenverfügbarkeit.

Wie funktionieren Blob-Transaktionen auf Ethereum?

Blob-Transaktionen sind neue Ethereum-Transaktionen, die neben der normalen Ausführungslogik zusätzliche Datenpakete tragen. Diese Blobs sind für die Konsensschicht verfügbar, werden aber nicht wie gewöhnliches Calldata dauerhaft in der EVM gespeichert oder von Smart Contracts direkt ausgelesen.

Ein Blob ist vereinfacht gesagt ein Datencontainer für große Mengen an Rollup-Daten. Statt diese Bytes vollständig in das normale Transaktionsfeld zu schreiben, verweist die Transaktion kryptografisch auf den Inhalt. Dafür nutzt Ethereum sogenannte KZG-Commitments, also kryptografische Bindungen, mit denen nachgewiesen werden kann, dass ein bestimmter Dateninhalt zu einem veröffentlichten Commitment gehört.

Wichtig ist die Trennung zwischen Ausführung und Datenverfügbarkeit. Die EVM verarbeitet weiterhin die eigentliche Transaktion, aber die Blob-Daten selbst liegen außerhalb des normalen Ausführungszustands. Smart Contracts sehen also nicht den Blob-Inhalt direkt wie ein Byte-Array, sondern nur die zugehörigen Commitments und Prüfbezüge. Das verhindert, dass Blobs versehentlich als billiger allgemeiner Datenspeicher missbraucht werden.

Die Daten bleiben nur für einen begrenzten Zeitraum im Netzwerk verfügbar. Für Rollups reicht das aus, weil Prüfer, Sequencer, Prover und andere Netzwerkteilnehmer die Daten in diesem Zeitfenster herunterladen und verarbeiten können. Danach müssen die Daten nicht mehr von jedem vollständigen Ethereum-Knoten dauerhaft vorgehalten werden. Genau diese zeitliche Begrenzung macht den Ansatz effizienter als permanentes Calldata.

Der Ablauf lässt sich in der Praxis so zusammenfassen:

• Ein Rollup bündelt viele Nutzertransaktionen außerhalb von Ethereum zu einem Batch.
• Der Batch wird komprimiert und in einen oder mehrere Blobs verpackt, statt vollständig als Calldata auf Layer-1 zu landen.
• Die Ethereum-Transaktion enthält Commitments auf diese Blob-Daten sowie die Informationen, die für die Verankerung des neuen Zustands nötig sind.
• Validatoren prüfen die Konsistenz der Blob-Bezüge und nehmen die Daten in den Konsensprozess auf.
• Rollup-Knoten und externe Prüfer laden die Daten innerhalb des Verfügbarkeitsfensters herunter, um den Zustandsübergang nachzuvollziehen.
• Nach Ablauf der Frist müssen die Blob-Daten nicht dauerhaft im normalen Ethereum-State gespeichert bleiben.

Damit entsteht ein Datenkanal, der für Rollups sehr nützlich, für allgemeine Smart-Contract-Speicherung aber bewusst eingeschränkt ist. Diese Designentscheidung ist zentral für EIP-4844.

Anzeige

Warum senkt EIP-4844 die Gebühren vieler Layer-2-Netzwerke?

EIP-4844 senkt Layer-2-Gebühren, weil Rollups einen großen Teil ihrer Kosten für die Veröffentlichung von Daten auf Ethereum zahlen. Werden diese Daten günstiger, sinken meist auch die operativen Kosten pro Batch und damit häufig die Endkosten für Nutzertransaktionen.

Rollups bestehen ökonomisch aus mehreren Kostenblöcken: Sequencing, Kompression, gegebenenfalls Proof-Erzeugung und vor allem Layer-1-Datenveröffentlichung. Bei vielen Netzwerken war der teuerste Posten nicht die Ausführung auf Layer-2, sondern das Einstellen der Batch-Daten auf Ethereum. Blob-Transaktionen schaffen dafür nun einen separaten Markt.

Dieser Markt ist wichtig, weil Blob-Gebühren nicht einfach mit normalem Gas identisch sind. Ethereum behandelt Blob-Raum als eigene knappe Ressource mit eigener Preisbildung. Das ähnelt konzeptionell der Trennung, die durch EIP-1559 für den normalen Blockspace populär wurde: Nicht jede Ressource im Netzwerk muss denselben Gebührenpfad haben. Für Rollups ist das ein Vorteil, weil Datenlast und Smart-Contract-Ausführung unterschiedliche Engpässe darstellen.

Die Wirkung ist dennoch nicht absolut. Wenn ein Layer-2-Netzwerk zusätzliche Kosten durch Sequencer-Margen, Bridging, DeFi-Interaktionen oder komplexe Ausführung hat, sinken Endnutzergebühren nicht automatisch im gleichen Verhältnis wie die Blob-Kosten. Auch hohe Nachfrage auf der Rollup-Seite kann günstigere Layer-1-Daten teilweise wieder ausgleichen.

Trotzdem verändert EIP-4844 die Architekturentscheidung vieler Teams. Wer ein Rollup baut, kann Daten nun ökonomisch anders modellieren als früher. Das passt gut zu Entwicklungen wie modularen L2-Stacks oder zu Systemen wie zkEVM-Rollups, bei denen Datenverfügbarkeit eine zentrale Rolle für Sicherheit und Kosten spielt.

Welche Rolle spielen Datenverfügbarkeit und KZG-Commitments?

Datenverfügbarkeit ist der eigentliche Kern von EIP-4844. Ein Rollup ist nur dann vertrauensarm, wenn unabhängige Teilnehmer die zugrunde liegenden Transaktionsdaten tatsächlich erhalten und prüfen können.

Bei Rollups genügt es nicht, bloß einen Endzustand oder einen Beweis zu veröffentlichen. Ohne die Eingabedaten könnten Nutzer nicht rekonstruieren, ob der neue Zustand korrekt aus den Transaktionen hervorgegangen ist. Deshalb ist Datenverfügbarkeit eine Sicherheitsfrage und nicht nur eine Performance-Frage.

KZG-Commitments lösen das Problem, dass Ethereum große Datenmengen nicht vollständig im Ausführungszustand tragen soll, aber dennoch kryptografisch auf genau diese Daten verweisen muss. Ein Commitment bindet an einen bestimmten Blob-Inhalt, ohne diesen Inhalt in jedem Kontext vollständig offenzulegen. Zusätzliche Nachweise erlauben, Konsistenz und Zugehörigkeit mathematisch zu prüfen.

Diese Konstruktion ist besonders nützlich, weil sie Netzwerkknoten entlastet. Statt jedes Byte dauerhaft in der EVM-Welt zu spiegeln, reicht eine kompakte kryptografische Repräsentation plus zeitlich begrenzte Verfügbarkeit. Das ist keine vollständige Datenverfügbarkeits-Sampling-Architektur wie im langfristigen Sharding-Ziel, aber ein klarer Schritt dorthin.

Im modularen Blockchain-Denken ist das gut anschlussfähig. Netzwerke wie modulare Datenverfügbarkeit trennen Ausführung, Settlement und DA bereits konzeptionell stärker. Ethereum bleibt mit EIP-4844 zwar eine integrierte Plattform, übernimmt aber ein ähnliches Prinzip: Nicht jede Information muss gleich behandelt werden, solange Sicherheit und Nachprüfbarkeit erhalten bleiben.

• Für Rollups zählt nicht nur, dass Daten existieren, sondern dass Prüfer sie innerhalb des Verfügbarkeitsfensters abrufen können.
• KZG-Commitments verknüpfen Blob-Inhalte kryptografisch mit der Transaktion, ohne die EVM mit Rohdaten zu überladen.
• Die Trennung von Ausführung und Datenablage reduziert Kosten, ohne den Layer-1-Anker aufzugeben.
• Der Ansatz ist ein Zwischenschritt auf dem Weg zu weitergehender Ethereum-Skalierung, nicht das Endstadium des Shardings.

Was ändert sich für Rollups, Sequencer und Nutzer konkret?

EIP-4844 verändert vor allem die interne Kostenstruktur von Rollups und damit indirekt das Nutzererlebnis. Für Endnutzer bleibt eine Transaktion auf einem Layer-2 meist ähnlich bedienbar, aber das Rollup selbst organisiert Batch-Erstellung und Datenpublikation nun über einen anderen Layer-1-Kanal.

Sequencer, also die Komponenten oder Betreiber, die Transaktionen ordnen und zu Batches bündeln, müssen Blob-Submission in ihre Infrastruktur integrieren. Dabei geht es um Fragen wie Batch-Größe, Timing, Kompression und Gebührenoptimierung. Ein Rollup, das zu häufig kleine Batches schreibt, nutzt Blob-Raum ineffizient; eines mit zu großen Verzögerungen verschlechtert möglicherweise die Nutzererfahrung.

Anzeige

Für Layer-2-Netzwerke entstehen dadurch neue Optimierungspunkte. Auch Fraud-Proof-Systeme bei Optimistic Rollups und Validity-Proof-Systeme bei ZK-Rollups profitieren nur dann sauber, wenn die zugehörigen Zustandsdaten erreichbar bleiben. Die Blob-Architektur ändert also nicht die Sicherheitsannahmen dieser Modelle, sondern deren Kostengerüst.

Für Nutzer ist wichtig: Günstiger bedeutet nicht automatisch sofort finale oder risikofreie Interoperabilität. Bridging, Sequencer-Zentralisierung, Notfallpfade, Auszahlungsfristen und die Abhängigkeit von Daten- und Beweisinfrastruktur bleiben relevant. Wer ein Rollup technisch beurteilen will, sollte deshalb nicht nur auf Gebühren schauen, sondern auch auf Finality, Escape Hatches und den Umgang mit Ausfällen.

Ein konkretes Fallbeispiel: Ein ZK-Rollup bündelt tausende Transfers, erzeugt einen Validity Proof und schreibt die komprimierten Batch-Daten als Blob nach Ethereum. Der kryptografische Beweis bestätigt den Zustandswechsel, aber die Blob-Daten erlauben zusätzlich die unabhängige Rekonstruktion des Inputs. Sinkt der Preis für diese Datenspur, kann das Rollup häufiger oder günstiger posten, ohne sein Sicherheitsmodell aufzugeben.

Ist EIP-4844 nur für ZK-Rollups relevant?

Nein. Sowohl Optimistic Rollups als auch ZK-Rollups profitieren, weil beide Daten nach Ethereum publizieren müssen. Der Unterschied liegt in der Art der Zustandsprüfung, nicht im grundsätzlichen Bedarf an verfügbarer Batch-Historie.

Werden Transaktionen auf Ethereum selbst dadurch billiger?

Nicht zwingend. EIP-4844 zielt primär auf Rollup-Datenkosten und nicht auf allgemeine Layer-1-Gebühren für jede normale EVM-Transaktion. Direkte Ethereum-Nutzer ohne Rollup-Bezug spüren den Effekt daher meist nur indirekt.

Sind Blobs einfach billiger Speicher auf Ethereum?

Nein. Blobs sind absichtlich kein allgemeiner Dauer-Speicher für Anwendungen. Sie sind zeitlich begrenzt, nicht direkt als EVM-Speicher nutzbar und speziell für Datenverfügbarkeit konzipiert.

Welche Grenzen hat EIP-4844 trotz seines Nutzens?

EIP-4844 ist ein wichtiger Schritt, aber keine vollständige Skalierungslösung für Ethereum. Der Vorschlag senkt vor allem Datenkosten für Rollups; er beseitigt weder alle Engpässe von Layer-2s noch ersetzt er spätere Sharding- oder DA-Weiterentwicklungen.

Eine erste Grenze ist die Zeitlichkeit der Daten. Das ist gewollt, kann aber nicht jede Anwendung abdecken. Wer Daten dauerhaft und unmittelbar im Smart-Contract-Kontext braucht, erhält mit Blobs keinen Ersatz für State, Logs oder klassisches Calldata. Damit bleibt die Architektur sehr klar auf Rollup-Bedürfnisse zugeschnitten.

Eine zweite Grenze ist die operative Komplexität. Clients, Rollups und Infrastrukturbetreiber müssen neue Transaktionstypen, Commitments und Gebührenpfade korrekt implementieren. Das erhöht die Systemtiefe von Ethereum. Mehr Tiefe ist nicht automatisch schlecht, verlangt aber mehr Sorgfalt bei Client-Diversität, Testing und Monitoring.

Drittens bleiben Rollups in vielen Fällen noch teilweise zentralisiert, etwa durch einzelne Sequencer oder kontrollierte Upgrade-Rechte. Proto-Danksharding verbessert Kosten und Datenpfade, löst aber Governance- oder Dezentralisierungsfragen einzelner Layer-2-Projekte nicht von selbst. Wer ein Rollup bewertet, muss deshalb Architektur und Betriebsmodell gemeinsam betrachten.

Schließlich ist EIP-4844 nur ein Zwischenschritt im Ethereum-Roadmap-Kontext. Langfristige Themen wie weitergehendes Sharding, bessere Datenverfügbarkeits-Mechanismen, stärkere Prover-Effizienz oder dezentralere Sequencer-Modelle bleiben offen. Trotzdem ist der Schritt strategisch bedeutsam, weil er zeigt, dass Ethereum Skalierung nicht nur über schnellere Ausführung, sondern auch über intelligenteres Ressourcen-Design angeht.

EIP-4844 zeigt, wie Ethereum Rollups gezielt entlasten kann, ohne das Grundmodell der Kette umzubauen. Blob-Transaktionen machen Datenverfügbarkeit günstiger, weil sie temporäre, zweckgebundene Daten anders behandeln als dauerhaften State. Gerade deshalb ist der Vorschlag weniger spektakulär als manche Hype-Erzählung, aber für die praktische Skalierung des Ökosystems technisch äußerst relevant.

Dieser Beitrag dient ausschließlich der technischen und sachlichen Information. Er stellt keine Anlageberatung, Steuer- oder Rechtsberatung dar.

Anzeige