Nelson: Automatic peer discovery for IOTA

This is a small update on Deviota project as requested by the community. An important issue we, the project and the IOTA in general is facing.

One of the things we were working on for Deviota is a way to automatically discover IOTA neighbor nodes, but minimizing the associated risks of Eclipse or Uncooperative-Node attacks.

Why?

Let’s face it, the number one concern in the crypto-community regarding IOTA is the coordinator. Many are skeptical that the tangle will be able to grow big enough to turn the coordinator off. The more full nodes are running, the stronger the network becomes, the faster the coordinator will be turned off.

However, right now, running your own full node is very unhandy. Besides of starting it on command line, you have to manually manage the neighbour nodes you want to connect to. It is a huge barrier for the network growth.

The risks

The main argument against automatic peer discovery is the possible eclipse attack that disrupts parts of the network, allowing the attacker to do some nasty stuff: from simple network interference to targeted node attacks for double-spending purposes, for example.

So, how do we minimise these risks, allowing faster network growth?

Meet Nelson

Nelson is a name for an early carrot variety. The name fits very well, because it started as a module for Deviota, but grew into a separate package that we are planing to release before anything else; as early as possible, due to it’s importance for the whole project.

Nelson is a wrapper written in Javascript around the IRI package. It starts the full node automatically, but acts as a gatekeeper and network supervisor. It is responsible for discovering other peers and filtering inbound and outbound links. You start Nelson and it just works. No manual neighbour management.

Quick look under the hood in layman’s terms

Nelson is completely transparent. You communicate with it as if you would with an IRI node. It is invisible to an untrained eye. What it does is creating a structured overlay:

The key

Each Nelson node has an internal random key. The key is changed once in a while. It is similar to the password change that you should do periodically for more security. We call the time between key-changes an epoch.

The peer IDs

Nelson keeps a list of all the peers it has been in contact with. Each peer in that list becomes an alphanumeric ID consisting of 32 characters, which is generated using the key and the peer’s IP address.

Hence, the ID of peer changes each epoch.

The peer selection

Nelson drops any incoming or outgoing connection that doesn’t comply certain selection rules. For example, in a certain epoch, only peers that have a certain character in the first 4 characters of their ID are allowed to connect. Similar rules apply to outgoing connections and neighbor disclosures.

A network of directional in/out-connections formed by the node’s rules

A network of directional in/out-connections formed by the node’s rules

There is a maximal set of allowed outbound connections. There might be more peers that comply with the outbound rules than the allowed amount. These connections are rotated once in a while. That is, we randomly select the maximal allowed amount of peers from the set of peers that comply with the outbound rules.

The rotation of these connections is called a cycle. An epoch consists of a set of cycles:

An epoch consists of a set of cycles

The morphing topography

These cycles and regular changes of rules and IDs cause the network to maintain a certain structure for some time and change it periodically. Each cycle causes a small change in the network’s topography. Each epoch causes a bigger change.

A cycle could be a 5-minute timeframe. An epoch: 30–60 minutes.

The idea behind it is to make it impossible for the evil nodes to predict which nodes to attack and from where, flooding their list with a set of evil nodes and cutting them off from the rest of the network.

The tests

We have written a simulation environment to test Nelson. We created another species of “evil” nodes that will accept and connect to anyone and propagate other evil nodes only. The idea was to see how evil nodes will affect the network and if they will be able to eclipse large parts of the network.

We added the evil nodes starting right at the first cycle. This wouldn’t happen in reality, especially at high “evil ratios”. However, we wanted to test the limits, no matter how theoretic they were. Better to be conservative in your measurements, right?

The tests were conducted using 1000 nodes. Running 36 epochs, 5 cycles each. We tested different ratios of evil nodes. Starting from 5% up to 70%.

The outcome

Network disruption by percent of evil nodes

There is an initial spike of disrupted nodes due to the fact that we added evil nodes right from the start. Surprisingly, independently of the ratio of evil nodes, over the course of cycles the network healed pretty well. Sure, the less the evil ratio, the faster and better the network heals.

Even with more than two-thirds of evil nodes, after about 100 cycles the network disruption is less than 16%. And these disruptions are temporary: As the topography of the network morphs with each cycle/epoch different parts of the network get eclipsed.

If you consider 70% ratio unrealistic, here is the same chart with evil-node-ratio up to 50% only:

Network disruption - healing

This chart shows that if the ratio of evil nodes is below 45%, no disruption will happen on mature networks (+20 cycles or after about 2 hours of the network’s age, depending on the cycle length). The longer a node is part of the network, the less it will be affected by a possible attack.

More tests

Right now we are testing targeted attacks on a node. How easy/hard it will be to eclipse just one specific node as a function of it’s maturity?

There are ways to protect the client from an eclipsed node by connecting to several randomly selected, independent full nodes and double-checking the outcomes. This part is still work in progress.

Next steps

I hope that we can release Nelson as a command-line tool and library in the next 2–4 weeks. We are still running heavy tests of possible attack vectors to make sure that the network cannot be harmed, even with large amount of evil nodes. It is lots of work, but I hope for the help of the community, once it’s released.

Additionally, I want to create a tiny electron app to start Nelson right from your desktop, maybe with a small built-in network spammer, if the time permits. We need to continue the progress on Deviota, but I think, this small side-project is worth the time. It will (hopefully) increase the amount of full nodes and explode the size of the network in a short amount of time.

Thanks for reading!

Roman Semko
IOTA Donations welcome:
NOT_ANYMORE_THANK_YOU

2018-07-24T15:51:02+00:00