---
tags: Network, Ethereum2.0
---
# (WIP) Complex BFT protocols analysis

**Work in Progress** An approach to analyze complex BFT protocols (relying on other protocols and services), including assessing attacks.

## Protocol analysis framework

Let's introduce concepts, which are important for analysis of complex Fault Tolerant protocols, consisting of sub-protocols or using (sub)services.

### Tolerance thresholds

Protocol tolerance properties (safety/liveness) are typically valid under some premises, e.g. amount of faults is less than some fraction of total processes. Or deposit-weighted value of faults is less than some fraction of total deposit weight. Or hashing power-weighted value of faults is less than some fraction of total hashing power.

### Correlated vs independent faults

Let's consider a system which can tolerate $f$ faults, given $3*f+1$ processes.
If faults are rare and independent then the probability that more than $f$ faults occurs can be extremely low.
However, faults can be correlated, i.e. probability of several simultaneous faults can be much higher.
There can be two group of reasons: centralization or attacks.

### Attacks

One particular case of correlated faults is attacks, i.e. there exist an adversary which has control over certain amount of nodes and is able to force node to deviate from protocol/benign behavior.
In the the case of Proof-Of-Stake system, one way is to put a deposit, so it can be costly.

However, an adversary can exploit weaknesses of a protocol to induce faulty behavior of otherwise benign node. So, protocol weakness can lower cost of attack, if obtaining indirect control of benign nodes becomes cheaper than the cost of deposits.

#### Centralization

If a protocol depends on another protocol or a service (supplier), either explicitly or implicitly, than the supplier faults can lead to the dependent process faults.

It may be the case, the supplier doesn't possess BF tolerance properties or they are weak(er), e.g. it has lower fault tolerance threshold.
If there is a single Byzantine fault, which can break safety/liveness of the protocol/service, then it's a centralized service/protocol.
If the protocol can tolerate only few Byzantine faults, then it's relatively centralized.

So, while some protocol may possess BFT properties, if ignoring its supplier faults, its dependence on a (semi-) centralized of can lower overall BFT properties of the system.