Ethereum's Fusaka Upgrade: A New Era of Scalability

As Ethereum continues to evolve, the network is gearing up for one of its most significant upgrades yet. The Fusaka upgrade, scheduled to activate on December 3, 2025, represents a critical milestone in Ethereum's scaling roadmap, combining the execution layer upgrade "Osaka" with the consensus layer update named after the Fulu star.

Following just six months after the Pectra upgrade, Fusaka demonstrates Ethereum's accelerated development cadence and commitment to continuous improvement. Fusaka operates primarily under the hood, implementing roughly a dozen Ethereum Improvement Proposals (EIPs) that fundamentally enhance the network's infrastructure, scalability, and efficiency.

The Fusaka upgrade implements improvements across three main areas: scaling blob data for Layer 2s, enhancing Layer 1 capacity, and improving user experience. Here's what's changing:

Scale Blobs: Unleashing Layer 2 Potential

PeerDAS: Share the Load, Multiply the Capacity

EIP-7594 introduces the upgrade's flagship feature: Peer Data Availability Sampling (PeerDAS). This fundamentally changes how Ethereum handles Layer 2 data. Currently, every full node must download and store every blob to ensure data availability. As Layer 2 networks post more data, this becomes unsustainably resource-intensive.

PeerDAS distributes blob data across the network, with each node storing only 1/8th of the total data. Through sophisticated erasure coding, the network can still guarantee availability, any 50% of the data can reconstruct the complete dataset. This enables theoretical 8x scaling for blob throughput while reducing bandwidth and storage requirements for nodes. Lower costs for Layer 2s translate directly to cheaper transactions for users, all while maintaining decentralization through accessible node requirements.

Blob Parameter Only Forks: Scaling at the Speed of Demand

EIP-7892 introduces a revolutionary approach to network upgrades. Instead of waiting months for coordinated hard forks to increase blob capacity, Blob Parameter Only (BPO) forks allow quick, configuration-only adjustments. Client teams can agree to increase blob targets and maximums between major upgrades, with node operators simply updating their configuration to participate.

Blob Fee Market Stability: Preventing the 1 Wei Problem

EIP-7918 fixes a critical flaw in blob pricing. When execution gas costs dominate, the blob fee can spiral down to 1 wei, losing its function as a price signal and potentially allowing spam. The fix establishes a proportional reserve price for each blob. When the reserve exceeds the nominal blob fee, the adjustment algorithm treats blocks as over-target, preventing fees from collapsing and ensuring Layer 2s always pay a meaningful portion of the computational cost they impose on nodes. This creates a more stable, predictable blob fee market that accurately reflects network usage and prevents exploitation.

Scale L1: Raising the Ceiling on Mainnet Capacity

Gas Limit Increase: 33% More Throughput

EIP-7935 coordinates client teams to raise the default gas limit to approximately 60 million, up from 45 million. The gas limit remained frozen at 30 million from the Merge until February 2025, when it increased to 36 million, then 45 million. Fusaka makes consistent scaling a priority. This increase enables more transactions to be processed directly on mainnet.

Transaction Gas Cap: Preventing Single-Transaction Dominance

EIP-7825 introduces a maximum of 16,777,216 (2^24) gas per individual transaction, roughly equivalent to pre-Pectra average block sizes. As block limits increase, without a per-transaction cap, a single transaction could monopolize block validation time, creating DoS vulnerabilities. The chosen limit is large enough for real-world contract deployments and heavy precompile usage, yet small enough to prevent any transaction from becoming a validation bottleneck. This proactive DoS hardening makes future gas limit increases safer.

Block Size Limit: Network Propagation Boundaries

EIP-7934 establishes a 10 MiB ceiling on RLP-encoded execution block size, with a 2 MiB safety margin for consensus layer framing. Very large blocks take longer to propagate across a global network of thousands of nodes, and without limits, blocks could create consensus issues or become DoS vectors. Since the consensus layer gossip already won't forward blocks exceeding approximately 10 MiB, this EIP aligns execution layer behavior, preventing scenarios where some nodes see blocks while others don't.

MODEXP Optimization: Clearing the Gas Limit Roadblock

EIP-7883 and EIP-7823 work together to fix the MODEXP precompile, which has been a major obstacle to gas limit increases. MODEXP handles modular exponentiation for RSA signatures and proof systems, but current gas pricing often underestimates computational costs, allowing a single transaction to consume most of a block's validation time. The fix raises the minimum charge from 200 to 500 gas, removes the one-third discount from EIP-2565, increases costs sharply for long exponents beyond 32 bytes, charges proportionally for large base or modulus values, and sets a maximum input size at 8192 bits. MODEXP now accurately reflects computational costs, removing a critical bottleneck for future gas limit increases while maintaining full functionality for legitimate use cases.

History Expiry: Lighter Node Requirements

EIP-7642 formalizes support for partial history expiry, which execution clients began implementing in July 2025. Clients drop history older than the Merge, significantly reducing disk space requirements for node operators. While not a protocol change, adding this to Fusaka puts it on every client's checklist and enables testing it alongside other upgrade changes.

Improve UX: Better Experiences for Users and Developers

Passkey Integration: Wallet UX Meets 2025

EIP-7951 introduces a precompile for the secp256r1 curve at address 0x100, bringing native support for device-based cryptography. Users can now sign transactions with Face ID, Touch ID, or device PINs through Apple Secure Enclave, Android Keystore, and FIDO2/WebAuthn, making onboarding as simple as creating any other app account. This enables better recovery through multi-factor authentication and recovery flows that match modern expectations, while developers gain drop-in compatibility with existing L2 implementations. The vision is clear: Ethereum wallets that feel like consumer apps, dramatically lowering the barrier to entry for mainstream adoption.

Deterministic Proposer Lookahead: Enabling Preconfirmations

EIP-7917 makes the Beacon Chain aware of block proposers for the next epoch, providing a deterministic view of who will propose future blocks. With advanced knowledge, proposers can offer preconfirmations, binding commitments to include specific transactions in their upcoming block, providing users with faster certainty without waiting for block finalization. This also prevents validators from manipulating proposer schedules, reduces implementation complexity for client teams, and improves validator security by eliminating edge cases.

Count Leading Zeros: Efficient Bit Operations

EIP-7939 adds a single new EVM instruction that counts zero bits at the front of 256-bit values. This common operation in computer science becomes a single, fixed-cost instruction rather than requiring hand-rolled implementations. Finding the first set bit, scanning bytes, or parsing bitfields becomes simpler and cheaper, with the opcode performing on par with basic addition while trimming bytecode and saving gas.

Configuration Visibility: Fork Readiness for All

EIP-7910 introduces the eth_config JSON-RPC method, allowing anyone to query their node's fork configuration. The method returns three snapshots showing current, next, and last fork details including chainId, forkId, activation times, active precompiles, system contracts, and blob schedules. This method prevents misconfiguration issues like those experienced during the Pectra fork on Holesky testnet, helping validators and monitoring tools verify fork readiness when moving from devnets to testnets to mainnet.

Conclusion

The Fusaka upgrade marks an important upgrade in Ethereum’s evolution. By implementing PeerDAS, introducing flexible blob scaling through BPO forks, increasing L1 capacity, and enhancing security, Fusaka addresses some of the most pressing challenges facing the network.

For users, Fusaka means cheaper transactions on L2 networks, faster interactions with dApps, and improved wallet experiences through passkey support. For developers, it provides powerful new tools, predictable scaling, and the infrastructure needed to build the next generation of blockchain applications. For validators and node operators, it reduces hardware requirements while maintaining network security.