TechTalk 4 — PBFT
In order not to let consensus become the bottleneck of the entire blockchain system, MAP decided to choose a non-self-verifiable type of consensus algorithm to provide scalability and performance. MAP will choose a mixed consensus algorithm of DPOS and PBFT. So in today’s Tech Talk, we will have a look PBFT using in MAP
What is pBFT?
PBFT stands for Practical Byzantine Fault Tolerance is a consensus algorithm introduced in the late 90s by Barbara Liskov and Miguel Castro. pBFT was designed to work efficiently in asynchronous(no upper bound on when the response to the request will be received) systems. It is optimized for low overhead time. Its goal was to solve many problems associated with already available Byzantine Fault Tolerance solutions. Application areas include distributed computing and blockchain.
How does pBFT work?
In a nutshell, pBFT is a State Machine Replication with Byzantine fault tolerance. An algorithm to solve the General Byzantine problem is to use several rounds of voting to obtain majority consensus (⅔ votes required). But who is going to vote on what? And for how many rounds so as to ensure both safety and liveness? pBFT’s voting is composed of three stages: Pre-prepared, Prepare, and Commit.
For the sake of simplicity, let’s have the following assumption and rules：
- pBFT needs a total of 3f+1 nodes to tolerate f nodes, f stands for faulty or byzantine nodes.
- Let us say we have a total of 4 nodes, meaning that we should be able to withstand 1 fault. And we name the nodes from node 0, node 1, node 2, and node 3.
- Each node can validate each other’s signature
- Each action carries a sequence number.
- Every round there is a leading Node, let us start with Node 0 as leader, and the rest we call them Validators (Replicas)
- Decision rounds in a number that is variable, consecutively, are lead by one leader only
- Resides in the same leading node proposing and other validators voting procedure round we called the process a view.
- If the leader is found to be compromised, other nodes can start to vote and collectively decide to change a new Primary by round-robin strategy, which means Node 1 will be the next leader. This action called a view change and the view number will be increased by 1
Step 1: Pre-prepare
- The leader is responsible for receiving the client’s request. Let’s say Bob transfer 10 coins to Alice, which is the transaction to vote.
- The leader is responsible for initiating the proposal. The proposal sent to the replicas shall include the message content (transaction), the view number (corresponding uniquely to the leader) and a sequence number (which decide txn sequence), which can be described as the numeral order of the action being undertaken.
- The leader sends the “pre-prepare” messages with his signature to the other validators via the p2p network communication protocol.
Step 2: Prepare
- After each replica receives the “pre-prepare” message, it can either accept or reject the leader’s proposal. If the replica accepts the leader’s proposal, it will send a “prepare” message with its own signature to all the other replicas (including the leader). If it rejects, it will not send any message.
- Each node who issued the “prepare” message enters the “prepare” phase.
- If a replica receives more than or equal to three (>= 2f+1) “prepare” messages (this include itself and also from the leader), it enters the “prepared” state.
Step 3: Commit
- If the “prepared” replica decides to commit, it will send a “commit” message with the signature to all the replicas. If it decides not to execute, no message is sent.
- The replica who issued the “commit” message enters the “commit” phase.
- If the replicas receive equal or greater than three (>= 2f+1) “commit” messages, the message object is executed, which also means that the proposal has reached a consensus.
- After the execution of the message, the replica enters the “committed” state and returns the execution result to the client.
- After the reply has been sent, the replicas wait for the next request.
Once the client receives f+1 confirmation, then the client can acknowledge the state change. Readers may be familiar with the following chart. This is the normal case operation in pBFT.
Why does MAP choose pBFT?
MAP’s mission is to build an ultimate payment blockchain infrastructure. So inevitably High Transaction Speed is essential. pBFT can ensure very quick consensus time in the required setup and also another advantage of pBFT is the finality of the block. Finality will eliminate double payment issues and the longest chain rules in the POW chain.
TechTalk 3 — LibP2P
TechTalk 2 — FlyClient
Techtalk 1 — Non-Interactive Proofs of Proof-of-Works
· MarcoPolo Protocol Medium (For the latest articles)
· MarcoPolo Protocol GitHub (For the complete codes)
For more information, visit marcopolo.link