Extend builder boost factor

[antonydenyer]

Background

One of the motivations around PBS was to enable solo validators access to private order flow that was only available to sophisticated centralised actors. Validators could delegate block building to someone else because they could build a better block. The problem is that the only dimension that we defined better on was profit. Currently, users have the option to choose a locally built block or a remote block based on the proposer rewards they will get. They can set the builder boost value to be something that is in line with their intrinsic motivations. For instance, they may prefer to have locally built blocks most of the time unless outsized rewards are available from a builder.

Vertically integrated block builders play latency games with the size (kb) of the block they produce to enable faster transmission of the block so that they can send the block later in the slot. This means that blocks are smaller than they otherwise could be whilst still being more profitable than locally built blocks. The impact is that transactions take longer to be included, especially during periods of high price volatility.

Proposal

To enable validators to express an opinion about what constitutes "best", we should allow them to choose a local block or builder block based on the gas used.

Add builder_boost_gas_factor parameter

Add a builder_boost_gas_factor parameter to extend the builder_boost_factor behaviour. This would require the remote block to be more profitable and use more gas than a locally built block.

#386
flashbots/mev-boost#653

[mcdee]

The gas used in a block has little relationship to the size of the block (see: blob transactions). So I don't think that this would address the issue raised.

[michaelsproul]

We could also add an option to prefer a local block if it has more blobs.

Anecdotal, but I proposed a block locally the other day with 6 blobs, while the slots either side (built by builders) had far fewer (0 and 2).

[mcdee]

I haven't considered this deeply, but it seems that there are multiple dimensions in play here, at least:

• number of blobs
• value to proposer
• gas used
• size of payload

which will have different weights to any given proposer. We need to consider how to surface this data: the first three items are returned by the current build bid structure, but payload size (assumedly the size of the payload after SSZ encoding) is not present.

And then work out some sane way to decide on which block is preferred, given different weightings of each value as per the proposer's requirements.

[antonydenyer]

that there are multiple dimensions in play here

Strongly agree!

The angle I was coming from was a pragmatic one; gas used is already available on the api response from the relay.

If there's an appetite to add additional parameters to the relay response, that would be extremely interesting.