Ethereum Fusaka Upgrade Explained: The Complete Guide to PeerDAS, Scaling, Security and UX Improvements

• What Fusaka is: Fusaka is a combined execution layer upgrade "Osaka" and consensus layer upgrade "Fulu". Together they aim to push Ethereum further along its long term roadmap for scaling, security and user experience.
• Main headline: Fusaka delivers PeerDAS, a data availability sampling system for blobs that lets nodes store only a fraction of rollup data while still guaranteeing that the full data exists. This unlocks theoretical blob capacity up to around eight times current levels over time.
• For rollups and L2s: More scalable blob space, a better blob fee market, and the ability to raise blob limits between major forks using blob parameter only (BPO) forks. This is key for long term rollup centric scaling.
• For L1 scaling and security: Fusaka formalizes history expiry, tightens rules around MODEXP, adds a transaction gas cap, introduces an execution block size limit, and coordinates an increase of the default gas limit toward 60 million, all aimed at safe capacity growth.
• For UX and devs: New features like deterministic proposer lookahead, the CLZ (count leading zeros) opcode, and a secp256r1 precompile improve preconfirmations, contract efficiency and passkey style wallet flows that feel like modern mobile apps.
• Who must act: Node operators and validators must upgrade both execution and consensus clients to versions that support Fusaka. Everyday users do not need to move or upgrade their ETH and should be wary of anyone saying otherwise.
• Network impact: Fusaka does not directly cut gas fees on Ethereum mainnet. The primary effect is to make layer 2 rollups cheaper and more scalable over time so that average users migrate there for everyday activity.
• Security mindset: As the protocol grows more complex, operational security for keys becomes more important. Validators, node operators and heavy DeFi users should pair protocol upgrades like Fusaka with solid self custody setups and professional monitoring.

1) What is the Ethereum Fusaka upgrade?

Fusaka is a planned Ethereum network upgrade that comes after Pectra on the official roadmap. The name combines two parts:

• Osaka - the execution layer upgrade that affects the EVM, gas rules and block structure.
• Fulu - the consensus layer upgrade named after a star, which updates the beacon chain and validator logic.

Put together, these changes form the Fusaka hard fork. Like previous milestones such as Berlin, London, the Merge and Dencun, Fusaka requires all mainnet execution and consensus clients to switch to new rules at a predetermined block or slot.

The Ethereum community has been moving toward a rollup centric scaling vision: layer 2 rollups handle most user activity, while Ethereum mainnet acts as a highly secure settlement and data availability layer. Fusaka fits squarely into that vision:

• It makes blob data availability more efficient through PeerDAS.
• It introduces flexible blob scaling using blob parameter only forks.
• It prepares the protocol for higher gas limits and larger blocks while keeping denial of service risks under control.
• It adds small but important UX and developer primitives that make Ethereum feel more like a modern platform and less like a bare metal protocol.

2) PeerDAS and blob scaling: how Fusaka unlocks rollup capacity

The headline feature of Fusaka is PeerDAS, a system that changes how Ethereum nodes handle blob data. Blobs are the special data containers introduced in the Dencun upgrade for rollups to post their transaction data cheaply to mainnet.

Before Fusaka, every full node needed to download and store every blob for a short retention period, even though blobs are not part of the permanent state. As blob throughput grows, this model eventually forces nodes to deal with huge amounts of data, hurting decentralization and increasing hardware requirements.

2.1 What PeerDAS changes

PeerDAS introduces data availability sampling for blob data. Instead of each node carrying every blob, the system:

• Divides blob data into columns and subnets.
• Assigns each full node responsibility for only a subset of the data, such as one eighth of the full blob payloads.
• Uses erasure coding and sampling so that any 50 percent of the data is enough to reconstruct the entire original blob set with extremely high probability.

The result: each node stores and downloads much less blob data, but the network as a whole can prove that the blobs are fully available.

2.2 Why this matters for rollups

Rollups scale Ethereum by posting their compressed transaction data to blobs. The more blob space there is, the more transactions they can pack in, and the lower per user fees on L2. But without PeerDAS, raising blob counts would eventually overload node bandwidth and storage.

