Discussion: not return headers to CL client if >3 sec into slot?

[metachris]

Proposers with slow network connection might call getPayload too late (getPayload requests arriving at the relay >4s into the slot will be rejected).

If there's a slow connection, getHeader will probably also be slow.

Should mev-boost not return headers to CL client if >3 sec into the slot, as the getPayload request would likely end up too late at the relay?

Could also make this opt-in or opt-out 🤔

cc/ @ralexstokes @jtraglia @terencechain @michaelneuder

See instances of this happening to users, when getHeader response was received at 3 seconds into the slot:

• Validator block proposal missing #517
• Missing Block #516

[qianxiaofeng]

FYI: As a few similar cases we encountered, the block was proposed successfully on chain, but a deadline timeout error was logged by MEV.

[ralexstokes]

I think this makes sense, esp given recent changes to other synchrony assumptions made at the relay

If anything we should bias towards block production, defaulting to local building, to support chain health

[Neq900]

I experienced a missing block proposal due to late inclusion again. I don't get it, as my internet connection is very stable. I only have a few validators and now it's the second time I'm missing a block proposal. Even though the inclusion wasn't too late, the relayer rejected it as it arrived slightly too late.

...level=info msg="submitBlindedBlock request start - 3965 milliseconds into slot...

..."sent too late - 4459 ms into slot"...
..."sent too late - 5378 ms into slot"...
..."sent too late - 6216 ms into slot"...
..."sent too late - 6922 ms into slot"...

I don't understand those high delays. It's about seconds... I'm constantly monitoring my internet connection and there were 100% no outages, especially not seconds with no internet connection.

Something has gone badly wrong since v1.6

I'd appreciate a setting which would lead to a local block proposal in case of the chance for a late inclusion.

[kolydart]

Have you changed the max-peer defaults in EL or CL? (--max-peers = xx)

[Neq900]

I used to have it default in Prysm but after the missing proposal two weeks ago, I changed it to 100. I thought I give it a try. What would you recommend there? I think default is 55 and that used to work fine in the past.

[kolydart]

I am not sure. There are some incidents where setting too high a peer number could hurt the validator's efficiency. The defaults are usually carefully thought by the developers.

In my case, in the past I did the opposite silly thing; I reduced the max-peer number to save bandwidth.
Of course I took my lesson by missing proposals.