Boy, it has been a long time since the last post about Nelson! Many sleepless nights and gallons of coffee down the road and with the Nelson’s alpha release in sight, here is a little less-technical explanation about the technology behind Nelson.
Nelson creates a structured overlay network of nodes (a ”Nelson community”) and manages the neighbours of locally running IRI node (IOTA’s full node written in Java). It runs as an independent service alongside IRI and communicates with it using IRI’s API interface.
java -jar iri-188.8.131.52.jar — config iri.ini
nelson —config nelson.iri
An already existing IRI node can benefit from the power of Nelson without changing a thing. IRI can have its own manually set neighbours, which Nelson will never touch or share with anyone else.
In fact, having some of the nodes in the network that have a static and secret set of nodes adds up on the network’s security. This network of manually set neighbours forms a backbone that makes a disruptive network attack even less likely.
Nelson is a more flexible, ever-changing mesh that can wrap around the backbone:
The backbone is nice to have, but not necessary for Nelson. It can handle any disruptive attack just as fine. How? Read on!
How Nelson community works
The whole idea behind Nelson is to mimic a social structure based on trust, recommendations and personal preferences that change over time. Each Nelson has a memory of all the members of the community it has been in contact with or that have been recommended.
There is a differentiation between passive (incoming) and active (outgoing) contacts. For active contacts, Nelson relies on trust and recommendations. For passive contacts it is very picky according to its own personal preferences (personality):
1. Trust and recommendations
As a new Nelson node joins the community it doesn’t know anyone, yet, apart of a few initial nodes. To make the newcomer get a foothold, these initial entry nodes are more welcoming and chatty than the others. They share a limited list of other members they trust the most (the oldest and connective ones).
The newcomer puts the highest trust into these initial nodes. They are treated as first-degree trusties. Each node recommended by them is treated as second-degree trusty. Then third-degree and so on. The farther away a node is down the recommendation chain, the less trust it gets.
Only recommendations from actively contacted nodes become certain degree of trust (depending of the trust level of the contacted node). Incoming contacts are generally not trusted at all, unless they are recommended by a trusty before or after the initial contact.
What does the trust network lead to?
The less you trust a node, the less likely you are to actively contact or recommend it.
The initial (master) nodes tend to trust/recommend the nodes that are oldest and most stable. All newcomers get recommended these nodes first. All other (normal) nodes recommend peers that they think are the most trustworthy based on their individual experience.
Over time, the community forms different levels of trust circles. The longer a node is part of the community, the trustworthier it becomes and is connected deeper into the network. The more it is recommended as a point of reference for the new nodes. The harder it is to get fooled, even if at some point +60% of all nodes are “evil”. The inner circles of trust become practically unshakable.
2. Personality and age
Each Nelson node has a “personality” which dictates how it treats passive (incoming) contacts. The personality changes over time. The time between personality changes is called an “epoch” and lasts about five to ten minutes.
Incoming contacts are not easily accepted. Depending on the personality, Nelson might just decide to drop the connection.
For the newcomers, who do not have lots of contacts, it might be a little frustrating to get accepted into the network. But waiting pays off. Trust and more contacts have to be earned. And they are earned with time and patience.
With this measure, it is impossible to predict whether a Nelson node will accept the connection. If the connection is dropped, the only thing that can be done is to wait for the next Epoch and hope that the target node’s personality changes to our benefit.
For unpredictable, ever-changing network morphology.
This makes it harder to poison a node by reserving all its connection slots. Even if this is achieved, it is usually for the period of an epoch (currently lasting about five to ten minutes). To make it even harder, we consider adding a computational riddle to the handshake, so that the“evil” nodes cannot easily spam the network without paying a hefty price.
The strength of the community
The head and the heart duality
The trust logic can be considered Nelson’s head, while the random personality changes over time can be called it’s “heart”.
The differentiation between incoming and outgoing contacts and the way they are treated (trust vs personality) makes it extremely hard to eclipse a random node for a prolonged period of time. Targeting a specific node becomes an impossible task: the deeper it is within the trust circles, the more computational power, time and nodes count the attacker would have to come up with. For nodes with very long relationship (+1 year equivalent) and trust history, even an increase of evil nodes ratio to over 80% didn’t change a thing.
Over period of the past few weeks we internally simulated hundreds of different scenarios: evil node ratios, network sizes, cycle and epoch intervals and a myriad of other variables. The best strategy has been chosen and passed additional set of tests to make sure that it delivers the security we seek.
At this point we can say with fair confidence that Nelson works and is secure, not only through the nodes count, but through the network’s age. The older the network, the deeper the relationships between the older nodes becomes. The more stable and secure the community is.
Where to go from here
Alpha version of Nelson is ready and deployed on a set of several “initial” nodes that form the base of a future network. We are currently testing those nodes in live environment and will soon start inviting IRI node maintainers to join the alpha phase by adding the Nelson service to their nodes.
In a matter of few days the whole source code will be released to the community. We hope to get fresh insights, ideas and help getting Nelson to the next level: testing and improving the algorithms.
We are in talks with specialised third parties to review and comment on the technology behind Nelson.
Simplify launching of IOTA full nodes
With the help of the community, we hope to streamline the process of running a full node using Nelson. Simple install scripts, docker/AWS images as well as automated services to “buy & launch your own node in the cloud with one click” are being drafted.
Above all, once released, we hope to get some days of sleep and relax before Christmas! ^^
Thanks for reading and happy holidays!
Here’s a Nelson carrot: 🥕
IOTA Donations welcome: