Ethereum scaling via EOF and PeerDAS improvements

EOF and the Execution Layer

EOF replaces unstructured bytecode with a container format that separates code from data. Current EVM bytecode lacks structure, which makes it difficult to distinguish functions from loops or to perform effective static analysis. EOF provides a dedicated data section where compilers place tuples of values, which removes the need for developers to edit bytecode manually during deployment. This change makes it easier to execute EVM code outside its native environment, such as in a SNARK. Early benchmarks show that EOF contracts use 10% to 15% less gas than legacy versions. The upgrade also helps with inlining because it provides cheaper relative jumps. This format may eventually allow for lifting bytecode size limits via EIP-7830. You should note that developers must support both EOF and the legacy EVM for the foreseeable future. The current implementation of EOF is an improvement for developer tooling. The container format also addresses the difficulty of performing formal verification on contracts. Because current contracts can inspect their own implementation details like gas spent or byte-level structure, simulation on target architectures is difficult. EOF bans code and gas introspection to simplify this process. This change makes it easier to implement new languages because it removes the burden of accommodating legacy EVM quirks. This upgrade improves the ecosystem.

Scaling via PeerDAS

PeerDAS enables the network to support larger blobs. In January 2026, the maximum number of blobs per block reached 21 after the BPO2 fork. Because PeerDAS allows validators to verify data availability by checking small samples instead of downloading every full blob, the network can increase the blob limit without forcing every node to handle significantly more bandwidth requirements during peak usage. This scaling prevents the fee market from becoming unstable when rollup demand grows significantly.

The blob fee market follows an EIP-1559 style logic where the base fee adjusts based on whether usage meets the target of 3 blobs. When usage exceeds this target, the base fee rises to discourage overuse. If usage falls below 3, the fee falls. The network utilizes a separate fee market for blobs so they do not compete with regular gas. Most major rollups such as Arbitrum, Optimism, and Base use these blobs for settlement. These rollups see much lower fees than they did before the Dencun upgrade. In April, inscription blobs pushed average blobs per block above the target, which drove fees to $27. The target demand paradox suggests that the market may struggle to find equilibrium if demand remains near the target. Effective demand falls between 3.13 and 3.20 blobs. The current blob scaling strategy is successful.

State Management and the Verkle Delay

Ethereum manages state growth by pruning blob data after approximately 18 days, or 4096 epochs. This history expiry prevents permanent storage bloat but forces rollups to store their own data if they need history beyond the pruning window. The delay in Verkle tree integration remains a problem for node efficiency. Verkle trees use zero-knowledge proofs to allow stateless validation, which reduces hard disk requirements for staking nodes. This would allow nodes to synchronize almost instantly. Vitalik Buterin expects this to improve the user experience for solo staking and bolster light client functionality. However, developers continue to face delays with testnet implementations. This delay is a failure in the upgrade timeline. How will the network handle the growing state if Verkle trees remain stalled? Current nodes must store and gossip blob data on their own schedule. A growing blob ceiling means growing storage and bandwidth requirements for anyone running this infrastructure. This places a heavier burden on node operators compared to serving standard JSON-RPC calls. Node operators must manage increasing storage and bandwidth as the blob ceiling rises.