PeerDAS and the technical shifts in the Fusaka upgrade

PeerDAS changes how nodes verify Layer-2 data. Current Layer-2 networks post transaction data to Ethereum in packages called blobs. Full nodes download all this data to verify it. This creates a data bottleneck as Layer-2 networks grow. EIP-7594 allows nodes to check small, random samples of the data instead of downloading everything. This approach reduces the data nodes check. This reduction enables up to an eight-fold increase in data space over time. Lower competition for data space reduces transaction fees on Layer-2 networks.

The heartbeat layer provides a mechanism for block production. If synchrony holds, the chain output by the heartbeat remains reorg-resilient because honest proposals do not get reorged. This provides a concrete security property. MEV extraction through reordering of honestly proposed blocks is not possible at the heartbeat layer. This guarantee is stronger than a prefix that stabilizes over time. Under asynchrony, the network loses an unfinalized suffix, but the finalized prefix remains safe under all network conditions. The damage remains bounded to the unfinalized suffix during periods of asynchrony. A protocol cannot distinguish between low participation and a network partition during asynchrony. This difficulty is why the availability-finality dilemma holds. The heartbeat keeps producing blocks as long as a majority of the awake stake remains honest.

EIP implementations and network regulators

The Fusaka upgrade includes about a dozen Ethereum Improvement Proposals. These changes make the protocol faster, leaner, and cheaper. The following table lists the primary EIPs in this collection.

The upgrade includes Blob-Parameter-Only (BPO) forks. These small, focused updates allow the network to raise blob targets between larger upgrades. This flexibility helps Ethereum adapt to the growing needs of Layer-2 networks. The upgrade also includes several new network regulators to handle increased activity safely. The network imposes caps on per-transaction gas to prevent any single transaction from consuming an entire block. Tighter MODEXP limits and revised pricing for certain heavy computational operations prevent abuse. A 10 MiB RLP block size cap prevents spam and keeps nodes running smoothly. Execution clients began supporting partial history expiry in July 2025.

EIP-7594 implements PeerDAS to allow nodes to verify L2 data by sampling. EIP-7892 creates a mechanism to increase L2 data space between major upgrades. EIP-7951 provides precompile for secp256r1 curve support, which allows wallets to use device-native security like Face ID or fingerprint sensors. EIP-7939 adds the CLZ opcode to make complex on-chain math cheaper and more efficient. EIP-7825 sets a transaction gas limit cap to prevent any single transaction from monopolizing a block. EIP-7934 sets a hard limit on the physical size of a block to prevent spam. EIP-7823 and EIP-7883 adjust the cost and bounds for MODEXP to prevent abuse. EIP-7917 uses deterministic proposer lookahead to make the network more predictable. EIP-7918 adjusts the blob fee market to maintain price stability during L1 congestion. EIP-7642 allows nodes to prune very old history to simplify the sync process. EIP-7935 increases the default gas limit to 60M. EIP-7910 adds the eth_config RPC method for node operators to verify upgrade configuration.

Coordination and the roadmap timeline

Tomasz Stanczak urged developers to redirect attention toward the Fusaka upgrade. He warned that focus on the Glamsterdam release could jeopardize near-term progress. Glamsterdam arrives in early or mid-2026, whereas Fusaka targets the fourth quarter of 2025. Stanczak advised project coordinators to pause discussions about Glamsterdam. He believes reducing the number of calls dedicated to future forks helps the team concentrate on solving current issues.

He argued that hitting the Fusaka target date remains vital for the broader roadmap. He stated that no amount of talking about the roadmap and vision matters if the team cannot achieve coordination levels that consistently meet goals on schedule. Talented engineers work to resolve the bottlenecks that prompted some to propose shifting deadlines. The push to finalize Fusaka follows pressure from the Ethereum community for faster upgrade rollouts. Many see these changes as critical for keeping Ethereum competitive in a rapidly evolving blockchain landscape.

The Fusaka deployment occurs in several phases. The Holesky testnet activation was planned for October 1, 2025. The Sepolia testnet activation was planned for October 14, 2025. The Hoodi testnet activation was planned for October 28, 2025. These testnet results determine the mainnet target date of December 3, 2025.

Impact on users and node operators

The upgrade impacts different groups in the ecosystem. Layer-2 networks like Arbitrum, Optimism, and Base benefit from cheaper data and new tools. These networks handle most of Ethereum’s activity. Users experience faster and cheaper transactions on these networks. New applications also use the secp256r1 precompile to allow wallets to use device-native security like Face ID or fingerprint sensors. This improves the user experience for passkey users. Developers benefit from the CLZ opcode, which provides an instruction for counting leading zeros. This makes complex on-chain math cheaper and more efficient.

Node operators must update their software to a Fusaka-compatible version. They must complete this update before the December 3, 2025 mainnet activation. The network increases the computational capacity of each block. The upgrade increases the gas limit and adds smart data verification. You might find that the reduction in data requirements helps your node run more efficiently. Will the implementation of these new regulators prevent all forms of network congestion? The current method of downloading every blob creates a heavy data bottleneck for full nodes.