Fusaka folgt dieses Jahr Pectra-UpgradeDies stellt einen großen Fortschritt in der Skalierungs-Roadmap von Ethereum dar, indem PeerDAS und wichtige Verbesserungen eingeführt werden, die den Blob-Durchsatz, die L1-Leistung und das Benutzererlebnis verbessern.
In diesem Beitrag wird der Testnetz-Aktivierungsplan für die ersten drei Testnetze bekannt gegeben, beginnend mit Holesky als Slot 5.283.840 (1. Oktober 2025, 08:48:00 UTC). Siehe die Aktivierungstabelle Unten finden Sie die vollständige Zeitleiste von Sepolia und Hoodi. Fusaka führt außerdem Blob Parameter Only (BPO)-Forks ein, um den Blob-Durchsatz nach der PeerDAS-Aktivierung sicher zu skalieren. Hierbei handelt es sich um minimale Upgrades, die nur auf die Konfiguration beschränkt sind und das Blob-Ziel/-Maximum und den Anteil der Gebührenaktualisierung anpassen.
Die Fusaka-Testnet-Client-Releases werden aufgelistet unten. Sobald alle drei Testnetze erfolgreich aktualisiert wurden, wird ein Mainnet-Aktivierungsslot ausgewählt.
Gesichtsübersicht
Fusakas Haupt-EIP ist PeerDAS (Peer Data Availability Sampling), das eine erhebliche Skalierung des Blob-Durchsatzes ermöglicht. Das Upgrade umfasst auch Optimierungen auf allen Ausführungs- und Konsensebenen, um die L1-Leistung zu skalieren und die Benutzererfahrung zu verbessern. In diesem Beitrag werden die wichtigsten Verbesserungen beschrieben. Eine umfassendere Übersicht finden Sie unter Anleitung von ethereum.org zum Upgrade.
Skalierungsblobs: PeerDAS
EIP-7594 führt PeerDAS ein, ein neues Netzwerkprotokoll, das es Knoten ermöglicht, die Verfügbarkeit von Blob-Daten durch Stichproben zu überprüfen, anstatt komplette Blobs herunterzuladen. Dies ist ein wichtiger Schritt zur Skalierung des Blob-Durchsatzes bei gleichzeitiger Wahrung der Sicherheit und Dezentralisierung von Ethereum.
Seit dem Dencun-UpgradeDie Layer-2-Nutzung hat erheblich zugenommen und erreicht häufig das aktuelle Limit von 9 Blobs pro Block. PeerDAS ermöglicht es Ethereum, dieses Limit zu erhöhen, ohne Kompromisse bei der Sicherheit einzugehen. Dies geschieht durch die Verwendung von Erasure Coding, um Knoten das Abtasten von Teilen von Blob-Daten zu ermöglichen und gleichzeitig kryptografisch zu gewährleisten, dass die vollständigen Daten im gesamten Netzwerk verfügbar sind. Dies schafft einen Weg zu höheren Blob-Zielen, die in Ethereum dargelegt sind Skalierungs-Roadmap.
Dieser Sampling-Ansatz kommt Layer-2-Rollups direkt zugute, indem er einen höheren Blob-Durchsatz unterstützt, ohne dass die Bandbreitenanforderungen für einzelne Knoten proportional steigen. Da die Blob-Kapazität über die aktuellen Grenzen hinaus skaliert, können die L2-Transaktionsgebühren weiter sinken, während gleichzeitig die Sicherheitsgarantien der Datenverfügbarkeit auf Ethereum L1 gewahrt bleiben.
Um den Blob-Durchsatz nach der Aktivierung von PeerDAS sicher zu steigern, verwendet Ethereum Blob-Parameter-Only (BPO)-Forks. Fusaka sieht zwei geplante BPO-Parameteranpassungen auf Holesky ab dem 7. Oktober 2025 vor, mit ähnlichen Zeitplänen für andere Testnetze. Diese BPOs erhöhen das Blob-Ziel und -Maximum pro Block von 6 bzw. 9 auf 10 und 15 in BPO1 und 14 und 21 in BPO2.
Skala L1
ModExp-Optimierung
EIP-7883 Und EIP-7823 arbeiten zusammen, um die ModExp-Vorkompilierung zu optimieren. EIP-7883 erhöht die Gaskosten, um die Rechenkomplexität genauer widerzuspiegeln, einschließlich der Erhöhung der minimalen Gaskosten und der Verdreifachung der allgemeinen Kostenberechnungen. EIP-7823 legt Obergrenzen für ModExp-Operationen fest. Zusammen stellen diese Änderungen sicher, dass ressourcenintensive kryptografische Vorgänge angemessen bepreist werden und mögliche zukünftige Erhöhungen des Blockgaslimits unterstützt werden.
Obergrenze für Transaktionsgas
EIP-7825 implementiert eine Transaktions-Gas-Limit-Obergrenze auf Protokollebene von 16.777.216 Gas, um zu verhindern, dass einzelne Transaktionen übermäßig viel Block-Gas verbrauchen, und um vor DoS-Angriffen zu schützen. Dies legt den Grundstein für die parallele Transaktionsverarbeitung im EVM.
Optimierung des Netzwerkprotokolls
EIP-7642 führt eth/69 ein, das Pre-Merge-Felder und den Empfangs-Bloom aus dem Netzwerkprotokoll entfernt. Diese Bereinigung reduziert den Bedarf an Synchronisierungsbandbreite, fügt ein explizites Verlaufsbereitstellungsfenster für Knoten zum Ankündigen hinzu und vereinfacht die Codebasis durch Entfernen von Legacy-Komponenten, die nach der Zusammenführung nicht mehr benötigt werden.
Erhöhung des Gaslimits
EIP-7935 erhöht das standardmäßige Gaslimit von Ethereum auf 60 MM und spiegelt das Gaslimit wider, auf das die Kernentwickler glauben, dass Ethereum L1 sicher skaliert werden kann. Diese Erhöhung ermöglicht mehr L1-Ausführungskapazität und wurde über verschiedene Client-Kombinationen hinweg gründlich getestet, um Netzwerkstabilität und -sicherheit zu gewährleisten.
Über diese Leistungsverbesserungen hinaus verbessert Fusaka auch die Benutzer- und Entwicklererfahrung durch mehrere gezielte Upgrades.
Verbessern Sie UX
secp256r1 Vorkompilieren
EIP-7951 Fügt durch einen neuen vorkompilierten Vertrag native Unterstützung für die elliptische Kurve secp256r1 hinzu. Dies ermöglicht die direkte Integration mit moderner sicherer Hardware wie Apple Secure Enclave, Android Keystore und FIDO2/WebAuthn-Geräten und reduziert die Reibung für die Mainstream-Blockchain-Einführung durch vertraute Authentifizierungsabläufe.
Zählen Sie führende Nullen Opcode
EIP-7939 stellt den CLZ-Opcode (Count Leading Zeros) vor, der eine native, gaseffiziente Möglichkeit bietet, grundlegende Bitzähloperationen durchzuführen. Diese Ergänzung unterstützt mathematische Operationen, Komprimierungsalgorithmen und Post-Quanten-Signaturschemata und reduziert gleichzeitig die ZK-Beweiskosten.
Gesichtsspezifikationen
Die vollständige Liste der in Fusaka eingeführten Änderungen finden Sie in EIP-7607. Zu den Kern-EIPs gehören:
Zusätzliche unterstützende EIPs:
Vollständige Spezifikationen für die Ausführungs- und Konsensschichtänderungen sind in den folgenden Versionen verfügbar:
Fusaka führt außerdem Änderungen an der Engine-API ein, die für die Kommunikation zwischen Konsens- und Ausführungsschichtknoten verwendet wird. Diese sind in der angegeben Osaka Datei des Execution-APIs-Repositorys.
Gesichtsschutz
Sicherheitsforscher können daran teilnehmen Audit-Wettbewerb in Fusaka um potenzielle Probleme vor der Mainnet-Bereitstellung zu identifizieren.
Gesichtsaktivierung
Das Fusaka-Netzwerk-Upgrade wird auf den Testnetzen Holesky, Sepolia und Hoodi wie folgt aktiviert:
| Netzwerk | Slot | UTC Time | UNIX-Zeitstempel |
|---|---|---|---|
| Holesky | 5.283.840 | 01.10.2025 08:48:00 | 1759308480 |
| Sepolia | 8.724.480 | 2025-10-14 07:36:00 | 1760427360 |
| Kapuzenpullover | 1.622.016 | 28.10.2025 18:53:12 | 1761677592 |
Wie bereits angekündigtBeachten Sie, dass Fusaka das letzte Netzwerk-Upgrade sein wird, das für Holesky bereitgestellt wird. Es wird kurz nach der Bereitstellung des Upgrades heruntergefahren.
Blob Parameter Only (BPO) Fork-Zeitplan
Nach der Hauptaktivierung von Fusaka wird das Netzwerk Blob-Parameter-Only-Forks implementieren, um den Blob-Durchsatz schrittweise zu erhöhen. BPO1 erhöht das Blob-Ziel und -Maximum pro Block auf 10 bzw. 15. BPO2 erhöht den Zielwert weiter auf 14 und maximal auf 21.
Holesky BPO-Zeitplan
| BPO-Gabel | Epoche | Datum und Uhrzeit (UTC) | Unix-Zeitstempel |
|---|---|---|---|
| BPO1 | 166.400 | 07.10.2025 01:20:00 | 1759800000 |
| BPO2 | 167.936 | 2025-10-13 21:10:24 | 1760389824 |
Cepolia BPO-Zeitplan
| BPO-Gabel | Epoche | Datum und Uhrzeit (UTC) | Unix-Zeitstempel |
|---|---|---|---|
| BPO1 | 274.176 | 21.10.2025 03:26:24 | 1761017184 |
| BPO2 | 275.712 | 27.10.2025 23:16:48 | 1761607008 |
Hoodi BPO-Zeitplan
| BPO-Gabel | Epoche | Datum und Uhrzeit (UTC) | Unix-Zeitstempel |
|---|---|---|---|
| BPO1 | 52.480 | 05.11.2025 18:02:00 | 1762365720 |
| BPO2 | 54.016 | 2025-11-12 13:52:24 | 1762955544 |
Client-Releases
Die folgenden Client-Releases sind für das Fusaka-Upgrade geeignet alle drei Testnetze. Weitere Versionen werden die Unterstützung im Mainnet aktivieren. Sobald diese veröffentlicht sind, wird es eine weitere Ankündigung auf diesem Blog geben.
Konsensschicht: Holesky-, Sepolia- und Hoodi-Veröffentlichungen
Beim Ausführen eines Validators müssen sowohl der Consensus Layer Beacon Node als auch der Validator Client aktualisiert werden.
Ausführungsebene: Holesky-, Sepolia- und Hoodi-Veröffentlichungen
Werkzeuge
FAQ
Wie funktionieren Ethereum-Netzwerk-Upgrades?
Upgrades des Ethereum-Netzwerks erfordern eine ausdrückliche Zustimmung der Knotenbetreiber im Netzwerk. Während sich Client-Entwickler darüber einig sind, welche EIPs in einem Upgrade enthalten sind, sind sie nicht die letztendlichen Entscheidungsträger über dessen Einführung.
Damit das Upgrade in Betrieb genommen werden kann, müssen Validatoren und nicht absteckende Knoten ihre Software manuell aktualisieren, um die eingeführten Protokolländerungen zu unterstützen.
Wenn sie einen Ethereum-Client verwenden, der nicht auf die neueste Version (siehe oben) aktualisiert ist, wird er am Fork-Block von den aktualisierten Peers getrennt, was zu einem Fork im Netzwerk führt. In diesem Szenario bleibt jede Teilmenge der Netzwerkknoten nur mit denjenigen verbunden, die ihren (nicht) aktualisierten Status teilen.
Während die meisten Ethereum-Upgrades unumstritten sind und Fälle, die zu Forks führen, selten sind, ist die Möglichkeit für Knotenbetreiber, zu koordinieren, ob ein Upgrade unterstützt wird oder nicht, ein Schlüsselmerkmal der Governance von Ethereum.
Einen ausführlicheren Überblick über den Governance-Prozess von Ethereum finden Sie unter dieser Vortrag von Tim Beiko.
Muss ich als Ethereum-Mainnet-Benutzer oder ETH-Inhaber etwas tun?
Kurz gesagt, nein.
Diese Ankündigung bezieht sich nur auf Ethereum-Testnetze. Es wird eine weitere Ankündigung zur Aktivierung von Fusaka im Ethereum-Mainnet geben, aber selbst dann wird nicht erwartet, dass Benutzer des Ethereum-Mainnets und ETH-Inhaber Maßnahmen ergreifen müssen.
Was muss ich als nicht absteckender Testnet-Knotenbetreiber tun?
Um mit dem Upgrade in einem dieser Testnetze kompatibel zu sein, aktualisieren Sie die Ausführungs- und Konsensschicht-Clients Ihres Knotens auf die in der obigen Tabelle aufgeführten Versionen.
Was muss ich als Testnet-Staker tun?
Um mit dem Upgrade in einem dieser Testnetze kompatibel zu sein, aktualisieren Sie die Ausführungs- und Konsensschicht-Clients Ihres Knotens auf die in der obigen Tabelle aufgeführten Versionen. Stellen Sie sicher, dass sowohl Ihr Beacon-Knoten als auch Ihr Validator-Client aktualisiert sind.
Was muss ich als Nicht-Testnet-Knotenbetreiber oder Staker tun?
Im Moment nichts. Weitere Ankündigungen zur Aktivierung von Fusaka im Mainnet werden erfolgen.
Was soll ich als Anwendungs- oder Toolentwickler tun?
Überprüfen Sie die in Fusaka enthaltenen EIPs, um festzustellen, ob und wie sie sich auf Ihr Projekt auswirken. Die Einführung von PeerDAS, secp256r1-Unterstützung und dem neuen CLZ-Opcode bieten spannende Möglichkeiten für erweiterte Funktionalität und Leistungsoptimierungen.
Warum „Wut“?
Upgrades auf die Ausführungsschicht folgen Devcon-Städtenamen, und Upgrades auf die Konsensschicht verwenden Sternnamen. „Fusaka“ ist die Kombination aus Fulu, einem Stern im Sternbild Kassiopeia, und Osaka, dem Standort von Devcon V.
