Ethereum’s new blob economics and the Fusaka upgrade

Dynamic pricing and PeerDAS

The Fusaka upgrade replaced the static 1-wei floor for blob fees with a dynamic minimum tied to L1 execution costs. EIP-7918 sets this floor at 1/16 of the execution base fee. This change prevents the blob fee market from dropping to the negligible 1-wei floor that previously allowed rollups to post data for essentially nothing during periods of low network demand. By tying the floor to execution costs, the protocol ensures blob consumers pay a meaningful fraction of the market rate for the computation they force on nodes. This mechanism aims to stabilize the market and prevent the cold-start problem where the market fails to respond to sudden demand. The decision to adjust the floor reflects a governance shift to prevent rollups from benefiting from essentially free data availability. The Fusaka upgrade is a necessary infrastructure overhaul for Ethereum’s scaling roadmap.

EIP-7918 solves cold-start problems.

PeerDAS changes how nodes handle data. Nodes sample small, random portions of data rather than downloading full blobs. This method uses Reed-Solomon erasure coding to split extended blob data into 128 columns distributed across dedicated gossip subnets. Each regular node subscribes to 8 of these subnets and holds 1/8th of the total data. This design allows the network to scale blob throughput while maintaining security and decentralization. Because nodes only need to verify small samples, the data availability problem becomes much easier to manage as L2 volume increases.

PeerDAS changes node data handling.

Scaling via BPO forks

The network increases blob capacity through Blob Parameter Only (BPO) forks. These configuration-only upgrades adjust the target and maximum blob counts without requiring a full hard fork. BPO1 increases the target to 10 and the maximum to 15. BPO2 pushes these values to 14 and 21. These upgrades follow the mainnet activation on December 3, 2025. BPO1 is set for December 9, 2025, and BPO2 occurs on January 7, 2026. This modular approach allows the network to respond to Layer 2 demand without the complexity of a major upgrade.

L2 fees dropped. You should track how these capacity shifts impact L2 fees. The implementation of the transaction gas limit cap of 16,777,216 gas prevents any single transaction from consuming an entire block and protects the network against denial-of-service attacks as the block size grows significantly during the scaling expansion process period this year.

Technical limits and capacity

The default gas limit rose to 60 million. EIP-7935 moved the limit from 45 million to 60 million. This provides more room for transactions. The increase in block size creates higher bandwidth needs for some.

EIP-7883 and EIP-7823 adjust the ModExp precompile. EIP-7883 raises the minimum gas cost from 200 to 500. It also removes the one-third discount from the general calculation. These changes ensure that resource-intensive cryptographic operations price correctly according to computational complexity. Additionally, EIP-7951 adds support for the secp256r1 elliptic curve. This enables direct integration with modern hardware like Apple Secure Enclave. EIP-7939 introduces the CLZ opcode to provide a gas-efficient way to perform bit-counting operations.

The transaction gas limit cap is 16,777,216 gas. This limit protects against DoS attacks. It also allows for future parallel transaction processing in the EVM. EIP-7934 imposes a 10 MiB RLP execution block size limit to prevent performance degradation. This cap protects against malicious transactions. EIP-7642 simplifies the codebase by removing pre-merge fields and the receipt Bloom. This reduces sync bandwidth requirements for nodes. The increase in the default gas limit from 45 million to 60 million helps the network process more transactions per block while accommodating the growing demand from various Layer 2 scaling solutions.

Will the increase in capacity lead to even lower L2 fees?