Description

According to the execution API spec, consensus clients must call engine_forkchoiceUpdatedV1 (fcU) with a payloadAttributes that is non-null when the node expects to produce a block in the next slot. This gives the execution engine time to prepare the optimal set of transactions, before we request the payload.

Lighthouse is not presently sending the payloadAttributes in advance. Instead, it always ends up hitting the fall-back path which sends the fcU message immediately before the engine_getPayloadV1 call.

Mechanisms

In order to supply payloadAttributes in advance, we need the VC to call the /eth/v1/validator/prepare_beacon_proposer, an endpoint currently implemented in a PR to the beacon-APIs repo.

The simplest implementation would be for the BN to immediately do an fcU call when it receives something on the prepare_beacon_proposer endpoint. However, I don't think that's how we should implement it. There's a whole bunch of edge-cases regarding re-orgs and timing assumptions, I think it's best if the VC just says "hey I have this validator" and then the BN takes care of issuing the right call at the right time. AFAIK, this is how all other clients are implementing it too.

To implement it properly, I think we should build a service in the BN that accepts prepare_beacon_proposer calls and then "registers" a validator_index as a local, potential block producer. Then, that service would issues the fcU with the appropriate payloadAttributes when it's some time (t) before the start of a slot. It would also be re-org aware and could make sure the execution engine is kept up-to-date relative to a changing head.

The API docs state:

The information supplied for each validator index will persist through the epoch in which the call is submitted and for a further two epochs after that, or until the beacon node restarts.

So, this service needs to track each validator for 2-3 epochs and then forget about it. That means that the VC will need to issue this call at least once every 2-3 epochs. I suggest we do it more frequently, perhaps every epoch or every slot.

Steps Required

As I see it, we need to do the following things:

1. Add the mechanisms to the VC to poll the prepare_beacon_proposer with all its validators (that have validator indices) every slot/epoch/whatever.
2. Add the service to the BN that can track the registered validator indices and issue the fcU calls at the appropriate times.
   • Note: we can call fcU on the EL whenever we want, we don't have to make sure we call it when our head changes. We can call it with the same head if we like.
3. Build tests