fix: do not always subscribe to all column subnets

[twoeths]

Motivation

• right now we always subscribe to all column subnets which is not necessary because we only need columns that we custody/sample
• that's why I see 128 logs like this per slot, and this could degrade performance. We only need 8 per slot

 debug: Received gossip dataColumn slot=198378, root=0x9945…49af, curentSlot=198378, peerId=16Uiu2HAm2J4ZRFnf7qWvu8VBRFT66E5XFWnRTwYTahB2oRJom5ji, delaySec=1.5910000801086426, gossipIndex=113, columnIndex=113, pending=data_column, haveColumns=31, expectedColumns=8, recvToValLatency=0.0009999275207519531, recvToValidation=0.0009999275207519531, validationTime=0

Description

• only subscribe to custody/sampling subnets

[matthewkeil]

This is great!!! We were just talking about this actually on the call with the Base contributor. A couple things jump out at me that we may need to consider.

For validator custody the number that we custody/sample will be variable so we should probably use a centralized source of truth for "what count we use." There is an object called the custodyConfig that is built at startup time and that we likely could update as part of the validator custody scope. Could we pass that into the gossip sub and read the value from that instead of recalculating it?

The second is block publishing. We will need to publish all 128 columns when we produce a block so we would need to figure out how to subscribe and unsubscribe during the epoch that we have publish duties.

This is a great idea though!!

[twoeths]

The second is block publishing. We will need to publish all 128 columns when we produce a block so we would need to figure out how to subscribe and unsubscribe during the epoch that we have publish duties.

to publish it's about to find peers on a topic, not about subscribe to that topic. That's a blocker for this work, will look into that part.