Author: Zhixiong Pan Background: Gas Limit upgrades do not require hard forks Prior to the Fusaka upgrade, most of the core parameters of the Ethereum protocol layer (such as block rewards and difficulty adjustment algorithms) were "hard-coded" in the client software. This meant that even if you just wanted to modify a single value, you had to go through a lengthy EIP proposal process, testnet drills, and coordinate a large-scale hard fork across the entire network, 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 rather allows validators to make minor adjustments using an algorithm when packaging blocks (for example, increasing it from 30M to 60M this year). This mechanism gives the network a degree of flexibility. EIP-7892, or Blob Parameter Only, was developed to extend this flexibility to the data domain. It makes the key parameters of a blob configuration-driven, and implements this through a lightweight hard fork of Blobs that allows for parameter changes without code modifications. From a client-side development perspective, it's almost like performing a hot parameter update. It freed Ethereum from the cycle of "having to wait for the next major hard fork every time you want to adjust the Blob count" in terms of scaling issues, allowing for more frequent parameter adjustments through smaller BPO forks. Why is the number of blobs important? The core target of this adjustment is the Blob. Since the Cancun upgrade, most Rollups no longer write most of their transaction data to the expensive calldata, but instead migrate to the Blob, a dedicated "temporary data mount point". The economic logic of blobs is very simple: blobs are a scarce resource, and the number of blobs that can be attached to each block is limited. Its price is determined by supply and demand; when the demand for Layer 2 blobs exceeds the supply, the unit price of blobs 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 the cost for L2 users. Core parameters: The mechanism of Target and Max In the BPO adjustment plan, two pairs of numbers (e.g., 10/15) can be observed. These are two key thresholds set based on the EIP-4844 mechanism: Target (or target value): The "regulator" of costs. This is the ideal load factor set by Ethereum. The system dynamically adjusts the Blob's base fee based on this value. If actual usage > Target, the fee increases to curb demand; if actual usage < Target, the fee decreases. It determines the network's throughput and rate benchmark under normal conditions. Max (maximum value): A safe "fuse". This is a physical hard limit set to prevent network paralysis. No matter how high the demand, the protocol mandates that the number of blobs contained in a single block cannot exceed this value to prevent nodes from crashing or going offline due to processing too much data. It represents the ultimate limit of network carrying capacity. In addition, since Pectra, the blob parameters of the mainnet have basically followed the pattern of "Max = 1.5 × Target": 6/9, 10/15, 14/21, all of which are this ratio. Upgrade Roadmap: Why did Fusaka choose a "step-by-step" approach? This capacity expansion was not completed all at once on December 3rd, but rather adopted a rigorous three-stage strategy of "deploying technology first, then releasing capacity": Phase 1: Fusaka upgrade launch (December 3rd) Parameter status: Target: 6 / Max: 9 (consistent with previous Pectra versions, no changes). The Fusaka upgrade activated PeerDAS (Data Availability Sampling), a core technology. While technically capable of handling more data, for security reasons, the developers chose not to increase network load on the first day of the upgrade. This was a "security observation period" to verify the stability of the PeerDAS mechanism under existing traffic conditions. Phase Two: BPO 1 (Expected December 9th) Parameter adjustment: Target: 10 / Max: 15 After PeerDAS had been running stably for about a week, the first hot update was performed via the BPO mechanism. The target value was increased from 6 to 10. This was the first substantial expansion within the Fusaka cycle. Phase 3: BPO 2 (expected January 7, 2026) Parameter adjustments: Target: 14 / Max: 21 After a month of thorough stress testing, a second hot update was performed. Compared to when Fusaka went live, the capacity increased by 2.3 times (6 → 14). This marks the complete implementation of this expansion plan. Summarize The introduction of BPO was a milestone. It broke the old paradigm of "every time a Blob is expanded, a large-scale hard fork is required", and broke up the expansion into a series of mini hard forks that only changed parameters. This means that Ethereum in the future will be like having a continuously variable transmission (CVT). Expanding Blob will no longer be strongly tied to major versions. Instead, it can plan BPO3 and BPO4 every now and then based on L2 demand and client performance, using more frequent small hard forks to optimize throughput, rather than changing it only once every few years.Author: Zhixiong Pan Background: Gas Limit upgrades do not require hard forks Prior to the Fusaka upgrade, most of the core parameters of the Ethereum protocol layer (such as block rewards and difficulty adjustment algorithms) were "hard-coded" in the client software. This meant that even if you just wanted to modify a single value, you had to go through a lengthy EIP proposal process, testnet drills, and coordinate a large-scale hard fork across the entire network, 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 rather allows validators to make minor adjustments using an algorithm when packaging blocks (for example, increasing it from 30M to 60M this year). This mechanism gives the network a degree of flexibility. EIP-7892, or Blob Parameter Only, was developed to extend this flexibility to the data domain. It makes the key parameters of a blob configuration-driven, and implements this through a lightweight hard fork of Blobs that allows for parameter changes without code modifications. From a client-side development perspective, it's almost like performing a hot parameter update. It freed Ethereum from the cycle of "having to wait for the next major hard fork every time you want to adjust the Blob count" in terms of scaling issues, allowing for more frequent parameter adjustments through smaller BPO forks. Why is the number of blobs important? The core target of this adjustment is the Blob. Since the Cancun upgrade, most Rollups no longer write most of their transaction data to the expensive calldata, but instead migrate to the Blob, a dedicated "temporary data mount point". The economic logic of blobs is very simple: blobs are a scarce resource, and the number of blobs that can be attached to each block is limited. Its price is determined by supply and demand; when the demand for Layer 2 blobs exceeds the supply, the unit price of blobs 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 the cost for L2 users. Core parameters: The mechanism of Target and Max In the BPO adjustment plan, two pairs of numbers (e.g., 10/15) can be observed. These are two key thresholds set based on the EIP-4844 mechanism: Target (or target value): The "regulator" of costs. This is the ideal load factor set by Ethereum. The system dynamically adjusts the Blob's base fee based on this value. If actual usage > Target, the fee increases to curb demand; if actual usage < Target, the fee decreases. It determines the network's throughput and rate benchmark under normal conditions. Max (maximum value): A safe "fuse". This is a physical hard limit set to prevent network paralysis. No matter how high the demand, the protocol mandates that the number of blobs contained in a single block cannot exceed this value to prevent nodes from crashing or going offline due to processing too much data. It represents the ultimate limit of network carrying capacity. In addition, since Pectra, the blob parameters of the mainnet have basically followed the pattern of "Max = 1.5 × Target": 6/9, 10/15, 14/21, all of which are this ratio. Upgrade Roadmap: Why did Fusaka choose a "step-by-step" approach? This capacity expansion was not completed all at once on December 3rd, but rather adopted a rigorous three-stage strategy of "deploying technology first, then releasing capacity": Phase 1: Fusaka upgrade launch (December 3rd) Parameter status: Target: 6 / Max: 9 (consistent with previous Pectra versions, no changes). The Fusaka upgrade activated PeerDAS (Data Availability Sampling), a core technology. While technically capable of handling more data, for security reasons, the developers chose not to increase network load on the first day of the upgrade. This was a "security observation period" to verify the stability of the PeerDAS mechanism under existing traffic conditions. Phase Two: BPO 1 (Expected December 9th) Parameter adjustment: Target: 10 / Max: 15 After PeerDAS had been running stably for about a week, the first hot update was performed via the BPO mechanism. The target value was increased from 6 to 10. This was the first substantial expansion within the Fusaka cycle. Phase 3: BPO 2 (expected January 7, 2026) Parameter adjustments: Target: 14 / Max: 21 After a month of thorough stress testing, a second hot update was performed. Compared to when Fusaka went live, the capacity increased by 2.3 times (6 → 14). This marks the complete implementation of this expansion plan. Summarize The introduction of BPO was a milestone. It broke the old paradigm of "every time a Blob is expanded, a large-scale hard fork is required", and broke up the expansion into a series of mini hard forks that only changed parameters. This means that Ethereum in the future will be like having a continuously variable transmission (CVT). Expanding Blob will no longer be strongly tied to major versions. Instead, it can plan BPO3 and BPO4 every now and then based on L2 demand and client performance, using more frequent small hard forks to optimize throughput, rather than changing it only once every few years.