Block chain consensus algorithm: A practical Byzantine fault-tolerant mechanism pbft

See personal blog for details:

http://brainware360.cn/%E5%8C%BA%E5%9D%97%E9%93%BE%E5%85%B1%E8%AF%86%E7%AE%97%E6%B3%95%EF%BC%9A%E5%AE%9E%E7%94 %a8%e6%8b%9c%e5%8d%a0%e5%ba%ad%e5%ae%b9%e9%94%99%e6%9c%ba%e5%88%b6pbft.html#more

Consensus mechanism is the core component of block chain, the consensus mechanism, represented by POW, POS and dpos, needs to be based on tokens, that is, to issue their own monetary system to form the incentive mechanism of their own network operation, but the node has a certain basis of mutual trust and does not need to rely on tokens to support the whole network block chain , traditional consensus algorithms such as PBFT, Paxos, and raft are useful, and Paxos is the first proven consensus algorithm. This article is limited to space, Paxos and raft left to follow.

practical Byzantine fault-tolerant mechanism pbft

PBFT algorithm is proposed by Miguelcastro and Barbara Liskov 1999, the original intention is to solve the problem of convergence in distributed system, and the goal of the consensus mechanism of block chain coincide, its main feature is that the network is highly fault-tolerant, in a network with 3f+ 1 nodes, The number of failed nodes is F, the network is still able to operate normally, and the fault tolerance is close to 33%. At present, the Chinese Chinaledger Alliance and the Hyperledger Alliance are studying and discussing the practical application of PBFT.

The algorithm first needs to introduce the concept of view and Validation node (replica), replica contains the master node and the backup node. The master node (primary) is selected based on a formula, and the other replica nodes become backup (backups) nodes. When the primary node is valid, it means that it is in the same view, and when the primary node fails, the backup node detects that it needs to start the view change process through the timeout mechanism to elect the new master node. The whole algorithm flow is as follows: First, a client initiates a service request to the master node, the master node distributes the request to all the backup nodes, the backup node is processed and then returns to the client, and the client receives the same result of f+ 1 nodes as the final result of the algorithm.

The implementation process is divided into three-stage protocol (THREE-PHASEPROTOCOL), i.e., preparation (pre-prepare), preparation (prepare) and validation (commit).

Pre-Preparation (Pre-prepare) phase: After the master receives the request, the request is given an ordinal n, and then the message is sent to all backup nodes, and the information format is <<pre-prepare,v,n,d>,m>,v is the view number. M is the request information sent by the client, and D is the summary of M. If the information satisfies the conditions established by the backup node (such as checking the view number, whether the ordinal n is in a reasonable interval, whether M was received before, etc.), the node enters the preparation phase. Some conditions are set up by the backup node because the primary node may be a failed node, it may give the same sequence number to different requests, or do not assign an ordinal number, or leave adjacent ordinal numbers discontinuous:

Preparation (Prepare) phase: The node that enters the preparation phase sends ready messages to all replica nodes <prepare,v,n,d,i>,i is the node number. After both phases, each node receives two messages, each replica node validating the consistency of the prepared and prepared messages, that is, verifying that the view number V, message ordinal n, and digest d are consistent and, if consistent, go to the next stage.

Confirmation (Commit) phase: Entering this phase, a replica node sends information to other replica nodes, Information format <commit,v,n,d (m),i>. When the node receives additional replica node acknowledgment information, it verifies that the view number V, message ordinal n, and digest d are consistent, and that the validation is consistent. When the replica node receives the confirmation message of 2f + 1 (including its own) validation, it executes the results to the client and writes the result to the block, in which there are at least 1 2f+ (including its own) nodes before writing the block.

The reason for the existence of a confirmation (commit) phase is that a single replica node receives 2f + 1 (including its own) prepare information and does not guarantee that its prepare information has been received by other replica nodes, That is, the other nodes are not necessarily ready to prepared, and a confirmation (commit) phase is required to validate this.

If the K-bar request is executed consecutively, when the K-clause is executed, broadcast to the whole network, tell the other replica node it has finished this k, if all feedback said that the k we also executed, then we can delete the information of this k, and then execute K, after the completion of a broadcast, That is, every K-bar to launch a whole network consensus, this concept called Checkpoint, every k go to ask everyone's opinion, if obtained most of the recognition, formed a stable checkpoint (recorded in the number of k), this mechanism is called " Garbagecollection ".

PBFT is a static consensus that can be applied when learning about a finite-consensus node. For the private chain and the alliance chain, if the number of nodes is small (no more than 100), PBFT can be used to form a consensus, the public chain has a large number of dynamically changing node networks, with PBFT efficiency is too low.

The use of PBFT algorithm also need to note that it can not be very good storage of its transaction information, some of the invalid copy may lead to information leakage, should be corresponding to the response mechanism.

My BTC Address: 1K8NI4MNQN7VJFZKJHJHLPWZ55OWG9J1JD