Multiple Superpeers Post 1/8

Implementation Plan and Progress

In our recent updated Roadmap post, I described the components we are working on for the next 6–8 months and beyond. “Multiple Superpeer Support”, one of the largest and most important items in the Roadmap, was covered only at a high level, and I promised a more granular look at each of the components in coming posts. This is the first in a series of 7 subsequent posts which will provide that in-depth detail.

Remember from previous posts and our technical whitepaper — the Superpeer serves several critical functions for linking together geographically separate local meshes.

Firstly, it provides hole-punching capabilities to get around firewalls (on cellular or corporate networks) and to work with Network Address Translation (NAT) for multiple devices behind the same router.

Secondly, it communicates with the Ethereum network allowing RightMesh devices to execute signed transactions (ie: execute smart contracts, create and fund payment channels, and normal funding transfers).

Thirdly, it acts a payment hub for the payment channels.

Fourthly, it performs caching to minimize the number of transmissions across the Internet links (keep in mind the local side of the network has people moving around and it may tear apart frequently — if this happens mid transfer if we didn’t use caching at particular devices, it would have to start right from the source).

The past two weeks our development team has been brainstorming approaches, white-boarding solutions, surveying other p2p approaches and the literature and coming up with an implementation plan for the “Soft Mainnet Launch”. We’ve also been running some early numbers based on our assumptions to determine system performance and to estimate profitability for various parts of the mesh. This post will describe in great detail the decisions we have made and why, and what our implementation plan will be.

First we will introduce naming conventions and list the assumptions that will apply to all subsequent posts in this series. The assumptions will be explained and justified in more detail in the upcoming post on Payment Channel Balancing.

Terminology:

Operator: person, entity or group operating a Superpeer

Remote Peer (RP): A non-Superpeer device, either a Buyer or Seller, also called a mobile device. Typically a mobile phone.

Community Superpeer (CSP): A Superpeer run by an operator which is not RightMesh AG

RightMesh Superpeer (RSP): A Superpeer run by RightMesh AG

Buyer: A Remote Peer which intends to purchase or consume data. Has no connection to the Internet, or has it disabled.

Seller: A Remote Peer which intends to sell or share data, has a connection to the Internet.

Assumptions:

• Buyers must use their own ETH to create the payment channel and deploy tokens into it. The Buyers’ goal is thus to minimise the amount of ETH to spend.
• Superpeers must also agree to create such channel. If the amount of tokens deployed into it is so low that the Superpeer cannot make profit by cashing out the tokens on its side without incurring a loss, the Superpeer can reject the payment channel creation.
• Superpeers can optionally refund Buyers for their initial creation cost in Eth to encourage them to remain connected to the same Superpeer when a channel close operation is performed in order to recoup the funds on the Superpeer side of the Buyer channel. If Ethereum ever allows tokens to be used for smart contract gas, this becomes much simpler.
• If a Superpeer does not refund the channel creation cost to the Buyer, the Buyer may factor this cost into whether the Superpeer will be selected again.
• Superpeers must pay in ETH to create the payment channel to the Seller and deploy tokens into it.
• If a Buyer is using a Superpeer which is not the same as the Seller there is added cost for the Superpeers to transmit funds between each other.
• Once a fee has been set, it must be honoured until the funds in the channel have expired.
• Whichever side is closing a channel to recoup funds should pay to re-establish channel, although we can’t really enforce this. A Buyer should operate on the principle that if a Superpeer won’t pay to re-open a closed channel, it is a very expensive Superpeer. Similarly, if a Seller won’t pay to re-establish the channel when it cashes out, the SP should regard it as a less profitable Seller, and consider operating with a different Seller.
• Aim to support 30 remote peers per mesh, 1000 meshes per Superpeer, up to 1000 Superpeers (total of 30M nodes maximum for Soft Mainnet Launch)

Recall from our roadmap post, that the goal of our Soft Mainnet Launch is to get token use through staking at the Superpeer, to begin to test the data network at scale, and to verify that tokens and payment channels are functioning and flowing correctly.

With only a single RightMesh Superpeer, we have the following topology in the network. While the local meshes themselves may be decentralised, since they must link to each other through one single Superpeer, it is still a centralised system.

Single RightMesh Superpeer global topology

Contrast this with the figure below which shows three RightMesh Superpeers. Now if one of them goes down, the network is more resilient.

Notice that the payment channels use the Superpeers as payment hubs. We often get asked the question “Why don’t you just make direct payment channels between the Buyer and Seller directly?”. The reason for this is because of cost. It costs gas to create and fund the payment channel. Keep in mind the types of networks that are forming the localised meshes. The Sellers may come and go very often and get replaced often. If a Buyer was always making payment channels with Sellers directly, the costs would become far too expensive. Instead, Buyers and Sellers (algorithms on the devices, not people) select which Superpeers they would like to use based on cost and performance and make a single relationship (which can change if conditions change) and this significantly reduces the cost. In a further post I’ll describe this with some real numbers to convince the reader more thoroughly.

Multiple RightMesh Supereers run by RightMesh with payment channels

The above figure is still organisationally centralised, however. If RightMesh as an entity ceased to exist, the network would cease to function. There is also more trust needed from the community that we would not act in a self-interested manner since all of the payment channels go through our own Superpeers.

Instead, what we are envisioning is a global network of Community Superpeers which is shown in the figure below. In this case, there are still several RightMesh Superpeers, however, there are also many Community Superpeers, which together form a decentralised Internet overlay network which can link together our local decentralised meshes.

A global decentralised RightMesh Superpeer network linking geographically separate meshes with Community Superpeers (note: the locations of the RightMesh Superpeers are just speculative and for illustrative purposes)

The next post will go into more detail on how this network will form initially (Superpeer Bootstrapping).

The remaining posts will cover Remote Peer bootstrapping, Superpeer Peer Exchange Protocol, Scaling the Peers through Hierarchy (FIND request), Superpeer Caching (reducing re-transmissions across the internet link), Payment Channel Balancing Algorithm, and the Automatic Faucet for the Competition.

For more information, visit www.rightmesh.io