What Is Ethereum's Major Upgrade, "Fusaka"? A Guide Centered on PeerDAS

Overview of This Article

“Fusaka” is the major upgrade released on Ethereum mainnet on December 3, 2025. This article explains its technical details and practical impact for validator and full-node operators, and for anyone following L2 and smart contract development.

(“Fusaka” is a portmanteau, coined from the fact that the Consensus Layer (CL) upgrade is named “Fulu” and the Execution Layer (EL) upgrade is named “Osaka”.)

Note: This article is based on information as of its original writing in October 2025. The Fusaka upgrade activated on mainnet as scheduled on December 3, 2025 (UTC). For Glamsterdam, the major upgrade that follows Fusaka, see our dedicated article.

Overview of the Fusaka Upgrade

Goals and Levers

This is the major upgrade following Pectra (May 2025), and it was developed with the following goals.

(A Blob is a cheap data area for temporarily carrying data from L2s and the like. “Data availability” means that anyone who needs that Blob data can retrieve it from the network.)

• Scaling data availability for Layer 2: introduce PeerDAS to raise the Blob count ceiling by up to 8x (theoretical) and reduce L2 transaction (TX) fees
• Improving Layer 1 TX throughput: raise the default block gas limit from 45M to 60M, and introduce a per-TX gas cap to prevent DoS attacks that fire off large numbers of TXs
• Reducing node operating costs: lower storage requirements through PeerDAS
• Improving UX and developer experience: add new opcodes (the basic instructions executed by Ethereum’s execution environment) to cut implementation and gas costs for specific use cases such as ZKP (zero-knowledge proofs)
• Securing safety and future readiness: enable gradual Blob scaling via Blob Parameter Only forks (BPO forks), and finalize the next epoch’s block proposer during the preceding epoch (an epoch is a unit period of about 6.4 minutes)

The upgrade is aligned with the Lean Ethereum roadmap that Ethereum has laid out (see our separate article for an explainer), and much of it serves as groundwork for future changes.

The EIPs in Scope

The upgrade consists of the EIPs in the table below. An EIP (Ethereum Improvement Proposal) is a document that proposes and records a change to Ethereum’s specification, and upgrades are composed in units of EIPs. Excluding the meta EIP that defines the scope and the informational EIP, there are 12.

Source: EIP-7607: Hardfork Meta - Fusaka

Let us start with an overview of PeerDAS, regarded as the single biggest headline feature of the Fusaka upgrade.

Headline Feature: PeerDAS (EIP-7594, Data Availability Sampling)

PeerDAS at a Glance

EIP-7594: PeerDAS is a proposal that integrates DAS (data availability sampling) into the P2P network layer. DAS is a technique that samples only part of the data and verifies it, probabilistically confirming that the whole is retrievable.

The Blob data it targets (128 KB) was introduced by EIP-4844 (Proto-Danksharding) in the Dencun upgrade of March 2024. The goal of EIP-7594 is to make verifying these Blobs easier.

It distributes the responsibility for storing Blobs across nodes, so that data availability can be verified probabilistically without every node downloading all the data. The figure below is a schematic of how nodes process each Blob once PeerDAS is in place.

Technical Details

We explain node behavior and the consensus model under the following assumptions.

• A block contains at most 48 Blobs (a theoretical figure of 8x the target of 6; the actual scheduled maximum is 21)
• Each Blob (up to 128 kB) is split into 64 pieces called cells (up to 2 kB each)
• Each Blob’s data is erasure-coded into 128 cells

*Erasure coding here means polynomial encoding. Using each Blob’s 64 cells of data ([m_0, m_1, ..., m_63]), we build the degree-63 polynomial f(x) = m_0 + m_1 x + m_2 x^2 + ... + m_63 x^63. Converting to 128 cells simply means computing [f(0), f(1), ..., f(127)].

Intuitively, if there are 64 unknowns (m_0 and so on), then 64 values are enough to solve the system of equations. Once solved, f(x) can be evaluated at any x, and extracting the coefficients recovers the original Blob data.

Previously, recovering a Blob required obtaining all 64 cells without exception. With erasure coding, any 64 of the 128 cells are enough to recover the Blob.

We walk through PeerDAS processing in the following order.

• How Blobs are split and assigned to nodes
• How nodes run PeerDAS through the consensus steps

How Blobs Are Split and Assigned to Nodes

Each Blob is split into 2 kB cells and then erasure-coded into 128 cells (2 kB each). With 6 Blobs, for example, the whole forms a 6-row by 128-column matrix.

Each column is called a Subnet. The number of Subnets a node is responsible for grows roughly in proportion to the node's total staked ETH / 32 ETH. There are floors and a ceiling, however: a node running validators covers at least 8 Subnets, a full node without validators still covers 4, and the ceiling is all 128 Subnets.

