What is the Fusaka upgrade on Ethereum?

Fusaka is the next hard fork coming to the Ethereum blockchain in its never-ending quest to continue scaling, becoming even more secure and improving the privacy options for users. All part of Vitalik’s 2035 vision.

Ethereum hard forks are on a cadence of every ~6/12 months, and the Fusaka upgrade follows the Pectra upgrade in May 2025 which included; improvements to the staking journey with faster deposit processing times and increased per validator staked balance, the introduction of account abstraction with normal accounts operating as smart contracts, and increasing the blob throughout max for more rollup capacity. This itself follows the Dencun upgrade from March 2024 which brought blobs for more efficient rollup data storage and a host of other improvements. You can see the full history of forks here: https://ethereum.org/history/ or here: https://eipsinsight.com/pectra

The name Fusaka follows the standard naming convention which is the combination of:

• Fulu (named after a star): the consensus part of the upgrade
• Osaka (named after a location of an Ethereum conference): the execution part of the upgrade

🛠️What exactly is the upgrade going to do? 🛠️

This upgrade has a whopping 12 EIPs (Ethereum Improvement Proposals) so if a biggie!

The areas of improvement are:

Scaling for rollups

• PeerDAS: This is the headline improvement and builds on the introduction of blobs in Dencun in 2024 to move from the current situation where every full node has to store every blob to ensure that it exists, to instead have a data available sampling (DAS) methodology where each node is only required to store a subset of blobs. This means that full nodes need to store only 1/8th of blobs and keeps node hardware and bandwidth at a minimum whilst also helping with future blob scalability.
• Blob parameter only forks: A core component of Ethereum’s scaling journey is the support of layer 2’s such as Arbitrum and Optimism which act as parallel highways to provide more transaction capacity, all whilst being supported by Ethereum’s security. These L2s provide ‘summary data’ of their activity on Ethereum through blobs, however as their activity (and the number of them) increases this is going to require more blob capacity. So as part of the Fusaka upgrade (but actually to be enabled within the 2 weeks after it) the max and target blob limit will be increased. Initially, one week after Fusaka, from 6 target:9 max to 10:15, and then the week after that to 14:21. This is being referred to as the BPO fork/schedule (Blob Parameter Only fork)
• Blob base-fee bounded by execution costs: When a layer 2 posts blob data onto the Ethereum mainnet they pay two fees; the blob fee and the execution gas to verify the blobs. The blob fee is dynamic so that if there’s more demand than space, the price increases and if there’s latent capacity then the blob fee can decrease. However to ensure that it can more accurately respond to changing demands, the idea is to increase a ‘reserve price’ so that the blob space doesn’t get too cheap (in times of low usage) and then struggle to quickly balance back to ‘normal prices’ if things get busy — since the blob price increase is set to an incremental increase and can get stuck too low for too long. If you want a GREAT analogy for this then I would recommend reading this: https://notes.ethereum.org/@anderselowsson/AIG

Scaling for the Ethereum L1

• MODEXP gas cost increase and upper bound cap: MODEXP is a function that calculates the modular exponential, some clever maths that is used in signature verification and proof systems to ensure that transactions are valid on chain. It’s a pretty hefty function and in Fusaka there’s an improvement to ensure that the gas cost matches the computation lift, since often the gas pricing is underestimated and then one transaction using MODEXP can take up the majority of a block’s processing capacity. This gas cost increase for MODEXP function use should make it safer for the overall gas limit to be futher increased in the future. In addition to the gas cost increase, there’s also an EIP which sets an upper bound on the values that can be computed using the function since super large numbers make it hard to test, easy to abuse and risk for client stability.
• New default gas limit: In line with the February 2025 gas limit increase from 30m to 36m and then later to 45m, this EIP requests client teams to test higher gas limits (towards 60m) and then implement the consensus chosen new limit by Fusaka. This increase will allow more space in the blocks for transactions so improves scalability on the base chain.
• Transaction gas limit cap: Another improvement coming which should make it harder for people to spam the chain is adding a cap of 16,777,216 (2²⁴) gas per transaction. This is a chunky amount of gas and should comfortably cover even the most legitimate compute intensive function or complex transaction.
• RLP execution block size limit: In line with the above is a new ceiling of 10MiB (with 2MiB in this saved for consensus data) for a block’s size. This is already the case on the consensus layer so this work is to bring parity to the execution layer. It’s to ensure that blocks can always be propagated and verified across the network, since very large blocks take longer to spread and verify and could create consensus issues.

Then one item which isn’t necessarily a hard fork implementation but included in as more of an FYI, is ‘history expiry’. This is the new requirement for execution clients to prune history before the Merge (when Ethereum changes from proof-of-work to proof-of-stake) in order to reduce storage requirements (and therefore costs) for nodes. Some execution clients started trialing this in July of this year, but it will be a requirement after the Fusaka upgrade.

User experience improvements

• Show the next proposer: Currently you only know what validator will propose the current block and who has created the previous blocks. However this EIP will show who the next proposer is. It’s a step towards preconfirmations — being able to set commitments that transaction will be included in a future block.
• Counting leading zeros: Many values in the EVM are represented as 256bit numbers and this new opcode will help count the leading zeros for more efficient arithmetic processes. This can be an easy error prone count (after all 15 leading zeros and 14 look very similar) so this nifty maths improvement should help wallets and services be more precise.
• New signature checker: To prove that you have ownership of an account (specifically the private key associated with it) you need to sign the transaction. In this EIP there’s a new passkey-style signature checker which will allow developers to use Apple Secure Enclave, Android Keystore, HSMs and FIDO2/WebAuthn directly rather than needing to work directly with the private key. This should make the user experience feel more like traditional onboarding flows; MFA etc. It’s also something that many of the L2s already do so helps bring compatibility to the L1 and a more consistent user experience across rollups and the base chain.

And finally,

• Eth_config: a new RPC method which allows you to ask your node what fork configuration you have. It will tell you what you’re running now, what you have run and what will be needed next so that you can ensure you’re going to be compatible with any upcoming forks. This is a ‘lessons learnt’ improvement following the challenges on Holesky for the Pectra upgrade when a minor misconfig across nodes led to a total testnet chain disaster and the eventual deprecation of Holesky (RIP).

⚡What will the impact be for users? ⚡

These EIPs are mainly focussed on scalability. PeerDAS should reduce the hardware requirements for full nodes, enabling them to run their infrastructure for less and possibly encouraging more network participants to keep their copy of the chain and be a broadcast route for transactions. It should also help reduce layer 2 fees since blob storage costs are reduced. The improvements around MODEXP and the transaction gas limit cap should reduce the risk of chain bloat/DoS attacks going forward, and the UX improvements are focussed on improving visibility; whether that’s at the validator or maths compute level.

⏱️When is the upgrade coming? ⏱️

Earlier this month, developers voted to ship the upgrade on December 3rd 2025 with testnet rollouts happening on Holesky (October 1st), Sepolia (October 14th), Hoodi (October 28th) and hitting mainnet on December 3rd. There will be simulations of the blob parameter only (BPO) forks through each testnet with the final BPO slated to go line on mainnet on 7th January 2026.

However the course of protocol upgrades rarely runs smoothly, and especially so close to the end of the year, so let’s see if Fusaka manages to squeeze into 2025 or if it becomes a new year’s gift.

Originally published at https://www.linkedin.com.