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.

[wemeetagain]

This is a cheap check that should come first or at least before the expensive checks...

Specs show this as first https://github.com/ethereum/consensus-specs/blob/master/specs/fulu/p2p-interface.md#blob-subnets

[lodekeeper]

Fixed in 589caee464: the ALREADY_SEEN_TUPLE lookup now runs right after extracting the sidecar header, before structural verification, parent-state regen, and KZG checks. The markSeenDataColumnSidecar call stays at the end after full validation passes.

[nflaig]

why do we need this, doesn't the BlockInput handle seen columns already?

[lodekeeper]

These two checks have different keys and the spec mandates the tuple check.

• BlockInput.hasColumn (gossipHandlers.ts:354-366) is keyed by (blockRoot, columnIndex) — it short-circuits re-gossip of the same column for the same block (or columns we already fetched via reqresp / getBlobsV2).
• seenBlockInputCache.isSeenDataColumnSidecar is keyed by (slot, proposerIndex, columnIndex) and is the spec's first check. It catches equivocation: a proposer signing two different blocks at the same slot produces sidecars with the same (slot, proposer, index) but different blockRoot, so the BlockInput-keyed check would miss the second one and we'd re-run KZG + propagate. The class comment at seenGossipBlockInput.ts:440-442 calls this out.

Same shape as the blob path (isSeenBlobSidecar, blobSidecar.ts:182).

[nflaig]

@lodekeeper are you sure about this, if that's the case this seems like a bug in our current implementation

[lodekeeper]

Good catch — my "spec orders this first" framing was wrong. Re-reading the Deneb spec and Fulu spec, the IGNORE tuple check is listed after KZG and qualified by "with valid header signature, sidecar inclusion proof, and kzg proof" — i.e. "first validated tuple", not "first tuple seen".

So neither file has a literal spec-correctness bug:

• Mark side (writes to cache) is what the "with valid…" qualifier constrains — and in both files markSeen* runs only after all checks pass (data column line 231, blob line 209). Good.
• Read side placement is up to the client. Lighthouse uses a two-phase pattern: an early read-only check (verify_is_unknown_sidecar) for perf, then the late write under the spec-listed position. See consensus-specs#3261 for the related blob-spam discussion.

This PR places the data column read check early; blobSidecar.ts (on this branch) places it after KZG. Both are correctness-equivalent given the post-validation mark; the early position saves a BLS sig + inclusion proof + KZG verify on duplicate gossip.

The two-key argument still holds: BlockInput.hasColumn catches re-gossip of (blockRoot, columnIndex), seen-tuple catches equivocations on (slot, proposerIndex, columnIndex). So we still need the seen-tuple check somewhere. Happy to align both files to the early position in a follow-up if you prefer the perf path.