Fusaka: The Ethereum Upgrade Bringing Real-World Scale, Security, and Better UX

---

What is Fusaka? 🦓

Fusaka represents Ethereum's next major evolution after the Pectra upgrade, scheduled for Q4 2025. The name combines two simultaneous upgrades:

• Osaka – the execution layer upgrade
• Fulu – the consensus layer upgrade (named after a star)

Together as Fusaka, these upgrades advance Ethereum toward its long-term vision: scalable Layer 2 (L2) ecosystems, enhanced network security, and significantly improved user and developer experiences.

Think of it this way:

• Pectra introduced blobs for rollups and refined core protocol mechanics
• Fusaka scales those blobs exponentially while hardening the network for mass adoption

The upgrade features a zebra as its mascot 🦓 — the stripes symbolize PeerDAS's column-based data distribution, where nodes maintain specific data "columns" and sample others to verify availability across the network.

---

Key Improvements in Fusaka

Fusaka delivers improvements across three main areas:

1. Scale Blobs (L2 Scaling)

• PeerDAS: Data Availability Sampling that enables up to 8× blob throughput
• Blob-Parameter-Only (BPO) Forks: Flexible blob capacity increases between major upgrades
• Improved Blob Fee Market: Prevents fee market manipulation and ensures meaningful pricing

2. Scale L1 (Mainnet Performance)

• History Expiry: Reduces node storage requirements by dropping old execution history
• MODEXP Safeguards: Input limits and repricing to prevent DoS attacks
• Transaction Gas Limit Cap: Maximum 16.7M gas per transaction for better network health
• Block Size Limits: 10 MiB RLP-encoded block ceiling for predictable propagation
• Coordinated Gas Limit Raise: Target of ~60M gas per block (up from 45M)

3. Improve UX (User & Developer Experience)

• Deterministic Proposer Lookahead: Enables preconfirmations for instant transaction guarantees
• CLZ Opcode: Efficient bit manipulation for developers
• secp256r1 Precompile: Native passkey support using device hardware (Face ID, fingerprint)
• eth_config RPC: Better fork configuration visibility for tools and validators

Let's explore each improvement with practical, real-world context.

---

Scale Blobs: Making L2s Massively More Affordable

PeerDAS: The Headline Feature 🚀

The Problem: Layer 2 rollups currently post their transaction data to Ethereum in blobs — a special data format created specifically for L2s in the Dencun upgrade. Before Fusaka, every full node must download and store every single blob to ensure data availability. As blob usage grows, this becomes unsustainable.

The Solution: Fusaka introduces PeerDAS (Peer Data Availability Sampling) through EIP-7594, fundamentally changing how blob data is distributed:

How It Works:

• Blobs are uniformly distributed across the network as smaller pieces
• Each full node stores only 1/8th of the total blob data
• Nodes sample other pieces from peers to cryptographically verify the complete dataset exists
• Any 50% of the blob data is sufficient to reconstruct the entire dataset
• The probability of missing or corrupted data is cryptographically negligible (~1 in 10²⁰ to 10²⁴)

Theoretical Scale: PeerDAS enables up to 8× blob throughput while keeping hardware requirements reasonable for node operators.

Note: The blob count increases gradually through BPO (Blob-Parameter-Only) forks to ensure network stability. See the average blob count chart showing the progression from Dencun (target: 3) → Pectra (target: 6) → Fusaka and beyond.

Real-world expectation:

• For users: You don’t see PeerDAS directly. What you should see over time is cheaper, more consistent fees on L2s, because Ethereum can safely carry more blob data.
• For node operators:
  • At the same blob target, disk and bandwidth per full node go way down, since each full node stores only ~1/8th of the blob data.
  • As future BPO forks increase blob counts, bandwidth will go back up, but from a much more sustainable baseline.
• For rollups: Massive upside. PeerDAS is what lets them plan for an order-of-magnitude more throughput without overloading Ethereum full nodes.

