test: data column sidecar gossip validation spec tests

[lodekeeper]

Motivation

Stacks on top of #9372 to extend Lodestar's gossip-validation spec-test coverage from data_column_sidecar (PeerDAS / Fulu+).

Description

Two follow-up commits on nflaig/deneb-gossip-spec-tests:

1. feat(test): wire gossip_data_column_sidecar into spec test harness — adds harness support for the data_column_sidecar topic in the gossip validation spec tests (consensus-specs PR Add executable gossip validation functions for deneb ethereum/consensus-specs#5146 / Add LC header validations #5246).
2. feat(beacon-node): validate finalized-ancestor and seen-tuple for data column sidecars — fills in the source-side gaps the harness surfaced: finalized-ancestor check on the sidecar's block root and the (slot, proposer_index, column_index) seen-tuple check, matching the spec's validation conditions.

Spec test results

Full networking suite passes on both presets against nflaig/deneb-gossip-spec-tests base:

• spec-minimal: 920 passed in 20.17s (logs/gossip-spec-rerun-minimal-2026-05-30-v2.log)
• spec-mainnet: 932 passed in 300.06s (logs/gossip-spec-rerun-mainnet-2026-05-30.log)

Notes

• Base: nflaig/deneb-gossip-spec-tests (PR test: deneb and electra gossip validation spec tests #9372). Will rebase onto unstable once test: deneb and electra gossip validation spec tests #9372 lands.
• No changes outside the gossip validation path for data_column_sidecar.
• pnpm lint clean.

---

🤖 Generated with AI assistance

[gemini-code-assist]

Code Review

This pull request implements gossip validation rules 9 and 12 for Fulu data column sidecars, including tracking seen sidecar tuples and verifying that the finalized checkpoint is an ancestor of the sidecar's block. It also integrates these validations into the spec tests. Feedback points out a critical issue in the ancestor check where calling chain.forkChoice.getAncestor with a slot higher than the parent block's slot throws an error, causing valid sidecars to be incorrectly rejected. A fix is suggested to handle cases where the parent block's slot is less than or equal to the finalized ancestor slot.

[gemini-code-assist]

If parentBlock.slot is less than or equal to finalizedAncestorSlot (which can happen when there are skipped slots or when the parent block is before the finalized slot), calling chain.forkChoice.getAncestor with a slot higher than the block's slot will throw an error. This causes ancestorRoot to remain undefined, leading to an incorrect FINALIZED_NOT_ANCESTOR rejection for a valid sidecar.

According to the consensus spec's get_ancestor logic, if the block's slot is less than or equal to the requested ancestor slot, the ancestor is the block itself (parentRoot). We should handle this case explicitly to avoid throwing an error and incorrectly rejecting valid gossip messages.

  let ancestorRoot: RootHex | undefined;
  if (parentBlock.slot <= finalizedAncestorSlot) {
    ancestorRoot = parentRoot;
  } else {
    try {
      ancestorRoot = chain.forkChoice.getAncestor(parentRoot, finalizedAncestorSlot).blockRoot;
    } catch {
      // parent not in fork-choice or finalized slot before parent's chain start
    }
  }

[lodekeeper]

Thanks for the careful read, but I think the premise here is incorrect.

getAncestor in packages/fork-choice/src/protoArray/protoArray.ts:1523-1541 follows the consensus-specs get_ancestor algorithm:

if (block.slot <= ancestorSlot) {
  return block;
}

It only throws in two cases:

1. MISSING_PROTO_ARRAY_BLOCK if blockRoot isn't in the proto-array. We already confirmed parentBlock exists via chain.forkChoice.getBlockHexDefaultStatus(parentRoot) just above (line 79-96), so this can't fire.
2. UNKNOWN_ANCESTOR if walking up hits a missing parent — but that requires block.slot > ancestorSlot, i.e. it's not the boundary case being described.

For parentBlock.slot <= finalizedAncestorSlot, getAncestor returns parentBlock directly, so ancestorRoot = parentRoot. The subsequent ancestorRoot !== finalizedCheckpoint.rootHex check then resolves correctly:

• Skipped slots at the checkpoint boundary (finalized root anchored at slot < finalizedAncestorSlot, parentRoot equals that root): ancestorRoot = parentRoot = finalizedRoot → PASS ✅
• Parent on a different fork at/before the finalized slot: ancestorRoot = parentRoot ≠ finalizedRoot → REJECT ✅ (correct rejection — that parent isn't on the finalized fork)

This pattern directly mirrors blobSidecar.ts:144-159, which has been live for some time without producing false rejections. The proposed fix is functionally equivalent (it just inlines the early-return that getAncestor already does internally).

Spec reference: https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/fork-choice.md#get_ancestor

No change needed here.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 3435d9b7a6

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Use the fork SSZ type for data-column gossip tests

When these networking tests run for gloas/gossip_data_column_sidecar, this always deserializes the message as the Fulu container, which still expects signedBlockHeader, kzgCommitments, and an inclusion proof. Gloas data-column sidecars instead contain slot and beaconBlockRoot, so valid Gloas fixtures will be mapped to SPEC_INVALID_SERIALIZED_BYTES and rejected before the Gloas validation path can be exercised; the harness should deserialize with sszTypesFor(fork).DataColumnSidecar and dispatch to the appropriate validator.

Useful? React with 👍 / 👎.

[lodekeeper]

You're right that the Gloas DataColumnSidecar differs from Fulu — packages/types/src/gloas/sszTypes.ts:301-313 drops signedBlockHeader / kzgCommitments / kzgCommitmentsInclusionProof and adds slot + beaconBlockRoot. Deserializing Gloas bytes through the Fulu container would indeed reject as SPEC_INVALID_SERIALIZED_BYTES.

Scope-deferring this for two reasons:

1. No Gloas DCS gossip fixtures yet. Both consensus-specs PRs (Track sync committee metrics #5146, Add LC header validations #5246) and the current test corpus only include gossip_data_column_sidecar under Fulu:

   packages/beacon-node/spec-tests/tests/{minimal,mainnet}/fulu/networking/gossip_data_column_sidecar
   

   The Gloas networking/ folder only has slashings, BLS-to-execution, sync committee — no DCS fixtures. Adding the dispatch now would be untested code that the runner never reaches.

2. Different validator signature. validateGossipGloasDataColumnSidecar(chain, payloadInput, sidecar, …) takes a PayloadEnvelopeInput, which isn't present in the standalone-DCS gossip fixture format. Once upstream defines the Gloas DCS fixture layout (likely coupled with the gossip_execution_payload_envelope flow), the harness can construct the right input shape and dispatch via sszTypesFor(fork).DataColumnSidecar.

Tracking as a follow-up — I'll wire the per-fork dispatch when Gloas DCS gossip fixtures land in consensus-specs.