Random autopeering

🌌 Research Experimental
1

Random Autopeering is a peer-list maintenance scheme that is not necessarily random, but also does not rely on any enforceable rules and is in essence a local method to maintain a peer list that is enabled by a basic interface and a bootstrapping process. Below is a description of the bootstrapping, the interface, and one peering method a node could implement.

Bootstrapping

There are several ways in which a disconnected node can acquire information about peers:

  • A hard coded list of nodes ran by known entities. (excluding user intervention, this is the only source of peers for a new node)
  • A user-added list of nodes, given to the software through a config file, a command line argument, or any other input method that the software supports. Through such an interface, the hard coded list could be modified or removed altogether. (This is optional for both the user and the implementation)
  • A list of nodes saved in the software database from previous executions. (This list should be empty only on the first execution of an installation of the software)
  • Querying existing peers for information of their own peers. This is covered in the next section.

Peering interface

A node’s API should have a ‘getaddr’ entry point, which can include an integer K indicating the amount of node addresses required. Upon receiving a ‘getaddr’ call, a node will return up to K addresses of nodes it knows about, along with additional information about each node, such as timestamp of last activity. A node is incentivized to share its peers for the benefit of becoming more connected in the network, thus reducing its max distance from any other node, and improving latency of traffic. There is no enforcement of the content of ‘getaddr’ responses, or of the existence of the response itself.

Local method

A node’s implementation could use or abuse the definitions above in various ways, but a node would be incentivized to use them in a way that would make it well-connected in the network, reduce the latency it experiences, and would be resource efficient.

A simple implementation could follow these rules:

  • Set the maximum number of needed peers based on the available network bandwidth.
  • For each peer, maintain:
    • Timestamp of last activity
    • Timestamp of last ‘getaddr’ request
  • Whenever a peer’s last activity is far away in the past, either ping it, or drop it.
  • As long as there are less than the needed amount of peers, pick a known peer based on time of last ‘getaddr’ request, and request new peers.

The list should be maintained in a database for future executions.

Additional considerations may be implemented:

  • Rate peers’ “uniqueness of data” and level of familiarity of other peers, in order to prioritize peers that seem to be “far away” in the network topology.
  • Rate peers’ contribution to information gossip to promote better information distribution.
  • Prefer a uniform distribution of IP blocks.
  • Maintain two separate lists of peers, identified by incoming and outgoing, to protect from eclipse attacks. (See additional considerations regarding symmetry).
  • Prioritize peers based on their mana. This would require peers to have some sort of tangle-based identities in addition to their addresses, and would require the node to have some updated view of the tangle.
  • Maintain a hops-score for each peer, indicating the minimal number of hops required from the initial hard-coded list, and use that score to prioritize connection in some fashion.

(All of these are local and subjective, and do not require any additional communication).

Additional considerations

  • On symmetry of communication channels:
    Everything above details how a node can maintain a list of peers, with no regards to the usual symmetric nature of communication in a network. It is likely that nodes’ APIs would also include some entry point for the creation of a symmetric connection, therefore adding peers when they request a connection.
  • On voting:
    The peering method detailed here is not resistant to voting attacks. While it protects from eclipse attacks, as some of the peers a node would acquire would be picked on its own volition, an attacker with multiple addresses could try to introduce as many of them to a target node’s list, therefore acquire a voting share which could be used to manipulate the target node’s voting results. This can be solved all together by implementing a second peering layer, such as the discussed salt-based one.
  • For additional consideration, see the similar peer discovery of the Satoshi client: https://en.bitcoin.it/wiki/Satoshi_Client_Node_Discovery

Open questions:

  • Assuming that this is equivalent to the Bitcoin network peering, what element of the tangle (other than voting) could require modification or invalidate such a peering method?