For its assigned Subnets, each node downloads, verifies, stores, and serves the Blob data over P2P.

The list of Subnets a node handles can also be derived deterministically from its NodeID (a list like [1,2,3,...,128], taking as many entries from the front as the node’s assignment count), so knowing a NodeID and its Subnet count identifies exactly which Subnets it handles. Working out the assignment for several staking tiers gives the following.

• Full node (0 ETH staked): 4 Subnets (floor)
• Solo validator (32 ETH staked): 8 Subnets (floor)
• Mid-size validator (2,048 ETH staked): 64 Subnets
• Large validator (4,096 ETH staked, i.e., two 2,048 ETH validators’ worth): 128 Subnets (all Subnets)

A node serving the data of all Subnets is called a Supernode. A mid-size validator covers 64 Subnets, but because 64 of the 128 cells suffice to recover a Blob thanks to erasure coding, mid-size validators and above can effectively reconstruct the data of all Subnets.

How Nodes Run PeerDAS Through the Consensus Steps

PeerDAS is processed on the Beacon Chain as follows. One slot (12 seconds) is divided into three phases: 4 seconds for block-data production and transmission, 4 seconds for reception and signing, and the remaining 4 seconds for signature aggregation (PeerDAS is not involved in aggregation, so we omit it).

In the first phase, block-data production and transmission (seconds 0–4), the block proposer aggregates all Blob data and produces the block data, then shares it with peers over the Gossip protocol (a P2P propagation scheme in which received data is relayed from neighbor to neighbor across the network). Concretely, the block proposer:

• Erasure-codes the Blob data into a matrix of Blob-count rows by 128 columns
• Issues a KZG commitment and KZG proof for each Blob (cryptographic data that lets anyone verify a cell really belongs to that Blob)
• Transmits the block data and Blob data to peers

In the following phase, reception and signing (seconds 4–8), each node receives the block data and Blob data from peers over the Gossip protocol. Each node then:

• Shares its NodeID and how many Subnets it holds
• Exchanges Subnet data with other peers over the Gossip protocol according to the Subnets it needs
• Uses each Blob’s KZG commitment and proof to verify that the Subnet data it obtained really belongs to that Blob (In practice this is not done per Blob; the per-Blob KZG commitments and proofs are combined and verified in one batch)
• Attests (votes for the block) once all data has been verified
• Depending on the client (e.g., Prysm), once data for 50% of all 128 Subnets (64 Subnets) has arrived, regenerates the remaining Subnet data instead of waiting for peers

In the production-and-transmission phase, a proposal only counts as valid if everything, including transmitting the block and Blob data, fits within 4 seconds. The more Blobs there are, the more resources — bandwidth above all — this demands.

For example, the Blob maximum reached 21 with BPO2 on January 7, 2026. After erasure coding, each Blob is 128 cells × 2 kB = 256 kB.

If we assume 3 of the 4 seconds are usable for transmission, then sending the full data to just a single peer already requires 21 (Blobs) × 256 (kB/Blob) ÷ 3 (s) = 1,792 (kB/s) = 14 Mbps at minimum. Since a proposer naturally transmits to multiple peers rather than one, on the order of 100 Mbps ends up consumed by Blob data alone.

Thanks to PeerDAS, the data each node stores and verifies has shrunk compared with the previous implementation — but note that bandwidth demand has increased relative to it.

The figure below shows the bandwidth required per Blob count, assuming the block proposer transmits Blob data to eight peers within 3 seconds.

Source: Fusaka bandwidth estimation by ethPandaOps

Other Important EIPs in Detail

Higher Blob Capacity and Staged Blob Updates (EIP-7892)

Since Pectra went live (May 7, 2025), the Blob target (the number usable at the minimum fee) has been 6. Recently, helped by sharp market swings, utilization has topped 90%. By paying an extra fee, up to 9 Blobs can be packed into a single block.

Even so, with L2 usage set to grow further, the Blob maximum and target need to keep rising.

The figure below shows daily Blob usage since April 14, 2025. The red line at 42K marks the approximate daily target Blob count — the Blob target (6) multiplied by the number of Ethereum blocks per day (roughly 7,100). Daily usage can be seen gradually approaching this line.

Source: Daily Blobs by blobscan

This is why Fusaka introduced a new kind of fork that updates only Blob parameters: Blob Parameter Only Hardforks (BPO). Through BPOs, parameters such as the Blob target and maximum are raised in stages.

Because BPOs can ship at shorter intervals than regular hardforks, parameters can be raised in step with market growth while monitoring the impact of Fusaka and of each BPO itself. They were bundled into Fusaka because PeerDAS makes it easier to push the Blob target and maximum higher.

