What is Fusaka?
On Dec. 3, 2025, Ethereum will activate the Fusaka upgrade on mainnet, its second major hard fork of the year after Pectra in May.
Rollups now carry the bulk of Ethereum transactions and fee revenue, yet they are still constrained by how much data they can post back to the layer 1 and what it costs.
Fusaka is designed to relieve that pressure. Its headline feature, PeerDAS (peer data availability sampling), lets validators verify rollup blob data without downloading everything, cutting bandwidth and storage requirements while opening the door to much higher data throughput.
At the same time, blob-only parameter (BPO) forks, new gas and block-size limits and history expiry tweaks prepare the chain for repeated capacity increases instead of one-off jumps.
In this article, we will unpack what Fusaka changes, where it sits in the Surge, Verge and Purge roadmap, and what it could mean for users, rollups and the broader Ethereum ecosystem over the next few years.
Did you know? Fusaka’s name comes from two internal upgrade code names, Osaka (Execution Layer) and Fulu (Consensus Layer), merged into “Fusaka.”
From Merge to Fusaka: The roadmap
To see where Fusaka fits, it helps to zoom out.
-
The Merge (2022) shifted Ethereum from proof-of-work to proof-of-stake, cutting energy use by around 99.9%.
-
Shapella (2023) enabled staked Ether (ETH) withdrawals, turning a one-way staking system into a liquid one and attracting more validators.
-
Dencun (March 2024) introduced Ethereum Improvement Proposal (EIP) 4844 “blobs,” a cheaper, temporary data lane for rollups, also known as protodanksharding.
-
Pectra (May 2025) added EIP-7702 account abstraction features and revamped staking parameters like the 2,048-ETH validator cap.
Those upgrades lined up with Vitalik Buterin’s shorthand roadmap: Merge, Surge, Verge, Purge and Splurge. The Surge is about scaling Ethereum through rollups and better data availability, while the Verge and Purge focus on lighter clients and pruning old history.
Fusaka is the first upgrade that pushes on all of those levers at once. It scales data for rollups as part of the Surge and leans into history expiry and lighter sync as part of the Verge and Purge. It also sets a clear target for a modular Ethereum stack aiming for more than 100,000 transactions per second (TPS) when you add up layer-2 throughput on top of L1 settlement.
PeerDAS, blobs and bigger blocks
Fusaka’s core scaling change is EIP-7594, PeerDAS.
Instead of every full node downloading entire blobs of rollup data, PeerDAS splits them into smaller cells and uses sampling and erasure coding so validators fetch only random pieces. If enough pieces are available, the network can be confident that the full data exists.
That reduces per-node bandwidth and storage and sets the stage for an eventual 8x increase in blob capacity over time without forcing home stakers onto data center hardware.
To make that growth more flexible, EIP-7892 introduces Blob Parameter Only (BPO) forks, tiny hard forks that change only three blob-related parameters: target, max and the base fee adjustment factor.
After Fusaka, Ethereum can raise blob capacity in smaller and more frequent steps as L2 demand grows rather than waiting years for a big bang fork.
On the execution side, Fusaka updates gas and block sizing:
-
The effective block gas target is raised from today’s 45 million toward much higher ceilings. EIP-7825 caps the gas a single transaction can use, and EIP-7934 adds a 10 MB Recursive Length Prefix block size limit to reduce denial-of-service risk.
-
EIP-7823 and EIP-7883 reprice and limit the MODEXP precompile so that one heavy cryptographic call cannot stall an entire block.
In plainer language, Fusaka gives Ethereum more room for rollup data and complex transactions while adding guardrails so blocks stay verifiable for regular nodes.
Did you know? Blobs are temporary data packets posted by rollups to Ethereum. They are cheaper than call data and are automatically pruned after about 18 days, so they do not bloat the chain.
UX, security and dev tools
Not everything in Fusaka is about raw capacity. Several EIPs focus on user experience, security and developer ergonomics.
EIP-7917 (deterministic proposer lookahead) makes the proposer schedule for the next epoch fully deterministic and accessible onchain through the beacon root. This matters for based rollups and pre-confirmation schemes that need to know in advance which validator will propose a given block to offer fast and credible soft finality guarantees.
On the user experience (UX) side, EIP-7951 adds a secp256r1 precompile, giving Ethereum native support for P-256 signatures, the curve used by Apple’s Secure Enclave, Android Keystore, Fast Identity Online 2 (FIDO2) and WebAuthn passkeys. This lets wallets rely on device-level biometrics and passkeys rather than seed phrases, bringing layer 1 closer to mainstream fintech login flows.
Developers get EIP-7939, the count…
cointelegraph.com