Stable attestation subnet subscriptions, note for fork transition clarification

[zilm13]

We have this note currently:
https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#attestation-subnet-subscription

---

Note: When preparing for a hard fork, a node must select and subscribe to subnets of the future fork versioning at least EPOCHS_PER_SUBNET_SUBSCRIPTION epochs in advance of the fork. These new subnets for the fork are maintained in addition to those for the current fork until the fork occurs. After the fork occurs, let the subnets from the previous fork reach the end of life with no replacements.

---

I have some doubts we need to do this in advance of 256 epochs before the fork:

• node subnets will be changed in 256 epochs with 100% guarantee
• we usually do it in like 2 epochs before the fork, for example, for sync committee subnets (though I've not found any constant for this in the spec)

Maybe EPOCHS_PER_SUBNET_SUBSCRIPTION is not related to an advance meaning that we should subscribe as usual for EPOCHS_PER_SUBNET_SUBSCRIPTION and do it in advance before the fork, but it's not clear with the current text. Maybe polish it a little? I'd just remove at least EPOCHS_PER_SUBNET_SUBSCRIPTION epochs part.

[ppopth]

I'm not sure I understand the question correctly.

we usually do it in like 2 epochs before the fork, for example, for sync committee subnets (though I've not found any constant for this in the spec)

There is no reason to do it only 2 epochs before the hark fork. 2 epochs is equal to only 12 minutes. The reason that we do it at least 256 epochs in advance because we want to ensure that the subnet backbones are stable enough.

Maybe EPOCHS_PER_SUBNET_SUBSCRIPTION is not related to an advance meaning that we should subscribe as usual for EPOCHS_PER_SUBNET_SUBSCRIPTION and do it in advance before the fork, but it's not clear with the current text. Maybe polish it a little? I'd just remove at least EPOCHS_PER_SUBNET_SUBSCRIPTION epochs part.

It's not directly related, but we should specify the time the nodes should be subscribed to the subnets before the hard fork in advance, so we just thought reusing that constant makes sense.

[zilm13]

@ppopth
From my understanding:

1. Compute subnet method is pretty deterministic with input of nodeId and epoch (no fork digest or whatever), stable backbone subscriptions lasts EPOCHS_PER_SUBNET_SUBSCRIPTION (256 epochs).
2. Once we drop stable subnet subscription ids from ENR, the only way to find appropriate peers for this subnet is using compute formula which for every nodeId provides subnet that lasts only EPOCHS_PER_SUBNET_SUBSCRIPTION, so if we do some subnet subscription in any advance (even 1 epoch), noone will be able to find us there.
3. On fork topic subscriptions are changed, topics method use fork digest for calculation which is changed on fork. Subnets are the same. So in advance we start to publish and listen messages on new fork topics, we don't need to do it for a lot of epochs as old attestations become irrelevant, 2 epochs are enough.

So current text in spec looks confusing for me. I've suggested the edit.

[ppopth]

so if we do some subnet subscription in any advance (even 1 epoch), noone will be able to find us there.

I don't understand. Why won't no one be able to find us?

we don't need to do it for a lot of epochs as old attestations become irrelevant, 2 epochs are enough.

I don't understand this as well. Why are the new topics related to the old attestations? and how is it related to 2 epochs? The reason that it's 256 epochs is that we would have enough time for the nodes to form the mesh of the new topics.