Eth2.0-specs: Finding peers of correct chain before genesis

[djrtwo]

We generally rely upon the eth2 field in the ENR to find peers on a particular chain. The ForkDigest within this field utilizes genesis_validators_root and fork_version to isolate the chain from others, but because genesis_validators_root is not previously know, the eth2 field cannot properly be used prior to genesis.

There is also some strangeness in wrt gossip topics because they use the fork_digest in the topic name. This would prevent any subscriptions being valid prior to knowing the genesis state. This isn't a huge deal because genesis is delayed for at least MIN_GENESIS_DELAY (1 day) during which gossip subscriptions can be made.

Some potential solutions:

1. A simple solution is to set genesis_validators_root to 0x00 prior to genesis, but then you might find peers of other (not yet to genesis) chains. Probably not too bad because only so many chains will be queued to start at any given time. Still, not optimal.
2. Could also use DEPOSIT_CONTRACT_ADDRESS as a temporary stub for genesis_validators_root to form a "pre-genesis" fork_digest. This would be useful in finding peers, but would not solve the gossip topic problem (which is probably okay). One downside is that this is an eth1-centric view of how to start an eth2 chain. A non-eth1 genesis chain might already know fork_digest in advance, or could use some other agreed upon bytes to fill genesis_validators_root before it is knwn.
3. Simply do not find peers until genesis state is known. This is at least 24 hours of lead time on mainnet. Is there actually any downside to this method? Do we gain much by peering 24+ hours in advance? Does it break anything fundamental in client work flows?

The above list is probably not exhaustive. Open to input here. I currently favor (3) for simplicity unless it is not in fact simple to implement. Otherwise, I think (2) should be fine.

[djrtwo]

cc: @nisdas @AgeManning @arnetheduck @mkalinin

[AgeManning]

We already do 3. So this is my vote, because no further work is required from our end :)

[nisdas]

I like 3) too as it is straightforward to implement, we avoid the situation of 2 potential fork-digests where you have a different fork digest pre-genesis and post-genesis. I think 24 hours should be ok to search and discover the appropriate peers, although I would be interested to know if there are any downsides to having peer discovery restricted to only 24 hours before chainstart.

[q9f]

(3) makes most sense because you can only check for valid genesis validators root after that genesis event took place. if you want to be fancy, you could populate a temporary record of potential peers that share the same fork id and then check that list after genesis for the correct root before adding them to the local node records. that way you could start a preliminary peer discovery before the genesis delay period.

[mkalinin]

if there are any downsides to having peer discovery restricted to only 24 hours before chainstart

My gut says that it should be sufficiently enough for peers to form a stable backbone. @zilm13 is about to figure out whether 27 to 54 hours would be enough to jump from one subnet to the other. I think this particular case around genesis could also be simulated. Thus, I'd suggest to stick with 3) for now and get back to this question once we have a proof of this option doesn't work well.

[zilm13]

@mkalinin 3) doesn't require jump and has another benefits, I'd bet for 3. It's one-time.

[djrtwo]

Thanks for the input everyone! (3) it is. PR coming right up

[hwwhww]

closing in favor of #1708