Ethereum hat das Fusaka-Upgrade am 3. Dezember 2025 aktiviert und die Datenverfügbarkeitskapazität des Netzwerks durch Blob-Parameter-Overrides erhöht, die die Blob-Ziele und -Maxima schrittweise erweitert haben.
Durch zwei nachfolgende Anpassungen wurde das Ziel von 6 Blobs pro Block auf 10 und dann auf 14 angehoben, mit einer maximalen Obergrenze von 21. Das Ziel bestand darin, die Layer-2-Rollup-Kosten zu senken, indem der Durchsatz für Blob-Daten erhöht wurde, den komprimierten Transaktionsbündeln, die Rollups aus Sicherheits- und Endgültigkeitsgründen an Ethereum senden.
Drei Monate nach Beginn der Datenerfassung zeigen die Ergebnisse eine Lücke zwischen Kapazität und Auslastung. Eine MigaLabs-Analyse von über 750.000 Slots seit der Aktivierung von Fusaka zeigt, dass das Netzwerk erreicht nicht die Ziel-Blobanzahl von 14.
Die mittlere Blob-Nutzung ging nach der ersten Parameteranpassung tatsächlich zurück, und Blöcke mit 16 oder mehr Blobs weisen erhöhte Fehlraten auf, was auf eine Verschlechterung der Zuverlässigkeit an den Rändern der neuen Kapazität schließen lässt.
Die Schlussfolgerung des Berichts ist eindeutig: Keine weiteren Erhöhungen des Blob-Parameters, bis sich die Fehlerraten bei hohen Blobs normalisieren und eine Nachfrage nach dem bereits geschaffenen Spielraum entsteht.
Was Fusaka veränderte und wann es geschah
Ethereums Basislinie vor Fusaka, etabliert durch EIP-7691legen Sie das Ziel auf 6 Blobs pro Block fest, maximal 9. Mit dem Fusaka-Upgrade wurden zwei sequentielle Anpassungen der Blob-Parameterüberschreibung eingeführt.
Der wurde erstmals am 9. Dezember aktiviertwodurch das Ziel auf 10 und das Maximum auf 15 angehoben wurde. Die zweite wurde am 7. Januar 2026 aktiviert, wodurch das Ziel auf 14 und das Maximum auf 21 angehoben wurde.
Für diese Änderungen waren keine Hard Forks erforderlich, und der Mechanismus ermöglicht dies Ethereum Kapazität durch Client-Koordination statt durch Upgrades auf Protokollebene bereitzustellen.
Die MigaLabs-Analyse, die reproduzierbare Codes und Methoden veröffentlichte, verfolgte die Blob-Nutzung und die Netzwerkleistung während dieses Übergangs.
Es stellte sich heraus, dass die mittlere Blob-Anzahl pro Block von 6 vor der ersten Überschreibung auf 4 danach sank, obwohl die Kapazität des Netzwerks erweitert wurde. Blöcke mit 16 oder mehr Blobs bleiben äußerst selten und kommen je nach der spezifischen Blob-Anzahl im Beobachtungsfenster jeweils zwischen 165 und 259 Mal vor.
Das Netzwerk verfügt über Headroom, den es nicht nutzt.
Eine Parameterdiskrepanz: Der Zeitleistentext des Berichts beschreibt die erste Überschreibung als Erhöhung des Ziels von 6 auf 12, aber die Ethereum Foundation Die Mainnet-Ankündigung und die Kundendokumentation beschreiben die Anpassung mit 6 zu 10.
Wir nutzen die Die Parameter der Ethereum Foundation als Quelle: 6/9 Grundlinie, 10/15 nach dem ersten Override, 14/21 nach dem zweiten. Dennoch betrachten wir den Datensatz des Berichts für beobachtete Nutzungs- und Fehlerratenmuster als empirisches Rückgrat.
Bei hoher Blob-Anzahl steigen die Miss-Raten
Die Messung der Netzwerkzuverlässigkeit anhand verpasster Slots, also Blöcken, die sich nicht korrekt verbreiten oder bestätigen, zeigt ein klares Muster.
Bei einer geringeren Blob-Anzahl liegt die Basis-Fehlerrate bei etwa 0,5 %. Sobald Blöcke 16 oder mehr Blobs erreichen, steigen die Fehlerraten auf 0,77 % bis 1,79 %. Bei 21 Blobs, der maximalen Kapazität, die im zweiten Override eingeführt wurde, erreicht die Fehlschlagsrate 1,79 %, mehr als das Dreifache der Basislinie.
Die Analyse schlüsselt dies auf die Blob-Anzahl von 10 bis 21 auf und zeigt eine allmähliche Abbaukurve, die sich über das 14-Blob-Ziel hinaus beschleunigt.
Diese Verschlechterung ist wichtig, weil sie auf die Infrastruktur des Netzwerks, wie z Validator-HardwareNetzwerkbandbreite und Attestierungszeitpunkt haben Schwierigkeiten, Blöcke am oberen Ende der Kapazität zu verarbeiten.
Wenn die Nachfrage irgendwann steigt, um das 14-Blob-Ziel zu erreichen oder sich dem 21-Blob-Maximum anzunähern, könnten die erhöhten Fehlschläge zu erheblichen Verzögerungen bei der Endgültigkeit oder einem Reorganisationsrisiko führen. Der Bericht stellt dies als Stabilitätsgrenze dar: Das Netzwerk kann technisch gesehen High-Blob-Blöcke verarbeiten, dies jedoch konsistent und zuverlässig zu tun, bleibt eine offene Frage.
Blob-Ökonomie: Warum die Mindestpreisuntergrenze wichtig ist
Fusaka hat nicht nur die Kapazität erweitert. Außerdem wurden die Blob-Preise durch EIP-7918 geändert, wodurch eine Mindestpreisuntergrenze eingeführt wird, um zu verhindern, dass Blob-Auktionen auf 1 Wei zusammenbrechen.
Vor dieser Änderung, als die Ausführungskosten dominierten und die Blob-Nachfrage niedrig blieb, konnte die Blob-Grundgebühr sinken, bis sie praktisch nicht mehr als Preissignal fungierte. Layer-2-Rollups zahlen Blob-Gebühren, um ihre Transaktionsdaten an Ethereum zu senden, und diese Gebühren sollen die Rechen- und Netzwerkkosten widerspiegeln, die Blobs verursachen.
Wenn die Gebühren auf nahezu Null sinken, wird die wirtschaftliche Rückkopplungsschleife unterbrochen und Rollups verbrauchen Kapazität, ohne dass entsprechende Kosten entstehen. Dies führt dazu, dass das Netzwerk den Überblick über die tatsächliche Nachfrage verliert.
Die Mindestpreisuntergrenze von EIP-7918 verknüpft die Blob-Gebühren mit den Ausführungskosten und stellt so sicher, dass der Preis auch bei schwacher Nachfrage ein aussagekräftiges Signal bleibt.
Dies verhindert das Trittbrettfahrerproblem, bei dem billige Blobs eine verschwenderische Nutzung fördern, und liefert klarere Daten für zukünftige Kapazitätsentscheidungen: Wenn die Blob-Gebühren trotz erhöhter Kapazität hoch bleiben, ist die Nachfrage echt; Wenn sie auf den Boden fallen, besteht Kopffreiheit.
Frühe Daten von Hildobby Düne Das Dashboard, das Ethereum-Blobs verfolgt, zeigt die Blob-Gebühren an haben sich nach Fusaka stabilisiert anstatt die Abwärtsspirale früherer Perioden fortzusetzen.
Die durchschnittliche Blob-Anzahl pro Block bestätigt die Feststellung von MigaLabs, dass die Auslastung nicht angestiegen ist, um die neue Kapazität zu füllen. Blöcke tragen routinemäßig weniger als das 14-Blob-Ziel und die Verteilung bleibt stark in Richtung niedrigerer Zahlen verzerrt.
Was die Daten über die Wirksamkeit verraten
Fusaka gelang es, die technische Kapazität zu erweitern und zu beweisen, dass der Blob-Parameter-Override-Mechanismus funktioniert, ohne dass umstrittene Hard Forks erforderlich sind.
Die Mindestpreisuntergrenze scheint wie vorgesehen zu funktionieren und verhindert, dass Blob-Gebühren wirtschaftlich bedeutungslos werden. Die Auslastung bleibt jedoch hinter der Kapazität zurück, und die Zuverlässigkeit an den Rändern neuer Kapazitäten zeigt messbare Verschlechterungen.
Die Miss-Rate-Kurve deutet darauf hin, dass die aktuelle Infrastruktur von Ethereum die Basislinie vor Fusaka und die 10/15-Parameter der ersten Überschreibung problemlos bewältigen kann, aber über 16 Blobs hinaus anfängt, sich zu belasten.
Dadurch entsteht ein Risikoprofil: Wenn die Layer-2-Aktivität ansteigt und Blöcke regelmäßig in Richtung des 21-Blob-Maximums schiebt, könnte das Netzwerk mit erhöhten Fehlerraten konfrontiert werden, die die Endgültigkeit und den Reorganisationswiderstand gefährden.
Nachfragemuster bieten ein weiteres Signal. Der Rückgang der mittleren Blob-Nutzung nach der ersten Überschreibung trotz erhöhter Kapazität deutet darauf hin, dass Layer-2-Rollups derzeit nicht durch die Blob-Verfügbarkeit eingeschränkt sind.
Entweder ist ihr Transaktionsvolumen nicht ausreichend gewachsen, um mehr Blobs pro Block zu erfordern, oder sie optimieren die Komprimierung und Stapelverarbeitung, um sie an die vorhandene Kapazität anzupassen, anstatt die Nutzung zu erweitern.
Blobscan, ein dedizierter Blob-Explorer, zeigt, dass einzelne Rollups im Laufe der Zeit relativ konsistente Blob-Anzahlen veröffentlichen, anstatt hochzufahren, um neuen Spielraum auszunutzen.
Vor Fusaka bestand die Sorge, dass die begrenzte Blob-Kapazität die Layer-2-Skalierung behindern und die Rollup-Gebühren hoch halten würde, da die Netzwerke um knappe Datenverfügbarkeit konkurrierten. Fusaka hat die Kapazitätsengpässe behoben, aber der Engpass scheint sich verschoben zu haben.
Rollups füllen den verfügbaren Platz nicht aus, was bedeutet, dass entweder die Nachfrage noch nicht eingetroffen ist oder dass andere Faktoren wie Sequenzerökonomie, Benutzeraktivität und Cross-Rollup-Fragmentierung das Wachstum stärker begrenzen als die Blob-Verfügbarkeit.
Was kommt als nächstes?
Die Roadmap von Ethereum umfasst PeerDAS, eine grundlegendere Neugestaltung der Datenverfügbarkeitsstichprobe, die die Blob-Kapazität weiter erweitern und gleichzeitig die Dezentralisierung und Sicherheitseigenschaften verbessern würde.
Die Fusaka-Ergebnisse deuten jedoch darauf hin, dass die Rohkapazität derzeit nicht die verbindliche Einschränkung darstellt.
Das Netzwerk hat Spielraum, um auf die 14/21-Parameter zu wachsen, bevor eine weitere Erweiterung erforderlich ist, und die Zuverlässigkeitskurve bei hohen Blob-Zahlen deutet darauf hin, dass Infrastruktur-Upgrades möglicherweise aufgeholt werden müssen, bevor die Kapazität wieder steigt.
Die Fehlerratendaten liefern eine klare Randbedingung. Wenn Ethereum die Kapazität erhöht, während 16+ Blob-Blöcke immer noch erhöhte Fehlerraten aufweisen, besteht die Gefahr einer systemischen Instabilität, die in Zeiten hoher Nachfrage auftreten könnte.
Der sicherere Weg besteht darin, die Auslastung in Richtung des aktuellen Ziels ansteigen zu lassen, zu überwachen, ob sich die Fehlerraten verbessern, wenn Clients für höhere Blob-Lasten optimieren, und die Parameter erst dann anzupassen, wenn das Netzwerk nachweist, dass es Randfälle zuverlässig verarbeiten kann.
Die Wirksamkeit von Fusaka hängt von der Metrik ab. Die Kapazität wurde erfolgreich erweitert und die Blob-Preise durch die Mindestreserve stabilisiert. Es hat weder zu einer sofortigen Steigerung der Auslastung geführt noch die Zuverlässigkeitsprobleme bei maximaler Kapazität gelöst.
Das Upgrade hat Spielraum für zukünftiges Wachstum geschaffen, aber ob dieses Wachstum zustande kommt, bleibt eine offene Frage, die die Daten noch nicht beantwortet haben.
