Sidelining Sybil Attacks

This is a repost of a Medium post. Please feel free to support the original article with claps.


Photo by Philipp Katzenberger on Unsplash

One of the key problems with decentralised system is their vulnerability to attacks. There is no central authority to regulate truth nor deny entry to potential bad actors.

Although there are many malicious behaviours that could harm the Network, Sybil attacks may be one of the most pressing so we wanted to address it and help the community understand not only what it is, but also why the team have spent so much time creating defences.

So What are Sybil Attacks?

Seems odd to name a form of malicious networking behaviour with a womanā€™s name, but there is method in the madness as it is named after the famous 1970ā€™s book: Sybil and subsequent film following the story of a young woman with a multiple personality disorder. This type of network attack is based on a single attacker creating multiple identities with which to flood the network in order to use these numbers to gain a disproportionately large amount of control and power.

If it helps to think of it in the context of the current Internet, think of a reviews site. A bad actor sets up multiple accounts to write fake accounts for a product luring others to buy a poor quality product. In the SAFE Network this bad actor may be seeking disproportionate influence within a Section to control the consensus mechanism or attempting to double-spend Safecoin.

Stop Sybil in her Tracks

OK so Sybil attacks sound like they could cause a lot of problems for a peer-to-peer network. So what is the best way to mitigate them? Thatā€™s the million dollar question and each decentralised system has its own solution. Many rely on consensus mechanisms such as the blockchain, which might use the Proof of Work mechanism to reduce the ability of bad actors to take control.

The main reason behind Sybil Resilience is to make it disproportionately expensive to conduct attacks in order to reduce the incentive and dilute influence throughout the system.

SAFE Network vs Sybil

There are three main ways in which the SAFE Network is designed to combat Sybil attacks. Firstly the Network will only accept new nodes when they are needed rather than blindly adding anyone who fancies it. This means a malicious actor cannot create 1 million nodes and simultaneously add them to the Network in order to take control.

Second, any node that joins the Network is subject to Balanced Relocation. This means that the node is not allowed to pick its own location but is instead allocated one by other nodes. This means that a bad actor cannot cluster their malicious nodes in one area to gain influence in that Section.

Thirdly, the SAFE Network also has a mechanism called Node Ageing which is similar to a reputation system. The level of influence that a node has is directly correlated to the amount of work and positive behaviours that it has performed. A malicious node would have to spend excessively large amounts of time and resources to gain the power to influence any network event ā€” and that power would be revoked as soon as negative behaviour was detected. Thus making it too disproportionately expensive to attempt an attack.

The SAFE Network has security at its core and every design decision has been made to ensure that protection of usersā€™ data and their privacy is paramount. This was only a very brief overview of Sybil resilience.

24 Likes

ā€œFirstly the Network will only accept new nodes when they are needed rather than blindly adding anyone who fancies it.ā€

So, at one point not everybody will be able to run a vault and ā€œfarmā€. How this will be managed? With a kind of waitlist? Based on what will be the new vaults chosen?

In all cases, I can try to join the network with 10 000 machines and this will increase my probability to become a farmer no? So can someone be able to attack the network in the long term?

And what will be the process if the network donā€™t need any new vault. For example, if I download the vault, and run it in my machine. If the network donā€™t need any new vaults, then I will have to keep the program running until the network need and then I will have a chance to be selected?

2 Likes

The idea is that if there are 1 million waiting to become farmers and the SAFE Network accepts 10,000 a day, your chance as a bad guy with 10,000 machines is 1 in 100ā€¦

I see, but what if in the launch of the network someone do it. Because in the beginning, there wonā€™t be lotā€™s of people trying to become farmer and as the network will be small, it will probably accept only a small number of new node.

So what if, for example, directly after the launch I set up 500 machines to ā€œapplyā€ as farmers, and there are in the same time 300 others vaults trying. So in the beginning, mainly my nodes will become farmers.

3 Likes

The answer is that we need a beta that will continue until the network becomes tens of thousands of computers and only then let go the SAFEcoinā€¦

1 Like

Great post. Very easy-to-grasp. Thanks.

8 Likes

If you give the average guy a vault which retries periodically and automatically until it is accepted, then the main difference is: first earning nothing instead of a little.
But what certainly has to be avoided I think: a race to have the highest retry frequency.

1 Like

Ok I agree, i donā€™t really like the fact that everybody canā€™t become a farmer. Maybe itā€™s possible to find a process to allow everybody to run a vault without reducing the security of the network.

