On start up the discovery protocol uses a Kademlia style approach to find peers. Thus we obtain a local routing table which holds the (IP address, UDP port, and node ID) of some online and alive peers.

The next stage as I understand it is:

  • Run a server which implements the Devp2p wire protocol
  • Connect to some peers to synchronise the blockchain.
  • Connect to some peers in order to broadcast any transactions.

What is the strategy used in order to select which nodes to connect to?


  • How many nodes do we connect to?
  • What is the criteria for selecting which nodes to connect to
  • What is the criteria for banning nodes
  • How does this strategy ensure full network connectivity without partitions?

1 Answer 1


Only a partial answer for the first couple of sub-questions...

How many nodes do we connect to?

The maximum number is set to 25 by default, but can be configured using the --maxpeers flag on the command line. This limit is flexible when taking into account "trusted" nodes. (See below.)

The finer detail is that we can also set the combined total of both pending incoming and outgoing connections using the --maxpendpeers flag. This is the number of nodes simultaneously performing connection handshakes, which may or may not be successful, and which depends on whether we can verify their identity. This is set to 66 by default (50 and 16 respectively).

What is the criteria for selecting which nodes to connect to?

There are three different categories of nodes that we connect to, though I'm unsure of the criteria they must meet (other than they must complete the handshake process):

  • Bootstrap nodes

    // Bootstrap nodes are used to establish connectivity
    // with the rest of the network.
    BootstrapNodes []*discover.Node
  • Static nodes:

    // Static nodes are used as pre-configured connections which are always
    // maintained and re-connected on disconnects.
    StaticNodes []*discover.Node
  • Trusted nodes:

    // Trusted nodes are used as pre-configured connections which are always
    // allowed to connect, even above the peer limit.
    TrustedNodes []*discover.Node

admin.addPeer() allows you to add a new entry to the array of static nodes.

  • Thanks so it seems nTab in server.go is populated by the DHT discovery process is passed to dial.go which attempts initiate the handshake. If server.go verifies identity then peers which pass are added to peers[] but then it is somewhere in the Eth protocol handler where the peerset is built. Jul 7, 2016 at 23:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.