Allow EL to suggest local execution

[potuz]

This PR adds a boolean field shouldOverrideBuilder to engine_getPayload. This provides a way for the EL to indicate that the CL should consider using this payload and not rely in any externally provided one. Arbitrary heuristics are allowed, and the CL may or may not use this information.

Rationale: We have currently a circuit breaker to prevent using a relayer in case blocks are missing under certain scenarios. These scenarios are purely based on consensus data. I propose that we let the EL weigh in this decision based on its local view of execution data. Examples of this are

• A particular transaction, paying much more than the usual priority fee, has not been included for several slots
• A particular transaction has been included in many blocks and those have been reorged out systematically.
• A particular transaction has been included in blocks that have been invalid systematically.

EL clients that do not want to implement any changes can simply return false in this field and behavior would be as before.

[terencechain]

A possible extension to this is also to return the "reason" of the override

[ralexstokes]

I like this change as it gives the CL more signal to determine how to orchestrate block production, including using mempool heuristics to decide if local execution should be preferred over an outsource.

I do think we should be careful about how much complexity/content we put into this interface as already we have effectively added two fields to this API to open a wider channel from the EL to CL when deciding how to think about block production.

I don't think this change in isolation makes the API unwieldy in this sense but is something we should all be thinking about with future changes.

[rolfyone]

We've just had our last testnet in theory, is there a critical issue this is solving? Otherwise can it wait till next fork?

[lucassaldanha]

I agree with @ralexstokes and @rolfyone views.

I am not against this change, but I do think that we should be mindful when adding "extra" or "non-critical" information on the interface, especially when the core protocol does not require it.

And the timing isn't great as we are all ready and set for Capella. Adding new non-critical changes atm to me only adds unnecessary risk to the fork.

[ajsutton]

You could also achieve the same kind of signalling that a local block should be used by giving it an absurdly high value. Not as conceptually clean obviously but would be an effective way to show these kinds of censorship detection are viable before we change the protocol to support them.

[LukaszRozmej]

Could we make it an optional field? So missing or null value would be considered false? Then we could add it at any time without the need to bump the version.

[potuz]

having an optional field was my first reaction, but @mkalinin mentioned that even if the field is optional we should bump the version since the semantics is different. I am not an API person, but since implementing this is absolutely trivial, I would want to see this before Cancun, and of course not necessarily right now. If there's a path for clients to ship this without a hardfork I would advocate for this and it seems that bumping the version is the easiest way to do that.

[LukaszRozmej]

Not if you make it optional in the shangai version :)

[mkalinin]

Included into the Cancun spec by #425