You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
More timely bids especially helpful for geographically decentralized or latency-variant proposers.
Maximize bid value: later, higher-value bids could still be delivered in time.
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:
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.
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.
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 😅.
Exact OpenAPI spec change as i'm proposing it, under parameters add:
- name: X-MEVBoost-StartTimeUnixMSin: headerrequired: falsedescription: | 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: integerformat: int64example: 1672531199000# Example timestamp in milliseconds
The text was updated successfully, but these errors were encountered:
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
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:
X-MEVBoost-StartTimeUnixMS
works, but if neutrality is preferred, i'd proposex-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:The text was updated successfully, but these errors were encountered: