The Silent Upgrade

Since the early days, an Ethereum upgrade has been something to celebrate. In my Devconnect 2025 talk, I compared it to a musical concert where each song (aka an EIP) is carefully written, composed, and selected. It is rehearsed by client developers, and finally comes the day of the live concert, presented to the world with thousands of viewers. Ethereum upgrades are grand performances - you get the picture.

Byzantium, in 2017, deployed nine Core EIPs, marking Ethereum’s first major network upgrade. It sparked developer interest and captured the community’s attention. By Istanbul in 2019, Ethereum upgrades became more structured, with proposals around cadence planning, EIP selection, and even naming conventions for upgrades. The idea of multiple upgrades in parallel was discussed, but it didn’t gain much traction at the time.

Ever since then, I’ve dreamed of a day with a better process in place when fewer people would be needed for upgrade coordination when the network would enhance performance quietly, without much noise, and the community would learn from the news that it had already happened. Ethereum becomes the invisible underlying technology powering countless applications. In my mind, that would mark the dawn of a new era: another decade of mainstream adoption.

Ethereum has to disappear and that is exactly how it wins!

That day has arrived.

Many of us celebrated Ethereum’s Fusaka upgrade in December 2025. Fusaka’s headliner proposal, PeerDAS, increased blob data availability, enabling Layer 2 networks to become faster and cheaper. To keep the network efficient, parameter tuning may be required from time to time and waiting six months for a full upgrade cycle may not be acceptable, especially for enterprise use cases.

To address this, a complementary feature was introduced, giving Ethereum developers a special superpower: the ability to adjust blob parameters with minimal coordination through Blob Parameters Only (BPO) forks.

Why Blob Parameter Only (BPO) Hardfork matters?

Blob is a temporary data container introduced by EIP-4844 (Proto-Danksharding) with Dencun upgrade to significantly lower transaction costs and improve scalability for Layer 2 (L2) rollups. Blobs hold large amounts of data off-chain, allowing L1<> L2 to interop. Since, this isn't accessible by the Ethereum Virtual Machine (EVM), and stays there for only limited time, making them much cheaper than traditional calldata, which is permanent and costly.

BPO hardforks documented in EIP-7892 are mini hardforks where the only thing that changes is the blob per block count. They provide a mechanism for Ethereum devs to safely scale the chain without the coordination overhead of a full network upgrade.

BPO forks adjusts blob per block capacity without introducing new protocol coordination or complexity.

BPO forks may seem to bring small parameter changes for Layer 2 projects, but it represents a huge shift in how Ethereum ecosystem evolves.

• More blobs per block mean more space for rollups to publish data.
• More data space lowers marginal costs for L2s.
• Lower L2 costs lead to a better user experience at scale.

The L1 protocol remains unchanged, while L2 capacity can be tuned based on real-world demand and performance metrics. Rollups gain more room to settle transactions on Ethereum leading to more enterprise adoption.

BPO1

After being tested and deploying Fusaka on mainnet on December 3, 2025, the first BPO occurred on December 9th, enabling Max Blob capacity to 15 blobs per block. Hundreds of thousands of users were watching closely and yet, the event was uneventful. Everything worked exactly as expected. That, in itself, was a sign of success.

BPO2

About than a month later, BPO2 further increased Target blobs to 14 (from 10) and Max blobs capacity to 21 blobs per block (from 15). It went live on January 7, 2026 again, quietly. No noise, just headlines noting another successful BPO fork. For Layer 2 projects and users, this was a major win: lower costs, better scalability, and room for more features in future Ethereum upgrades.

BPO forks adjusts the blob limits to support more data throughput. This gradual ramp-up allows the network to safely test increased load step-by-step. BPO#2 is the last of the BPO forks that were planned as part of Ethereum’s Fusaka upgrade.

With a goal to continue increasing or adjusting the network's capacity, BPO forks will continue to be used as a tool for ongoing, data-driven scaling. BPO forks mark an important milestone: the beginning of the era of silent upgrades. Kudos, Ethereum!

This story is part of a new series of short Ethereum stories. Let me know how you liked it and what you’d like to explore next as Ethereum’s history continues to unfold. Cheers!