Preventing Sybil Attacks


Blog post on what are Sybil attacks

When thinking about Sybil in Radix, you need to consider where Sybil would give you a distinct advantage.

  1. Eclipse attacks
  2. Consensus attacks

Neither of these are easy or cheap to pull off…

Blog post on Eclipse attacks

Sybil protection for Eclipse Attacks

All nodes have a NID (Node Identifier) which is produced by creating a POW hash of sufficient difficulty using its public key and some ledger meta data. I won’t detail the algorithm used to decide which ledger data is used for the POW here, but its results in ASIC resistance.

If I want to eclipse a node (or set of nodes), then due to the fact that connections and gossip are driven by NIDs and NID distance, I need to calculate my NID to be as close to the NID of the node I wish to attack as possible.

If I don’t, I cant have any strong guarantees that I can eclipse them, or that my eclipse is temporary (another new node joins that has a NID closer to my target than I do, therefore the eclipse is broken and the target node has access to the truth).

Generally for me to create a NID in acceptable range of a target NID requires me to generate as many POWs for my public key as there are nodes in the network. In a healthy network of 10,000 nodes (similar to BTC and ETH), thats 10,000 hours of work for a NID that is in range.

The target node probably holds more than 1 TCP connection, the default is 8, but node operators can configure however many they would like.

In order to fully eclipse that node via its TCP connections, I would need 8 NIDs in range, so about 80,000 hours of work.

Exaggerating the problem further is that I never actually know if I have eclipsed that node. Say I create 8 NIDs for my target, but only 6 of them can connect. Does that mean that the node only has 6 connections in total and is eclipsed? Or are 2 of its connections already occupied by other NIDs that I don’t control.

My only option here is to continue trying to connect to it, in the hope that the nodes I don’t control disconnect from it, and I can connect to it before a connection to another node is established.

Maybe all 8 of my nodes connect, but I still don’t know the status of the eclipse, maybe that node is configured to hold 9+ TCP connections.

Finally, nodes use TCP for sync, and UDP for gossip. UDP doesn’t have any connection limit, and I as an attacker can not prevent any node in the network talking to my target over UDP, nor can I prevent my target from talking to any other node over UDP.

My target can still receive truthful statements, from anywhere in the network, and there is nothing I can do about that as an attacker. Even if I have managed to eclipse them from a TCP/Sync perspective, they will likely receive truthful information over UDP that conflicts with whatever it is I am telling it.

Full eclipse attacks in Radix are pretty much impossible as far as I can tell.

Sybil Protection for Consensus Attacks

POW in Bitcoin mining is used to ensure that only one vote can be made every 10 mins (on average). Its a very simple Sybil protection mechanism that means no matter how many machines I have, or miners, or identies, the probability is that I can only vote (create a block) once every 10 mins.

The issue is that POW vote Sybil is not very scalable or efficient.

In Radix, Mass is used as our “POW” vote Sybil mechanism, and mass is a product of an Atoms value (which can be monetary, data, or some other metric) and time. The longer something is static, the more mass it achieves.

This mass is then distributed to the nodes in the network depending on their position in the Temporal Proof for that Atom.

Each Atom takes a different route than another Atom depending on its origin point, which makes predicting where and who Atoms are going to come from to you next totally unpredictable.

When I receive an Atom, and validate it, I “stamp” the Temporal Proof with my approval, essentially a vote, which is weighted by the amount of mass that NID controls.

In order for me as an attacker to control consensus and double spend, I need to control > 51% of all the mass in the Radix universe.

Now, a 51% attack in Bitcoin is expensive but possible, just buy lots of ASIC hardware, setup and go.

Not so in Radix. To control the universe you need mass. Mass is produced by mass carrying Atoms (transactions mainly). The longer some funds have been in an account, the more mass they produce.

In order to have enough mass to mount an attack, I as an attacker would have to be the initial validator for > 50% of all Atoms in the universe.

I can produce my own Atoms, which would require a HUGE amount of funds at my disposal, which I then need to manage to extract the maximum amount of mass from them (which generally means I would have to hold 50%+ of ALL XRD in existence at all times), not to mention the fees.

A better option is probably to be the initial validator for as many of everyone elses Atoms as possible.

To do that I need to create an equal amount of nodes in the network as there were before I started. If there were 10,000 nodes before I started, I need to create 10,000 nodes of my own.

I need to generate 10,000 NIDs, distributed as evenly as possible throughout the NID space and pay the 10,000 hours cost of doing so.

Finally, I need my 10,000 to be connected to as many transaction producing clients as possible. If a client holds 8 connections to the network, I need at LEAST 4 of those in order to catch my 50%+ mass, for EVERY connected client.

As with eclipsing though, even if I do all that, theres a final nail that kills me dead.

50% of the mass from now isn’t enough, as all the nodes that were in the network before me already have mass. I actually need 50%+ of all the mass ever generated in order to be sure my 51% attack will actually be near successful, which in turn means that I need to control much more than 10,000 nodes to do so in a reasonable amount of time.