Find diverse peers

[mpetrunic]

Is your feature request related to a problem? Please describe.

We should aim to have at least one peer from each subnet.

Describe the solution you'd like

Use discv5 to periodically search for peers with attestation subnets we are missing

Describe alternatives you've considered

Additional context

[twoeths]

this is not normal from canbo's log:

2020-08-10 23:43:58  [CHAIN]            info: Initialize forkchoice with pre-finalized blocks from 17408 to 17408
        and finalized block 17440

and from my log

2020-08-11 15:09:23  [CHAIN]            info: Initialize forkchoice with pre-finalized blocks from 28127 to 28127
        and finalized block 28160

in my case, I debugged and found that finalized block still in block database so there is no pre-finalized blocks saved in ArchiveBlock db except for the justified block, it means ArchiveBlocks task not finished while ArchiveState finished already (because it's faster)
this may happen if we don't do a cleanup stop (kill -9 to kill the process)

[mpetrunic]

I think you posted this in wrong issue? 😄

[twoeths]

the above comment should be for #1381 which is closed.

[twoeths]

@mpetrunic what's the rationale of this?

right now we have ATTESTATION_SUBNET_COUNT=64 so we should have at least 64 peers for each subnet?

also I see we have maxPeers as network option but I don't see where it's being used.

[mpetrunic]

right now we have ATTESTATION_SUBNET_COUNT=64 so we should have at least 64 peers for each subnet?

At least 1 peer for each subnet (single peer can be subscribed to multiple subnets so we don't actually need to have 64 peers at minimum). If you aren't subscribed to subnet and you are publishing attestation, you are doing fanout and you need peer with connection that is on that subnet in order for someone to aggregate your attestation.

also I see we have maxPeers as network option but I don't see where it's being used.

I think we need to set it here, but we can have more peers in peer store but just maxPeers with connection.
https://github.com/libp2p/js-libp2p/blob/master/doc/CONFIGURATION.md#configuring-connection-manager

[twoeths]

At least 1 peer for each subnet (single peer can be subscribed to multiple subnets so we don't actually need to have 64 peers at minimum). If you aren't subscribed to subnet and you are publishing attestation, you are doing fanout and you need peer with connection that is on that subnet in order for someone to aggregate your attestation.

I see. Just a clarification that we have RANDOM_SUBNETS_PER_VALIDATOR as 1, it means 1 peer only subscribe to 1 subnet so if we want to have peers subscribing to all subnets we need to have 64 peers https://github.com/ChainSafe/lodestar/blob/master/packages/lodestar/src/tasks/tasks/interopSubnetsJoiningTask.ts

[mpetrunic]

I see. Just a clarification that we have RANDOM_SUBNETS_PER_VALIDATOR as 1, it means 1 peer only subscribe to 1 subnet so if we want to have peers subscribing to all subnets we need to have 64 peers https://github.com/ChainSafe/lodestar/blob/master/packages/lodestar/src/tasks/tasks/interopSubnetsJoiningTask.ts

That's unreleated to that, we don't have to be subscribed to subnet to propagate attestation, we just need to have peer on our attestation subnet.

But since you've asked, we implement that incorrectly, we don't track how many active validators we have (so we are always subscribed to one random subnet).
There are couple of solutions to that

• validator must send committee subscription request even if it's not aggregator (update validator subnet subscriptions and validator flow doc ethereum/beacon-APIs#68)
• we assume active validators based on attester duties