Add Gloas boilerplate

[macladson]

Proposed Changes

Adds the required boilerplate code for the Gloas (Glamsterdam) hard fork. This allows PRs testing Gloas-candidate features to test fork transition.

This also includes de-duplication of post-Bellatrix readiness notifiers from #6797 (credit to @dapplion)

Additional Info

Not all tests have been updated yet.

[dapplion]

@macladson can you add this de-duplications?

• Dedup post merge readiness notifiers #6797

[michaelsproul]

Can we resolve conflicts on this and merge?

Might be nice before your types refactor @macladson?

[macladson]

I have rebased this code onto #7909 to clear up the confusion around payload versioning. I also removed the new versions of get and new_payload and Gloas will just reuse the Fulu ones for now. These aren't too hard to add later when required. As for any missing tests, I think we can just update those as we start adding Gloas content, it's not worth holding off on getting this merged.

Edit: With #7909 merged this is now ready for review

[mergify]

Some required checks have failed. Could you please take a look @macladson? 🙏

[shane-moore]

Note: Comment below has no impact on this PR. just something we'll have to address in epbs branches, and noting here while reviewing since it's top of mind

When loading blinded blocks from the db, we run reconstruct_default_header_block to get a default ExecutionPayloadHeader. If we expect the db to store blinded blocks for Gloas, then this ForkName::Gloas => ExecutionPayloadGloas::default().into() variant will be hit for creating a default payload, but when we try let header_from_payload = ExecutionPayloadHeader::from(payload.to_ref()); right below it, ExecutionPayloadHeader is no longer supported in gloas, so it will fail.

I haven't thought enough about how the db will be refactored, but my intuition is that we will only store Full beacon blocks post-gloas, so we should be able to move Gloas into the variant:

 ForkName::Base | ForkName::Altair => {
            return Err(Error::PayloadReconstruction(format!(
                "Block with fork variant {} has execution payload",
                fork
            ))
            .into())

[shane-moore]

Note: Comment below has no impact on this PR. just something we'll have to address in epbs branches, and noting here while reviewing since it's top of mind

we removed the gloas variant of generate_rand_block_and_blobs in eip-7732 branch since beacon blocks no longer contain execution payloads or blobs.

The goal of this test seems to be:

1. Generate a beacon block with blob commitments
2. Generate corresponding blob sidecars
3. Link them together with proofs

This won't work in gloas, since the kzg commitments will be revealed along with the ExecutionPayloadEnvelope instead of the BeaconBlock. We should probably make a comment in the epbs branches that we'll need a new test based off this separation

[shane-moore]

much cleaner now 🤙

[shane-moore]

LGTM, all changes seem isolated to gloas variants, so no side effects on current functionality. ofcourse could use a few more sets of 👀

[ethDreamer]

LGTM!

[ethDreamer]

As Shane mentioned, there are many things in this PR that don't make total sense in the context of block payload separation. So we've been addressing them as they come up in the implementation of Gloas. It doesn't make sense to address them in this PR as it's beyond the scope and will start to cause conflicts with the changes we've already made.

[michaelsproul]

We'll be able to delete this once Fulu goes live on mainnet.

i.e. we can avoid making any more Gloas-related changes to this (hopefully).

[michaelsproul]

LGTM, let's merge