PeerDAS lets Ethereum theoretically scale blob throughput up to around eight times while keeping node requirements manageable. At the moment of Fusaka activation, the target number of blobs per block stays the same as post Pectra values, but the protocol now has a path to gradually raise them without breaking decentralization.

3) Blob parameter only forks: scaling blobs between major upgrades

One of the subtle but powerful ideas in Fusaka is the concept of blob parameter only (BPO) forks. These are small, coordinated updates that tune target and maximum blob counts without waiting for a full network upgrade that bundles many EIPs together.

3.1 Why BPO forks exist

Traditional Ethereum hard forks are heavy operations. They usually ship multiple changes at once, require extensive testing, and take months of coordination between client teams, researchers and node operators. This cadence is too slow for the rapidly evolving demand from layer 2s.

Blob parameter only forks solve this by letting client teams:

• Publish new client releases that simply raise blob parameters.
• Coordinate these changes via configuration values, similar to how gas limits are adjusted.
• Repeat the process multiple times between major upgrades, following data from L2 adoption and node health.

3.2 Example schedule

The official documentation gives a sample schedule to illustrate how BPOs might unfold after Fusaka:

• Before Fusaka: target 6 blobs, maximum 9 blobs per block.
• At Fusaka activation: parameters remain the same, PeerDAS groundwork is laid.
• BPO 1 a few weeks later: raise to target 10, maximum 15.
• BPO 2 another few weeks later: raise to target 14, maximum 21.

Each step is deliberately staged to watch for side effects on node bandwidth, latency and client performance.

4) Blob fee market upgrade: base fee bounded by execution costs

Rollups that post data to Ethereum pay for two things:

• The blob fee, which pays for blob space.
• The execution gas needed to verify the commitments and process the transaction on L1.

In some situations, execution gas can dominate those costs. If the blob base fee drifts down near 1 wei while execution gas is high, the blob fee signal gets distorted. EIP 7918, included in Fusaka, tweaks the fee algorithm so that the blob market continues to behave sensibly.

4.1 Proportional reserve under each blob

EIP 7918 introduces a reserve price for blobs that is proportional to the execution costs they impose. When this reserve is higher than the nominal blob base fee, the block is treated as if it were over target for fee adjustment. The algorithm stops pushing the base fee lower and instead allows it to rise with congestion.

This keeps three things in balance:

• The blob fee market stays responsive to network congestion and blob demand.
• Rollups pay a meaningful share of the compute cost they impose on nodes.
• Execution layer fee spikes can no longer strand blob base fees at meaningless values that ignore real resource usage.

5) L1 scaling and security changes in Fusaka

Fusaka is not only about blobs. It also ships a package of execution layer changes that prepare Ethereum for higher throughput and safer growth. Think of these as housekeeping and guardrails for the base chain.

5.1 History expiry and simpler receipts

Ethereum's state and history grow continuously. Node operators already face large storage footprints. In mid 2025, execution clients began supporting partial history expiry, dropping historical data older than the Merge to keep disk usage manageable.

Fusaka does not switch on a new behavior for history expiry inside the fork itself. Instead, it acts as a coordination point, requiring client teams to support history expiry by the time they ship Fusaka compatible versions. This lets implementers test Fusaka alongside history expiry and ensures future upgrades have a predictable baseline.

5.2 MODEXP upper bounds and gas cost changes

The MODEXP precompile is a built in function for modular exponentiation, used in RSA verification and some proof systems. Previously, MODEXP accepted extremely large inputs, which made it difficult to analyze worst case resource use. Fusaka includes two related changes:

• Input limits: EIP 7823 caps each MODEXP input at 8192 bits (1024 bytes). Oversized calls are rejected, gas is burned and no state changes occur. This keeps pathological cases out of blocks.
• Gas repricing: EIP 7883 updates MODEXP pricing so that gas usage better matches real computation cost. It raises minimum charges, removes older discounts and increases cost more sharply for very long exponents or large base and modulus values.

With these guardrails, a single transaction using MODEXP can no longer quietly dominate an entire block's compute budget.

5.3 Transaction gas limit cap

EIP 7825 adds a hard cap of 16,777,216 gas (2²⁴) for any single transaction. This is distinct from the block gas limit, which controls how much work a whole block can contain. The new cap:

