Multiple Superpeers Post 2/8

Part 1— Superpeer Bootstrapping

This is the second in a series of RightMesh Roadmap posts. Please refer to the initial post for naming conventions and assumptions.

When the Superpeers first startup, how should they find each other in order to connect to the RightMesh network? In our previous Proof-of-Concept (PoC), we assumed a single Superpeer so we could simplify the problem and focus on getting payment channels to function. We would now like to support multiple Superpeers, most of which will be run by the community, so we need to determine a method by which new Superpeers are able to discover each other.

We would like this to be designed in a manner which is as decentralised as possible so the Superpeers we operate are not single points of failure (even from an organisational standpoint, so that if RightMesh ever ceases to exist as an entity, or we come under attack the network will persist). We would also like this process to be secure so that devices don’t wind up tricked into joining impostor networks which have split from the main RightMesh network.

After surveying other p2p networks, and scientific literature, there appears to be four categories of bootstrapping.

1. Partially centralised via a redundant bootstrap nodes
2. Fully decentralised, scanning or probing IP addresses
3. External 3rd party services
4. Manual override

Partially centralized bootstrapping is currently used by Tor, Bitcoin, Ethereum, IPFS and Bittorrent DHT. This is usually a list of IP addresses or hostnames which is either hardcoded into the source code or packaged as a configuration file within the software and maintained by the organization running the project. This can often be manually overridden in the case where the organization is no longer able to provide updated lists.

Fully decentralized bootstrapping is typically more of an academic approach which involves scanning or probing IP addresses. As you can imagine, this approach can be incredibly slow, particularly when the network is young and has very few Superpeers. Over time, this approach can be adopted as the Superpeer density increases.

External service bootstrapping was used by many p2p file sharing applications in early days, and even by Bitcoin. This can be using things like a set of IRC servers which just have lists of IP addresses in particular channels. Security in these cases is a concern, although perhaps IRC has capabilities to only allow particular users to post the IP addresses. Then there are still the questions of who administers the rights to be able to post, is that still centralized, etc.

Manual override bootstrapping is used by most p2p systems so if all else fails, the users of the system can set their own bootstrap nodes. This is particularly useful in systems like Tor where governments and ISPs try to block the IP addresses of Tor entrance nodes so people in their countries aren’t able to access the network.

What we will implement over the next 6–8 months

For the MVP for six months, we have elected to use the partially centralized bootstrap method. In this case, we are extending the number of Superpeers we operate to three, which will be located at superpeer1.rightmesh.io, superpeer2.rightmesh.io and superpeer3.rightmesh.io. By default all RightMesh Community Superpeers will attempt to connect randomly to one of these bootstrap Superpeers. In this case, we are aiming for functional decentralisation of the bootstrap process, but not yet for organisational decentralisation. Organisational decentralisation will occur in the next stage.

Bootstrapping process for a Community Superpeer joining the RightMesh Superpeer network

Initially, the Superpeer network will only contain RightMesh Superpeers. A new Community Superpeer will randomly choose one, and query it for a list of all possible Superpeers and begin making peer connections with them.

Subsequent connecting Community Superpeers will then receive a list which contains the 1st Community Superpeer as well, and so on. If these Superpeers ever leave the network and rejoin, they now have the option to use the other Community Superpeers for bootstrapping.

A second bootstrapping Community Supeer receives a list of all the other connected Superpeers

One risk with the three RightMesh Superpeers is that the RightMesh DNS will be attacked causing the IP addresses to be resolved incorrectly. Instead we may elect to use the IP addresses directly to mitigate this problem somewhat. This also opens these three servers up to DDOS attacks by malicious parties. We will work with Amazon and ThreatStack which we already use in order to mitigate this risk.

Tasks

1. Create AWS instances for superpeer2.rightmesh.io, superpeer3.rightmesh.io, run RightMesh Superpeers on all three servers
2. Create a RightMesh Superpeer artifact that only our Superpeers runs (this should be similar to how the visualization stuff should run as well).
3. Have the RightMesh Superpeers recognize they are in fact the RightMesh Superpeers (as a first test of this code).
4. Change the logic of connecting to a Superpeer — presently, only the non-Superpeer devices do this (in InternetLink)
5. Design the connection logic for Superpeers, should be TCP connections because the connections are reliable- but must be done so it can handle many simultaneous connections. Could be a standalone prototype even. Benchmark the number of concurrent connections and data throughput this logic can handle by simulation load through this system with lots of clients running increasing in scale amounts of data.
6. After the TCP connections are made, implement the HELLO packets which will form the actual discovery of Superpeers with each other (as well as the discovery of remote peers attached to the Superpeer).
7. Implement the logic in RightMesh.
8. See if the three Superpeers see each other (without any remote peers).
9. Create a first “Community Superpeer” and see if all four see each other (hold data transmission aside for now) (without any remote peers).
10. Add remote peers to each of the Superpeers. Verify that the Superpeers are able to see each other’s remote peers in their routing tables.
11. Work with the Faucet team so that the first time a Community Superpeer is discovered by a RightMesh Superpeer, the Community Superpeer is funded.
12. Determine whether it is easy to create payment channels between SPs on demand, or when they first connect with each other.
13. Implement a blacklist of TCP connections for those which attempt connections and do not conform with RightMesh protocols.
14. Implement a check for mainnet token staking. This should run in a thread and periodically check that the mainnet tokens haven’t been removed. If they have, initiate a clean shutdown of the Superpeer.

What we will implement in the following 4–6 months afterwards

In the following four to six months, while the contest is operational, we will shift the process somewhat so that only during the initial bootstrap, the RightMesh Superpeers are required. During initial bootstrap, a list of all other Superpeers will be provided to the Superpeers, which will be ranked in a consensus model from all the other Superpeers. This ranking will be based on things like (but not limited to):

1. How much data has each Superpeer facilitated in the transmission of?
2. What are the fees of the Superpeers?
3. Where are they geographically located, relative to the Superpeer coming online
4. What are the uptimes of the other Superpeers

Updated information will be provided in INFO ACK responses (which occur periodically as RightMesh runs) so this information does not get stale as long as the Superpeer is running.

The Superpeer coming online would then use a Superpeer from this list for its bootstrapping in the subsequent times coming online (after a shutdown, or loss of Internet connectivity, etc.)

If the Superpeer has not run in sometime, the list could become stale, in which case it could fallback to the RightMesh superpeers again.

Further, we will add mechanisms to support manual bootstrap Superpeers and also probing techniques so the RightMesh Superpeer network can continue to function even if RightMesh as an entity ceases to exist, or experiences widespread DDOS attacks.

The next post will go into detail about how the remote peers will perform their bootstrapping, discovery, ranking and selection of Superpeers

If you missed the initial post in the RightMesh Roadmap Series, you can read it here.

For more information, visit www.rightmesh.io