Ethereum Pectra hard fork’s blob capacity enhancement is operating within the thresholds analysts forecast, ethPandaOps said in a May 30 report.
The update, which was initiated via the Ethereum Improvement Proposal 7691 (EIP-7691) on May 7, doubled the default blob count from three to six and lifted the ceiling from six to nine. Blobs are data pieces included in Ethereum blocks.
The report instrumented 123 Beacon-chain nodes across 27 countries, 29 in controlled data centers, and 94 in residential settings to track the “New Head” event. This is a timestamp recorded when a client declares a block and its blobs the new chain tip.
The benchmark requires 66% of peers to reach New Head within four seconds, or the block risks being orphaned.
Working as expected for home users
Charts covering 50,025 slots through May 28 show home-user nodes accepted locally built solo-staker blocks in under four seconds 99.5% of the time, with only a handful of outliers.
Regression across block size and arrival time projects that home nodes could tolerate up to 14 blobs before brushing the deadline, well above the nine-blob cap.
The report concluded that “home users were able to support nine blobs,” validating pre-fork modeling that assumed bandwidth sensitivity at the network edge.
The report then stress-tested the model against a 60 million-gas worst-case block size, reflecting the upper bound under Pectra.
The same regression trimmed safe capacity to 10 blobs, leaving a narrow margin but still clearing the live 6/9 envelope.
The report noted that a higher gas cap would further tighten the window, reinforcing community calls to halt future gas limit increases until peer-to-peer data availability sampling (PeerDAS) ships in the subsequent Fusaka release.
Manageable relay timing
About 91% of main-chain blocks route through MEV-Boost relays, which insert a bid-acceptance round-trip between proposers and builders.
Relay-sourced blocks reached New Head marginally slower, with home nodes registering 97.1% inside four seconds versus 99.5% for locally built blocks.
A distribution plot attributes the tail to relays that delay header broadcasts as part of competitive timing strategies. Worst-case 60 million-gas simulations indicated a safe relay capacity of five blobs, but ethPandaOps expects relays to adjust once the competitive landscape penalizes late delivery.
Additionally, developers plan to shift from proposer-side blob propagation to PeerDAS under the Fusaka hard fork.
EthPandaOps stated that the team is “heads-down” in integrating PeerDAS, which should reduce per-block bandwidth and open up room for higher gas limits and larger blob counts once deployed.
The report concluded that the telemetry from the first week of Pectra shows the 6/9 blob schedule functions as designed, giving client teams room to focus on Fusaka’s data-availability upgrades without immediate pressure to revisit bandwidth ceilings.
Read the full article here
