---
tags: Network, Ethereum2.0
---
# Sybil attack counter-measures in practical BFT systems

**Abstract**

Byzantine Fault Tolerance protocols can tolerate amount of faults which is less than some fraction of total amount of participant processes. If it's relatively easy to add a new participant, then a [Sybil attack](https://en.wikipedia.org/wiki/Sybil_attack) is possible: an adversary can add a number of processes, so that the amount exceeds the fraction of faults that the protocol can tolerate. Practical BFT systems thus have to restrict protocol participants. We review common approaches to do that and analyze beacon chain weaknesses from that point of view.

## Motivating example

Let's a consider a BFT protocol, which requires $3f+1$ processes to tolerate $f$ faults. If other processes can join freely, then an adversary can add to a system comprising of $n$ processes $\lceil n/2 \rceil$ new processes that it can fully control. The combined system will need $3\lceil n/2 \rceil + 1$ to tolerate $\lceil n/2 \rceil$ faults, while it has only $n+\lceil n/2 \rceil$ processes, which is strictly less than $3\lceil n/2 \rceil + 1$. Thus, the adversary can orchestrate an attack on the system.

## Proof-of-X systems

Practical BFT protocols, like blockchains can have their safety/liveness thresholds expressed in different terms, i.e. "2/3 deposit-weighted validators" for [Proof-of-stake](https://en.wikipedia.org/wiki/Proof_of_stake) or "50% hashing power" for [Proof-of-work](https://en.wikipedia.org/wiki/Proof_of_work) consensus mechanisms.
However, the principle stays the same and [Sybil-like attacks](https://en.wikipedia.org/wiki/Sybil_attack) can be possible, if it's an open system. However, designers of such system can make such attacks expensive in some sense: if a participant is detected to be maleficent, then it loses some resource.
Thus, one can view Proof-of-X ([Proof-of-Work](https://en.wikipedia.org/wiki/Proof_of_work), [Proof-of-Space](https://en.wikipedia.org/wiki/Proof_of_space), [Proof-of-Stake](https://en.wikipedia.org/wiki/Proof_of_stake), [Proof-of-Authority](https://en.wikipedia.org/wiki/Proof_of_authority)) consensus mechanisms as a way to solve Sybil attack problem in an open system. The choice of X denotes the resource kind at stake.

The main conclusion is that any practical BFT system should augment its safety/liveness principles with a resource constraint principle, which will make it costly for an adversary to organize a Sybil attack. One can argue that this is true regarding open systems only, which allows new participants to join more or less freely. However, closed systems can be viewed as a Proof-of-Authority systems, allowing participants to join according some administrative rules.

Many academic BFT protocols can be viewed as abstract Proof-of-Authority systems: they simply assume there are $n$ distributed processes, abstracting from how they have been chosen. However, when implementing them in reality, one has to choose participants by some principle.

Thus, a resource constraint mechanism is an important principle when designing or analyzing practical BFT systems.

## Modular protocols

Complex protocols can be formulated in a modular way. A high level protocol can rely on services or properties, which should be implemented by sub-protocols.

If a super-protocol should possess BFT properties and critically depends on some service, which is to be implemented by a sub-protocol, then the sub-protocol should also possess BFT properties. Obviously, if the latter is not true, then there are certain faults which cannot be tolerated by the sub-protocol. But since the super-protocol critically depends on the sub-protocol, then one cannot be sure the super-protocol is tolerant to the faults. At least, additional rigorous analysis is required. But in general, one should suspect that the super-protocol can be compromised.

So, when analyzing modular BFT protocols, one wants sub-protocols to possess BFT properties too, or, at least, re-assure, that if the latter is not true, then the faults can be tolerated by some other means.

## Beacon chain protocol of Ethereum2.0

Based on the above, let's examine beacon chain protocol of Ethereum 2.0 from this point of view.

### Validator clock synchronization

If validator clock discrepancy becomes large, then Casper FFG protocol safety, liveness or robustness can be violated. Clocks are drifting, typical uncompensated computer clocks can drift up to several seconds a day, thus clock should be synchronized by some protocol.
Following the principle above, the clock synchronization protocol should be BF tolerant.
However, since no protocol is specified, one can expect that most validators will choose NTP protocol, to synchronize to

###

- validator clock should be synchronized. No clock sync sub-protocol currently is specified
- topic service. lib-p2p.
- topic and node discovery. discovery
- node membership