Ethereum Fusaka Upgrade: What Happened, What Changed, and Why It Matters

What is Fusaka?

Fusaka is a coordinated Ethereum hard fork that bundles multiple Ethereum Improvement Proposals (EIPs). The goal is straightforward: scale Ethereum’s data availability for rollups (blobs), increase Layer 1 execution capacity without compromising decentralization, and add a few foundational UX and developer improvements.

The biggest theme is “scale safely”: raise ceilings, but add explicit limits and pricing changes so the network stays stable even under stress.

Why Fusaka matters

Ethereum’s roadmap leans rollup-centric. That only works if posting rollup data to Ethereum stays cheap and scalable. Fusaka’s blob work is meant to remove the bottleneck where every node must download and store everything, which becomes unrealistic as blob capacity grows.

At the same time, Ethereum also needs more “real” execution bandwidth on L1. Fusaka pushes that forward, while making sure a single massive transaction can’t monopolize an entire block.

What changed in Fusaka

1) PeerDAS (EIP-7594): scaling blobs without forcing everyone to download everything

PeerDAS (Peer Data Availability Sampling) changes how blob data availability is verified. Instead of requiring each validator/node to download full blob data, participants can sample smaller pieces from peers. The idea is: if enough random samples check out, the network can be confident the full data is available.

Why it matters: this lowers bandwidth pressure on validators and makes it feasible to increase blob throughput over time, which directly supports lower and more stable fees on Layer 2 networks that rely on blobs.

2) Blob-Parameter-Only forks (EIP-7892): safer, smaller adjustments between major upgrades

Fusaka also formalizes a mechanism for “blob-parameter-only” forks. In plain terms, that means the ecosystem can adjust blob targets/max values without bundling everything into a huge, all-or-nothing hard fork.

This matters because blob demand can change quickly. Smaller, focused adjustments are easier to coordinate and test.

3) Blob base-fee bounded by execution costs (EIP-7918): fewer weird fee-market edge cases

Fusaka refines blob fee behavior by tying blob fee dynamics more closely to real execution costs. This is aimed at keeping incentives sane and reducing pathological situations where blob pricing becomes detached from the resources the network is actually spending.

4) Safer L1 scaling: higher default gas target + hard per-transaction cap

Fusaka coordinates clients toward a higher default block gas limit (the commonly cited target is around 60M), which allows more computation per block.

The key safety rail is the per-transaction gas limit cap: 16,777,216 gas (2²⁴). That cap prevents a single transaction (like an extreme contract deployment or specially crafted call) from consuming an entire block and stressing nodes in unpredictable ways.

5) Block propagation guardrail: execution block size cap (EIP-7934)

Gas limits measure computation, but they don’t perfectly bound “bytes on the wire.” Fusaka adds a hard cap on the RLP-encoded execution block size (commonly described as 10 MiB with a reserved margin) to reduce propagation risks and weird “some nodes see it, some don’t” behavior.

6) MODEXP hardening: limits and repricing

Fusaka also includes changes that make the MODEXP precompile harder to abuse. It adds clear upper bounds and reprices the operation so its cost better reflects real compute time. This reduces DoS-style risk and makes it easier to reason about node performance as throughput increases.

7) UX + developer upgrades: proposer lookahead, CLZ opcode, and passkey-friendly cryptography

• Deterministic proposer lookahead (EIP-7917): improves predictability around upcoming proposers and enables future UX ideas like preconfirmations.
• CLZ opcode (EIP-7939): a small EVM improvement that makes certain bit-operations cheaper and cleaner for developers.
• secp256r1 support (EIP-7951): unlocks wallet UX that can better leverage device-native security (think passkeys / hardware-backed signing patterns).

What users, developers, and node operators should do

Regular users

In most cases: nothing. Your ETH doesn’t need to be “upgraded.” Be careful with scams, nobody legitimate will ask for your seed phrase or to “migrate” funds because of Fusaka.

DApp and smart contract developers

• Be aware of the 16.7M per-transaction gas cap if you rely on unusually heavy deployments or single-call workflows.
• If you operate rollups or data-heavy systems, track blob fee behavior and future blob parameter adjustments.
• Explore secp256r1-based flows if you’re building onboarding/passkey-style UX.

Validators and node operators

• Upgrade execution + consensus clients to Fusaka-ready releases.
• Check configuration around blob serving / subscriptions (especially if you run infra for L2s or other dependent systems).
• Monitor bandwidth, disk IO, and block processing times as network parameters evolve.

FAQs

Does Fusaka reduce Ethereum gas fees on Layer 1?

It can help by increasing execution headroom, but L1 fees still depend on demand. The most direct “fee feel” improvement is usually on L2s via better blob scalability.

Will Fusaka affect ETH price?

Nobody can responsibly promise a price outcome from a protocol upgrade. What Fusaka does is improve capacity and efficiency, which can strengthen the network’s fundamentals over time.

What’s next after Fusaka?

Ethereum’s roadmap points to Glamsterdam (2026), with major themes like proposer/builder changes and access-list improvements. Think of Fusaka as an important “make scaling safe” step that sets up the next phase.