PeerDAS scales throughput while testnet participation stalls

The Fusaka upgrade implements PeerDAS to increase blob capacity for layer 2 networks. This upgrade introduces EIP-7594, which lets nodes verify data availability by sampling small portions of data. This method prevents nodes from needing to download entire blobs, which currently limits scaling. PeerDAS allows a theoretical 8x increase in data space. This change benefits rollups by reducing bandwidth requirements for individual nodes and lowering transaction fees.

The upgrade includes several other technical changes. EIP-7935 raises the default gas limit to 60 million, while EIP-7825 sets a transaction gas limit cap of 16,777,216 gas to protect against DoS attacks. EIP-7883 and EIP-7823 adjust the ModExp precompile to better price computational complexity and set upper bounds for those operations. EIP-7642 removes legacy pre-merge fields to reduce sync bandwidth, and EIP-7951 adds native support for the secp256r1 elliptic curve.

The rollout relies on a three-phase structure. The mainnet hard fork targets December 3, 2025. This is followed by BPO1 on December 9, 2025, and BPO2 on January 7, 2026. These Blob Parameter Only forks allow the network to adjust blob targets and maximums without a major hard fork.

Verkle trees and the 2027 roadmap

The Fusaka upgrade precedes the Verkle transition. Developers planned the Verkle transition to occur after Pectra to minimize technical risks. Verkle trees use vector commitments, typically KZG polynomial commitments, to replace the current Merkle Patricia Trie. This change allows for smaller witnesses, which enables stateless clients to function. Stateless clients do not need to store the entire state database to validate blocks. Instead, they use a witness containing only the fragments of state data required to execute transactions.

A Merkle Patricia Trie requires approximately 3.5 MB for a witness covering 1,000 state leaves. A Verkle tree reduces this witness to approximately 150 KB. This reduction makes it easier for nodes to receive and process data within a 12 second slot. Vitalik Buterin’s 2027 roadmap includes Hegota, which focuses on FOCIL and Frame Transactions. Hegota follows Glamsterdam, which targets Q4 2026.

The transition to Verkle trees remains in the research and testnet stage. While Verkle trees provide smaller proofs, they depend on more complicated cryptography and require a trusted setup through a KZG ceremony. This dependence on elliptic-curve pairings means Verkle trees are not post-quantum secure. The current Merkle Patricia Trie remains the primary data structure for the Ethereum mainnet state.

Testnet participation and upgrade fatigue

The Fusaka testnet activation follows a specific schedule across three networks. Holesky activated at slot 5,283,840 on October 1, 2025. Sepolia activated at slot 8,724,480 on October 14, 2025. Hoodi follows on October 28, 2025. These testnets allow developers to test PeerDAS and BPO forks before mainnet deployment.

Recent data shows a decline in testnet engagement. After the Pectra activation, testnet participation dropped by 12%. This drop suggests a level of fatigue among testers following the previous major upgrade. The complexity of the Fusaka upgrade, which includes 12 EIPs, requires significant coordination from node operators. Validators and non-staking nodes must manually update their software to support the new protocol changes. If they use outdated clients, they will disconnect from upgraded peers, causing a network fork.

The rollout of BPO forks adds to the coordination burden. These forks allow for a gradual increase in blob throughput, but they still require node operators to update their client implementations. The three-phase structure of Fusaka creates a 35 day window of compounded coordination risk. If validator nodes fail to upgrade at any stage, the blockchain could split. This could impact transaction finality and cause balance discrepancies between on-chain data and internal records.

The scaling trade-offs for nodes

PeerDAS changes the role of nodes in the network. While it reduces the data load for individual validators, it creates a need for highly capable supernodes. These supernodes must download and store all the data rather than just sampling portions of it. RPC providers and large staking services will likely fill this role because they possess the necessary storage and bandwidth.

The use of PeerDAS introduces a three-tiered system consisting of supernodes, validating nodes, and full nodes. This structure could concentrate the full data layer among a few large players. Some developers worry this concentration threatens decentralization. Others argue the design is intentional because the network relies on the availability of data from these specialized nodes.

The capacity for layer 2 networks to scale remains tied to these technical constraints. Since the Dencun upgrade, layer 2 usage has grown and often reaches the current limit of 9 blobs per block. PeerDAS allows Ethereum to increase this limit without increasing the bandwidth requirements for individual nodes. If the network successfully implements BPO forks, L2 transaction fees should decrease further.

The current capacity usage shows that rollups have not yet used the full potential of available space. Following the Pectra upgrade, only 67% of the available blobs were used. This suggests that even with the recent increases in capacity, significant headroom remains. Will the community reach a consensus on the necessary weight of supernodes before the next scaling phase?