Clarify validator responsibilities

[ralexstokes]

Validators are expected to periodically (once per epoch? once per N epochs?) submit a SignedValidatorRegistration to builder software but I do not think this is document anywhere outside of the comment in the https://github.com/ethereum/beacon-APIs

We should craft a spec/validator.md that contains some light prose on the expected validator flow to be able to participate in the external builder network.

[lightclient]

Agreed. We should also outline how validators should propose blocks -- i.e. they should still request against local EL in case the external builder fails, there should be some mechanism to force local EL block if the previous N beacon blocks had empty/invalid execution payloads, etc. I started something a while back but it didn't make it into v0.0.0:

The Builder API offers a protocol for proposing blocks built by external entities, but it is not a complete replacement for locally sourced blocks. Builders may timeout, go offline, or otherwise behave dishonestly. It’s crucial that validators be prepared for this.

A potential expansion of this process, which takes into account results from the Builder API, could be as follows:

First, the CL client will need to decide on a deadline for releasing the block to the network. For illustrative purposes, suppose that deadline is 4 seconds into the slot. This is the maximum amount of time the CL is willing to expend on block production. If no result has be retrieved from the Builder API at this point, the CL should sign and release a block using a local payload. Now, working backwards, the CL can decide the maximum amount of time it will wait for an ExecutionPayloadHeader from the builder. The API specifies that the builder must respond immediately to header requests with the best header on hand, so it is fair game for the CL to expect this request should be quite fast.

Once the CL has received both a local payload and an external payload header, it should compare the expected value of proposing each. This isn’t trivial today, because GetPayload doesn’t return the expected value of local payloads. This is a bit of an open question as to how to handle this in the short term. In the medium term, we should expand the method’s response to also return the expected value of the local payload. After deciding which payload is more profitable, the CL should seal and release it. If the CL uses an external payload header, it will need to submit the SignedBlindedBeaconBlock to the builder to get the unblinded values. This shouldn’t cut much into the deadline though, as the builder will have all the necessary data (and incentive) to gossip the signed block as soon as it receives the request.

[metachris]

Sending the validator registration once an epoch might be a good starting point.