Further reading:

• EIP: EIP-7594 – PeerDAS
• Talk: Scaling Ethereum Today – PeerDAS (ETHSofia 2024)
• Paper: A Documentation of Ethereum’s PeerDAS

---

Blob-Parameter-Only (BPO) Forks: Adaptive Scaling 📈

The Challenge: Previously, increasing blob capacity required full network hard forks (like Dencun → Pectra). These major upgrades involve extensive testing and coordination, making it slow to respond to L2 demand.

The Innovation: Fusaka introduces Blob-Parameter-Only (BPO) forks via EIP-7892:

• BPO forks only adjust blob parameters (target and max blob counts)
• They contain no other protocol changes
• They are pre-configured in client releases supporting Fusaka
• Client operators can activate them without waiting for major network upgrades

Example schedule:

• Before Fusaka: target = 6, max = 9
• At Fusaka activation: still target = 6, max = 9
• BPO1 (weeks later): target = 10, max = 15
• BPO2 (weeks after that): target = 14, max = 21

Real-world expectation:

• Users / Validators: You do not need to manually update for each BPO event. Just stay current with normal client releases.
• Rollups: Can get more blob capacity on a shorter cadence than full hard forks.
• Node operators: Need to track release notes and network announcements, as each BPO increases bandwidth demands, but still within recommended hardware margins.

---

Blob Fee Market Improvements: Preventing Price Manipulation 💰

The Issue: Layer 2s pay two separate costs when posting data to Ethereum:

1. Blob fee — for data availability
2. Execution gas — for verifying and processing those blobs

When execution gas dominates the cost, the blob fee can spiral down to 1 wei and stop functioning as a meaningful price signal for network congestion.EIP-7918 fixes this by:

• Pinning a proportional reserve price under every blob.
• If the reserve is higher than the nominal blob base fee, the fee adjustment algorithm treats the block as over target and stops pushing the fee down.

This ensures:

• The blob fee market always responds to congestion.
• Rollups always pay at least a meaningful minimum for the compute they impose on nodes.
• L1 execution layer fee spikes can no longer trap blob base fee at 1 wei.

Real-world expectation:

• Rollups: Fees become more predictable and aligned with real resource usage.
• Users: No dramatic “new discount” effect; this is more about stability and preventing pathological underpricing.

---

---

Scale L1: Hardening Ethereum for the Future

History Expiry Support (EIP-7642)

Ethereum state and history grow over time. To keep node requirements sane, client teams have begun implementing partial history expiry—dropping very old execution history (e.g., data older than The Merge).

EIP-7642 doesn’t change behavior at the fork itself; instead, it:

• Formally requires that clients support history expiry by Fusaka.
• Ensures client teams test Fusaka with history expiry enabled.

Real-world expectation:

• Node operators: Reduced disk usage over time, making it easier to run full nodes.
• Developers: Very old execution traces may not be available locally; use archive providers if you need deep historical data.

---

MODEXP Safeguards: Input Size Limits & Gas Repricing

MODEXP is a precompile used for modular exponentiation (critical for RSA verification and some proof systems). Historically it has been hard to model and test safely.

Fusaka introduces two key changes:

1. Input Size Limits (EIP-7823)

EIP-7823 sets clear upper bounds:

• Each MODEXP input number can be at most 8192 bits (1024 bytes).
• Inputs larger than that are rejected: gas is burned, no state changes occur.

This:

• Makes client behavior easier to test and reason about.
• Protects against pathological inputs used for DoS attacks.
• Has no impact on realistic application needs.

2. MODEXP Gas Cost Increase (EIP-7883)

EIP-7883 aligns gas costs with real computation by:

• Raising the minimum cost from 200 → 500 gas.
• Removing the one-third discount introduced in EIP-2565.
• Charging more aggressively as:
  • The exponent length grows beyond 32 bytes.
  • The base or modulus exceeds 32 bytes.

