This post examines the potential timing dynamics at play between validators and builders, particularly in the context of post EIP-4844 with blob transaction enabled. We analyze various scenarios, discussing preventable measures for each.

Vanilla Validators Without MEV-Boost:

Approximately 8% of blocks are produced without MEV-Boost, suggesting a similar proportion of validators do not use MEV-Boost. These validators are straightforward to reason, and they adhere to the default behavior of standard client implementation, including transaction from public mempool based on predetermined code. If a transaction meets the base fee requirements and sometimes a priority fee as per EIP-1599, it gets included in the block. These validators do not engage in censorship or MEV extraction based on the nature of transactions. Representing the essence of blockchain in its purest form, they are integral to its fundamental principles.

In the post EIP-4844 world, validators maintain a consistent approach, including blob transactions from the blob mempool as long as they are accompanied by adequate fees. This consistency simplifies economic modeling and analysis for entities like Layer 2 solutions or others aiming to publish blobs on the Ethereum network.

Validators Using MEV-Boost

The remainder of validators utilize MEV-Boost, indicating that block construction is outsourced to external builders, leading to increased centralization. In this scenario, validators play a limited role, focusing solely on constructing the consensus aspect of the block while deferring the execution component to the builders. This process involves validators signing the block and broadcasting it before a deadline (4s into the slot) to avoid reorg.

In most client implementation, a validator’s local execution block can override a builder block under specific triggers:

In the post EIP-4844 world, builders, not validators, have the final say on the contents of blobs. Builders can choose which blob transactions to include or exclude entirely. However, why is this process complex, and why wouldn’t builders include certain blob transactions as the default behavior of the software? Here are some speculative guesses:

To guarantee the inclusion of their blob transaction, blob publishers are compelled to increase their fees, despite already meeting the chain-reported sufficient amount. This results in a poor UX. Moreover, they must continue raising their fees until the transaction is accepted. Additionally, this approach complicates the economic modeling of the blob market, as it introduces uncertainty due to the potential for builder bias.

What can the Ethereum community do?

Before implementing protocol enforcement measures like a forced inclusion list, the best current approach is monitoring and alerting. Clients can implement plugins to detect short-term blob censoring. As a blob publisher, it is crucial to recognize that a blob might not be included despite paying a sufficient fee. In such cases, the fee may need to be increased over time.

Validator delaying block proposal for a higher block reward

It has been publicly acknowledged that validators are delaying block proposals to compete for higher rewards based on the belief that more time leads to more MEV and greater rewards. Recent developments have introduced counterpoints 3 explaining why delaying block proposals is detrimental and contributes to poor chain health. The rest of this post will discuss how post EIP4844 blob transactions further complicates this issue.

Why does the introduction of blobs further complicate this issue? To understand this, let’s first examine the consensus specification. The is_data_available definition in the consensus specs states:

The block MUST NOT be considered valid until all valid `Blob`s have been downloaded. Blocks that have been previously validated as available SHOULD be considered available even if the associated `Blob`s have subsequently been pruned.

(Source)

Let’s consider why blobs would arrive after the block. This is due to two main reasons:

Clients will often have to wait sometime after the arrival of a block before they can accurately deem it valid if the block includes blobs.

Screenshot 2023-12-30 at 4.44.46 PM1842×1124 244 KB

Diagram:

Validator and builder (independent) delay block

Two opposing forces are at play:

In this scenario, if the validator requests the block late, the builder might choose not to include the blob transaction, anticipating that the block could be reorg later. (H/T @potuz) In this situation, the transaction fee for the blob may begin to rise. Consequently, the validator may realize that not delaying the block is more profitable than delaying it, as the increased fee from the blob transaction compensates for the potential gains from delay. This scenario leads to the creation of an oscillating feedback loop. As validators adjust their strategies between delaying and not delaying the block based on profitability, and builders respond to these changes, the dynamics between transaction fees and block timing continue to fluctuate.

Screenshot 2024-01-02 at 3.17.41 PM966×426 19.2 KB

Validator and builder (vertically-integrated) delay block

A more refined prediction in the vertically integrated realm of builders and validators is that validators delaying block proposals could perceive the waiting period as a chance to justify the delay. Ideally, they would aim to time the delay of the block proposal to offset the variance in arrival times between the block and the slowest-arriving blob. This strategy ensures that the block and the blobs arrive simultaneously for their peers. It will consistently subscribe to the maximum number of peers possible on the blob subnet to minimize network hops. Some may even use heuristics to dynamically figure out how long to delay, based on the propagation of the last few blocks and blobs.

Screenshot 2023-12-30 at 4.48.33 PM1848×1178 257 KB

Diagram:

Caveat:

Our current understanding of blob arrival delay is based exclusively on data from previous devnets and the Goerli shadowfork. The network topology of this setup is distinct from that of other testnets or the mainnet. Continual monitoring is essential, as a minimal delay might render our present conclusions obsolete.

Possible short-term solutions

Conclusion

Validators are currently engaged in timing games, but their behavior may become more unpredictable post EIP4844, especially considering that blob transactions are likely to introduce additional delays before a block is validated and becomes the head.

Validators have several strategies they can adopt:

How these strategies will play out in practice remains to be seen. It will require enhanced infra monitoring capabilities to observe their effects over the upcoming testnets and eventually on the mainnet.