Fusaka and the data scaling roadmap

Fusaka’s implementation of PeerDAS provides the data infrastructure for the Lean Ethereum roadmap Vitalik Buterin proposed in July 2026. This roadmap describes a three to four year technical overhaul to simplify the protocol. PeerDAS (EIP-7594) changes how nodes handle data. It replaces full blob downloads with data sampling. This allows Ethereum to scale blob throughput without increasing hardware requirements for every validator. The upgrade follows the Pectra update. Developers aim for a twice-a-year hard fork cadence. This shift moves Ethereum toward a modular settlement network.

I recommend the Fusaka upgrade.

The Fusaka upgrade, the 17th major upgrade for the project, combines the Osaka execution layer update with the Fulu consensus layer improvements. It follows the Pectra update. The roadmap components include Lean Consensus, Lean Data, and Lean Execution. Lean Consensus aims for faster finality. Lean Data focuses on post-quantum cryptography. Lean Execution targets a more minimal, SNARK/STARK-friendly virtual machine.

PeerDAS uses erasure coding to split blobs into smaller pieces. A node verifies the data by sampling random portions instead of downloading everything. This works because nodes can reconstruct missing pieces from the remaining data. It provides a statistical guarantee that the data exists. The probability of missing data slipping past the sampling mechanism remains between one in $10^{20}$ and one in $10^{24}$, which is roughly the same as guessing a random 256-bit private key. PeerDAS allows validators to verify data through sampling rather than downloading entire datasets. This reduces bandwidth requirements by 87.5%. Every validator handles just one eighth of the blob data.

Ethereum scales blob capacity through Blob Parameter Only (BPO) forks. These are minimal, config-only upgrades. They allow the network to adjust targets without a full hard fork.

BPO1 scales capacity. The BPO2 fork increased the maximum to 21 in January 2026. Developers originally faced delays because Devnet-4 was unstable. Bugs in execution and consensus clients made the original timeline risky. EIP-7823 and EIP-7883 work together to optimize the ModExp precompile. EIP-7823 sets upper bounds for ModExp operations. EIP-7883 increases gas costs to reflect computational complexity. EIP-7642 removes pre-merge fields and the receipt Bloom from the networking protocol. This cleanup reduces sync bandwidth requirements.

Rollups like Arbitrum, Base, and Optimism benefit from the increased throughput. These networks use Ethereum for settlement and data availability. Lowering data costs makes transactions cheaper for users. You likely know that rollups batch transactions offchain. They post the results to Ethereum to ensure security. PeerDAS increases the space available for these transaction batches. This capacity increase helps avoid the bottleneck where blob fees spike when demand surges.

EIP-7935 raises the default gas limit to 60 million. This increases L1 execution capacity. EIP-7825 implements a transaction gas limit cap of 16,777,216 gas. This prevents a single transaction from consuming an entire block. EIP-7951 adds native support for the secp256r1 elliptic curve. This allows for direct integration with modern secure hardware like Apple Secure Enclave. EIP-7939 introduces the CLZ opcode for gas-efficient bit-counting operations.

Will the community successfully implement the planned 128 blobs per block?

L2 transaction fees depend on network traffic and rollup architecture. Some rollups prioritize compression while others optimize for liquidity. The network handles 530 million monthly transactions across its L2 ecosystem. Arbitrum, Optimism, and Base process transactions for cents.

Blobs are temporary.