For example everybody can run a Vault BUT:

  • A new farmer start with a reputation of 0 and is a NON FARMING NODE (=node without farming capabilities)
  • You need a minimum reputation of 50 to be an UNCONFIRMED FARMER (this value can evolve with the time), under this level you are a NON FARMING NODE
  • You need a minimum reputation of 100 to be a CONFIRMED FARMER (this value can evolve based, for example, on the actual number of farmers in the network, and the average reputation, etc.). So between 50 and 100 you are an UNCONFIRMED FARMER and before 50 a NON FARMING NODE
  • Based on you uptime, the age of you node, etc. you reputation will increase
  • If you node is disconnected, not reachable, sending incorrect datas, etc. you reputation will decrease
  • When new CONFIRMED FARMER are needed by the network, the network will choose randomly new ones amongst UNCONFIRMED FARMERS
  • If an CONFIRMED FARMER have his reputation decreasing under the minimum requirement (=100), he will become an UNCONFIRMED FARMER and will have to get back above the minimum requirement to have a chance to become a CONFIRMED FARMER again. AND he can become a NON FARMING NODE if his reputation drop under 50.
  • Chunks will be stored in CONFIRMED and UNCONFIRMED FARMER vault
  • UNCONFIRMED farmer will be non-essential nodes. Letā€™s say a data chunk is replicated 5 times. 3 copy will be stored in CONFIRMED FARMER vaults and 2 in UNCONFIRMED FARMER vaults
  • CONFIRMED FARMER reward is more important than UNCONFIRMED vault reward

In this way:

  • Everybody can become a farmer and earn Safecoins
  • NON FARMING NODE and UNCONFIRMED FARMER canā€™t impact the network as they are non-essential. But they strengthen the network because they store chunks!
  • UNCONFIRMED FARMER are still useful even if they are non-essential
  • An attacker can not set up 10000 node and start to farm, each of his node will have to reach the minimum reputation
  • Even if the 10000 nodes of this attacker become UNCONFIRMED FARMER, they canā€™t impact the network because they are non essential
  • Only a small part of the attacker nodes will become CONFIRMED FARMER as CONFIRMED FARMER are chosen randomly within UNCONFIRMED FARMERS
  • This system will incentivize people to run vaults as they can also be rewarded as UNCONFIRMED FARMER. More the network will have UNCONFIRMED FARMERS, more it will be difficult for an attacker to have CONFIRMED FARMER nodes
  • UNCONFIRMED FARMERS will act like a reserve. They will be immediately available for the network if needed.

Itā€™s just an idea i am giving quickly like this. I am sure there is a lotā€™s of things which are wrong, but itā€™s just to give an idea.

5 Likes

Keep digging and pushing, this is how we build this together.

I donā€™t have time to work in this atm, but these instincts feel good so I hope youā€™ll all keep at this. :slight_smile:

Seeing this as the very first sentence in response to the topic makes me a little unhappy (only a little)! Sybil attacks are about attacking consensus, so to immediately bring farming in as the primary concern is missing the point of the topic imo (but I understand farming is very interesting!).

Farming is (or should be) entirely separate from consensus.

Donā€™t get me wrong, Iā€™m 100% in agreement with you that all vaults should be allowed to join - the network is for everyone - but thereā€™s also a need for some protection of the consensus mechanism so disallow is somewhat unavoidable.

One thing to consider here is that very large networks are counterproductive (taken to the extreme every vault stores only one chunk or less), so some restrictions on network size is helpful. But thatā€™s a fairly extreme case and overall I lean toward having less restrictions on joining rather than more.

Details about the disallow rules and queue rules would be very welcome. The RFCs have some info about disallowing nodes in Node Ageing - Starting a node but it doesnā€™t really help me understand how the disallow/queue works (and may be out of date?).

To clarify further about sybil attacks with respect to farming vs consensus - when a vault joins the network it has several roles. One role may be as a farmer, another may be forming consensus, another may be routing messages, another may be storing and delivering chunks. These are all separate roles and not all roles will be active throughout the life of the node. Sometimes thereā€™s overlap (eg farming and storage roles have significant overlap) but consensus and farming roles should ideally have NO overlap - those roles are entirely independent. Saying a ā€˜farmerā€™ joins the network is missing the point of this topic which is addressing sybil attacks on consensus.

You correctly point out that disallowing vaults in order to prevent sybil attacks would impact farming, and I see that as a bad side effect for the network. Letā€™s try our best to separate the ability to farm from the (dis)ability to perform sybil attacks.

While the many attacking vaults are ageing the network is continually growing and diluting the influence of those attacking nodes. Itā€™s not as easy as just ā€˜start lots and waitā€™.

