Fusaka ist nun live, und die Debatte hat sich von den erwarteten Auswirkungen zu der Frage verlagert, wie gut es sich bewährt hat. Sieben Monate nach Pectra aktiviert, markierte es den zweiten Hard Fork von Ethereum im Jahr 2025 und die bisher kürzeste Umsetzungszeit zwischen großen Upgrades seit dem Wechsel des Netzwerks zu PoS.

Die Veröffentlichung bestätigte ein verändertes Tempo. Core-Entwickler ersetzten den alten jährlichen Takt durch engere, häufigere Forks, und Fusaka war der Proof of Concept. Hier erfahren Sie, was tatsächlich veröffentlicht wurde, wie das Netzwerk reagiert hat und was dies für ETH im weiteren Verlauf des Jahres 2026 bedeutet. 👇

Was war das Ethereum Fusaka-Upgrade?

Das Ethereum Fusaka-Upgrade war ein koordinierter Hard Fork, der am 3. Dezember 2025 auf dem mainnet live ging. Der Tradition folgend verbindet der Name „Fulu“, einen Stern im Sternbild Kassiopeia, mit „Osaka“, einer früheren Devcon-Gastgeberstadt, und verbindet so die Konsens- und Ausführungsschichten zu einer einzigen Version.

Fusaka konzentrierte sich im Gegensatz zum vorausgegangenen Pectra-Upgrade eher auf Skalierbarkeit als auf benutzerorientierte Funktionen. Die wichtigste Neuerung, PeerDAS (EIP-7594), überarbeitete die Art und Weise, wie Nodes die Existenz von Layer 2-Blob-Daten bestätigen, indem sie nun Fragmente sampeln, anstatt jedes Byte zu speichern. Damit wurde der Grundstein für ein vollständiges Danksharding gelegt.

Der Fork bündelte rund zwölf Ethereum Improvement Proposals, von denen die meisten aus früheren Planungsrunden übernommen wurden, mit dem Schwerpunkt auf der Härtung der Ethereum Virtual Machine und der Datenebene. Zusammen versetzten sie Ethereum in die Lage, schnellere rollups und datenintensive Anwendungen zu unterstützen, ohne die Node-Anforderungen über die Hardware von Endnutzern hinaus zu steigern.

Wichtigste Vorteile von Fusaka

Fusaka priorisierte die Netzwerkintegrität und eine vorhersagbare Skalierung gegenüber herausragenden Funktionen, was die Vorsicht widerspiegelt, die den finalen Umfang prägte. Die Änderungen gestalteten neu, wie Ethereum größere Datenlasten verarbeitet und wie Validatoren die Blockproduktion im gesamten Netzwerk koordinieren.

Zu den wichtigsten Neuerungen, die Fusaka einführte, gehören die folgenden:

• Blob-Sampling (PeerDAS): Reduziert die Bandbreiten- und Speicherlast auf Konsensknoten um rund 85 %, sodass Validatoren die Blob-Verfügbarkeit anhand von Teilstichproben statt vollständiger Downloads überprüfen können.
• Höherer Blob-Durchsatz: Erhöhte die maximale Anzahl von Blobs pro Block durch stufenweise Forks von 9 auf fast 21, wodurch die Layer 2-Kapazität drastisch erweitert und die Kosten für die Veröffentlichung von rollup mit der Zeit gesenkt wurden.
• Größeres L1-gas-Limit: Hob das Standard-Blockgaslimit über EIP-7935 auf 60 Millionen an, wodurch die Basisschicht etwa 20-30 % mehr Spielraum für Transaktionen und komplexe Smart-Contract-Ausführungen erhält.
• Flexible Blob-Skalierung (EIP-7892): Fügte Forks vom Typ „Blob Parameter Only“ hinzu – leichtgewichtige Upgrades, die die Blob-Einstellungen anpassen, ohne dass jedes Mal ein vollständiger Hard Fork erforderlich ist, wenn Entwickler mehr Kapazität wünschen.
• Vorhersehbare Proposer (EIP-7917): Ermöglichte eine deterministische Proposer-Vorschau, sodass Validatoren früher erfahren, wer anstehende Blöcke vorschlägt, was Vorbestätigungen und die Konsensstabilität unterstützt.
• Natives Passkey-Signieren (EIP-7951): Fügte einen secp256r1-Präcompiler hinzu, der gerätenative Signaturen über WebAuthn, FIDO2 und Hardware-Sicherheitsmodule für ein reibungsloseres Onboarding im wallet freischaltet.

