The Byzantine Fault Tolerance (BFT) algorithm ensures a transparent, trustless network, even with malicious activities. Network nodes agree on transaction timing and block generation. Byzantine Fault Tolerance allows the network to reach a fair consensus even if a 1/3 of nodes block transactions.
pBFT systems are energy efficient; they do not need high computational resources or a lot of energy to operate. Furthermore, pBFT can reach consensus at a fast pace because all the nodes are in constant communication with each other, and there’s no need for multiple confirmations.
The consensus achievement can be simplified in four steps:
- pBFT uses a voting mechanism to elect a leader node in a round-robin format.
- The leader initiates the decision and broadcasts it to the secondary nodes.
- All the nodes, both the leader and the secondary nodes, send a response.
- The response is considered valid when ⅔ + 1 nodes send the same response.
Recall that for the system be tolerant to **f** (faulty) nodes, we need the minimun of **3f + 1** nodes.
Example of 7 nodes, with 2 faulty ones:
The total **minimum **message count for this replica set is:
1 + 3f + 3f(3f-f) + (3f-f+1)(3f+1) + 3f-1However, constant communication is also pBFT’s Achilles heel: it only properly works in networks with a limited amount of nodes. The communication overhead increases exponentially with every new node that joins the network, and so does the time necessary to respond.
This is why **pBFT **does **not scale **as well as other consensus algorithms.
The Big O complexity of PBFT (Practical Byzantine Fault Tolerance) communication is typically **O(N^2)** in the number of nodes in the network, where N is the number of nodes in the network.
Unlike load-balancing your EC2 instances, you should never add more replicas than you absolutely need due to the added messages.
Asynchronous Byzantine Fault Tolerance (aBFT) improves BFT by removing the time limit on delayed messages and allowing them to be lost entirely.
https://medium.com/coinmonks/pbft-understanding-the-algorithm-b7a7869650ae
The PBFT algorithm provides both safety and (compromised) liveness assuming no more than [n-1/3] replicas are faulty. That means, if there are **f** amount of Byzantine nodes, the PBFT algorithm works only if the total number of **3f + 1** nodes are in the network (thus, we need 2f + 1 normal replicas). But why 3f + 1?
- Faulty replicas might not be responding to the communication. So we need n-f replicas to be greater than 0 for successful communication, where n is the total number of replicas in the network. Thus, n > f.
- We can think of a possible situation where f faulty replicas are in fact responding to the communication requests (of course maliciously, but other normal replicas can’t ensure whether they are honest or not), but another f amount of normal replicas are not responding. Still, we want the communications to proceed so n - 2f (f replicas that do not respond + f replicas that do respond but are faulty) should be greater than f (faulty nodes). Thus n -2f > f, and n > 3f.
- n > f and n > 3f. Thus n > 3f
n is an integer value, so we need minimal 3f + 1 replicas in the network.
In more detail, all the nodes within a consensus group are ordered in a sequence, with one primary node (aka a leader) and the others are referred to as backup nodes. Every round of PBFT has three phases as discussed below:
**Pre-prepare phase**: In this phase, the leader announces the next piece of record that the group should agree on. This is done by sending a “pre-prepare” message.**Prepare phase**: Upon receiving the pre-prepare message, every node validates the correctness and validity of the record and multicasts a “prepare” message to all the other nodes.**Commit phase**: Upon receiving the prepare messages from the 2/3 majority, each node multicasts a “commit” message to the group. Finally, each node waits for commit messages from the 2/3 majority to ensure that a sufficient number of nodes have agreed on the record proposed by the leader.
https://mirror.xyz/imlearning.eth/0b-UwdYw1SmsLROdiCe2IOro3fXZKXLG7l8-HT4Egm0
PBFT mechanisms can also be **susceptible to Sybil attacks **in situations where the network has fewer nodes. This could be solved by increasing the number of nodes but that will ultimately cause further scalability problems.
The communication complexity is O(n^2|B|)
The communication overhead increases exponentially