The parameters were updated in stages on the following schedule.

Source: Fusaka Mainnet Announcement (Ethereum Foundation Blog)

Higher Block Gas Limit and a Per-Transaction Gas Cap (EIP-7935 & EIP-7825)

Ethereum’s block gas limit had only just been raised to 45M on July 21, 2025. Average gas utilization has recently hovered around 50%, as the chart below shows, leaving headroom for transaction processing.

Source: Average gas limit by Blockscout

Nevertheless, some blocks exceed 90% utilization, and as the six-month average gas price chart below shows, the impact on gas fees has not gone away. Raising the gas limit therefore remains an ongoing effort.

Source: Average gas price by Blockscout

The Fusaka upgrade raises the block gas limit to 60M (EIP-7935). The increase is expected to improve throughput and stabilize gas prices.

Paired with this, a per-transaction gas cap (EIP-7825) aims to get the most out of the relaxed block gas limit. As a protocol rule, a single transaction is capped at roughly 17M gas (2^24 gas, a little over one third of the current block gas limit).

Because this prevents a single TX from monopolizing most of a block and concentrating verification load, the gas limit can be raised safely.

If you anticipate transactions that would exceed this cap, the contract needs to be redesigned.

Deterministic Proposer Lookahead (EIP-7917)

Previously, the proposers for the next epoch (1 epoch = 32 blocks, about 6.4 minutes) were not necessarily fixed in advance. This was seen as an obstacle to Preconfirmation — a much-discussed technique in which the inclusion of a specified transaction at a specified time is promised in advance.

The Fusaka upgrade fixes the next epoch’s proposers in advance, removing this obstacle.

This is not a change with immediate effect; it is groundwork for future UX improvements.

Impact on Validator and Full-Node Operators, and on L2 and Contract Developers

Impact on Validator and Full-Node Operators

For node operators, the biggest impacts come from PeerDAS (EIP-7594) and the higher Blob capacity with staged updates (EIP-7892). Both bear directly on node storage usage and network bandwidth consumption. In addition, the simplification of eth/69 inter-node communication (EIP-7642) stops nodes from returning unused data (Bloom), which should trim bandwidth consumption.

According to ethPandaOps estimates, with PeerDAS in place, performance requirements are actually relaxed for validators with smaller stakes. Conversely, operators running many validators, or validators with large stakes, can expect stricter bandwidth requirements.

The figures below show storage usage (Blob-related only) and block-proposal bandwidth for several staking tiers. In Subnet terms, 320 ETH corresponds to 10 Subnets and 1,024 ETH to 32 Subnets.

Blob-related storage usage per Blob count for a validator staking 320 ETH

Blob-related storage usage per Blob count for a validator staking 1,024 ETH

Data transmission rate at block proposal per Blob count for a validator staking 320 ETH

Data transmission rate at block proposal per Blob count for a validator staking 1,024 ETH

Source: Fusaka bandwidth estimation by ethPandaOps

For stakes up to 320 ETH, storage usage stays below pre-Fusaka levels even beyond 20 Blobs. The real issue is bandwidth at block proposal. The chance to propose comes around only occasionally for each validator, but at that moment the node must aggregate all Blob data and serve it to peers for signing, so the more Blobs there are, the more bandwidth is needed.

Some clients implement mechanisms such as receiving Blob data from the execution layer (EL), or flags like --max-blobs that cap the Blob count. If bandwidth constraints are a concern, check your client’s capabilities.

Impact on Layer 2 Developers

For Layer 2 development, the impact centers on the two EIPs that directly move the capacity and cost of Blobs — the DA (data availability layer, where L2s park their data) — namely PeerDAS (EIP-7594) and the higher Blob capacity with staged updates (EIP-7892). Beyond those, EIPs with clear benefits for ZK Rollup builders, such as EIP-7939, also shipped.

Impact on Smart Contract Developers

For smart contract development, the biggest impacts are the higher block gas limit and the per-transaction gas cap (EIP-7935 & EIP-7825). Most contracts are unaffected, but if you have built complex contracts whose single-TX gas consumption exceeds the cap, you will need to split functionality or take similar measures.

Summary

The Fusaka upgrade is a large, scalability-focused hardfork bundling 12 EIPs. PeerDAS gets most of the attention, but it also carries many smaller changes that touch every stakeholder, from node operators’ bandwidth requirements to contract gas caps.

Another hallmark of this upgrade is how many of its EIPs — further TX throughput growth, Preconfirmation, and more — only pay off in combination with changes still to come.

As an Ethereum staking service provider (SSP), Omakase continuously tracks client support for this upgrade, PeerDAS above all, and the resulting changes in node operation requirements.