search

ethereum / beacon-APIs

Collection of RESTful APIs provided by Ethereum Beacon nodes
https://ethereum.github.io/beacon-APIs/
Creative Commons Zero v1.0 Universal
335 stars 169 forks source link

Extend builder boost factor #450

Open antonydenyer opened 5 months ago

antonydenyer commented 5 months ago

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.

https://github.com/ethereum/beacon-APIs/pull/386 https://github.com/flashbots/mev-boost/issues/653

mcdee commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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

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 commented 4 months ago

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.