Real-world expectation:

• Contract developers:
  • MODEXP-heavy contracts will pay more accurate (often higher) gas.
  • In return, network operators can safely raise block gas limits without one MODEXP call stalling a whole block.
• Users: If you use apps relying heavily on RSA or certain proofs, expect some gas increase for those specific operations, but better network robustness overall.

---

Transaction Gas Limit Cap (EIP-7825)

EIP-7825 introduces a per-transaction gas cap of:

16,777,216 gas = 2²⁴ gas per transaction

Why that number?

• It’s less than the block gas limit, so one transaction can’t hog an entire block.
• It’s large enough for real-world deployments, heavy precompile usage, and complex contract interactions.
• It’s a power of two, making implementations simpler.

This is preemptive DoS hardening that makes block propagation and validation easier to model as we push block gas limits higher.

Real-world expectation:

• Most contracts: Unaffected; typical transactions already fall well below this number.
• Edge cases: Extremely huge single-call transactions may need to be split into multiple calls or redesigned.

---

RLP Execution Block Size Limit (EIP-7934)

Besides gas, there’s another physical limit: how big a block can be on the wire.

EIP-7934 sets:

• A 10 MiB total block ceiling.
• With a 2 MiB safety margin reserved for consensus data.
• Practically: clients use MAX_BLOCK_SIZE = 10,485,760 bytes and reserve 2,097,152 bytes for beacon-block framing.

Blocks larger than this are simply rejected.

Why? Because overly large blocks:

• Take too long to propagate, causing temporary forks and reorgs.
• Can become a DoS vector by stalling validation.

The consensus layer already refuses to gossip blocks over ~10 MiB, so this aligns execution behavior with consensus.

Real-world expectation:

• Node operators: More predictable bandwidth usage and fewer weird “seen by some, dropped by others” situations.
• Devs: No change to normal contract logic; this is a protocol-level guardrail.

---

Coordinated Default Gas Limit Raise to ~60M (EIP-7935)

Ethereum’s block gas limit sat at 30M from The Merge (2022) until early 2025, then was stepped up to 36M and then 45M.

EIP-7935 is an Informational EIP that:

• Coordinates client teams to test and ship a higher default gas limit (targeting around 60M).
• Stresses devnets at ~60M with full synthetic blocks.
• Recommends pairing this with the transaction gas cap (EIP-7825) so no single transaction dominates.

Research suggests worst-case block-size issues shouldn’t bind below ~150M gas, so 60M is comfortably conservative.

Real-world expectation:

• Users: Over time, a higher block gas limit can translate into more L1 capacity and potentially smoother fee dynamics, especially during moderate load. Don’t expect fees to be slashed overnight, but it’s an important step.
• Validators / Node operators: Slightly higher CPU and bandwidth load, but mitigated by other Fusaka changes (gas caps, MODEXP repricing, block size limits). Hardware recommendations remain broadly similar, but expect more sustained utilization.

---

---

Improve UX: Better Experience for Everyone

Deterministic Proposer Lookahead (EIP-7917)

EIP-7917 makes the Beacon Chain aware of which validators will propose blocks in the next epoch.

Why this matters:

• It enables preconfirmations:
  Users (or apps) can obtain a commitment from a future proposer that their transaction will be included in their block, before the block is actually produced.
• It simplifies some edge cases and reduces room for proposer-schedule manipulation.

Real-world expectation:

• Users: Over time, wallets and dapps can offer instant-ish confirmations backed by future proposers, improving UX especially for high-value transactions.
• Validators: Your duties don’t fundamentally change, but you have more insight into your upcoming roles. Monitoring tools should be updated to use this lookahead.

---

CLZ Opcode: Count Leading Zeros (EIP-7939)

EIP-7939 adds a new EVM instruction: CLZ – count leading zeros in a 256-bit word.

This is a common instruction in many CPU architectures and is useful for:

