consensus algorithm
The most important thing in the blockchain is the consensus algorithm. Bitcoin uses POS (Proof of Work, Proof of Work), and Ethereum uses POS (Proof of Stake, Proof of Stake), which makes the arithmetic less important. Now, the variant of POS, DPOS (Delegated Proof of Stake), further reduces the waste of computing power and strengthens the security of the blockchain.
However, for permissioned chains or private chains that do not require a currency system, the nodes with absolute trust and the high-efficiency requirements cannot be provided by the above consensus algorithms. Therefore, for such blockchains, the traditional consensus algorithm becomes the first choice, PBFT (Byzantine Fault Tolerance), PAXOS, RAFT.
PBFT (Byzantine Fault Tolerance)
Based on the Byzantine Generals problem, consistency assurance is mainly divided into three stages: pre-prepare, prepare, and commit. The process is shown in the figure below:
Among them, C is the sending request side, 0123 is the server side, and 3 is the downtime server side. The specific steps are as follows:
1. Request: Requester C sends a request to any node, here is 0
2. Pre-Prepare: Server 0 broadcasts after receiving C's request and spreads to 123
3. Prepare: 123, record and broadcast again after receiving, 1->023, 2->013, 3 cannot broadcast due to downtime
4. Commit: 0123 node in the Prepare stage, if it receives more than a certain number of identical requests, it will enter the Commit stage and broadcast the Commit request
5. Reply: 0123 node in the Commit stage, if it receives more than a certain number of identical requests, it will give feedback to C
According to the above process, consistency is possible in the case of N ≥ 3F + 1, where N is the total number of computers and F is the total number of computers in question
When N=4 F=0:
| get data | final data | |
| A | 1 1 1 1 | 1 |
| B | 1 1 1 1 | 1 |
| C | 1 1 1 1 | 1 |
| D | 1 1 1 1 | 1 |
When N=4 F=1:
| get data | final data | |
| A | 1 1 1 0 | 1 |
| B | 1 1 0 1 | 1 |
| C | 1 0 1 1 | 1 |
| D | 0 1 1 1 | 1 |
When N=4 F=2:
| get data | final data | |
| A | 1 1 0 0 | NA |
| B | 1 0 0 1 | NA |
| C | 0 0 1 1 | NA |
| D | 0 1 1 0 | NA |
It can be seen from this that Byzantine fault tolerance can accommodate nearly 1/3 of the faulty node error, and Hyperledger created by IBM uses this algorithm as a consensus algorithm.
PAXOS
PAXOS is a consensus algorithm based on message passing and highly fault-tolerant.
The algorithm itself is extremely concise in language description:
phase 1
a) The proposer sends a prepare message to more than half of the acceptors in the network
b) The acceptor normally replies to the promise message
phase 2
a) When there are enough acceptors to reply to the promise message, the proposer sends the accept message
b) Normally the acceptor replies to Accepted information
a) The proposer sends a prepare message to more than half of the acceptors in the network
b) The acceptor normally replies to the promise message
phase 2
a) When there are enough acceptors to reply to the promise message, the proposer sends the accept message
b) Normally the acceptor replies to Accepted information
There are three types of roles Proposer, Acceptor and Learner in PAXOS. The main interaction process is between Proposer and Acceptor. The diagram is shown in the following figure:
Where 1,2,3,4 represent the order.
The following figure describes the situation of multiple Proposers, T represents the time axis, and only the relationship between one Proposer and Acceptor is drawn in the figure:
A3 sends accepted to A1 at T1, and then receives A5's prepare at T2, and A1 notifies A5 of the final result (tax rate 10%) at T3. There are two situations here:
1. The N5 sent by A5 is smaller than the N1 sent by A1, then A3 directly rejects A5
2. The N5 sent by A5 is greater than the N1 sent by A1, then A3 replies to the promise, but with (N1, 10%) on A1
The final A5 will also accept 10%
The above figure describes that if a larger N has been Promised, it will directly Reject a smaller N
As described above, even if a Promise has an N, if a larger N is received before it is accepted, it will still Reject the N that has been Promised.
The overall flow chart is summarized as follows:
The PAXOS protocol is used in WeChat PaxosStore, and the
Paxos protocol process is called billions of times per minute.
RAFT
The core idea of RAFT is easy to understand. If several databases have the same initial state, as long as the subsequent operations are consistent, the subsequent data can be guaranteed to be consistent. Therefore, RAFT uses Log to synchronize, and divides the server into three roles: Leader, Follower, Candidate, which can be converted to each other.
From a large perspective, RAFT is divided into two processes:
1. Election of Leader
2. Leader generates Log and synchronizes Headbeats with Follower
Election Leader
Follower increments the current term, converts to Candidate, votes for itself, and initiates RequestVote RPC, waiting for the following three situations to occur;
1. Get more than half of the servers' votes, win the election, and become the Leader
2. Another server wins the election and Receive the corresponding heartbeat and become a follower
3. The election times out, no server wins the election, the current term is incremented, and the election is re-initiated
1. Get more than half of the servers' votes, win the election, and become the Leader
2. Another server wins the election and Receive the corresponding heartbeat and become a follower
3. The election times out, no server wins the election, the current term is incremented, and the election is re-initiated
Sync log
Leader accepts client requests, Leader updates logs, and sends Heatbeats to all Followers to synchronize logs. All follers have ElectionTimeout. If the Headbeats from the leader are not received within the ElectionTimeout time, the leader is considered invalid and the leader is re-elected.
Flow chart:
Security Guarantee
1. The flow of the log is only from the leader to the follower, and the leader cannot cover the log
2. Logs that are not up-to-date cannot become Candidate
Animated RAFT: http://thesecretlivesofdata.com/raft/
Summarize
The above three consensus algorithms are just the core ideas. Of course, there are still many aspects that need to be further improved if they are to be implemented concretely. All of the above three algorithms can be used as consensus algorithms for blockchain, and some companies have begun to use them, but the most famous one is the PBFT consensus algorithm used by IBM's Hyperledger.
| get data | final data | |
| A | 1 1 1 1 | 1 |
| B | 1 1 1 1 | 1 |
| C | 1 1 1 1 | 1 |
| D | 1 1 1 1 | 1 |