The 'continuously variable transmission' in Ethereum Fusaka upgrade: establishing a fast response mechanism for L2 expansion one ️⃣ Background: Gas Limit upgrade does not require a hard fork Before the Fusaka upgrade, the majority of core parameters in the Ethereum protocol layer, such as block rewards and difficulty adjustment algorithms, were "hard coded" in the client software. This means that even if you just want to modify a value, you must go through a lengthy EIP proposal, test network drill, and coordinate a large-scale hard fork across all network nodes, which typically takes 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 minor adjustments through algorithms when packaging blocks (such as increasing from 30M to 60M this year). This mechanism endows the network with a certain degree of elasticity. The emergence of EIP-7892, BPO (Blob Parameter Only), is aimed at extending this elasticity to the data domain. It makes the key parameters of Blob configuration driven and takes effect through BPO, a lightweight hard fork that only changes parameters without changing code. From the perspective of client development, it's almost like doing a parameter hot update. It frees Ethereum from the rhythm of "having to wait for the next large hard fork every time you want to adjust the number of Blob" when it comes to scaling issues, and allows for more frequent parameter tuning through small BPO forks. two ️⃣ Why is the number of Blob important? The core object of this adjustment is Blob. Since the Dencun upgrade, most Rollups no longer write most of their transaction data into expensive calldata, but instead migrate to Blob, a dedicated 'temporary data mount area'. The economic logic of Blob is very simple: Blob is a scarce resource, and the number of Blob that can be mounted on each block is limited. Its price comes from the supply and demand relationship. When the demand for Layer 2 exceeds the supply, the unit price of Blob will increase, resulting in higher L2 handling fees. Therefore, while ensuring security, increasing the maximum number of Blob as much as possible is the most direct way to reduce L2 user costs. three ️⃣ Core parameters: Mechanism of Target and Max In BPO's adjustment plan, it can be seen that there are two paired numbers (such as 10/15). These are two key thresholds set based on the EIP-4844 mechanism: Target: The 'regulator' of costs This is the ideal load set by Ethereum. The system will dynamically adjust the base fee of Blob based on this value. If the actual usage exceeds the target, the cost will increase to suppress demand; If the actual usage is less than the target, the cost will decrease. It determines the throughput capacity and rate benchmark of the network under normal conditions. Max (maximum value): Safe 'fuse' This is a physical hard limit set to prevent network paralysis. No matter how high the demand is, the protocol mandates that the number of Blob contained in a single block must not exceed this value to prevent nodes from crashing or disconnecting due to excessive processing of big data. It is the ultimate ceiling of network carrying capacity. In addition, since Pectra, the blob parameters of the main network basically follow the pattern of "Max=1.5 × Target": 6/9, 10/15, 14/21, all at this ratio. four ️⃣ Upgrading Roadmap: Why did Fusaka choose 'step-by-step'? This expansion was not completed in one step on December 3rd, but adopted a rigorous three-stage strategy of "deploying technology first, then releasing capacity": Phase 1: Fusaka Upgrade Landing (December 3rd) Parameter status: Target: 6/Max: 9 (unchanged from previous Pectra versions). Fusaka has upgraded and activated the core technology of PeerDAS (Data Availability Sampling). Although technically capable of processing more data, for safety reasons, developers choose not to increase network load on the first day of the upgrade. This is a 'security observation period' used to verify the stability of the PeerDAS mechanism under existing traffic. Phase 2: BPO 1 (expected on December 9th) Parameter adjustment: Target: 10/Max: 15 After about a week of stable operation of PeerDAS, the first hot update is performed through the BPO mechanism. The target value has been increased from 6 to 10. This is the first substantial expansion during the Fusaka cycle. Phase 3: BPO 2 (expected on January 7, 2026) Parameter adjustment: Target: 14/Max: 21 After a month of sufficient stress testing, conduct a second hot update. Compared to when Fusaka was launched, its capacity increased by 2.3 times (6 → 14). This marks the complete implementation of this expansion plan. five ️⃣ summary The introduction of BPO is a milestone. It breaks the old paradigm of "waiting for a large feature hard fork every time we expand Blob" and breaks down expansion into a series of mini hard forks that only change parameters. This means that in the future, Ethereum will be like installing a "continuously variable transmission". Expanding Blob in the future does not require strong binding with large versions, and BPO3 and BPO4 can be planned periodically based on L2 requirements and client performance, using denser small step hard forks to optimize throughput, rather than changing it every few years.