The future of Ethereum is like installing a "continuously variable transmission," where expanding Blob no longer needs to be strongly tied to major version updates.
Written by: Zhixiong Pan
Background: Gas Limit Upgrade Does Not Require 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 took 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 hard forks 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 into 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 major hard fork every time we want to adjust the Blob count" and enables more frequent parameter adjustments through smaller BPO forks.
Why is the Number of Blobs Important?
The core focus 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 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 increases, leading to higher L2 transaction fees.
Therefore, under the premise of ensuring security, increasing the upper limit of Blob as much as possible is the most direct way to reduce costs for L2 users.
Core Parameters: Target and Max Mechanism
In the BPO adjustment plan, two paired numbers can be seen (for example, 10/15). 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 Blob based on this value. If the actual usage > Target, fees increase to suppress demand; if actual usage = Target, fees decrease.
It determines the network's throughput capacity and fee rate benchmark under normal conditions.
Max: The "Fuse" 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 ceiling of the network's carrying capacity.
Additionally, since Pectra, the blob parameters on 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 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 want to expand 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 installing a "continuously variable transmission," where expanding Blob no longer needs to be strongly tied to major version updates. Instead, it can plan BPO3, BPO4, and other adjustments based on L2 demand and client performance, allowing for more frequent small-step hard forks to optimize throughput rather than making changes every few years.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
