-
Notifications
You must be signed in to change notification settings - Fork 167
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extend builder boost factor #450
Comments
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. |
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). |
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. |
Strongly agree! The angle I was coming from was a pragmatic one; If there's an appetite to add additional parameters to the relay response, that would be extremely interesting. |
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 thebuilder_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
The text was updated successfully, but these errors were encountered: