ethereum / builder-specs

Specification for the external block builders.
https://ethereum.github.io/builder-specs/
Creative Commons Zero v1.0 Universal
179 stars 61 forks source link

Adding optional timestamp header to Builder API block-header request #106

Open alextes opened 2 weeks ago

alextes commented 2 weeks ago

Why the Change Currently, competitive relays use various timing mechanisms to respond with the highest-value bid within the proposer deadline. Proposers prefer the highest bid, builders prefer relays that give them the most time. This is how relays are incentivized to delay some, but not too much. Knowing the latency between relay and proposer is critical for these timing optimizations.

mev-boost 1.8, released in August started including the HTTP header X-MEVBoost-StartTimeUnixMS on block-header requests. the PR proposed by bloXroute relay can be found here: mev-boost #647.

Benefits

  1. More timely bids especially helpful for geographically decentralized or latency-variant proposers.
  2. Maximize bid value: later, higher-value bids could still be delivered in time.
  3. Less implementation drift we'd avoid some clients having significant advantages over others and fragmenting how this is implemented.

The most popular implementations that would benefit here are https://github.com/attestantio/vouch (at least 12% of blocks) and Kiln (at least 4%). I'll make sure to reach out to them and flashbots/mev-boost also.

Proposed Solution If agreed to, here’s a suggested approach:

  1. Optional personally (i'm on the ultra sound team btw!), and talking to @ralexstokes, i'd say this should be optional. it is in no way required to run the mev-boost / pbs protocol. at most you're losing some efficiency, or see some implementations outperform others for unclear reasons.
  2. Location of Data the current request is a GET, adding it as a query parameter could work but would be the first. As this is almost transport level detail and mev-boost already supports a header i think that option is best.
  3. Naming Convention: The current header name X-MEVBoost-StartTimeUnixMS works, but if neutrality is preferred, i'd propose x-request-timestamp-ms instead. Whatever others want is fine with me, the last thing i want is to bikeshed this 😅.

current specification of the request here

Exact OpenAPI spec change as i'm proposing it, under parameters add:

- name: X-MEVBoost-StartTimeUnixMS
  in: header
  required: false
  description: |
    Optional header containing a Unix timestamp in milliseconds representing
    the time the request was sent. This header can be used to measure latency
    or for other timing-based processing needs.
  schema:
    type: integer
    format: int64
    example: 1672531199000  # Example timestamp in milliseconds
mcdee commented 3 days ago

I understand the idea. X- headers have been deprecated for quite a while now, and unfortunately the standard Date header is only in seconds precision, so perhaps something nice and simple like Date-Milliseconds would work for the name.

alextes commented 3 days ago

i didn't know about the X- deprecation, RFC 6648 apparently. let's not do that then.

Date-Milliseconds works for me 👍.

i'll do another round of pinging those who'd be affected by this.

ralexstokes commented 1 day ago

Date-Milliseconds sounds good to me as well

there's a deep debate to be had around how this data is used and what it implies for the network

however, given that this information is already included in implementations, this issue would just suggest standardizing something that is already being used

so I'd support a PR to formalize this