Soft fork gossip topic activation and deactivation

[dapplion]

Issue Addressed

PeerDAS requires new features not available in current gossip topic machinery:

• Unsubscribe from a topic kind at a fork boundary (so far we only added)
• Change core topics at an epoch that does not align with a ForkName fork
• Change core topics without changing fork-digest

Most of the changes from this PR can be back-ported to unstable but I want to make sure they align with what we need for PeerDAS

Proposed Changes

• Move logic to compute what to subscribe to the function core_topics_to_subscribe(epoch, opts). It consolidates logic that is fork dependant with other user options like subscribe-all-subnets. The previous approach was very rigid expecting a set of topics for every ForkName. Now the set of topics change depending on peer das epoch
• Define a list of "fork transitions" which include your beloved altair, capella, etc and now a non-fork transition "peerdas".
• Add two functions new_topics_to_subscribe_at_epoch and old_topics_to_unsubscribe_at_epoch which diff the output of core_topics_to_subscribe across a "fork transition". Then, at the fork transition epoch subscribe the new topics, and forget the old ones

---

Closes https://github.com/sigp/lighthouse/issues/5894

[jimmygchen]

My understanding from latest discussions on ACDC & breakout call is that the plan is to activate PeerDAS at a hard fork (due to consensus changes and ease of coordination), thus PEERDAS_ACTIVATION_EPOCH would be the same as either ELECTRA_FORK_EPOCH or FSTAR_FORK_EPOCH. Therefore topic change could just occur as part of the hard fork transition?

[dapplion]

What consensus changes ?

[jimmygchen]

Rules to import into fork choice are different (custody columns instead of blobs) and incompatible; and additionally trailing fork choice changes. Are these not consensus changes?

New nodes won't be sharing the same view of the chain as old nodes, isn't that technically a hard fork?

[jimmygchen]

• Unsubscribe from a topic kind at a fork boundary (so far we only added)
• Change core topics at an epoch that does not align with a ForkName fork
• Change core topics without changing fork-digest

I think these features added could still be quite useful though, regardless of whether we use it for PeerDAS - and maybe we could use it for PeerDAS - I'm just raising what I understood from various discussions.

[dapplion]

fork choice changes are not a consensus change, because you can still interop and only matters in your local view. Fork-choice changes SHOULD be coordinated tho, otherwise weird things can happen, but that's why using an activation epoch is enough

[michaelsproul]

Please update to point at unstable by either:

1. Rebasing on unstable (if your branch has a small number of commits that are easy to tease out), or
2. Merging origin/das into this PR: git fetch origin; git merge origin/das. This will result in the smallest number of conflict resolutions and is better for branches that already contain merge commits or have extensive history.

[dapplion]

Obsolete, PeerDAS is part of Fulu