• Prevents one giant transaction from consuming as much gas as an entire block at higher limits.
• Makes propagation and validation times easier to model as gas limits rise.
• Still leaves plenty of room for heavy contract deployments and complex DeFi interactions.

For normal users, this cap is far above the gas used by typical transfers or swaps. Only very complex multicalls, mega contract deployments or large batch operations may need to be redesigned into smaller segments.

5.4 Execution block size limit

Gas measures computational work, but it does not directly bound how large a RLP encoded block can be when serialized for network gossip. Very large blocks take longer to transmit between nodes and can be abused as a denial of service vector.

Fusaka aligns the execution layer with consensus layer gossip rules by introducing a block size ceiling of 10 MiB, with a 2 MiB safety margin reserved for consensus data. Clients effectively compute a maximum RLP payload size and reject any execution block that exceeds it.

5.5 Raising the default gas limit to around 60 million

Finally, EIP 7935 coordinates an increase of Ethereum's default gas limit. The gas limit had stayed flat at 30 million since the Merge until modest increases to 36 million and then 45 million. Fusaka sets an expectation that client teams should test and ship a higher default gas limit, targeting roughly 60 million.

This is not a forced change from the protocol itself, but a shared plan: stress test higher load on devnets, ensure new limits are safe in combination with the transaction gas cap and other guardrails, and then ship them in Fusaka ready releases.

6) UX and developer improvements in Fusaka

Alongside headline features and low level security tweaks, Fusaka introduces several small but powerful user experience and developer focused improvements.

6.1 Deterministic proposer lookahead

EIP 7917 lets the beacon chain know in advance which validators will propose blocks in the next epoch. This deterministic proposer lookahead:

• Enables preconfirmations, where users or protocols can agree with upcoming proposers about including specific transactions in their block.
• Simplifies some edge cases around proposer schedule manipulation.
• Makes validator client implementations and monitoring simpler, since they can see further into the schedule.

For everyday users, this is mostly invisible. In the background, it will support new UX patterns where wallets and dapps offer fast, probabilistic inclusion guarantees before transactions land on chain.

6.2 CLZ opcode - count leading zeros

EIP 7939 adds a new EVM opcode known as CLZ (count leading zeros). Since Ethereum represents values as 256 bit integers, CLZ returns how many zero bits are at the beginning of a value. This is a common primitive in hardware instruction sets that enables efficient:

• Bit scans and rank operations.
• Parsing of compressed formats or bitfields.
• Certain cryptographic and numeric tricks that were previously encoded as long bytecode sequences.

With CLZ, compilers like Solidity and Vyper can generate shorter, cheaper bytecode for common patterns, saving gas and simplifying smart contract design.

6.3 secp256r1 precompile for passkey style wallets

One of the most exciting UX changes is a new precompile that supports the secp256r1 (P 256) curve. Many hardware security modules, phone secure enclaves and WebAuthn passkey systems use secp256r1 rather than Ethereum's traditional secp256k1 keys.

The Fusaka precompile:

• Lives at a fixed address and accepts a simple input format already adopted by several L2s.
• Verifies signatures and returns a deterministic output that contracts can use for authentication.
• Includes safety checks around point at infinity and subtle comparison edge cases.

For users, this is the bridge to device native signing and multi factor flows. Wallets built on top of this can lean on:

• Apple Secure Enclave and Android Keystore.
• Hardware tokens and FIDO2 authenticators.
• Passkey backed account abstraction where onboarding feels like logging into a normal app, without visible seed phrases.

7) Impact on validators, full nodes and large operators

Fusaka changes how nodes interact with blob data and slightly shifts hardware and bandwidth expectations. The exact impact depends on whether you run a full node without validators, a solo staking setup or a large validator operation.

7.1 Full nodes without validators

Regular full nodes that do not run validator keys will:

• Subscribe to a small number of blob subnets, for example four out of 128.
• Custody roughly one eighth of the coded blob data.
• See significant reductions in blob disk usage and download bandwidth compared to pre PeerDAS behavior at the same blob target.

As BPO forks raise blob counts, blob traffic will grow again, but from a lower baseline and in a more controlled fashion.

