Steelmanning a blob throughput increase for Pectra

Steelmanning a blob throughput increase for Pectra

With the discussions about the Pectra hardfork scope continuing, I want to provide some empirical input on the current state of the network.
I’ll try to do so by answering some commonly raised questions that arise in discussions on the proposed blob target/limit increase for Pectra.

The arguments for shipping EIP-7691 in Pectra are:

  • Continue scaling DA - with EIP-4844, we have only set the foundation.
    • Provide existing L2s and their apps enough blob space for further scaling.
    • Avoid creating a precedent of “blob fees can explode and are unpredictable” (h/t Ansgar); this harms future adoption if rollups have to account for rare fee spikes over extended periods.
  • The number of reorgs has been trending down since Dencun.
  • The impact of blobs on reorgs has decreased as well.

How did the number of reorgs evolve over time?

reorged = “nodes saw a block by the proposer of the respective slot”
missed = “no sign that the proposer was online”

  • Within the last 365 days, 5,900 blocks were reorged.
  • This equates to 0.225% of the blocks in that time interval.
  • At the same time, 14,426 slots were missed, representing 0.549%.
  • On average, we observe 492 reorgs and 1,202 missed slots per month.

The number of reorgs has been decreasing, which is a positive development, though not surprising, as core devs continuously improve client software. Interestingly, contrary to expectations that the most recent hard fork (= Dencun) would lead to a significant rise in reorgs, we actually observed the opposite trend.

Since the Dencun upgrade, the number of reorgs halved.

It’s challenging to identify the exact reason for the change in trend, but it may be attributed to the ongoing improvements made by core devs to their client software.

What’s the impact of blobs on reorgs?

Initial analysis conducted a few months after the Dencun hardfork showed that blocks with 6 blobs were reorged 3 times more frequently than 0-blob blocks. In general, we observed that the reorg rate has increased steadily with a growing number of blobs.

Updating this analysis presents a different picture today. Even though we still see that 6-blob blocks are reorged more frequently than 0-blob or 1-blob blocks, the numbers have decreased significantly, showing no substantial difference between blocks with one blob and those with six blobs.
We still observe a small difference in the reorg rate for 0-blob blocks and x-blob blocks (where x > 0).

reorgrate_animation

How well are blobs distributed over blocks?

Plotting the distribution, we can see that most blobs contain either 0 or 6 blobs, with blocks containing 1 to 5 blobs representing the minority. However, the situation has improved since the last study, with fewer slots at the extremes of 0 blobs and 6 blobs.

all_blobs_day

Related work

Title Url
On Attestations, Block Propagation, and Timing Games ethresearch
Blobs, Reorgs, and the Role of MEV-Boost ethresearch
Big blocks, blobs, and reorgs ethresearch
On Block Sizes, Gas Limits and Scalability ethresearch
The Second-Slot Itch - Statistical Analysis of Reorgs ethresearch
8 Likes

Thanks for putting together a comprehensive overview of blob reorg rates since Dencun. One additional datapoint to consider is that during the June 20th blob congestion event resulting from the Layer Zero airdrop, blob reorg rates shot up to ~7% (20132500 to 20135500).

36 observed reorgs during this 3000 block period out of a 492 monthly average is ~7% of average monthly reorgs in less than half a day!

image

It’s quite certain that we will see more black swan events like this in the future and this will spike reorg rates. The open question is what the worst case scenario might be to the network and if that is acceptable under an increased blob target/limit.

For example, in another black swan event with an increased blob target, could reorg rates be significantly higher than 7%, excacerbated by the increased number of blobs in the blob market?

2 Likes