Fusaka PeerDAS und die EOF-Entscheidung erklärt

Zwei Komponenten bestimmten den Umfang von Fusaka: PeerDAS, das es als Ankerfunktion in das Release schaffte, und EOF, das die Entwickler letztendlich strichen. Das Verständnis beider Komponenten erklärt, warum das finale Upgrade schlanker ausfiel, als frühere Roadmaps vermuten ließen.

Was ist PeerDAS in Fusaka?

PeerDAS (Peer Data Availability Sampling) ermöglicht es Nodes der Konsensschicht, große Blob-Transaktionen zu bestätigen, indem sie kleine zufällige Stichproben prüfen, anstatt jeden Blob vollständig herunterzuladen. Die Daten werden in 128 Spalten aufgeteilt, die im Netzwerk verteilt sind, sodass jede Node nur einen Bruchteil speichert und gleichzeitig kollektiv die Verfügbarkeit garantiert.

Dieses Design kappte die Verbindung zwischen Blob-Durchsatz und den Hardwarekosten für Validatoren, sodass Ethereum seine Datennapazität skalieren konnte, ohne Maschinen auf Unternehmensebene zu erfordern. Entwickler stuften jedes Feature herab, das das Risiko barg, PeerDAS zu verzögern, da dies die Grundvoraussetzung war, um die zukünftige Nachfrage nach rollup und data availability zu decken, wie in unserem EIP-4844-Erklärer beschrieben.

Warum EOF aus Fusaka entfernt wurde

Das EVM Object Format (EOF) zielte darauf ab, Smart Contracts zu restrukturieren, indem klare Grenzen zwischen Code, Daten und Metadaten gezogen und der bisher unstrukturierte Bytecode ersetzt wurde. Der Plan bündelte rund ein Dutzend koordinierter EIPs zur ersten tiefgehenden Überarbeitung der EVM seit ihrer Einführung.

Core-Entwickler entfernten EOF nach einem Call aller Core-Entwickler im April 2025 aus Fusaka und verwiesen dabei auf ungelöste Komplexität, Zeitplanrisiken und einen Mangel an grobem Konsens. Protokollleiter Tim Beiko bezeichnete die Streichung als Schutzmaßnahme für PeerDAS, sodass die Befürworter von EOF ihr Argument für einen späteren Fork vorbringen müssen, anstatt ihn mit Gewalt durchzusetzen.

Ethereum Fusaka Veröffentlichungszeitplan

Fusaka erreichte das mainnet termingerecht, nachdem im Oktober 2025 drei öffentliche testnets durchlaufen worden waren. Die Einführung wurde daraufhin in zwei reinen Parameter-Forks fortgesetzt, die die Blob-Kapazität in abgemessenen Schritten statt auf einmal skalierten - ein bewusst vorsichtiger Ansatz angesichts der Neuheit der Sampling-Technik.

Die Einführung von Fusaka vollzog sich in den folgenden Meilensteinen:

• Holesky testnet: Aktiviert am 1. Oktober 2025 zur Testung von Basisänderungen, einschließlich der Erhöhung des gas-Limits und der Validator-Leistung unter den neuen Regeln.
• Sepolia testnet: Aktiviert am 14. Oktober 2025 mit Schwerpunkt auf dem PeerDAS-Verhalten und simulierten höheren gas-Limits über Client-Implementierungen hinweg.
• Hoodi testnet: Aktiviert am 28. Oktober 2025 als letzte erlaubnisfreie Validator-Probe vor der Bestätigung der mainnet-Bereitschaft durch die Entwickler.
• Mainnet-Aktivierung: Ging am 3. Dezember 2025 in Epoche 411392 live und schloss bei allen großen Clients innerhalb von rund fünfzehn Minuten sauber ab.
• BPO1-Fork: Aktiviert am 9. Dezember 2025, wodurch das Blob-Ziel auf 10 und das Maximum auf 15 pro Block angehoben wurde.
• BPO2-Fork: Aktiviert am 7. Januar 2026, wodurch das Ziel auf 14 und das Maximum auf 21 angehoben wurde, womit Fusakas Parameterabstimmung abgeschlossen wurde.

