Practical Byzantine Fault Tolerance (PBFT) the one Consensus to Master

If you’re going to master one consensus in Blockchain thoroughly I would recommend mastering Practical Byzantine Fault Tolerance (PBFT). It’s currently not used by most blockchain applications but it’s the foundation of many consensus algorithms (i.e. RBFT, dBFT: Used by Neo, Plenum: Used by Indy/Sovereign) out there in the blockchain space.

With the PBFT consensus algorithm Barbara Liskov and Miguel Castro promised us more Safety and Liveness in distributed systems. However, biggest stipulation was that no more than 1/3 of the machines would be faulty.

Below is a diagram explaining how PBFT works. Let’s visualize this consensus algorithm as a group of generals (replicas). The generals are supposed to come up with an agreement, and there is one general that’s special and they are called the primary (see the stared one in line 0). The primary’s job is to relay the client’s message to the rest of the generals (see lines 1, 2, 3), once the message is relayed to other generals do their due diligence and work together to come up with an agreement.

*Line 3 has a stop sign because it’s the one faulty node, but don’t fear because no more than 2/3rd’s of the nodes are working fine.

How does it work?

1.Client sends a request to invoke a service operation to the primary (general)

2.The primary multicasts requests to replicas (other generals)

3.Replicas execute the request and send the reply to the client

4.Client waits for f + 1, f being # of faulty replicas, to reply with the same results

The 3 PBFT Phases: Pre-Prepare, Prepare, Commit

The PBFT algorithm goes through 3 phases, the pre-prepare, prepare, and commit phases.

Pre-Prepare phase they receive the request and creates a proposal (think of it as the order they are formally putting down on paper with all the necessary details).

In this scenario Frodo is a faulty replica, hence the f next to its name

Prepare phase they are coming to an agreement.

In this scenario Frodo is a faulty replica, hence the f next to its name

Commit phase, the name says it all, they commit their agreement and reply back. In addition they individually execute the request to check that they are getting the same results (to ensure the consensus property safety).

In this scenario Frodo is a faulty replica, hence the f next to its name