7 Likes

My thought is that rather than a only add when actually needed there should be a tapering off on that.

If you just accepted every vault then the earning capacity of vaults will reduce due to the glut of space and farming rate dropping. At this point good users will start to turn off due to low earnings. But the malicious will remain and increase proportionally and create better conditions for them. So there has to be a point at which you stop allowing vaults to join before people start stopping their vaults due to an attacker (& good users) joining at a fast rate.

7 Likes

Neglecting the psychological aspects of Vault rejection will be devastating to the future of the network. Simulate, at least, that any Vault are part of the network from the beginning, even though in reality are in a simple waiting state, is, in my opinion, absolutely essential.

7 Likes

This can/will all eveolve as we go on. Let me put forward an attack that some claim is realistic, it may be, I am not sure(, but in early days e-corp here could be of SME size). What we start with is a protection against a hardened attacker who just floods the network with nodes for a period. That kills the network and kills the protection of node age.

Imagine an attacker like e-corp, they hate this, absolutely hate it, one day there are not many nodes joining, they spin up millions of vps etc. and flood join. Our sections cannot have thousands of nodes per section so they split. The section with average Edler age 100 (say) is not 2 with average age much less than 100 (so less trusted). e-corp is winning so it continues for a few hours splitting sections and growing the network to the point all good adults that were there are now Elders (before their time). Tipping point and we cannot stop this, e-corp are still going the current sections all have elders that are not e-corp, but the next split, e-corp have approx 50%, E-corp now delays all good decisions and allows decisions to have itā€™s own members promoted, very quickly e-corp own the network.

6 Likes

I think itā€™s super easy to show a message - ā€œYouā€™re connected, the average time to get SAFEcoin is 24 hoursā€

Do we really have to tell the average person that the average time to get money is 24 hours because he is on a wait list?

3 Likes

At network level they will be denied, yes. But at software level, they will have a request and if refused, the software will resubmit automatically after 10 minutes, for example. I do not think thatā€™s a lieā€¦

2 Likes

Seems like the tactic approach then by MaidSafe if dummed down is a queue for entrance: And the pace at which that queue lets in new vaults will be slow enough even if the attacked lined up tons of bad agents in the queue the network could protect against the constant influx of bad actors? This issue seems a lot less likely to be a problem once network is bigger with already lots of existing elders and sections to end up in, maybe at scale the network could relax such restrictions to enter the network.

3 Likes

Better to just say waiting to join the network. Donā€™t give such estimates. So while the user may be rejected the software will continue trying to join and inform the user that it is waiting to join. That way the user will know what is happening and not discouraged by rejection messages.

5 Likes

Case 1 for queues:

Having some element of gambling / unpredictability / chaos to the join process is ā€˜normalā€™ for the young internet

https://www.reddit.com/r/funny/comments/99x5pf/todays_kids_will_never_understand_the_struggle/

Case 2 for queues:

People seem to be proud of their ability to queue

Case 3 for queues:

I have periodically tried to join the community testnet (now joined yay!) but honestly if it had a queue feature rather than manual rejoin I would have definitely used that and feel it should be default behaviour.

I think you raise a great point. Truly. If the queue experience is handled in a way that allows people to engage with the process rather than find it repulsive then it may become a strength. It can be a talking point. A badge of pride. Anticipatory. Cathartic. Biological and emergentā€¦ I donā€™t like queues but I can see how the friction might be leveraged into an ā€˜invite onlyā€™ sort of prestige crossed with lotto-style dopamine hit.

Itā€™s definitely not a clear cut decision and the engineering is merely one part of this puzzle.

6 Likes

I think this thread is onto something here. Joining the network can be an achievement - are you good enough? / can you make the grade? - and the process itself made interesting and something not to be dropped lightly.

Showing stages (like earning badges and getting nearer to the goal) can both give encouragement and make it hard to let go - if you stop you lose this progress and have to start again.

Fertile ground for creative UX and even viral marketing here. All you marketeers could contribute something powerful by working out how to present this and use it to encourage sharing.

Maybe getting accepted gives bragging rights, maybe other kinds of reward such as a dummy token with some non financial benefits.

4 Likes

Many improvements along the way, even stake X safecoin up front etc. I think we will explore lots of ways, but none will be a rejection notice :smiley: It should all be fun and (eventually) profitable. Of course the other side of the equation must stand, we cannot pay nodes to do nothing as that increases the costs of storage and we do want them to be as small as possible. So there is a lot hiding in this one I feel.

10 Likes