Gloas containers additions

[shane-moore]

Changes

• renamed execution payload header to execution payload bid (#4525)
• removed builder_payment_threshold_numerator and builder_payment_threshold_denominator from chain_spec Config since are constants per the spec
• PayloadAttestationMessage.signature type updated to Signature since is an unaggregated signature
• add some envelope helpers, which are useful in later VC -> beacon node envelope requests PR's

@ethDreamer

[ethDreamer]

This function isn't used so I would leave it out. We have other ways of doing these things if it is needed.

[shane-moore]

yes, alternatively, we could match on fork_name, kind of like this:

SupportedProtocol::BlocksByRangeV2 => match fork_name {
            Some(ForkName::Altair) => Ok(Some(RpcSuccessResponse::BlocksByRange(Arc::new(
                SignedBeaconBlock::Altair(SignedBeaconBlockAltair::from_ssz_bytes(decoded_buffer)?),
            )))),

            Some(ForkName::Base) => Ok(Some(RpcSuccessResponse::BlocksByRange(Arc::new(
                SignedBeaconBlock::Base(SignedBeaconBlockBase::from_ssz_bytes(decoded_buffer)?),
            )))),

the idea was that it would be perhaps more extensible to use from_ssz_bytes_for_fork so you wouldn't have to add variants for new forks in various places across the repo. just add the fork variant once to SignedExecutionPayloadEnvelope::from_ssz_bytes_for_fork instead, so you can just do things like:

   Ok(Some(RpcSuccessResponse::ExecutionPayloadEnvelopesByRange(
                        Arc::new(SignedExecutionPayloadEnvelope::from_ssz_bytes_for_fork(
                            decoded_buffer,
                            fork_name,
                        )?),
                    )))

i used the from_ssz_bytes_for_fork in a couple p2p boilerplate PR's for ExecutionPayloadEnvelopesByRange and ExecutionPayloadEnvelopesByRoot

• https://github.com/shane-moore/lighthouse/blob/2abfbdab4814278a8ca64aa8119ffcb42ba0d25d/beacon_node/lighthouse_network/src/rpc/codec.rs#L741-L749
• https://github.com/shane-moore/lighthouse/blob/b2de0c5e01b2ff3ce50dfaee3450ca461d6c1fbb/beacon_node/lighthouse_network/src/rpc/codec.rs#L778-L783

but can easily update them to just use match fork_name approach instead. is preferable to kill from_ssz_bytes_for_fork and go this route?

[ethDreamer]

it's rare that we need a method like this because usually when we decode from the network we have context bytes to tell us what we decode and then we would do something like:

ExecutionPayloadEnvelope::Gloas(<_>::from_ssz_bytes(bytes))

when we do need a method for decoding by fork variants, we have traits for that. Since the future fork doesn't even exist yet, it's best to leave out for now.

[shane-moore]

i feel you on that! thanks for the context about context bytes ha

just removed SignedExecutionPayloadEnvelope::from_ssz_bytes_for_fork in latest commit

[ethDreamer]

This function is also not used so I would leave it out.

[shane-moore]

i think this helper is just used later in this VC block production PR here:
https://github.com/shane-moore/lighthouse/blob/4eac78c70d1b1cb046180d21b6f81ffa5d617d9a/validator_client/lighthouse_validator_store/src/lib.rs#L760-L784

perhaps I just add the from_envelope to that PR instead?

[ethDreamer]

no that's fine we can leave this in then