Fusaka, Ethereum’s latest upgrade, has been operational on the network since December 3rd. With it, this ecosystem received its second hard fork (hard fork) of the year, after Pectra in May.
As reported by CriptoNoticias, the proposal known as PeerDAS is Fusaka’s most relevant improvement and brought to the network something that Vitalik Buterin himself had been waiting for since 2015.
PeerDAS introduces a system for verify data availability by sampling between nodes. Instead of each node having to download all the blobs complete (space where second layer networks store information), now only requests small random samples from different peers.
The chart below, taken hours after Fusaka’s release, reflects PeerDAS operating as intended:
In the image, a node located in Finland (“tysm”) requests the network for some columns of data corresponding to blobs used by Base and Arbitrum.
That particular node does not have those samples stored, so the ‘MISSING’ message appears. This is normal in PeerDAS: nodes no longer need to save all data to check its availability.
Instead, the node consults other peers (in this case, a node in Taiwan). These peers do have those columns and send them in less than half a second.
In this way, the network confirms that the associated data is availableeven when they are not fully replicated on each node.
This behavior exactly reflects the goal of PeerDAS on Ethereum: to reduce the burden on individual storage while ensuring that information remains accessible to those who need it.
Ethereum second layer networks publish more data in the form of blobs
The following graph «Average Blob Count per Block» (average of blobs per block) shows the evolution of the average number of blobs per block.
The black line rises from around “4” (left axis) until approaching the target marked “6” blobs per block (horizontal skyline).
This indicates that, after Fusaka, the network began to use more space blobs in the blocks, approaching the objective defined for that parameter.
In simple terms: L2s began to publish more data in the form of blobsand PeerDAS begins to exercise its role of checking on that increased traffic.
Why is it useful for L2? Because by sharding and distributing the load across many nodes, the system allows layers two to publish more data without relying on each Ethereum node to fully download and verify everything.
This reduces operating costs, improves the speed with which batches are processed and enables L2 continue to scale without imposing an increasing load on the base network.
In addition, what that graph shows is just the beginning of a planned sequence of expansions, so this effect will increase in the future.
From the proposal EIP-7892which proposes a series of gradual updates that exclusively adjust the limit of the blobs, On December 9, a fork that will raise the current target of blobs from 6 to 10and on January 7 of next year another fork It will take you from 10 to 14.
Rate blobs: the peak and the correction after Fusaka
Hours before Fusaka’s arrival, the network recorded a abrupt peak in the blob fees the fees that L2s pay to publish their data on Ethereum using the blobs.
According to the following graph, that fee reached about 1,463 gwei (minimum unit of ether used to express fees in Ethereum), equivalent to about 0.0047 dollars currently:
Until the integration of Fusaka, the floor of the blob fees It was practically symbolic. The minimum possible was set at 0.000000001 Gwei and remained stuck there as long as there was no congestion.
This static floor led to the L2 will publish data on Ethereum almost for free 99% of the timeeven when their activity generated a real cost for the network.
With the activation of Fusaka and, in particular, EIP-7918that tariff “floor” of the blobs It stopped being fixed and It moved to a dynamic system linked to the real cost of operating in L1.
The floor of the committees of the blobs stood at around a sixteenth (1/16) of the Ethereum base feeaccording to the text of EIP-7918.
This is what the dynamic floor of the blob fees after Fusaka:
Considering usual levels of Ethereum usage, the system established by EIP-7918 places the minimum of blob fees in values that are usually between 0.01 and 0.5 gwei (that is, between tens and hundreds of millions of times above from the old minimum of 1 wei). Unlike the previous scheme, it can no longer drop to zero.
Furthermore, this new rate floor has a direct effect on the Ethereum economy: by charging a realistic minimum for blobsthe network stops subsidizing its verification and It starts to generate more income from commissions.
On the other hand, and for the end user, the impact is almost imperceptible: commissions in L2 are still very low, because these costs they are diluted between millions of transactions.
Gas limit per block: more data capacity
From EIP-7935After Fusaka, Ethereum clients operate by default with a gas limit per block of 60 million. That implies 100% growth from the 30 million that used the network at the beginning of 2025.
The “gas limit” defines how much computational work or transaction space can be included in a block. Apart from Fusaka, the gas limit is a measure agreed upon by the validators, and can be increased or lowered.
Raising it to 60 million allows for more transactions per block to be held, making it easier for the network to support greater load without immediate congestion.
Ethereum consensus software crashed after Fusaka
Finally, hours after Fusaka went live, the Prysm consensus client (one of the programs used by nodes to coordinate the chain) suffered a failure. He himself temporarily left offside about 23% of the network.
From what they communicated from Prysm, there are no indications that the failure was caused by Fusaka.
The Prysm team identified the problem and published a simple solution that any operator could implement in minutes by adding a line of code to their node, without needing to download a new version.
Thanks to that, the network continued to function without major consequences.