• Finding the first set bit.
• Parsing bitfields.
• Implementing certain arithmetic tricks efficiently.

Instead of hand-rolled loops, contracts can now do this in one low-cost opcode, benchmarked to be similar in cost to a basic addition.

Real-world expectation:

• Developers:
  • Less boilerplate and lower gas for bit-level operations.
  • Smaller bytecode and easier-to-maintain libraries.
• Users: Marginally lower gas for protocols that do a lot of bit fiddling (e.g., some DeFi or compression-related contracts).

---

secp256r1 Precompile: Passkey-Powered Wallets 🔐

The most user-visible UX improvement comes from EIP-7951, which adds native support for the secp256r1 (P-256) elliptic curve — the cryptographic standard used by:

• Apple Secure Enclave
• Android Keystore
• Many HSMs
• FIDO2 / WebAuthn (passkeys)

Key points:

• Implemented at address 0x0100.
• Uses the same call format many L2s have already adopted (and fixes edge cases), so contracts can often be ported from L2 to L1 with minimal changes.
• Input: 160 bytes; Output: 32 bytes.

Why this matters in practice:

• For users:
  • Wallets can integrate device-native signing and passkeys.
  • No seed phrases, better recovery flows, and login flows that feel like modern apps (Face ID, fingerprint, device PIN + hardware security).
• For developers:
  • Enables account abstraction flows aligned with what billions of devices already support.
  • Simplifies building secure, mainstream-friendly onboarding.

EIP-7951 supersedes the earlier proposal RIP-7212.

Real-world expectation:

• Over the Fusaka → post-Fusaka period, expect more wallets and dapps to roll out passkey-style accounts, particularly where onboarding friction and security are top priorities (payments, gaming, consumer-facing apps).

---

eth_config JSON-RPC Method (EIP-7910)

EIP-7910 adds a eth_config JSON-RPC endpoint so tooling can query what configuration a node is actually running, including:

• chainId and forkId
• Current, next, and last fork settings
• Planned fork activation times
• Active precompiles and their addresses
• System contract dependencies
• Fork blob schedule

This was motivated by a real-world issue: during the Pectra fork on Holesky in early 2025, minor misconfigurations led to a non-finalizing state.

Real-world expectation:

• Client & tooling developers: Easier to monitor, debug, and verify that nodes are aligned for upcoming forks.
• Validators / Node operators: More reliable tools and dashboards; fewer surprises at upgrade time.

---

Frequently Asked Questions (with Practical Takeaways)

Does Fusaka affect all Ethereum nodes and validators?

Yes.

• Both execution clients and consensus clients must be upgraded.
• Client teams will mark Fusaka-ready releases as high priority.

Action item:

• If you run a node or validator, upgrade to a Fusaka-compatible version before the activation block.
• Track releases via client GitHub repos, Discord, EthStaker, and the official Ethereum Foundation blog.

---

Do I need to “convert” my ETH after the Fusaka hard fork?

No.

• Your ETH stays exactly the same. Balances remain unchanged.
• There is no such thing as “Fusaka ETH” that you must swap into.

If anyone tells you to “upgrade” or “convert” your ETH for Fusaka, they are trying to scam you.

Action item:

• Ignore any offers or sites asking you to migrate ETH because of Fusaka.
• Use official channels and trusted wallets only.

---

What’s with the zebras?

Fusaka’s mascot is a zebra.

• The zebra’s stripes represent PeerDAS’s column-based data availability sampling: nodes hold specific “columns” of data and sample others to verify availability.
• It follows the tradition started with the panda mascot for The Merge: each major upgrade gets an informal mascot, often appearing as ASCII art in client logs during the fork.

It’s just for fun — not part of the protocol.

---

What are the main improvements for L2 scaling?

• PeerDAS: unlocks up to an 8× increase in theoretical blob throughput.
• BPO forks: allow gradual, responsive increases to blob capacity over time.
• Blob fee market improvements (EIP-7918): keeps pricing meaningful and aligned with congestion.

