Adding optional timestamp header to Builder API block-header request

[alextes]

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]

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]

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]

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

[alextes]

I feel like there's been plenty time to chime in. I've pinged relevant people multiple times.

Maybe if we don't hear anything by next week we look to merge? Perhaps if we really want more input still, then @ralexstokes a round of pinging from you could help? I'd rather not ping Kiln / Flashbots a third time 😅 but also they don't have to chime in imo.

[metachris]

To clarify, this is about

1. Standardizing the already used header
2. Changing the header from X-MEVBoost-StartTimeUnixMS to Date-Milliseconds

I don't disagree, although I don't really see the need to change the header key. If you all prefer the new header, I'm not feeling strongly and am on board too.

[metachris]

Btw, the regular Date header uses this format:

Date: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT

I'd much prefer our header to keep being a simple unix timestamp in milliseconds.