Ethereum Fusaka EIP-Liste

Fusakas finales EIP-Set verfolgte drei Ziele: die Skalierung der Layer-2-Datakapazität, die Verbesserung der Layer-1-Ausführungseffizienz und die Verfeinerung der Entwickler- und Validator-Erfahrung. Basierend auf der Mainnet-Ankündigung der Ethereum Foundation und dem Forkcast-Tracking waren dies die Vorschläge, die das Release prägten.

Zu den folgenschwersten Fusaka-EIPs nach Rolle gehören folgende:

• EIP-7594: Führte PeerDAS ein, das Sampling-Protokoll, mit dem Konsensknoten die Blob-Verfügbarkeit ohne vollständige Downloads verifizieren können, das Ankerstück des gesamten Upgrades.
• EIP-7892: Ermöglichte Blob-Parameter-Only-Forks (BPO), die leichte Anpassungen von Blob-Zielen und -Maxima ohne einen vollständig koordinierten Hard Fork erlauben.
• EIP-7935: Legte das standardmäßige Block-gas-Limit auf 60 Millionen fest und standardisierte damit einen Wert über Clients hinweg, den Validatoren bereits vor der Aktivierung zu übernehmen begonnen hatten.
• EIP-7825: Begrenzte das gas pro Transaktion auf etwa 16,7 Millionen (2²⁴), eine DoS-Härtungsmaßnahme, die zudem den Grundstein für parallel execution legt.
• EIP-7918: Begrenzte die Blob-Basisgebühr anhand der Ausführungskosten, wodurch verhindert wird, dass die Blob-Preise auf 1 wei einbrechen, und ein aussagekräftiges Gebührensignal erhalten bleibt.
• EIP-7951: Fügte eine secp256r1-Precompile hinzu, wodurch Signaturen im Passkey-Stil und hardwarebasierte Signaturen günstig on-chain verifiziert werden können.
• EIP-7917: Lieferte deterministisches Proposer Lookahead, sodass rollups und Anwendungen kommende Block-Proposer für ein besseres Sequencing antizipieren können.
• EIP-7939: Fügt den CLZ-Opcode (count leading zeros) hinzu und bietet Entwicklern damit eine günstige native Instruktion für Bit-Ebene-Mathematik und kryptografische Helfer.

Mehrere kleinere Vorschläge rundeten das Paket ab, darunter das ModExp-Repricing-Paar (EIP-7823 und EIP-7883), das RLP-Blockgrößenlimit (EIP-7934) und Netzwerkprotokollverbesserungen (EIP-7642). Diese strafften hauptsächlich die gas-Ökonomie und die Propagationseffizienz, während die Blockkapazität wuchs.

Wie das Netzwerk nach dem Start reagierte

Der echte Test für Fusaka kam nach der Aktivierung, als Live-blob-Nutzung und -Gebührendaten die Prognosen ablösten. Die frühen Signale entsprachen weitgehend den Erwartungen der Entwickler, auch wenn einige Ergebnisse Beobachter überraschten, die in den folgenden Wochen den Ethereum gas-Preis und die blob-Märkte verfolgten.

Die beiden BPO-Forks verdreifachten die maximale blob-Kapazität innerhalb von etwa einem Monat, wodurch rollups wesentlich mehr Raum für das Posten von Batches erhielten. Die Layer 2-Gebühren auf großen Netzwerken blieben bei typischen Transaktionen weit unter einem Cent, und Analysten verwiesen auf weitere Reduzierungen, da die Skalierung der Kapazität in Richtung des langfristigen Ziels von 128 blobs voranschritt.

Ein kontraintuitives Ergebnis stach hervor. Der blob-Gebührenboden von EIP-7918 führte zu einem starken Anstieg der blob-Base-Gebühren von ihren vorherigen Werten nahe Null, da das Posten von Daten nicht mehr effektiv kostenlos war. Die L2-Kosten blieben ungeachtet dessen niedrig, da der Gebührenboden hauptsächlich ein funktionierendes Preissignal wiederherstellte, anstatt blobspace für rollups wirklich teuer zu machen.

Fusaka und ETH: Preisentwicklung seit dem Start

