Ethereum News
The Fusaka upgrade scales Ethereum while maintaining decentralization
The Fusaka upgrade scales Ethereum while maintaining decentralization, having activated on the Ethereum mainnet at slot 13,164,544 on December 3, 2025, at 21:49:11 UTC, following months of testing on the Holesky and Sepolia networks. This update raised the default block gas limit from 45 million to 60 million through EIP-7935, adding 67% more computation capacity per block. Peer Data Availability Sampling, specified in EIP-7594, lets validators check small, randomly sampled pieces of data from different network peers instead of downloading entire blobs. Verkle Trees also entered the network during Fusaka to compress cryptographic proofs into smaller, more efficient structures. This data structure replacement for Merkle-Patricia trees reduces the storage space nodes maintain. The upgrade also includes EIP-7951, which introduces support for the secp256r1 curve for better wallet user experience. EIP-7823 and EIP-7883 adjust pricing for MODEXP to prevent computationally heavy operations from being abused. To prepare for the rollout, the Ethereum Foundation offered a bug bounty program with rewards of up to $2 million for critical vulnerabilities during the four-week program. These changes help the network manage the extra load of larger blocks without forcing every node to download all blob data.
Scaling through data management
Ethereum increased blob capacity through Blob Parameter Only (BPO) forks after the mainnet activation. BPO1 on December 9, 2025, increased the blob target to 10 and the maximum to 15. BPO2 on January 7, 2026, raised these to a target of 14 and a maximum of 21. These adjustments, managed via EIP-7892, let Ethereum scale data availability without requiring client software updates. The protocol also added a transaction gas limit cap of 16,777,216 via EIP-7825 to reduce denial-of-service risks.
| Parameter | BPO1 Target | BPO1 Max | BPO2 Target | BPO2 Max |
|---|---|---|---|---|
| Blobs | 10 | 15 | 14 | 21 |
The gas limit increase aids Layer 2 rollups. Because rollups post transaction data to Ethereum in blob format, capacity ramps lead to lower L2 transaction fees. This capacity expansion builds on EIP-4844, which decreased Layer 2 costs by as much as 90% in many scenarios. The upgrade also included EIP-7642, which removes legacy pre-merge fields and receipt bloom from the networking protocol to reduce sync bandwidth requirements. You should monitor how these changes influence fee volatility for rollup users.
The path to statelessness
Verkle Trees provide a foundation for the statelessness goal described in The Verge. This roadmap seeks to allow fully verifying nodes to operate with only a few gigabytes of storage. One proposal for state expiry involves creating a state tree for specific time periods, such as one epoch lasting approximately eight months. In this model, nodes only need to hold the most recent two trees, which include the current epoch and the one preceding it. This approach reduces the state that nodes must store to a flat 20 to 50 GB. For accounts that have not been accessed recently, expiration can occur by charging rent or by using a countdown from the last interaction. To facilitate this, the address space extension roadmap item allows addresses to be lengthened. If an object is modified in an old epoch, the sender must provide a witness showing the object’s state in the old tree and its absence in all intervening trees from that epoch. A different proposal, the unified binary tree, uses only hash functions to remain secure against quantum attacks.
Weak statelessness places the responsibility for state storage on block proposers, while other nodes verify blocks without the full state data. This requirement relies on proposer-builder separation so that builders can specialize in generating witnesses. The network faces a problem where stateless clients might overwhelm full nodes by requesting massive amounts of data on-demand via the GetNodeData primitive. If the population of the network shifts toward these leeching nodes, the performance of full nodes will degrade. Will the increased request load from stateless clients eventually outpace the ability of full nodes to serve the network?
