Stability subnets expressed in terms of validator leaves ambiguity

[arnetheduck]

https://github.com/ethereum/eth2.0-specs/blob/v1.0.0/specs/phase0/validator.md#phase-0-attestation-subnet-stability

Typically, the attestation subscriptions are handled by the beacon node, but the stability subscription is expressed in terms of "validator" - this implies that a beacon node running without any validators should not subscribe to stability subnets at all and beacon nodes with multiple validators should be subscribed to multiple stability subnets - what is the intent?

It seems reasonable that the spec instead mandates that each beacon node must be subscribed to at least one stability subnet at all times, and may choose to subscribe to more, regardless of the number of validators it runs.

This avoids leaking information about how many validators are running on the node, keeps the enr stable and provides guidance for how to implement "read-only" non-validating beacon nodes.

[djrtwo]

The intention is per validator. In subsequent phases, the amount of data (subnets) you are required to process is related to the number of validators (and associated roles) attached to the node. This phase 0 stub simulates this behavior until we actually have shards to handle.

It is fully the intention that if yuo have fewer validators you process and follow less of this noise.

In terms of read-only (0 validator) nodes, it is a feature that bandwidth requirements are reduced. In fact, it should even be optional to follow the global aggregate channel.