How to prevent Sybil Attacks without PoW/PoS
Preventing Sybil Attacks in a Decentralized Oracle Network, without relying on Proof of Work or Proof of Stake… and not die trying!
In this article, we’ll discuss the challenge of preventing Sybil attacks on Witnet, the Decentralized Oracle Network, without relying on Proof of Work (PoW) or Proof of Stake (PoS). Sybil attacks are an Achilles’ heel for decentralized protocols, so we’d like to share our process and design choices to deal with them.
So who’s Sybil?
The term “Sybil attack” is in reference to the 1973 book, Sybil — a case study of a woman diagnosed with a dissociative identity disorder.
The mechanisms of the attack are as follows: attackers aim to undermine a network by creating numerous fake identities. To an observer, these identities appear as separate users, but in reality, they are all controlled by a single entity. As a result, the attacker has a significant influence on voting power and could collapse or corrupt the network.
Sybil attacks are often confused with Eclipse attacks. However, in the latter, fake identities do not attempt to mislead the network entirely; instead, they corner individual nodes on the network by monopolizing all their P2P connections. By isolating specific elements, the attack can portray a fake network state to them. In summary, Eclipse attacks affect a small portion of a network, whereas Sybil attacks violate the entire network. You can read more about Eclipse attacks here:
How decentralized consensus algorithms deter Sybil attacks
Proof of Work (PoW), utilized by Bitcoin’s network, is the go-to model for Sybil resistance. To be rewarded, each identity on the network must carry out a non-arbitrary and equal amount of computational work. In other words, every Sybil identity must perform as much work as every honest identity, thus making a Sybil attack prohibitively expensive.
In Proof of Stake (PoS), consensus is achieved within a network of validators, who have “locked” or “staked” a non-negligible amount of capital for a set period of time. An attacker that wishes to carry out a Sybil attack on a PoS network needs to lock at least as much stake as that locked by honest validators.
Whilst the initial cost of an attack may not be immediately obvious (lock capital -> perform attack -> retrieve stake after a certain period), the PoS model is assumed to work because:
- the amount of capital an attacker can stake is limited, since the sum of the attacker’s stake plus all other stakes cannot exceed total circulation
- by performing a Sybil attack, the attacker depreciates public confidence (and value) of the underlying protocol/asset, thereby reducing or eliminating any profitability on the attack
The problem: divide and conquer approach
Consensus decisions within a Decentralized Oracle Network typically result in single data points, which are then often reutilized by other protocols. As a result, the benefits of performing a Sybil attack might take the form of assets other than those used to execute the attack. Thus, even with a loss of confidence in a network, a Sybil attack might still be profitable.
Thus, we can categorize Sybil attacks by two distinct incentive motives:
- those aiming to manipulate the result of a data request
- those aiming to attack the underlying blockchain consensus protocol.
Manipulating the result of a data request
An attacker can manipulate a data request so as to manipulate the resulting consensus. Attackers might be incentivized to do this if:
- the attacker’s stake in a particular result is large enough (e.g. conditional payments)
- the attacker aims to sabotage the reputation (and/or collateral) of other identities on the network.
These attacks often take one of two forms:
- Flash attacks: an attacker quickly spins up fresh Sybil identities and thus holds significant influence over the outcome of a data request
- Playbook attacks: the attacker must first play by the rules. The attacker creates numerous Sybil identities and then spends considerable time and resources pretending they are all honest identities. Once enough trust is gained, the attack is executed.
Attacking the underlying blockchain consensus protocol
If the protocol has its own blockchain, an attacker may be willing to disrupt the underlying consensus algorithm, by gaining sufficient influence through Sybil identities. The attacker can choose either to create invalid blocks or to disrupt the network. Defending against this kind of attack relies heavily on the reliability and resilience of the protocol’s consensus algorithm.
Proposing a new alternative
As described in the post below, the Witnet protocol aims to be fair, accessible and fully parameterizable, whilst maintaining data integrity.
Sybil attacks pose a significant barrier to achieving these goals. As a result, the following precautions have been built into Witnet’s architectural design.
An algorithmic reputation system
Witnet does not use a Proof-of-Work (PoW) or a Proof-of-Stake (PoS) mechanism, and so cannot rely on upfront cost to prevent Sybil attacks. Instead, Witnet has built an algorithmic reputation system designed to incentivize nodes to execute data requests in an honest way.
In short, the system works by redistributing reputation points from outliers and cheaters to honest, active network participants. Identities are assigned data request tasks (alongside mining and reward privileges) in proportion to their overall reputation score — their track-record. Reputation is non-tradeable and is redistributed autonomously and algorithmically by the Witnet protocol.
Thus, if an attacker wants to perform a Sybil attack on the network, each Sybil identity must first perform tasks honestly (and gain sufficient reputation scores). This is a classic Playbook attack, and not easy, fast or cheap to coordinate.
Performance-based data request committees
As mentioned above, active identities with high reputation scores are more likely to be assigned to data request committees (and thus be rewarded). To achieve this, the Witnet protocol has:
- an Active Reputation Set (ARS) tracking active identities in the system
- a Committee Selection Mechanism; a cryptographic algorithm for pseudo-randomly selecting committees based on reputation score.
To calculate the ARS, the system tracks a metric that can determine if an identity is actively participating in data requests. The metric consists of all identities that have been selected for committees over a period of time (e.g. during the last 1000 epochs).
For committee selection, each identity computes its own eligibility based on a Verifiable Random Function (VRF), which takes into account the identity’s current reputation score. If deemed eligible, the identity executes the data request and broadcasts a commitment to resolve it in a subsequent block.
Selecting block proposers in a fair way
Each identity calculates its eligibility to mine a block, based on the number of identities on the network. Eligibility is randomized (using a VRF), and is unrelated to reputation at this stage. This aligns with Witnet’s goal of a low barrier to entry, since miners do not need expensive hardware, large amounts of capital, or a reputation track-record to participate.
However, this means the system is vulnerable to Denial of Service (DoS) attacks. If an attacker controls enough Sybil identities, they may propose empty blocks, and halt the network (Note: invalid blocks would be rejected by the network).
In order to mitigate against this vulnerability, the Witnet protocol enforces a minimum of B block candidates for each epoch. This parameter is termed backup factor. If there is more than one block proposer, the deadlock is resolved by selecting the block proposed by the identity with the highest reputation (so long as the block is valid).
Collateral and coin age
Thus far, we have decreased the probability of a successful Sybil attack on the network by ensuring:
- every Sybil identity must hold a high reputation within the network
- Sybil identities cannot predict when they‘ll be elected to a data request committee
- a set of Sybil identities cannot predict when they will hold sufficient reputation to perform an attack
However, if an attacker can create infinite Sybil identities, the network is (theoretically) still vulnerable to both Flash and Playbook attacks. Therefore, Witnet has a combination of:
- Witnessing collateral: data requests require that participating nodes stake collateral, in the form of Unspent Transaction Output (UTXO)
- Coin age: in order to be used as collateral, UTXO must have reached a certain age (i.e. recently created UTXO cannot be staked).
The risk of Flash attacks can be drastically reduced by setting collateral requirements that are difficult to distribute among Sybil identities. Coin age makes it harder for an attacker to avoid detection when rapidly creating new identities, and makes it almost impossible to predict when a sufficiently high reputation score will be attained by each identity.
Reputation shelf-life
Even with the above precautions, the reputation system is still vulnerable to hoarding; an attacker may attempt to accumulate a significant portion of reputation points in their Sybil identities in order to perform an attack.
To prevent hoarding, the protocol has built-in reputation shelf-life, whereby reputation points expire and are redistributed after a certain time. Shelf-life is not determined by the passing of human time, but instead corresponds to the network’s velocity; higher velocity = higher volume of witnessing requests per block.
Thus, in order to maintain a high reputation, nodes will have to continuously contribute to the network by executing data requests in an honest manner. Additionally, given the stochastic nature of the cryptographic sortition, the reputation should continuously be flowing between nodes. It should not be easy to predict when nodes will have high reputation scores, so that it should be significantly hard for attackers to orchestrate a Playbook attack.
Recent updates
One of the issues with not using PoW or PoS is that node operators can spin up a vast number of nodes on the same device or IP, leaving the network vulnerable to crashing if one of the core servers goes down, and leaves the network more vulnerable to Sybil attacks. This is what happened in Testnet 9.0 during the Testnet Incentive Program Phase 2, when ~35k nodes joined (and quickly forked) the network. You can read about what happened here.
To solve these scalability issues, Testnet 9.1 now has some key additional components:
- Icing
If a node tries to connect to another node and fails (for example, the node is out of consensus or down), it will “freeze” that peer address for 24h. This makes the discovery of healthy peers much more efficient. - Inbound Sybil rejection 👥
Each node will only accept incoming connections from diverse IP ranges, i.e. a connection from IP1.2.3.4will be rejected if it has already established a connection from1.2.5.6. This guarantees a neutral view of the network consensus, and reduces the risk of your node going down if some unreliable but well-connected nodes fail.
Not only do these updates solve the issues faced in T9.0, but they also make the network hyper-connected, since nodes will often be connected to many nodes in other IPs.
What’s next?
We’ve tried our darndest to design a secure and fair reputation system to deal with Sybil attacks, but they need to be tested in the wild!
The reputation system is already complete, and can be field-tested in Testnet 9.2, so feel free to try it out by following the link below:
If you have any issues, need any help, or have any questions, don’t hesitate to reach out on the Witnet Community’s Telegram or Discord channels
Acknowledgements
This post was written in collaboration with Gorka, Claudia, Thomas and Adán. However, we depend on countless discussions with the wider Witnet community and, as always, this post would have been impossible without you all! :)
