EIP-4844 im Jahr 2026: wie Blobs nach Fusaka funktionieren und was sie kosten

Jedes Mal, wenn einRollupeinen Batch von Transaktionen abschließt, muss sein Betreiber auf Ethereum die Daten hinterlegen, mit denen jeder den Zustand dieses Netzwerks rekonstruieren und die Ausführung nachprüfen könnte, also die Abläufe imSequencer. Bis März 2024 wurden diese Daten als Calldata übertragen, also im Datenfeld einer gewöhnlichen Transaktion, und konkurrierten um dasselbe Gas wie jeder Aufruf eines Smart Contracts.EIP-4844, aktiviert mit Dencun am 13. März 2024, schuf dafür eine eigene Ressource: den Blob, einen Datenblock, den das Netzwerk verteilt und für begrenzte Zeit vorhält, mit einem eigenen Gebührenmarkt.

Dieses Design ist zweieinhalb Jahre später unverändert, die Zahlen, mit denen ein Rollup rechnet, jedoch nicht. EIP-4844 legte das Blob-Format und die Preisregel für den Blob-Speicherplatz fest; Pectra verdoppelte im Mai 2025 die Kapazität, und Fusaka änderte im Dezember 2025 die Art, wie die Datenverfügbarkeit geprüft wird, erhöhte die Kapazität auf ein Ziel von 14 Blobs pro Block und führte einen Mindestpreis ein. Eine Kostenkalkulation mit den Parametern von 2024 bildet nicht mehr ab, was ein Betreiber heute zahlt. Das Upgrade vom März 2024 enthielt außerdem acht Vorschläge, die Smart-Contract-Entwickler betreffen; sie werden in unserem Artikel überDencun und seine Änderungen an der EVMerläutert; hier verfolgen wir nur den Blob.

Was ein Blob in EIP-4844 ist und was das Netzwerk speichert

LautSpezifikation von EIP-4844, die den Status Final hat, ist ein Blob ein Vektor aus 4.096 Elementen zu je 32 Bytes, insgesamt 131.072 Bytes, der in einem neuen Transaktionstyp (0x03) übertragen wird. Jedes Element muss ein gültiger Wert im Feld der Kurve BLS12-381 sein, sodass die nutzbare Kapazität davon abhängt, wie der Rollup seine Daten kodiert, und etwas unter der nominalen liegt. Die Transaktion enthält den Blob nicht selbst, sondern einen versionierten Hash, abgeleitet aus seinemKZG-Commitment, und der vollständige Blob wird separat über die Konsensschicht verbreitet.

Diese Trennung erklärt, was ein Smart Contract mit den Daten tun kann. Die EVM liest den Inhalt des Blobs nicht. Ein Contract erhält den versionierten Hash über die Instruktion BLOBHASH (0x49, 3 Gas) und nutzt, wenn er einen bestimmten Wert prüfen muss, das Point-Evaluation-Precompile (Adresse 0x0A, 50.000 Gas), das mit einem KZG-Proof verifiziert, dass das committete Polynom an diesem Punkt diesen Wert annimmt. Mit diesem Mechanismus kann ein Rollup seine Daten mit seiner On-Chain-Logik verknüpfen, etwa bei der Beilegung eines Streitfalls oder der Verifikation eines Proofs, ohne für deren Speicherung im State zu zahlen.

Die Speicherung ist bewusst zeitlich begrenzt. Konsens-Nodes müssen Blobs 4.096 Epochen lang bereitstellen, rund 18 Tage, und dürfen sie danach löschen; die Ausführungsschicht speichert sie überhaupt nicht. Dauerhaft in der Historie bleibt nur das Commitment, mit dem sich wiederhergestellte Daten verifizieren, aber nicht rekonstruieren lassen. Die für den Blob gezahlte Gebühr wird verbrannt und nicht erstattet, wenn die Transaktion fehlschlägt.

Wie der Preis für Blob-Gas festgelegt wird

