Understanding Fusaka: Ethereum’s Infrastructure Overhaul

Fusaka is set to go live on December 3, 2025.

While Pectra (May 2025) focused on user experience and account abstraction, Fusaka (a fusion of Fulu consensus and Osaka execution) is the heavy-infrastructure upgrade. It transitions Ethereum from a “single-lane road” into a multi-lane, modular data-and execution-scaled L1.

The Fusaka upgrade includes the following to prepare Ethereum for its next decade of throughput expansion:

• Introduces Peer Data Availability Sampling (PeerDAS) which enables nodes to verify blob availability with small random ‘cells’ instead of entire blobs.

• Raises the default block gas limit to 60M.

• Formalizes Blob Parameter Only (BPO) forks enabling Ethereum to upgrade blob capacity without shipping full client releases. 

• Prepare for history expiry by removing legacy fields and allowing nodes to advertise which block ranges they serve. 

Covalent as the long-term data layer

For developers building on Ethereum, the Fusaka upgrade redefines how historical data is stored, served, and queried. Over time, clients will prune older data to reduce disk usage and help improve decentralization. However, this means applications cannot assume that standard RPC nodes will serve deep historical receipts and logs. This creates a Data Availability Gap that specialized indexers fill.

Covalent is the long-term data layer that permanently stores full historical onchain data including transactions, receipts, logs, and traces that are normalized into a canonical schema. 

The 12 Fusaka EIPs

1. EIP-7594: PeerDAS Decouples data verification from data download, allowing nodes to verify blob availability via random sampling (KZG proofs) rather than full replication.

2. EIP-7642: History Expiry Modifies client behavior to prune historical state data older than 1 year, shifting the burden of long-term history retention from validators to specialized indexers.

3. EIP-7935: Set Default Gas Limit to 60M Doubles the execution layer throughput capacity by strictly raising the gas_limit parameter, targeting ~60M gas per block.

4. EIP-7917: Deterministic Proposer Lookahead Exposes the proposer schedule 32 slots (1 epoch) in advance via the Beacon state, enabling synchronous composability and "based preconfirmations" for L2 sequencers.

5. EIP-7892: Blob Parameter Only (BPO) Forks Introduces a configuration-based fork mechanism to dynamically adjust MAX_BLOBS_PER_BLOCK without requiring full client release cycles.

6. EIP-7918: Blob Base Fee Bounded by Execution Cost Couples the blob gas price to the execution base fee, preventing spam by ensuring blob data cost never decouples from the computational cost of processing it.

7. EIP-7825: Transaction Gas Limit Cap Enforces a protocol-level cap (~16.7M gas) on individual transactions to mitigate computational DoS vectors and bounded block verification times.

8. EIP-7934: RLP Execution Block Size Limit Imposes a hard 10MB cap on the RLP-encoded execution payload to prevent propagation latency spikes and gossip protocol fragmentation.

9. EIP-7951: Precompile for secp256r1 Curve Support Adds a native precompile for the secp256r1 elliptic curve, enabling direct on-chain verification of signatures from Secure Enclaves (iOS/Android) and WebAuthn.

10. EIP-7939: Count Leading Zeros (CLZ) Opcode Introduces the CLZ opcode to the EVM instruction set, optimizing gas costs for binary search, compression algorithms, and ZK-proof verification.

11. EIP-7823: Set Upper Bounds for MODEXP Hardens the MODEXP precompile by enforcing a 1024-byte limit on input/modulus size, eliminating edge-case stalling attacks.

12. EIP-7883: ModExp Gas Cost Increase Realigns MODEXP gas pricing to accurately reflect CPU processing time, closing under-priced resource exhaustion vectors.

1. EIP-7594 — PeerDAS (Peer Data Availability Sampling)

📄 EIP link

What it is:

The centrepiece of Fusaka. Nodes verify blob availability by downloading small, random “cells” instead of entire blobs. Verification uses KZG cell proofs, not full blob proofs.

Why it matters:

PeerDAS removes the data bandwidth bottleneck. It enables Ethereum to safely increase blob capacity through BPO forks, unlocking significantly higher data throughput for rollups. This is the prerequisite for TPS growth on Layer 2s.

2. EIP-7642 — eth/69 - History Expiry

📄 EIP link

What it is:

Updates the networking protocol to prepare Ethereum for history expiry by:

• Removing legacy fields (like receipt blooms), and

• Allowing nodes to advertise which block ranges they serve (“history serving windows”).

Why it matters:

