An archive node custodies every column group but advertises CUSTODY_REQUIREMENT.
IsArchivedMode is true when --caplin.blobs-archive or --caplin.blobs-immediate-backfill is set (cl/das/peer_das.go:262), and resubscribeGossip then subscribes to all DataColumnSidecarSubnetCount (128) subnets (:295-299). Confirmed on a gnosis archive node: 128 JOIN /eth2/<digest>/data_column_sidecar_N topics, and blob reconstruction from gossiped columns succeeds at the tip — 37 [blobsRecover] recovering blobs with 37 matching recovering done, no not enough columns to recover.
The ENR and the metadata response tell a different story. The only non-mock path that raises the count is UpdateValidatorsCustody → SetCustodyGroupCount, whose sole caller is on_block.go:440 inside the validator-custody branch. Without validators attached it never runs, so advertisedCgc stays at CustodyRequirement for the process lifetime — 4 on every network, since no chain overrides it. metadataV3Handler reports the same value (cl/sentinel/handlers/heartbeats.go:116), so both discovery and the metadata RPC understate custody by 32x.
The cost is borne by the network rather than the node: peers pick column sources from the advertised count, so a node holding all 128 groups is asked for 4 and its data goes unused. The node itself still receives everything, because its gossip subscriptions come from GetMyCustodyColumns, not from what it advertises — which is why this is invisible in normal operation.
The fix is presumably for archived mode to advertise NumberOfColumns rather than leaving the seeded requirement in place, but the interaction with the increase-only ratchet and with #23566 wants deciding together rather than piecemeal.
Found in review of #23560, which seeds the entry (0 -> 4 on the node above) and deliberately stops short of this.
An archive node custodies every column group but advertises
CUSTODY_REQUIREMENT.IsArchivedModeis true when--caplin.blobs-archiveor--caplin.blobs-immediate-backfillis set (cl/das/peer_das.go:262), andresubscribeGossipthen subscribes to allDataColumnSidecarSubnetCount(128) subnets (:295-299). Confirmed on a gnosis archive node: 128JOIN /eth2/<digest>/data_column_sidecar_Ntopics, and blob reconstruction from gossiped columns succeeds at the tip — 37[blobsRecover] recovering blobswith 37 matchingrecovering done, nonot enough columns to recover.The ENR and the metadata response tell a different story. The only non-mock path that raises the count is
UpdateValidatorsCustody→SetCustodyGroupCount, whose sole caller ison_block.go:440inside the validator-custody branch. Without validators attached it never runs, soadvertisedCgcstays atCustodyRequirementfor the process lifetime — 4 on every network, since no chain overrides it.metadataV3Handlerreports the same value (cl/sentinel/handlers/heartbeats.go:116), so both discovery and the metadata RPC understate custody by 32x.The cost is borne by the network rather than the node: peers pick column sources from the advertised count, so a node holding all 128 groups is asked for 4 and its data goes unused. The node itself still receives everything, because its gossip subscriptions come from
GetMyCustodyColumns, not from what it advertises — which is why this is invisible in normal operation.The fix is presumably for archived mode to advertise
NumberOfColumnsrather than leaving the seeded requirement in place, but the interaction with the increase-only ratchet and with #23566 wants deciding together rather than piecemeal.Found in review of #23560, which seeds the entry (0 -> 4 on the node above) and deliberately stops short of this.