Jeder Blob verbraucht 131.072 Einheiten Blob-Gas, einen eigenen Zähler, getrennt vomGasder Ausführung. Der Preis dieser Einheit folgt einer ähnlichen Logik wieEIP-1559: Das Protokoll legt ein Ziel an Blobs pro Block fest und führt Buch über den kumulierten Überschuss (excess_blob_gas). Enthalten die Blöcke mehr Blobs als das Ziel, wächst der Überschuss und die Basisgebühr für Blobs steigt exponentiell; enthalten sie weniger, sinkt der Überschuss und die Gebühr fällt. Die Kosten eines Blobs ergeben sich aus seinem Blob-Gas multipliziert mit dieser Basisgebühr.

Die wirtschaftliche Folge ist genau die, mit der der Vorschlag begründet wurde: Der Preis für Rollup-Daten hängt nicht mehr davon ab, wie ausgelastet die Ausführung auf der Basisschicht ist, sondern von der Nachfrage nach Blobs im Verhältnis zum Ziel. Eine Aktivitätsspitze bei Ethereum-Contracts verteuert das Ausführungs-Gas, bewegt die Blob-Gebühr aber nicht von selbst. 2024 lag dieses Ziel bei 3 Blobs pro Block, mit einem Maximum von 6, und genau das hat sich seitdem geändert.

Von 3 auf 14 Blobs pro Block: was Pectra und Fusaka geändert haben

Pectra, aktiviert am 7. Mai 2025 laut demAnkündigung der Ethereum Foundation, enthieltEIP-7691, das das Ziel auf 6 Blobs und das Maximum auf 9 anhob, sowieEIP-7623, das Calldata für Transaktionen verteuerte, die sie überwiegend als Datenträger nutzen: Für sie gilt ein Mindestpreis von 10 Gas pro Null-Byte und 40 pro Nicht-Null-Byte. Transaktionen mit relevanter Ausführung, etwa eine Überweisung oder eine DeFi-Operation, zahlen weiterhin 4 und 16. Ziel war es, die maximale Blockgröße zu begrenzen, um Platz für mehr Blobs zu schaffen, und es drängt alle, die Daten noch als Calldata veröffentlichten, zu Blobs.

Fusaka ging am 3. Dezember 2025 im Mainnet live, mitPeerDAS, das die Prüfung derDatenverfügbarkeitverändert: Jeder Blob wird per Erasure Coding erweitert und in Spalten aufgeteilt, und jeder Node speichert und sampelt nur einen Teil davon, nach den aktuellen Parametern ein Achtel der Daten. Mit diesem Spielraum bei der Bandbreite sah dieFusaka-Ankündigungzwei Forks vor, die nur Blob-Parameter ändern (BPO): Der erste hob Ziel und Maximum am 9. Dezember 2025 auf 10 und 15 an, der zweite am 7. Januar 2026 auf 14 und 21.

Fusaka brachte zwei Regeln, die den Betreiber eines Rollups direkt betreffen. Die erste stammt aus PeerDAS: Wer die Transaktion sendet, berechnet die Cell Proofs jedes Blobs, das Netzwerkformat wechselt auf Version 1 mit diesen Proofs, und die Clients begrenzen jede Transaktion auf 6 Blobs, sodass die Software zur Batch-Veröffentlichung aktualisiert werden musste. Die zweite istEIP-7918: Früher konnte die Gebühr bei einer Nachfrage unter dem Ziel bis auf 1 Wei fallen, und es dauerte über eine Stunde mit nahezu vollen Blöcken, bis sich wieder ein Gleichgewichtspreis einstellte. Jetzt gibt es einen Reservepreis, der an die Basisgebühr der Ausführung gekoppelt ist: Solange die Kosten eines Blobs unter denen von 8.192 Einheiten Ausführungs-Gas liegen, wird der Überschuss nicht mehr abgebaut und die Gebühr sinkt nicht weiter.

Ein Batch von 550.000 Bytes, berechnet mit den Parametern vom November 2026

