Summary

A seed node is used to jump start other nodes by providing a list of peers that the node can connect with. The general flow is for peers to explicitly list one or two seed nodes in the config so that on start up the node temporarily connects with the seed node, the seed sends the node its entire address book and then drops the connection. The node then starts dialling the peers on the list and using them to catch up / participate in consensus. If a node needs more addresses it can redial the seed node again.

Please see the UPDATE for changes to the context of this issue

Specification

• Nodes should never sustain a connection with seed nodes beyond the address book transfer. This means that seeds should never be PersistentPeers or UnconditionalPeers. Nodes should not redial seeds when the connection is closed or when they still have sufficient peers that they are connected with.
• To begin with, seeds should not score addresses in any way. This is left to the node. At a later date we may consider methods of peer scoring that can be done by seeds.

Non functional:

• Seeds should be highly available
• Seeds should be light weight

Questions:

• Should seed nodes exchange addresses with one another. i.e. is there a special seed to seed connection?
• Should seed nodes iteratively ping peers in the addressbook to check for liveness (and update their addressbook)?
• Should seeds communicate other information such as RPC endpoints (which may be helpful for state sync)?

Have I missed anything? Is there any more context you might be able to provide cc @alexanderbez

Notes

We should probably fix this / find a better solution somehow.

// addresses under which the address manager will claim to need more addresses.
needAddressThreshold = 1000

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned