EIP-7691 Retrospective

Introduction​

EIP-7691 was recently enabled on Mainnet with the Pectra hardfork, bumping the blob count from 3 Target 6 Max, to 6 Target 9 Max. This analysis focuses on the results of this change on the network, asserting that our previous analysis that justified the increase was correct.

Background​

When a block is proposed, the proposer needs to quickly gossip the block and all accompanying blobs to at least 66% of the network within 4 seconds, otherwise they risk their block becoming orphaned. The previous analysis primarily looked at this scenario from two angles:

• Solo stakers proposing locally built blocks.
• Home users observing these blocks.

This approach assumed these two groups represented the nodes most sensitive to an increase in bandwidth requirements.

Methodology​

Data Sources​

Our analysis leverages data from the ethPandaOps monitoring infrastructure, which provides visibility into Ethereum network performance through the Xatu data collection system. Nodes are run by both the ethPandaOps team and the community. Xatu connects to the Beacon API event stream, which has no guarantees on event publication or ordering, and as such can be considered worst case performance.

Parameters​

We analyzed Mainnet over a 7-day period to understand the impact:

Metrics​

Our analysis focuses on our "New Head" metric. For those that read our previous blog post on the 60M Gas Limit on Sepolia & Hoodi, this is the same metric that we used in that post as well.

Analysis​

Since the ethresear.ch post that justified the increase, the Xatu public contributor system has expanded from ~20 nodes to ~80 nodes. We've gone from 9 countries to 27, and now cover 52 distinct cities. There has also been a recent push to pump the gas limit, with Mainnet currently running at 36M compared to 30M at the time of the previous analysis.

Given these changes, our analysis foundation has slightly changed.

1. The geographical distribution of nodes contributing to Xatu has shifted, with more nodes in more countries. This is especially important as one of the bottlenecks to block propagation is the speed of light and the time it takes for data to travel across the globe.
2. The worst-case block size has slightly increased, as the gas limit has increased.
3. All nodes will take slightly longer to process the block, as the gas limit has increased.

---

1. Was 6/9 safe for home users?​

We can observe our ✓ New Head metric for all Locally Built blocks proposed by Solo Stakers and observed by Home Users.

We observe that our home users have been able to support the increase blob count, with only a few outliers outside of the 4s threshold. We can also run the same analysis that locked in 6/9 to see what the predicted maximum blob count is today:

Those with a keen eye will notice that this configuration seemingly supports up to 20 blobs! Unfortunately this is not the full picture as we have to account for the worst case scenario block size on top of our 9 blobs.

This configuration more accurately reflects the restrictions of today, and we can observe a predicted maximum blob count of 14, meaning that 6/9 was safe for home users.

2. Can we support a 60M gas limit?​

Let's first take a look at the worst case scenario block size at a 60M gas limit in the same configuration.

Cutting it a tad close now! A worst-case block size with 60M gas used only supports 10 blobs, so the 6/9 configuration has really hit the mark for our home users. As a reminder, these are all worst case scenarios, but it's reassuring to see that we can compound these types of scenarios and still be able to support our most bandwidth sensitive nodes.

Note: this highlights the importance of limiting the gas limit in Pectra to 60M.

3. What about when using MEV Boost?​

Let's take a look at historical p99 block size but for blocks that are provided by MEV Relays. This is a good baseline as ~91% of blocks are provided by MEV Relays.

Around the same as locally built blocks, which is reassuring. Now lets look at the worst case scenario block size at a 60M gas limit.

At first glance this is a worrying result, with the predicted maximum supported blob count being 5! However this is a worst case scenario block size under 60M gas. Some relays have started delaying header responses (playing timing games), which is highly likely to be the cause of this. We would expect relays to adjust their timing games as the landscape evolves, rendering this forward-looking analysis of the network a little moot.

To investigate our MEV Relay findings, we can view the data differently, opting for the distribution of when slots are 'accepted' by the Xatu network. That's a fancy way of saying:

• For every slot, find the time where 66% of the Xatu nodes saw the block as the new chain head.
• Plot the CDF of this metric.

We observe that locally built blocks (dashed lines) consistently achieve faster acceptance times compared to MEV Relay blocks (solid lines). This aligns with expectations, given locally built blocks don’t suffer the overhead of the MEV bid-acceptance dance. Amongst the MEV data is also operators playing their own timing games.

High-bandwidth ethPandaOps nodes reach <4s acceptance rates of 99.5%, compared to just 97.1% for home user nodes. This discrepancy likely boils down to bandwidth limitations, and is potentially compounded by a few outliers in the home user group (...like our team mate, Barnabas, whose setup might run on a 1990s spinning HDD and vibes). These potential outliers will need further investigation as we push on with PeerDAS in Fusaka.

Conclusion​

Our evaluation confirms that 6/9 was right on the money for home users, and our data demonstrates that a 60M gas limit remains viable even under worst-case block size conditions. However, we found that a 60M gas limit appears to be about the limit of what home users can support on the Pectra fork.

Insights gathered from MEV Boost blocks surfaced the inherent issues of forward-looking analysis, but generally aligned with our expectations. The team is now heads-down on Fusaka, which includes PeerDAS, significantly enhancing blob scalability for our Layer 2 friends.

Acknowledgments​

Special thanks to our contributoor community for providing the distributed monitoring data that makes this analysis possible. Their participation gives us unprecedented visibility into Ethereum network behavior.

Want to contribute to our monitoring efforts? Become a contributoor!