Nehmen wir einen hypothetischen Rollup, der einen komprimierten Batch von 550.000 Bytes abschließt. Bei nominal 131.072 Bytes pro Blob braucht er fünf Blobs, selbst mit einer Kodierung, die das letzte Byte jedes Elements nicht nutzt, und fünf passen in eine einzige Transaktion, weil das Limit bei sechs liegt. Die Transaktion verbraucht 655.360 Einheiten Blob-Gas, zusätzlich zum Ausführungs-Gas, das jede Transaktion verbraucht.

Für den Preis nehmen wir eine Basisgebühr der Ausführung von 0,5 gwei und eine Blob-Nachfrage unter dem Ziel von 14 an. Mit EIP-7918 liegt die Gebühr pro Blob bei rund 8.192 × 0,5 gwei, also 4.096 gwei, oder darüber, sodass die fünf Blobs mindestens etwa 20.480 gwei kosten. Würde derselbe Batch als Calldata veröffentlicht, käme er mit dem Mindestpreis von EIP-7623 auf 40 Gas pro Nicht-Null-Byte: rund 22 Millionen Einheiten Ausführungs-Gas, beim gleichen Preis etwa 11 Millionen gwei. Keine der beiden Zahlen ist eine beobachtete Gebühr, doch das Verhältnis von mehr als dem Fünfhundertfachen erklärt, warum Calldata im Mainnet kein sinnvoller Weg mehr ist, Batches zu veröffentlichen.

Das Beispiel hat eine zweite Konsequenz, die sich nicht in der Gebühr zeigt. Rund 18 Tage nach der Aufnahme ist das Netzwerk nicht mehr verpflichtet, diese Spalten bereitzustellen, gemäß derNetzwerkspezifikation von Fulu. Will ein Nutzer im März den Zustand des Rollups aus Batches vom Januar rekonstruieren oder muss ein Indexer alte Daten erneut verarbeiten, muss jemand die Blobs archiviert haben: der Betreiber, ein Archivdienst oder der Indexer selbst. Der auf der Chain verbliebene versionierte Hash belegt, dass die wiederhergestellten Daten authentisch sind, stellt aber nichts wieder her, was niemand gespeichert hat.

EIP-4844 hat Rollup-Daten günstiger gemacht, nicht aber ihre Archivierung oder Ausführung

Was EIP-4844 gelöst hat, ist konkret und dauerhaft: Es hat den Preis der Rollup-Daten vom Preis der Ausführung auf Ethereum getrennt und eine Ressource geschaffen, deren Kapazität sich ohne Formatänderung erweitern lässt, wie Pectra und Fusaka gezeigt haben, als sie das Ziel von 3 auf 14 Blobs anhoben, ohne Transaktionstyp oder Commitment-Modell zu ändern. Es war zudem der Vorläufer von PeerDAS: Die damals eingeführten KZG-Commitments sind es, die heute das Sampling von Spalten erlauben, statt ganze Blobs herunterzuladen.

Was es nicht gelöst hat, liegt im übrigen Teil der Rechnung und der Verantwortung. Die Gebühr, die ein Nutzer in einem Layer-2-Netzwerk zahlt, umfasst die Ausführung in diesem Netzwerk, die Häufigkeit und Komprimierung der Batches, die Marge des Sequencers und dessen Subventionspolitik; der Blob ist nur ein Teil davon. Die Archivierung historischer Daten bleibt Aufgabe des Betreibers oder Dritter. Und die Ausführungskapazität der Basisschicht hat sich durch Blobs nicht verändert. Um den Effekt auf einen bestimmten Rollup zu messen, trennt ein aussagekräftiger Vergleich Datenkosten, Ausführungskosten und Betreibermarge für denselben Zeitraum und dieselbe Art von Transaktion.

Das Team von Metlabs entwickelt Anwendungen und Smart Contracts aufEthereum und seinen Layer-2-Netzwerken. Wenn Sie die Datenkosten eines Rollups kalkulieren oder entscheiden, wo Sie die Daten Ihrer Anwendung veröffentlichen,erzählen Sie uns davondas Batch-Volumen und die Archivierungsanforderungen, und wir prüfen gemeinsam mit Ihnen, welcher Teil vom Blob-Markt und welcher von Ihrem Design abhängt.