The upgrades on @ethereum has never stopped. Over the last few months, we have seen a lot of upgrades on Ethereum and all these overhauls are targeted improvements that compound over time.

From the merge to proto-danksharding, Ethereum’s roadmap is no longer about surprise improvements, but about steady execution.

𝘛𝘩𝘢𝘵 𝘱𝘩𝘪𝘭𝘰𝘴𝘰𝘱𝘩𝘺 𝘣𝘦𝘤𝘢𝘮𝘦 𝘷𝘦𝘳𝘺 𝘤𝘭𝘦𝘢𝘳 𝘸𝘪𝘵𝘩 𝘍𝘶𝘴𝘢𝘬𝘢. 𝘈𝘯𝘥 𝘴𝘪𝘯𝘤𝘦 𝘍𝘶𝘴𝘢𝘬𝘢 𝘸𝘦𝘯𝘵 𝘭𝘪𝘷𝘦, 𝘸𝘦’𝘷𝘦 𝘢𝘭𝘳𝘦𝘢𝘥𝘺 𝘴𝘦𝘦𝘯 𝘉𝘗𝘖-1 𝘢𝘤𝘵𝘪𝘷𝘢𝘵𝘦.

Now, Ethereum is moving forward again with BPO-2.
-----------------------------------

𝐅𝐮𝐬𝐚𝐤𝐚 𝐬𝐞𝐭𝐬 𝐭𝐡𝐞 𝐬𝐭𝐚𝐠𝐞

The Fusaka upgrade is best understood as infrastructure, not spectacle.
Its main job was to finalize Ethereum’s post-4844 environment and introduce a new upgrade pattern which is the Blob-Parameter-Only (BPO) forks.

With EIP-4844, Ethereum added blobs, temporary, low-cost data containers designed specifically for rollups.

This shifted most scaling pressure away from L1 execution and toward data availability.

𝘉𝘶𝘵 𝘵𝘩𝘦 𝘪𝘯𝘪𝘵𝘪𝘢𝘭 𝘣𝘭𝘰𝘣 𝘭𝘪𝘮𝘪𝘵𝘴 𝘸𝘦𝘳𝘦 𝘥𝘦𝘭𝘪𝘣𝘦𝘳𝘢𝘵𝘦𝘭𝘺 𝘤𝘰𝘯𝘴𝘦𝘳𝘷𝘢𝘵𝘪𝘷𝘦. 𝘌𝘵𝘩𝘦𝘳𝘦𝘶𝘮 𝘯𝘦𝘦𝘥𝘦𝘥 𝘢 𝘸𝘢𝘺 𝘵𝘰 𝘪𝘯𝘤𝘳𝘦𝘢𝘴𝘦 𝘣𝘭𝘰𝘣 𝘤𝘢𝘱𝘢𝘤𝘪𝘵𝘺 𝘰𝘷𝘦𝘳 𝘵𝘪𝘮𝘦 𝘸𝘪𝘵𝘩𝘰𝘶𝘵 𝘸𝘢𝘪𝘵𝘪𝘯𝘨 𝘧𝘰𝘳 𝘧𝘶𝘭𝘭 𝘩𝘢𝘳𝘥 𝘧𝘰𝘳𝘬𝘴 𝘰𝘳 𝘳𝘪𝘴𝘬𝘪𝘯𝘨 𝘪𝘯𝘴𝘵𝘢𝘣𝘪𝘭𝘪𝘵𝘺.

Fusaka made that possible.
-----------------------------------

𝐖𝐡𝐚𝐭 𝐁𝐏𝐎 𝐟𝐨𝐫𝐤𝐬 𝐚𝐫𝐞 𝐚𝐧𝐝 𝐰𝐡𝐲 𝐭𝐡𝐞𝐲 𝐦𝐚𝐭𝐭𝐞𝐫

A BPO fork changes nothing except blob capacity parameters:

➢ The target number of blobs per block

➢ The maximum number of blobs allowed in a block

The update does not add new opcodes, alter execution behavior, or modify account or state logic

This makes BPO forks low risk, easier to coordinate across clients, and safe to repeat as demand grows
-----------------------------------

𝐁𝐏𝐎-1 𝐰𝐚𝐬 𝐭𝐡𝐞 𝐟𝐢𝐫𝐬𝐭 𝐬𝐢𝐠𝐧𝐚𝐥 𝐚𝐧𝐝 𝐩𝐫𝐨𝐨𝐟 𝐨𝐟 𝐜𝐨𝐧𝐜𝐞𝐩𝐭

It increased blob capacity modestly, giving rollups more room to post data while allowing node operators, client teams, and the broader network to observe real-world effects.

And it worked.

The network absorbed the change cleanly, blob markets behaved as expected, and rollups immediately benefited from higher available process rate.

That success cleared the path for the next step.
-----------------------------------

𝐁𝐏𝐎-2: 𝐰𝐡𝐚𝐭’𝐬 𝐜𝐡𝐚𝐧𝐠𝐢𝐧𝐠 𝐧𝐨𝐰

BPO-2 is the second and more meaningful blob capacity increase under the Fusaka framework.

At a high level, BPO-2:

➢ Raises the target blob count per block

➢ Raises the maximum blob count per block

➢ Increases total data availability per block without touching execution gas

This means that rolllups can publish more transactions per block, we will see less congestion on the blob market and data availability will become cheaper and more predictable.

Nothing else about Ethereum’s consensus or execution model changes. The chain behaves the same, it just carries more data.
-----------------------------------

𝐖𝐡𝐲 𝐁𝐏𝐎-2 𝐢𝐬 𝐢𝐦𝐩𝐨𝐫𝐭𝐚𝐧𝐭 𝐟𝐨𝐫 𝐫𝐨𝐥𝐥𝐮𝐩𝐬

Ethereum’s scaling strategy is rollup-centric. That only works if data availability keeps up.

BPO-2 directly improves:

➢ Rollup process which means more batches can be posted per block

➢ Less competition for limited blob space and this results into fees stability

➢ We will se fewer fee spikes during high activity periods

This matters most for fast L2s, app-specific rollups and Future rollup designs that assume sustained DA capacity, not just bursts

𝘐𝘯 𝘴𝘩𝘰𝘳𝘵, 𝘉𝘗𝘖-2 𝘮𝘢𝘬𝘦𝘴 𝘌𝘵𝘩𝘦𝘳𝘦𝘶𝘮 𝘢 𝘣𝘦𝘵𝘵𝘦𝘳 𝘴𝘦𝘵𝘵𝘭𝘦𝘮𝘦𝘯𝘵 𝘢𝘯𝘥 𝘥𝘢𝘵𝘢 𝘭𝘢𝘺𝘦𝘳 𝘸𝘪𝘵𝘩𝘰𝘶𝘵 𝘢𝘴𝘬𝘪𝘯𝘨 𝘓1 𝘵𝘰 𝘥𝘰 𝘮𝘰𝘳𝘦 𝘤𝘰𝘮𝘱𝘶𝘵𝘢𝘵𝘪𝘰𝘯.