ethereum / ethereum/beacon-APIs

Extend builder boost factor

Open
#450 4 comments 0 reactions 0 assignees View on GitHub
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.