Author: Zhixiong Pan

Background: Gas Limit Upgrade Without Hard Fork

Before the Fusaka upgrade, most core parameters of the Ethereum protocol layer (such as block rewards, difficulty adjustment algorithms, etc.) were "hard-coded" in the client software. This meant that even if one wanted to modify a single value, it had to go through a lengthy EIP proposal, testnet rehearsals, and coordinate a large-scale hard fork across all network nodes, which typically required a cycle of six months or even longer.

Prior to this, the only exception in the Ethereum protocol was the Block Gas Limit. The Gas Limit is not determined by a hard fork but allows validators to make slight adjustments through algorithms when packaging blocks (for example, increasing from 30M to 60M this year). This mechanism gives the network a certain degree of flexibility.

The emergence of EIP-7892 and BPO (Blob Parameter Only) is precisely to extend this flexibility to the data domain. It makes the key parameters of Blob configuration-driven and takes effect through the lightweight hard fork of BPO, which "only changes parameters, not code." From the perspective of client development, it is almost like performing a parameter hot update.

This allows Ethereum to break free from the rhythm of "having to wait for the next large hard fork every time we want to adjust the Blob number" and enables more frequent parameter adjustments through smaller BPO forks.

Why is the Number of Blobs Important?

The core object of this adjustment is the Blob. Since the Cancun upgrade (Dencun), most Rollups no longer write most transaction data into expensive calldata but have migrated to the Blob, a dedicated "temporary data mounting area."

The economic logic of Blob is very simple: Blobs are a scarce resource, and the number of Blobs that can be mounted in each block is limited. Its price comes from the supply and demand relationship; when the demand for Layer 2 exceeds supply, the unit price of Blob will increase, leading to higher L2 transaction fees.

Therefore, under the premise of ensuring security, increasing the upper limit of the number of Blobs as much as possible is the most direct way to reduce costs for L2 users.

Core Parameters: Mechanism of Target and Max

In the BPO adjustment plan, two paired numbers (for example, 10/15) can be seen. These are two key thresholds set based on the EIP-4844 mechanism:

Target: The "Regulator" of Fees

This is the ideal load amount set by Ethereum. The system dynamically adjusts the base fee of Blobs based on this value. If the actual usage > Target, fees increase to suppress demand; if the actual usage = Target, fees decrease.

It determines the network's throughput capacity and fee rate benchmark under normal conditions.

Max: The "Circuit Breaker" for Safety

This is a physical hard limit set to prevent network paralysis. Regardless of how high the demand is, the protocol strictly stipulates that the number of Blobs included in a single block must not exceed this value to prevent nodes from crashing or disconnecting due to processing excessively large data.

It is the upper limit of the network's carrying capacity.

Additionally, since Pectra, the blob parameters of the mainnet have generally adhered to the pattern of "Max = 1.5 × Target": 6/9, 10/15, 14/21, all follow this ratio.

Upgrade Roadmap: Why Did Fusaka Choose a "Step-by-Step" Approach?

This expansion is not a one-time event on December 3 but adopts a rigorous three-phase strategy of "first deploying technology, then releasing capacity":

Phase One: Fusaka Upgrade Launch (December 3)

Parameter Status: Target: 6 / Max: 9 (consistent with the previous Pectra version, no change).

The Fusaka upgrade activated the core technology of PeerDAS (Data Availability Sampling). Although it technically has the capability to handle more data, for safety reasons, developers chose not to increase the network load on the first day of the upgrade. This is a "safety observation period" to verify the stability of the PeerDAS mechanism under existing traffic.

Phase Two: BPO 1 (Expected December 9)

Parameter Adjustment: Target: 10 / Max: 15

After approximately one week of stable operation of PeerDAS, the first hot update will be conducted through the BPO mechanism. The target value will be increased from 6 to 10. This is the first substantial expansion during the Fusaka cycle.

Phase Three: BPO 2 (Expected January 7, 2026)

Parameter Adjustment: Target: 14 / Max: 21

After a month of thorough stress testing, the second hot update will be conducted. Compared to the launch of Fusaka, the capacity will have increased by 2.3 times (6 → 14). This marks the complete implementation of this expansion plan.

Conclusion

The introduction of BPO is a milestone. It breaks the old paradigm of "having to wait for a large functional hard fork every time we expand the Blob" and divides the expansion into a series of mini hard forks that only change parameters.

This means that the future of Ethereum will be like having a "continuously variable transmission," where expanding the Blob does not have to be strongly tied to major version updates. Instead, based on L2 demand and client performance, BPO3, BPO4 can be planned periodically, allowing for more frequent small-step hard forks to optimize throughput rather than making changes every few years.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。