Over time, clients will prune older data to reduce disk usage, improving decentralization. However, this means applications cannot assume that standard RPC nodes will serve deep historical receipts and logs. This creates a Data Availability Gap that specialized indexers fill.

Where Covalent fits:

• EWM (Ethereum Wayback Machine): Permanently stores full historical transactions, receipts, logs, and traces that are normalized into a canonical schema.

• GoldRush API: Provides unified access to both fresh and historical data across chains, independent of node retention policies.

3. EIP-7935 — Set Default Gas Limit to 60M

📄 EIP link

What it is:

Raises the protocol’s recommended default gas limit for block proposers to 60 million gas.

Why it matters:

Represents a ~50–70% execution capacity increase compared to pre-Fusaka levels.

This directly increases L1 throughput and gives complex smart contracts more breathing room.

4. EIP-7917 — Deterministic Proposer Lookahead

📄 EIP link

What it is:

Makes the proposer schedule visible in advance via the Beacon state.

Why it matters:

This unlocks "Based Preconfirmations." Layer 2 rollups can now coordinate with future block proposers to guarantee transaction inclusion instantly. It bridges the gap between the speed of a centralized sequencer and the security of decentralized Ethereum.

5. EIP-7892 — Blob Parameter Only (BPO) Forks

📄 EIP link

What it is:

A mechanism for “mini-forks” that change only blob-related parameters (e.g., target or max blobs per block) without shipping a full client release.

Why it matters:

Agility. Ethereum no longer needs to wait 6-12 months for a major hard fork just to increase data capacity. It can ramp up supply in near real-time to match Layer 2 demand.

6. EIP-7918 — Blob Base Fee Bounded by Execution Cost

📄 EIP link

What it is:

Ensures blob gas fees cannot fall below a baseline tied to the execution base fee.

Why it matters:

Prevents spam scenarios where blob fees could drop to near zero (“1-wei blob attacks”).

Creates a healthier, more predictable fee market for rollups.

7. EIP-7825 — Transaction Gas Limit Cap

📄 EIP link

What it is:

Imposes a cap of ~16.7M gas on an individual transaction.

Why it matters:

As the block gas limit increases, this cap prevents a single super-heavy transaction from dominating an entire block and helps maintain fast block validation times.

8. EIP-7934 — RLP Execution Block Size Limit

📄 EIP link

What it is:

Introduces a physical limit (approx. 10 MB) on the size of the RLP-encoded execution payload.

Why it matters:

Computational gas and payload size are not perfectly correlated.

This limit ensures blocks cannot become too large to propagate, keeping Ethereum runnable on consumer-grade hardware.

9. EIP-7951 — Precompile for secp256r1 Curve Support

📄 EIP link

What it is:

Adds a native precompile for secp256r1 (P-256), the cryptographic curve used by WebAuthn, iOS Secure Enclave, Android Keystore, and Passkeys.

Why it matters:

Enables cheap on-chain verification of device-backed biometric signatures.

A major unlock for smart wallets and passkey-based authentication in Web3.

10. EIP-7939 — Count Leading Zeros (CLZ) Opcode

📄 EIP link

What it is:

A new EVM instruction that counts the number of leading zero bits in a bite array.

Why it matters:

A small but extremely useful primitive for:

• ZK circuits

• Binary searching

• Compression algorithms

• Hashing optimizations

This reduces the cost of many cryptographic and data-processing patterns.

11. EIP-7823 — Set Upper Bounds for MODEXP

📄 EIP link

What it is:

Sets strict limits on the input sizes accepted by the MODexp precompile.

Why it matters:

Prevents resource-exhaustion attacks where adversaries craft inputs that stall clients.

12. EIP-7883 — ModExp Gas Cost Increase

📄 EIP link

What it is:

Reprices MODexp gas costs to match actual CPU burden.

Why it matters:

Eliminates underpriced computational paths that attackers could exploit.

Infrastructure First, Scale Second

Fusaka signals a maturity moment for Ethereum:

• PeerDAS dramatically expands data throughput by distributing blob availability verification.

• BPO forks make Ethereum agile and able to scale blob capacity quickly and safely.

• History expiry support reduces node overhead and shifts long-term archival needs to specialized providers.

• Increased gas limits and execution safeguards expand block capacity while preserving network health.

For developers and applications, this means:

• Faster blocks

• Cheaper and more abundant blob space

• Higher throughput for rollups

• Increased reliance on durable, standardized historical data layers

As Ethereum becomes more modular and lightweight, Covalent provides the stable foundation for long-term data availability and ensures onchain data remains accessible.