ethereum / ethereum/beacon-APIs
Extend builder boost factor
- Dominant language
- HTML
- Stars
- 389
- Forks
- 224
- Avg merge
- 8h 29m
- Merged PRs (30d)
- 3
Description
## 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
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with the proposal and the linked beacon-APIs pull request #386 and mev-boost issue #653 to understand the existing builder_boost_factor behavior and intended API change. Done means the specification defines builder_boost_gas_factor alongside the existing parameter and clearly describes the combined profitability and gas-used selection criteria.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- openapi
- Domain
- api
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100