Don't use a builder with an optimistic head

[paulhauner]

Description

Lighthouse currently will allow proposing a block atop a head which it knows to be optimistic. Whilst this seems wrong, it is legitimate since an EL can only build a payload atop a parent payload when the parent is known and valid. Therefore, if the EL is able to produce a payload atop a payload which Lighthouse considers to be optimistic, then Lighthouse just had an outdated view of the EL payload tree.

This all holds true whilst we use a local EL, however it starts to become dubious when builders are involved. It might be the case that a malicious builder can produce a chain the honest ELs will never resolve, therefore forcing CLs into an optimistic state. To mitigate this, I propose that if the head is optimistic then we don't sign across any blinded payloads from builders.

Implementation

I think the implementation must be careful not to just check that the head is optimistic in one action the build a block in another without ensuring that the head hasn't changed between those two calls.

It may be desirable to try and produce a block using the EL when the head is optimistic, without checking the builder. This gives us a chance to still produce a block if the EL happens to sync in the nick of time. The risk here is that MEV can be disabled by forcing a node into optimistic sync at just the right time, however this is a very fiddly attack and we already operate under the assumption that an attacker cannot reliably force nodes into optimistic sync.

[realbigsean]

Let me know what you think about the implementation in #3412

I think the implementation must be careful not to just check that the head is optimistic in one action the build a block in another without ensuring that the head hasn't changed between those two calls.

Builder queries are made with the parent block hash so as long as we are checking that this execution status is not optimistic, we should be good.

It may be desirable to try and produce a block using the EL when the head is optimistic, without checking the builder. This gives us a chance to still produce a block if the EL happens to sync in the nick of time

By adding this to the is_healthy check, we use the fallback-from-builder logic that already exists for other chain health conditions

[paulhauner]

Resolved via #3412 🎉