Consensus algorithm in block chain _ block chain

Source: Internet
Author: User

In the Peer-to-peer network structure block chain system, each running node keeps its own copy of the data, how to guarantee the data unification between each other, make the data produced in the network so that everyone can recognize, and ensure the consistency of distributed system, then need consensus algorithm to realize.

The consensus algorithm solves the process of agreeing on a proposal (proposal). Common Algorithms

In the case of non-Byzantine errors, it generally includes Paxos, raft and their variants.
For situations where Byzantine errors can be tolerated, the PBFT series, POW series algorithms, etc. are generally included. Paxos and Raft

The Paxos problem refers to a consensus (Consensus) problem where there is a failure (fault) in a distributed system, but there is no malicious (corrupt) node scenario (that is, possible message loss or repetition, but no error message). Because the first is Leslie Lamport use Paxon Island's story model to describe and name. Byzantine problems and algorithms

The Byzantine issue was more extensive and discussed the question of agreeing on the possibility of the existence of a few nodes of evil (the message could be forged). The Byzantine algorithm discusses the protection of worst-case scenarios. The question of the Chinese general

Before the Byzantine general question, there had been a question of the Chinese general: Two generals would have to make an attack by courier or an agreement to retreat, but the messenger might get lost or be blocked by the enemy (lost or forged), and how to reach an agreement. According to FLP impossible principle, this problem has no solution.

FLP Impossible principle: There is no deterministic algorithm to solve the problem of consistency in a minimal asynchronous model system with reliable network and node failure (even if there is only one). Byzantine issues

Also known as the Byzantine general (Byzantine generals Problem), is a fictional model that was proposed by Leslie Lamport 1982 to explain the problem of consistency. Byzantine was the capital of the ancient Eastern Roman Empire, and because of its broad territory, several generals guarding the border (multiple nodes in the system) needed to pass messages through messengers to reach some unanimous decision. But as the generals may be traitors (errors in the System node), these traitors will try to send different messages to different generals, trying to interfere with the achievement of consistency.

The Byzantine question is how, in this case, the faithful generals will be able to achieve the same action.

In the Byzantine general question model, there are two default assumptions about the generals (nodes):

When all loyal generals receive the same order, the result of the execution of the order must be the same;

If the order is correct, then all loyal generals must carry out this order.

Suppose 1 means that all nodes have the same parsing and execution of the command, that the command must be a deterministic command, not random, and not dependent on the state of the node itself. (This command can not be a good mood to attack the enemy, bad mood on the ground to rest.) )

Suppose 2 means that a loyal general needs to determine whether the command received is correct. This method of judging commands is the core of the entire Byzantine fault-tolerant technique.

The general communication process, in the "Byzantine general Problem" also has a default assumption: point-to-point communication is no problem. in other words, here, we assume that general a is going to give General B an order x, then the dispatched runner will definitely pass the command X to General B.
We consider the situation of 4 generals and assume that the 4 generals have at most 1 traitors. When 4 generals A, B, C, D surround the enemy, a unified time must be negotiated to launch the attack. At this time, general a sent 3 messengers, respectively, told B, C, D general, 1 o'clock in the afternoon on time to launch an attack. At 1 o'clock in the afternoon, a, C, D three generals launched an attack that wiped out the enemy, while three of them found that B was a betrayal. Although B betrayed, it has no effect on the final task.
But if a is a betrayal, what will happen. A dispatched 3 messengers, telling B, C, and d the attack at 1 o'clock in the afternoon, 2 and 3 respectively. Then, at 1 o'clock in the afternoon, General B to attack the enemy, because of outnumbered, annihilated; 2, General C annihilated; 3, General D was annihilated.

For a loyal general, he did not know who the traitor was, so he could not fully believe the command he had received, and he must judge the order. Byzantine Fault tolerant algorithm

The fault-tolerant algorithm for Byzantine problems solves the problem that the network communication is reliable, but the consistency of the node may fail.

The practical Byzantine Fault tolerant (PBFT), first proposed by Castro and Liskov in 1999, is one of the most widely used BFT algorithms. Consistency can be guaranteed as long as some nodes in the system are working properly.

