`GET /eth/v1/builder/header/...` `duration > 950 ms`

[nalepae]

MEV boost has this option:

  -request-timeout-getheader int
        timeout for getHeader requests to the relay [ms] (default 950)

This value (950 ms) is chosen to be slightly less than the BUILDER_PROPOSAL_DELAY_TOLERANCE=1 sec spec value to allow some network latency between the beacon node and MEV boost.

However, I often see the duration field in the GET /eth/v1/builder/header/... log higher than that:

Examples with v1.11

INFO[XXXT00:25:12.121Z] http: GET /eth/v1/builder/header/... 200  duration=0.982362 method=GET path=/eth/v1/builder/header/... status=200 version=v1.11.0

And even with v1.12, > 1 second:

level=info msg="http: GET /eth/v1/builder/header/... 200" duration=1.010395 method=GET path=/eth/v1/builder/header/... status=200 version=1.12

The consequence of that is, even if MEV boost already has some relays bid, the connected beacon node falls back on the locally built block after the BUILDER_PROPOSAL_DELAY_TOLERANCE cutoff.