Real-world expectation:

• Over the months following Fusaka, as BPO forks increase blob capacity, L2 fees should trend downwards or at least remain low even as usage grows.
• L1 gas fees may be indirectly influenced, but Fusaka is not an L1 gas-fee reduction upgrade.

---

How are BPO forks different from normal hard forks?

• BPO forks only tweak blob parameters (target/max).
• They are preconfigured in Fusaka-supporting client releases.
• You don’t update your clients for each BPO; you just need to be on a recent client version.

Still, it’s good practice to:

• Monitor your clients around major forks and BPO windows.
• Keep software reasonably up-to-date for bug fixes and optimizations.

---

Will Fusaka lower gas fees on Ethereum L1?

Not directly.

• Fusaka’s main fee impact is on L2s, by enabling more blob space.
• That could have some second-order effects on L1 demand (e.g., more activity migrating to L2s), but no significant immediate L1 gas drop is expected solely from Fusaka.

If you want cheaper everyday transactions, the path is: use rollups, whose capacity Fusaka helps scale.

---

As a staker, what do I need to do?

• Upgrade both your EL and CL clients to Fusaka-ready versions.
• Follow the mailing lists and EF Protocol Announcements for exact activation times.
• Test on public testnets where Fusaka activates earlier, to validate your setup and catch misconfigurations.

---

Does Deterministic Proposer Lookahead (EIP-7917) change how my validator works?

Not in any critical way.

• Your validator still proposes and attests as usual.
• You simply gain better visibility into upcoming proposer slots.

You may want to:

• Update monitoring and tooling to take advantage of the new lookahead information.
• Explore opportunities around preconfirmations if you run infrastructure for wallets or apps.

---

How does Fusaka affect bandwidth for nodes and validators?

PeerDAS completely changes how blob data moves across the network.

• Blobs are split into columns across 128 subnets.
• Nodes subscribe only to some subnets and custody a subset of the data.

At Fusaka activation (with the same blob target):

• Full nodes (no validators):

  • Subscribe to 4 subnets.
  • Custody 1/8 of the data.
  • Blob-related bandwidth and disk usage can drop by around 80%, down to just a few MB over time.

• Solo stakers / validator nodes:

  • Subscribe to at least 8 column subnets.
  • Process roughly 2× the data of a non-validating full node, but still less than pre-Fusaka at the same blob target.

As BPO forks gradually raise blob targets and max counts:

• Total network blob bandwidth will increase, but from a much more scalable baseline.
• Current projections keep hardware requirements within recommended margins, even after planned BPOs.

Real-world expectation:

• If you run a node today on recommended hardware, you should remain comfortably within specs post-Fusaka.
• Over time, as blobs grow, expect steadily higher utilization, but not a sudden, unmanageable spike.

---

Putting It All Together

Fusaka isn’t a flashy “everything changes overnight” fork. It’s a structured, safety-conscious upgrade that:

• Makes Ethereum far more scalable for rollups through PeerDAS and BPO forks.
• Hardens the L1 against DoS and worst-case scenarios, paving the way for sustained increases to gas limits and throughput.
• Introduces user-facing UX improvements like passkey support and preconfirmation-enabling features.

In real-world terms:

• Users will increasingly experience Ethereum through fast, cheap L2s — whose capacity Fusaka helps boost.
• Developers gain new primitives (CLZ, P‑256 precompile, clearer configuration) to build smoother, more mainstream apps.
• Node operators and validators get a protocol that scales without silently crushing their hardware under unbounded data and pathological workloads.

As always, the most important operational step is simple: keep your clients up to date, verify configuration via tooling (like the new eth_config), and, if you’re validating, test your setup on the testnets before Mainnet Fusaka goes live.

Ethereum’s roadmap is a multi-step marathon, not a sprint. Fusaka is one of the key steps that makes the next steps even possible.