5067 compliance

[tbenr]

https://github.com/ethereum/consensus-specs/blob/f6d34a1c9a2c7e3fba8a267395050c68e152ec9f/tests/core/pyspec/eth_consensus_specs/test/helpers/genesis.py#L213

with additional tests

Let's follow ethereum/consensus-specs#5149 in this pr

Documentation

• I thought about documentation and added the doc-change-required label to this PR if updates are required.

Changelog

• I thought about adding a changelog entry, and added one if I deemed necessary.

---

Note

Medium Risk
Changes Gloas genesis execution state initialization, which can affect first post-genesis block/fork-choice behavior; coverage is improved with new targeted tests but any mismatch could impact network startup behavior for Gloas.

Overview
Adjusts Gloas genesis initialization so latestBlockHash remains 0x00…00 (treating genesis as having an EMPTY execution parent) while the genesis latestExecutionPayloadBid.blockHash is set to the Eth1 block hash.

Adds/extends Gloas-focused tests to lock in genesis semantics across genesis generation, block processing (processParentExecutionPayload not updating latestBlockHash at genesis), fork choice parent payload status when the parent’s bid blockHash is zero, and withdrawals processing not advancing indices at genesis.

^{Reviewed by Cursor Bugbot for commit 3e53a8f. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Genesis detection broken in block processor after bid change

High Severity

Changing the genesis bid's blockHash from Bytes32.ZERO to eth1BlockHash breaks the isGenesisBlock check in BlockProcessorGloas.processParentExecutionPayload (line 141), which still uses parentBid.getBlockHash().equals(Bytes32.ZERO). After this change, that check evaluates to false at genesis. The sibling check in WithdrawalsHelpersGloas correctly uses stateGloas.getLatestBlockHash() instead. The new test masks this by constructing a parentBid with blockHash = Bytes32.ZERO, which no longer reflects the actual genesis state.

Additional Locations (1)

• ethereum/spec/src/test/java/tech/pegasys/teku/spec/logic/versions/gloas/block/BlockProcessorGloasTest.java#L38-L40

 

^{Reviewed by Cursor Bugbot for commit e3c30cc. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

^{Reviewed by Cursor Bugbot for commit 3e53a8f. Configure here.}

[cursor]

Test uses wrong genesis bid blockHash, exercises wrong path

Medium Severity

The test creates a parentBid with blockHash = Bytes32.ZERO, but the genesis generator now sets blockHash = eth1BlockHash (non-zero). This causes the test to exercise the isGenesisBlock path in processParentExecutionPayload (via parentBid.getBlockHash().equals(Bytes32.ZERO)), which is not the path that actually executes for genesis blocks in production. In reality, isGenesisBlock would be false and the isParentBlockEmpty path would handle the genesis case instead. The test passes but doesn't validate the actual production code path, masking potential regressions in the isParentBlockEmpty logic.

 

^{Reviewed by Cursor Bugbot for commit 3e53a8f. Configure here.}

[StefanBratanov]

Closing this, will implement ethereum/consensus-specs#5172