Author: Toni Wahrstätter Source: ethresear.ch Translation: Shan Ouba, Golden Finance
Brief overview:
Builders may have no incentive to include blobs due to the higher latency they cause .
Non-MEV-Boost users on average contain more blobs in their blocks than MEV-Boost builders.
Compared with non-MEV-Boost users, the probability of MEV-Boost users being reorganized is significantly lower (see MEV-Boost for details and reorganization part).
Rsync-Builder and Flashbots builders have lower average number of blobs per block than other builders.
In the recent analysis of large blocks, blobs and reorganizations, we can see the impact of blobs on the probability of reorganization.
In what follows, I would like to take the MEV-Boost ecosystem into consideration for further discussion.
The basic question is:
-> "Does MEV-Boost affect reorganization? If so, how big is the impact?"
Blob is a "large" object , while large objects result in higher latency. Therefore, builders may not include blobs in their blocks under the following circumstances:
Builders submit blocks late within a time slot to minimize latency (see timing games).
Builders want to capture high MEV opportunities and do not want their blocks to be invalidated by unusable blobs.
Proposers are less connected (because propagation starts later).
Builder may require compensation through priority fees to include changes that may result in block propagation High latency transactions. Before 4844, these transactions were mainly transactions containing large amounts of calldata. Starting with 4844, blobs become the main driver of latency.
< /p>
As shown in the picture above, the tip for blob transactions is not as good as that of regular Type-2 transactions.
Based on this, blobs do not give builders a significant advantage when competing for the same time slot.
Another explanation could be a private deal between the builder and rollup to ensure timely inclusion of blob transactions with fees paid through side channels.
MEV-Boost and reorganization
M< strong>The EV-Boost ecosystem consists of a complex set of participants, builders, and relaysthat are well-connected and have specialization in establishing low-latency connections with peers.
Therefore, proposers who use MEV-Boost should be refactored less often than "Vanilla Builders" (i.e. users who do not use MEV-Boost).
< /p>
This expectation holds true when looking at the picture above.
We can see thatas the number of blobs increases, the probability of recombination increases. However, the reorganization probability of MEV-Boost users is much lower than that of non-MEV-Boost users (Vanilla Builders).
In this case, it is important not to confuse correlation with causation:
-> Non-MEV-Boost users are on average less complex entities, which also leads to the effect we observe in the figure above.
In this case, it is interesting to compare the average number of blobs per block between MEV-Boost users and non-MEV-Boost users.
  ;As shown in the figure above, proposers who do not use MEV-Boost have more blobs on average in their blocks, while MEV-Boost users have fewer.
This may indicate that MEV-Boost ecosystem participants (relayers and builders) are adopting a strategy beyond “include when there’s room”.
First, let's take a closer look at the builder.
< /p>
Vanilla Builders (non-MEV-Boost proposers) have the highest blob inclusion rate, followed by Beaverbuild and Titan Builder.
Rsync-Builder seems to contain far fewer blobs in its chunks.
The same applies to the Flashbots builder, which seemed to change its behavior in early May, with the average number of blobs per block approaching zero.
"Is it fair to say 'builder XY reviewed blob'?"
Unfair
Different builders use different strategies. For example, a builder like Rsync-Builder is often competitive in time slots where low latency and speed are important, and may end up winning those blocks without blobs (see selection bias).
Next, let us turn our focus to the repeater:
As shown above, Vanilla Builders have the highest average blob inclusion rate.
Ultrasound and Agnostic Gnosis repeaters came in second and third place respectively, followed by BloXroute’s repeater.
Flashbots repeater seems to contain the smallest number of blobs.
Importantly, repeaters are dependent on builders, and it is ultimately the builders who influence the diagram above.
Next steps
In the context of PeerDAS 10, the network will have to rely on nodes that are more powerful than other nodes and capable of handling more than 6 blobs per block node. Therefore, it would be very valuable to see more research on this topic.
Reproduction Appeal: If anyone can verify my results by reproducing this analysis As a result, that would be great.
Investigate reasons why some builders have significantly lower blob inclusion rates than others.
Reduce the reorganization rate for non-MEV-Boost users: Relayers can provide their block propagation services to non-MEV-Boost users to ensure that their blocks are updated Less reorganized.
The blob market is still developing, and stable blob prices have yet to be discovered. As demand for blob space increases, tips from blob transactions may catch up with regular transactions.