Fusaka aktivierte in einen kurzen Kaufimpuls, wobei ETH am Starttag bei etwa 3.200 USD lag, etwa 4 % im Plus, während der Fork inmitten des Optimismus über Zinssenkungen der Fed und Mehrjahrestiefs bei den Börsenreserven finalisiert wurde. Diese Stärke hielt sich nur bis Anfang Januar, als ETH noch über 3.000 USD verharrte, bevor breitere Bedingungen die Oberhand gewannen.

Der Rückgang vertiefte sich daraufhin. ETH fiel bis Februar 2026 unter 1.800 USD, da Rezessionsängste, Verkäufe von ETH durch Mitgründer Vitalik Buterin und anhaltende spot-ETF-Abflüsse zusammenkamen. Frühlingsrallyes Richtung 2.350 USD im März und 2.100 USD im April wurden jeweils abverkauft, und eine Risk-off-Bewegung im Juni drückte den Preis in die Nähe von 1.570 USD.

Das kumulierte Bild ist nüchtern. ETH notiert Anfang Juli bei rund 1.774 USD, was einem Rückgang von etwa 45 % seit dem Start entspricht, und hat seine ersten drei roten Quartalskerzen in Folge verzeichnet. Fusaka hat wichtige technische Einwände ausgeräumt, und dennoch bewegte sich der Preis in den folgenden sieben Monaten in die entgegengesetzte Richtung.

Dieser Widerspruch verdeutlicht die Frage nach dem Wertzuwachs, die über ETH schwebt. Günstigerer, reichlicherer blockspace hebt die Basisgebührenverbrennung oder die staking-Rendite bei anhaltend schwacher Nachfrage nicht automatisch an, sodass Fusaka eher die Qualität des Netzwerks als dessen Preis verbessert hat. Nichts davon ist eine Finanzberatung, machen Sie also Ihre eigenen Recherchen vor einer Allokation.

Was Fusaka als Nächstes vorbereitet hat

Fusaka war niemals ein Endpunkt. Mit der Auslieferung von PeerDAS und dem BPO-Mechanismus gab es Core-Entwicklern eine wiederholbare Methode zur Skalierung der Datenkapazität sowie ein Fundament für die ehrerizöseren Arbeiten an der Execution-Layer an die Hand, die nun folgen. Die Roadmap nach Fusaka nimmt bereits Gestalt an.

Der unmittelbare Nachfolger ist Glamsterdam, das für die zweite Jahreshälfte 2026 geplant ist und den Schwerpunkt auf die Skalierung von Layer 1 selbst durch verankerte Proposer-Builder-Separation und parallel execution legt. Über den Hard-Fork-Zeitplan hinaus veröffentlichte Vitalik Buterin eine „Lean Ethereum“-Roadmap, die Quantensicherheit, Datenschutz und langfristige Skalierbarkeit bis 2029 abdeckt.

Weitere BPO-Forks zielen darauf ab, die Blob-Anzahl bis Mitte 2026 auf 48 pro Block zu steigern, womit die schrittweise Skalierung fortgeführt wird, die Fusaka ermöglicht hat. Jeder Schritt baut auf dem vorherigen auf und führt Ethereum stetig näher an den Durchsatz heran, den seine Rollup-zentrierte Roadmap seit Langem verspricht.

Fazit

Fusaka hat sein zentrales Versprechen gehalten: Es hat die Datenebene von Ethereum skaliert, ohne die Dezentralisierung zu gefährden, auf die Node-Betreiber angewiesen sind. PeerDAS wurde sauber ausgeliefert, die Blob-Kapazität verdreifachte sich innerhalb weniger Wochen, und das Netzwerk verarbeitete die Änderungen mit minimalen Unterbrechungen.

Die schwierigere Frage lautet, was daraus resultiert. Fusaka gab Ethereum die Infrastruktur an die Hand, um die nächste Welle von Nutzern an Bord zu holen, doch Infrastruktur allein garantiert noch nicht, dass auch Aktivität, Gebühren oder Kurse folgen. Während sich Glamsterdam und die breitere Roadmap für 2026 entfalten, bleibt die Fähigkeit des Netzwerks, technische Leistungsfähigkeit in nachhaltigen Wert umzuwandeln, die Geschichte, die man im Auge behalten sollte.