Add engine_forkchoiceUpdatedV4

[mcdee]

Validator clients have the ability to read a configuration file that provides per-validator values for fee recipient and gas limit, however although execution nodes are passed the fee recipient they are not passed the gas limit. This results in the execution nodes using what users will see as incorrect values.

This change adds a gasLimit field to the payloadAttributes section of the fork choice updated call, which provides this additional information and allows execution nodes to create payloads with the appropriate gas limit.

[g11tech]

also "/eth/v1/validator/prepare_beacon_proposer" need to have gas limit included in api request as well

[mcdee]

also "/eth/v1/validator/prepare_beacon_proposer" need to have gas limit included in api request as well

Yes we'll need to bump the version as well.

That said, the beacon node does obtain this information in /eth/v1/validator/register_validator. Although it isn't a perfect solution by any means the beacon node could obtain the gas limit from here until we have a v2 of prepare_beacon_proposer in place.

[nflaig]

That said, the beacon node does obtain this information in /eth/v1/validator/register_validator. Although it isn't a perfect solution by any means the beacon node could obtain the gas limit from here until we have a v2 of prepare_beacon_proposer in place.

maybe a good opportunity to consolidate those apis as suggested in ethereum/beacon-APIs#435

[mcdee]

That said, the beacon node does obtain this information in /eth/v1/validator/register_validator. Although it isn't a perfect solution by any means the beacon node could obtain the gas limit from here until we have a v2 of prepare_beacon_proposer in place.

maybe a good opportunity to consolidate those apis as suggested in ethereum/beacon-APIs#435

If the consensus nodes want to go along with the suggestion at ethereum/beacon-APIs#435 (comment) that would certainly simplify things. The edge case of the beacon node not knowing the validator registrations directly after a restart is, though, real so we'd need to consider how to handle this.

[nflaig]

If the consensus nodes want to go along with the suggestion at ethereum/beacon-APIs#435 (comment) that would certainly simplify things. The edge case of the beacon node not knowing the validator registrations directly after a restart is, though, real so we'd need to consider how to handle this.

Let's continue that discussion on the beacon-api issue

[g11tech]

lgtm