7.2 Solo stakers and home validators

When you run validators, your node has to subscribe to a larger set of subnets and process more blob data in order to:

• Propose blocks that include blobs.
• Gossip blob data to the rest of the network.
• Perform data availability sampling from its peers.

Solo stakers are expected to see:

• Disk and download bandwidth that is still lower than pre Fusaka, thanks to sampling.
• Higher upload bandwidth requirements, especially once block builders send more blobs and BPO forks raise targets. Documentation points to upload bandwidth near or above 100 Mbps for comfortable performance after later BPOs.

7.3 Large validator operators and supernodes

At high validator balances, nodes subscribe to more and more subnets, eventually becoming supernodes that custody all columns. At this level:

• Download bandwidth and disk usage can exceed pre Fusaka values once blob targets are raised multiple times.
• Operators may need to plan for hundreds of gigabytes of blob data and strong symmetric bandwidth.
• These nodes play an important role in healing the network and serving missing data back to peers.

8) What everyday users and L2 users should expect

If you are an everyday Ethereum user who interacts mostly with L2 rollups through a wallet, Fusaka feels different from flashy events like the Merge. There is no new token and no migration step for your ETH.

8.1 No action required for ETH balances

After Fusaka activates, your ETH balance stays exactly the same. You do not need to swap, wrap or "upgrade" your coins. Any message claiming that you must send ETH somewhere to make it Fusaka compatible is almost certainly a scam.

8.2 Fee impact on L1 and L2

Fusaka is not designed to directly make L1 gas fees cheap. Raising the block gas limit may have a modest effect on base fees, but the primary goal is to host more rollup activity rather than to make mainnet itself a low fee environment for every transaction.

The real fee benefit comes from:

• More blob space for rollups due to PeerDAS and BPO forks.
• A better functioning blob fee market that continues to react to congestion.
• Rollups passing blob cost savings on to users through lower L2 gas prices.

8.3 Wallet UX and passkeys

Over time, users can expect new wallet flows built around the secp256r1 precompile and account abstraction patterns. Examples include:

• Signing Ethereum transactions using platform passkeys tied to your phone's secure enclave.
• Recovery flows that feel closer to "sign in with your device" rather than "find a 24 word phrase you wrote two years ago".
• Multi factor setups where a hardware wallet such as Ledger, SafePal, Ellipal, Keystone, OneKey or Ngrave acts as one factor and a passkey acts as another.

9) Fusaka from a smart contract developer perspective

Smart contract developers need to understand how Fusaka can affect deployment strategies, gas usage and UX patterns for their users.

9.1 Transaction size limit and complex DeFi flows

The new 16.7 million gas cap per transaction is the most visible change for advanced DeFi protocols and contracts that rely on large batch operations, multi step arbitrage or heavy cryptographic checks in single transactions.

Developers should:

• Run simulations via eth_call with realistic parameters to see how close they come to the cap.
• Break very large flows into multiple smaller transactions or use batching contracts on L2 where gas limits are different.
• Consider designing contracts so that external callers can process work in chunks rather than in one monolithic call.

9.2 CLZ and MODEXP gas changes in practice

For many contracts, CLZ will simply appear as a new low level primitive that compilers can target when optimizing bit operations. Gas savings will show up automatically in new deployments without manual changes.

Contracts that rely on MODEXP require more careful review:

• Verify that your inputs stay within the new size limits.
• Estimate gas for worst case inputs using updated pricing formulas.
• Expose configuration knobs on chain so that you can adapt to changing gas conditions without redeploying entire systems.

9.3 secp256r1 for account abstraction and passkeys

The secp256r1 precompile is a powerful foundation for smart contract wallets and account abstraction frameworks. With it, developers can:

• Verify signatures produced by WebAuthn compatible devices directly on L1.
• Build wallets where authentication keys live in phone secure enclaves while spending logic lives in smart contracts.
• Implement recovery schemes that combine passkey authentication, time locked guardians and optional hardware wallet approvals.

10) Security, tooling and how to prepare in practice

Protocol upgrades are also moments to review personal and organizational security. Fusaka itself does not change wallet balances, but increased complexity and new UX patterns mean more room for human error and social engineering.

