• Ethereum’s Fusaka upgrade introduces PeerDAS, a new data distribution model improving scalability and decentralization.
• Node responsibilities will now depend on the amount of ETH staked, balancing load across the network.
• The rollout will occur in multiple phases, gradually increasing blob capacity to enhance network performance.

Ethereum’s upcoming Fusaka upgrade, now live on the Holesky testnet, is one of the most significant network improvements in recent years. With the mainnet launch approaching, the upgrade introduces a major feature known as PeerDAS, a new approach to data sharing that reshapes how nodes handle information.

PeerDAS divides Ethereum’s 128kB blobs into 128 smaller pieces, or columns, of roughly 2kB each. These are distributed across nodes based on their stake size. The concept ensures that validators with larger ETH holdings manage more data, while smaller home stakers handle less. This balances the workload and keeps the network open to all participants.

According to ethPandaOps, this model will make Ethereum’s data handling nearly eight times more efficient than the current setup, thanks to erasure coding that doubles blob size while maintaining redundancy. The new approach allows nodes to verify data availability without downloading entire blobs, cutting down on bandwidth and disk usage.

PeerDAS Reshapes Node Responsibilities

The Fusaka rollout also changes how nodes operate. Three distinct node types will emerge: Supernodes, Validating nodes, and Full nodes.

Supernodes, holding 4,096 ETH or more, will store and process all 128 column subnets for around 18 days, serving as the backbone of the network. These entities will bear the highest bandwidth and processing demands but also play a vital role in maintaining network integrity.

Regular validators with a single validator setup will process about one-eighth of a Supernode’s data. This design keeps participation practical for individual stakers while supporting data distribution.

Full nodes, meanwhile, will handle just one-thirty-second of the data. Even though they don’t validate transactions, they still play a key role in maintaining data availability, particularly for RPC services.

Ethereum Introduces BPO Forks to Simplify Blob Scaling

Fusaka also marks the introduction of Blob Parameter Only (BPO) forks under EIP-7892. These lightweight forks will allow Ethereum developers to adjust blob counts without launching full hard forks.

The planned rollout includes Fusaka with a target of six blobs and a maximum of nine, followed by BPO1 with 10–15 blobs, and BPO2 with 14–21 blobs. Each phase will be monitored to measure network impact before moving toward more aggressive scaling.

With these adjustments, Ethereum aims to strike a balance between scalability and decentralization, ensuring the network remains efficient and inclusive as activity continues to grow.

Also Read: Ethereum Holdings Surge as Tom Lee’s BitMine Strengthens Position with $13 Billion Treasury