The core idea of the algorithm is that for every general who receives a command, it asks the other person what order they receive.
Back to the second situation (A is a traitor), a dispatched 3 messengers, respectively, telling B, C, D to attack at 1 o'clock in the afternoon, 2, 3. General B sent a messenger to tell the C and D two generals, B received the order is 1 o'clock in the afternoon attack. C also dispatched a messenger to tell B and D two Generals, C received the order is 2 o'clock in the afternoon attack. D likewise told B and C two generals, D received an order of 3 o'clock in the afternoon offense. So, B got 3 instructions: a command B 1 o'clock in the afternoon offense, a command C 2 o'clock in the afternoon offense, a command D 3 o'clock in the afternoon offense. b It's easy to judge that A is a traitor (because B knows that there is at most one traitor). C and D can make the same judgments. Therefore, the negotiation of this attack time is invalid.
With this approach, what will happen in the other case. When B was a traitor, General a dispatched 3 messengers, telling B, C, and D, to launch the attack on Time 1 o'clock in the afternoon. B told C said B received the order is 2 o'clock in the afternoon, B told D said received the order is 2 o'clock in the afternoon, C and D respectively told the other 2 generals, a told them the order is 1 o'clock in the afternoon.
So, C, D received messages are two 1 points, a 2 point. For C and D, it is not necessary to judge who is a and b who is the traitor-they only need to execute the command received more than that.

If a is loyal, then B is betrayed, in this case, for A, he knows he is loyal, he issued a command, at least 2 generals will be executed, so 1 o'clock in the afternoon, a, C, D three generals to attack together, 3 generals to attack together, the enemy was annihilated. If B is loyal, then B will receive two 1 points a 2 point, B will also execute received more orders, so B, C, D three generals to attack together, there are 3 generals to attack together, the enemy was annihilated. In any case, this is the way it is done, and the result is no problem.
The use of PBFT method is essentially to use the number of communications in exchange for credit. The execution of each command requires 22 interactions between nodes to check the message, and the cost of communication is very high. Usually using PBFT algorithm, the communication complexity between nodes is the square of the number of nodes.
Note that in all the cases discussed above, there is also the assumption that all messages delivered are verbal messages . The verbal agreement satisfies three conditions:

A1: Each sent message can be posted correctly
A2: Information recipient knows who sent the message
A3: To know the missing message

The meaning is, a tells B 1 o'clock in the afternoon offense, B may tell C to say "a command I 2 o'clock in the afternoon attack". If a written message is used, the situation is not the same. In addition to A1,A2 and A3, we add a conditional A4 to the verbal agreement to make it a written agreement.

A4: (a) The signature cannot be forged and can be found once tampered with and the traitor's signature may be forged by other traitors; (b) Anyone can verify the reliability of the signature.

A send a runner to b a piece of paper, a general in his own unique handwriting written "1 o'clock in the afternoon attack", then asked B to pass this paper to c,b on paper with their own unique handwriting signed to agree, and B to C,c also signed the agreement, and then D agreed, and finally signed the famous paper to give everyone another look, You can make all the nodes consistent. This use of a written signature message, the algorithm requirements is much simpler. However, the premise of using a written message is that every general knows what the other generals ' handwriting is and can't imitate the other generals ' handwriting.

On the basis of PBFT, there are many variant algorithms, these algorithms are often with some additional assumptions. For example: think that the client initiating the request must be loyal, the client to verify the loyalty of the node; think most of the time the generals are loyal, so reduce the number of 22 interactive verification messages, by dividing the nodes to improve the processing speed of the whole system; These variant algorithms, due to additional assumptions, lead to a reduction in the overall system's degree of centrality (see the 6th article in this series for an understanding of the degree to which the block chain system is going to be centered).

The PBFT algorithm includes three stages to reach a consensus: Pre-prepare, Prepare, and Commit. the consensus algorithm in Super Ledger

At present, the consensus algorithm of fabric embedding is pbft.

Reference URL:
Byzantine problems and algorithms
Block Chain Workshop | Understand the "Byzantine fault-tolerant", also read the core technology of block chain
A probe into the problems of Byzantine generals
Super Ledger pbft (Byzantine fault-tolerant) algorithm detailed (too complicated to look at)

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.