10.1 Node operator and validator checklist

• Follow your client teams and the Ethereum Foundation's protocol announcements for Fusaka ready releases.
• Upgrade both execution and consensus clients before the activation time. Running misconfigured clients can lead to missed attestations or accidental forks.
• Monitor bandwidth, CPU and disk usage before and after Fusaka. PeerDAS will change the profile of blob traffic in subtle ways.
• Test your setup on named testnets where Fusaka activates earlier, and practice handling BPO forks as they arrive.

10.2 Self custody and key management hygiene

With higher ETH prices locked in staking and more of the economy built on L2s, losing access to keys is more painful than ever. Consider:

• Storing long term holdings and withdrawal keys on hardware wallets rather than only browser wallets.
• Keeping backup seed phrases in multiple secure locations, ideally on metal seed plates instead of only paper.
• Using multi device setups where a transaction requires approvals from both a passkey backed account and a hardware wallet.

10.3 Tracking performance, fees and taxes around Fusaka

Fusaka will change fee dynamics and may influence where you prefer to hold assets or stake. Good analytics and tax tooling help you make decisions without drowning in spreadsheets.

• Use a data platform like Nansen to monitor L2 adoption, blob usage and rollup fee trends as PeerDAS and BPO forks roll out.
• Use dedicated crypto tax and portfolio tools to track transactions across mainnet and L2s so that you are ready for local reporting season.

11) FAQ: common questions about the Fusaka upgrade

12) Fusaka preparation checklist by user type

12.1 Everyday users and DeFi participants

• Verify that your main wallet is maintained and will stay up to date with Ethereum forks.
• Ignore any direct messages or websites that ask you to "upgrade" your ETH for Fusaka.
• Explore L2 rollups that benefit from blob scaling if you want lower fees and faster confirmation times.
• Consider moving long term holdings off exchanges into reputable hardware wallets over time.

12.2 DeFi and NFT power users

• Map out which of your favorite protocols run on which L2s and how they plan to benefit from PeerDAS and BPO forks.
• Monitor fee changes pre and post Fusaka using analytics platforms.
• Review any highly complex DeFi strategies that rely on single massive transactions, and test their gas usage relative to the new cap.
• Harden your security by pairing browser wallets with hardware wallets for large positions.

12.3 Smart contract developers

• Update toolchains, clients and libraries to versions that understand Fusaka EIPs.
• Add tests that simulate transactions near the 16.7 million gas cap and ensure your flows either stay below it or gracefully split work.
• Experiment with CLZ and secp256r1 based account abstraction patterns on testnets.
• Document how your contracts behave under higher block gas limits, especially if they involve extensive looping or batch operations.

12.4 Node operators and validators

• Track Fusaka activation timelines for mainnet and testnets through official announcements.
• Upgrade both client types in advance, validate configuration with eth_config style tooling once available, and monitor logs for Fusaka specific messages.
• Budget for extra upload bandwidth after PeerDAS and later BPO forks, especially if you run builders or many validators.
• Review your disaster recovery plan, including how you restore nodes, regenerate slashing protection databases and recover funds using hardware wallets if needed.

13) Official resources and further reading

Fusaka is part of a long term Ethereum roadmap. To dig deeper, combine educational posts like this with primary sources and client documentation. Useful starting points include:

• The official Fusaka page on ethereum.org, which lists included EIPs, expected timelines and FAQs.
• The Fusaka meta EIP and individual EIPs such as 7594 (PeerDAS), 7892 (blob parameter only forks), 7918 (blob fee market), 7823 and 7883 (MODEXP), 7825 (transaction gas cap), 7934 (RLP block size limit), 7935 (gas limit guidance), 7917 (proposer lookahead), 7939 (CLZ) and 7951 (secp256r1 precompile).
• Ethereum Foundation blog posts announcing testnet activations and mainnet fork schedules.
• Client team GitHub releases for your preferred execution and consensus clients.
• Independent analyses and podcasts that compare Fusaka and Pectra with earlier upgrades like Dencun and discuss the longer roadmap toward full data sharding.

As always, the safest way to understand a protocol upgrade is to experiment with small amounts on testnets and L2s first, then scale up once you are confident in both the technology and your own operational processes.