Ethereum's Fusaka Upgrade: Optimizing Blob Parameters Without Hard Forks

Key Takeaways

• Background: The need for more flexible upgrades to Ethereum parameters.
• EIP-7892 (BPO): Introduction of Blob Parameter Only upgrades without full hard forks.
• Blob Importance: The role of Blobs in reducing Layer 2 transaction costs post-Cancun upgrade.
• Target & Max: Explanation of the Target and Max mechanisms in managing Blob fees and network stability.
• Fusaka Roadmap: A phased deployment strategy for increasing Blob capacity through three stages.
• Summary: The impact of BPO on the future of Ethereum scalability.

Ethereum's Fusaka Upgrade: Optimizing Blob Parameters Without Hard Forks

Historically, most modifications to the Ethereum protocol, such as adjusting block rewards or difficulty adjustment algorithms, required a full hard fork. This was a time-consuming process, often taking six months or more, involving an Ethereum Improvement Proposal (EIP), testnet exercises, and coordination among all network nodes. The only exception was the Block Gas Limit, which validators could slightly adjust during block creation. EIP-7892, known as BPO (Blob Parameter Only), extended this flexibility to Blob parameters.

EIP-7892: A Game Changer

BPO allows critical Blob parameters to be modified through a lightweight hard fork that only changes configuration. From a client development perspective, this is akin to a hot parameter update. It enables Ethereum to address scalability issues more efficiently by frequently adjusting Blob parameters via small BPO forks. This capability is crucial because Blobs are a scarce resource, and the number of Blobs that can be included in a block affects Layer 2 transaction costs.

The Role of Blobs in Cost Reduction

Following the Cancun (Dencun) upgrade, most Rollups started using Blobs instead of expensive Calldata to store transaction data. Since Blobs are a scarce resource, their price is determined by supply and demand. When Layer 2 demand exceeds supply, the Blob price increases, leading to higher L2 fees. Therefore, increasing the maximum number of Blobs per block, while maintaining security, is a direct way to lower user costs on Layer 2.

Target & Max: Ensuring Stability

BPO utilizes Target and Max mechanisms to manage Blob capacity. Target represents the ideal load Ethereum aims for. The network dynamically adjusts the base Blob fee based on this target. If actual usage exceeds Target, fees increase to dampen demand. If actual usage is below Target, fees decrease. Max represents the absolute maximum number of Blobs per block, preventing the network from overloading. Key Blob parameters in Ethereum generally follow a pattern where Max = 1.5 × Target.

Fusaka Roadmap: A Phased Approach

The Fusaka upgrade didn't increase full Blob capacity all at once on December 3rd, but followed a phased, three-stage approach: first deploy the technology, then release the capacity.

Stage 1: Fusaka Launch (December 3rd)

Fusaka launched with Target at 6 and Max at 9, unchanged from the previous Pectra version. Fusaka introduced PeerDAS (Data Availability Sampling), a core technology. Although the network was technically capable of handling more data, developers chose not to increase network load initially. This was an observation period to ensure PeerDAS stability under existing traffic.

Stage 2: BPO 1 (Planned for December 9th)

After about a week of stable PeerDAS operation, the first update was implemented via the BPO mechanism. Target was raised from 6 to 10, marking the first significant expansion of Blob capacity during the Fusaka cycle.

Stage 3: BPO 2 (Planned for January 7th, 2026)

After a month of stress testing, a second update was implemented, raising Target to 14 and Max to 21. This step increased capacity by 2.3 times compared to the Fusaka launch. This completed the rollout of the expansion plan.

Summary: The Future of Ethereum Scalability

The introduction of BPO marks a significant milestone. It has ended the old paradigm of waiting for a major hard fork to expand Blobs. Now, Ethereum can expand capacity through a series of small hard forks that only change parameters. This allows Ethereum to more frequently tune throughput based on Layer 2 demand and client capabilities through frequent BPO rollouts, rather than waiting years between major upgrades.