1.4 [Blockchain] consensus algorithm contention (pbft,raft,pow,pos,dpos,ripple)

Several common consensus mechanisms (pbft,raft,pow,pos,dpos,ripple) in blockchain have been summarized in recent days. Try to use simple and understandable language, the space is large, want to understand can read each algorithm introduced in front of the principle. This article mainly refers to the Blockchain technology guide, first of all to express our thanks!

---Begin---

Blockchain architecture is a distributed architecture. Its deployment mode has three kinds of public chain, alliance chain and private chain, corresponding to decentralized distributed system, partial decentralized distributed system and weak center distributed system.

In distributed systems, multiple hosts compose network clusters by means of asynchronous communication. In such an asynchronous system, there is a need for state replication between hosts to ensure that each host agrees on a state consensus. However, in an asynchronous system, there may be failed hosts that cannot communicate, and the performance of the host may be degraded and the network may be congested, which can cause error messages to propagate within the system. Therefore, it is necessary to define fault-tolerant protocols in the default unreliable asynchronous network to ensure that the hosts reach a secure and reliable state consensus.

The so-called consensus, simple understanding means that everyone has agreed to the meaning. In fact, in real life, there are a lot of situations that need to reach consensus, such as meeting and discussion, the two sides or parties signed a cooperation agreement. In a blockchain system, what each node has to do is keep its ledger consistent with other nodes ' ledgers. In a traditional software architecture, this is almost not a problem, because there is a central server exists, that is, the so-called Main library, the other from the library to the main library on the line. In real life, a lot of things people are in accordance with this way of thinking, such as corporate bosses issued a notice, employees do. But Blockchain is a distributed peer network structure, in which no node is "Boss" and everything has to be discussed.

So in the blockchain system, how to keep each node consistent with one rule is a very central problem, the solution of this problem is to develop a set of consensus algorithms, to achieve the consistency and correctness of the ledger data on different ledger nodes. It is necessary to learn from the existing algorithms to realize the state consensus in the distributed system, to determine the mechanism of selecting the accounting nodes in the network, and how to ensure the formation of correct and consistent consensus in the whole network of the ledger data.

The consensus algorithm is actually a rule, and each node confirms its own data according to this rule. Let's put aside the principle of the algorithm, first think about how we will solve such a problem in life: If a group of people in the meeting, the group does not have a leader or the boss, everyone's opinions, then finally how to unify a decision out? In actual processing, we usually select a person in a certain period of time, the person responsible for the summary of the content, and then publish the full views, the other people vote, everyone has the opportunity to do the summary of the publication, and finally who the supporters of the final opinion of who will prevail. This idea is actually a kind of consensus algorithm. However, in the actual process, if the number of people and the number is determined, it is good to deal with, if a large number and the number is not fixed, it is difficult to vote in this way, the efficiency is too low. We need a mechanism to filter out the most representative of the people, in the consensus algorithm is to filter out a representative node.

So how do you filter it? is actually set up a set of conditions, just like screening top students, to a set of indicators for everyone to complete, who can better complete the indicators, who will have the opportunity to be selected. In the blockchain system, there are many such screening schemes, such as PBFT (practical Byzantine Fault tolerance, practical Byzantine Fault tolerant algorithm), PoW (Proof of work, workload proof), PoS (Proof of Stake, proof of Rights), DPoS (Delegate Proof of Stake, entrusted with the rights of proof), Ripple (Ripple), and so on, a variety of different algorithms, in fact, is a different game play method.

I. Byzantine fault-tolerant technology (Byzantine Fault TOLERANCE,BFT)

The Byzantine fault-tolerant technology (Byzantine Fault TOLERANCE,BFT) is a kind of fault-tolerant technology in distributed computing field. The Byzantine hypothesis is the modelling of the real world, which can cause unpredictable behavior in computers and networks due to hardware errors, network congestion or interruptions, and malicious attacks. Byzantine fault-tolerant techniques are designed to handle these anomalous behaviors and to meet the specification requirements of the problem to be solved.

Byzantine fault-tolerant technology comes from the Byzantine general Problem (bash!) View the issue).

In distributed systems, especially in the blockchain network environment, it is similar to the Byzantine general environment, with a functioning server (like loyal Byzantine generals), faulty servers, and a server for the perpetrators (like a renegade Byzantine general). The core of the consensus algorithm is to form a common understanding of the network state between the normal nodes.

Typically, these failed nodes are called Byzantine nodes , and the normal nodes are non-Byzantine nodes .

The Byzantine fault-tolerant system is a system with n nodes, and the whole system satisfies the following conditions for each request:

1) All non-Byzantine nodes use the same input information to produce the same result;

2) If the information entered is correct, then all non-Byzantine nodes must receive this information and calculate the corresponding result.

The commonly used assumptions in Byzantine systems include:

1) The behavior of the Byzantine nodes can be arbitrary, and the Byzantine nodes can be conspired;

2) Errors between nodes are irrelevant;

3) between nodes through an asynchronous network connection, the message in the network may be lost, disorderly and delayed arrival, but most of the protocol assumes that the message can be communicated to the destination in a limited time;

4) information passed between servers can be sniffed by a third party, but cannot tamper with, falsify, and verify the integrity of the information.

The original Byzantine fault-tolerant system lacked practicality because of the need to demonstrate its theoretical feasibility. Additionally, additional clock synchronization mechanisms are required , and the complexity of the algorithm is increased exponentially with the number of nodes .

Two. pbft:practical Byzantine Fault tolerance, a practical Byzantine fault-tolerant algorithm.

The practical Byzantine fault-tolerant system (PBFT) reduces the operational complexity of Byzantine protocols, from the exponential level to the polynomial level (polynomial), making it possible to use Byzantine protocols in distributed systems.

PBFT is a state machine copy-copying algorithm, which is modeled as a state machine and a state machine is replicated in different nodes of a distributed system. A copy of each state machine saves the state of the service and also implements the operation of the service. The collection of all replicas is represented by the capital letter R, using 0 to | An integer of r|-1 represents each copy. For ease of description, it is generally assumed that the number of failed nodes is m and the total number of service nodes is | R|=3m+1, here m is the maximum number of copies that are likely to fail. Although more than 3m+1 replicas can exist, additional replicas do not improve reliability in addition to performance degradation.

PBFT requires co-maintenance of a state in which all nodes take action consistently. To do this, you need to run class three basic protocols, including conformance protocols, checkpoint protocols, and view Exchange protocols. We focus on consistency protocols that support the daily operation of the system. A consistency protocol consists of at least a few stages: request, Sequence number allocation (Pre-prepare), and Response (reply). Depending on the protocol design, it may include phases such as mutual interaction (prepare), sequence confirmation (commit), and so on.

PBFT Protocol Communication Mode

For the PBFT protocol communication mode, each client request needs to go through 5 stages, and then execute the client's request after the server has reached a consensus in two 22 interactions. Because the client is not able to  from the server on any server running state, the primary node in PBFT can only be monitored by the server if an error occurs. If the server cannot complete a client request for a period of time, the view Exchange protocol is triggered. Where c is the client, N0~N3 represents the service node, special, N0 as the primary node, N3 as the fault node. The basic process for the entire agreement is as follows:

1) The client sends a request to activate the service operation of the master node.

2) When the primary node receives the request, it initiates a three-phase protocol to broadcast the request to each slave node.

[2.1] The ordinal allocation phase, the master node assigns a sequence number n to the request, the broadcast sequence number assigns the message and the client's request message m, and constructs the pre-prepare message to each slave node;

[2.2] Interactive phase, receive pre-prepare messages from the node, broadcast prepare messages to other service nodes;

[2.3] Sequence confirmation phase, each node in the view of the request and order validation, broadcast a commit message, execute the received client's request and to the client in response.

3) The client waits for a response from a different node, and the response is the result of the operation if the m+1 response is the same.

PBFT is used in many scenarios, and in a blockchain scenario, it is generally suitable for private chain and federated chain scenarios where strong consistency is required. For example, in the IBM-led blockchain Super Ledger project, PBFT is an optional consensus protocol. In Hyperledger's fabric project, the consensus module is designed to be pluggable modules that support consensus algorithms like PBFT, raft, etc.

Three. Raft agreement.

Under the practical scenarios of these distributed systems, the hypothetical conditions do not need to consider the Byzantine fault, but only deal with the general freezing failure. In this case, the adoption of protocols such as Paxos is more efficient. Paxos is a protocol designed by Lamport to maintain the consistency of distributed systems. But because the Paxos is very complex, it is difficult to understand, so there are a variety of different implementations and variants. Raft is an easier-to-understand consistency algorithm proposed by Stanford, which is intended to replace the currently widely used Paxos algorithm. Currently, there are some open source implementations in various mainstream languages, such as the JGroups-based raft protocol implemented in this article. On the principle of raft, we strongly recommend the animated version of Raft explanation (punch!) View the video).

Raft was originally a consensus algorithm for managing replication logs, a protocol established for real-world applications, focusing on the floor and the understanding of the Protocol. Raft is a strong agreement to reach a consensus on non-Byzantine failures.

In the blockchain system, the process of using raft to realize the accounting consensus can be described as follows: first elect a leader, then give leader full power management bookkeeping. Leader receives accounting requests from clients, completes accounting operations, generates chunks, and replicates to other billing nodes. With the leader simplifies the management of bookkeeping operations. For example, leader can decide whether to accept new transaction entries without regard to other billing nodes, leader may fail or lose contact with other nodes, and the system will elect a new leader.

In raft, each node is in one of the following three states:

• Follower: All nodes start with the follower state. If you do not receive the leader message, it becomes candidate state.
• Candidate: It will "pull the ballot" to the other nodes, and if the majority of the votes become leader. This process is called the Leader election (Leader election)
• Leader: All modifications to the system will be leader first. Each modification will write a log entry. Leader the process of receiving a modification request is as follows, and this process is called log copy Replication:
  
  • Copy logs to all follower nodes (replicate entry)
  • Most node response subset commit log
  • Notifies all follower node logs that they have been submitted.
  • All follower also submit logs
  • Now the whole system is in a consistent state.

Raft stage mainly divides into two, first is the leader election process, then carries on the normal operation on the election Leader Foundation, for example the log copy, the bookkeeping and so on.

1.Leader election

When follower does not receive the leader heartbeat message within the election timeout period, it is converted to the candidate state. To avoid an electoral conflict, this time-out is a random number between 150~300ms.

Generally, in raft systems:

1) Any server can be a candidate for candidate, which sends requests to other servers follower to elect themselves.

2) Other servers agree, issue OK. Note that if, in this process, there is a follower outage, there is no request for an election, the candidate can choose himself, as long as the majority of n/2+1 votes, the candidate can still become leader.

3) This candidate becomes the leader leader, who can issue instructions to the electorate, follower, such as bookkeeping.

4) later through the heartbeat of the notification of accounting.

5) Once the leader collapses, one of the follower becomes a candidate and an invitation to vote is made.

6) Follower agreed, it became leader, continue to bear bookkeeping and other guidance work.

2.Log Replication

Raft's bookkeeping process is done in the following steps:

1) Assuming that the leader leader has been elected, the client sends a request to add a log;

2) leader requires follower to follow his instructions and append this new log content to their respective logs;

3) Most follower server writes transaction records to the ledger, confirms the successful addition, and sends out the confirmation success message;

4) in the next heartbeat, leader will notify all follower to update the confirmed item.

Repeat the process for each new transaction.

In this process, if a network communication failure occurs, so that leader cannot access most follower, then leader can only update the follower servers it can access normally. Most of the servers follower because there is no leader, they will re-elect a candidate as leader, and then this leader as a representative to deal with the outside world, if it is required to add new transaction records, This new leader will notify most follower as described above. When the network communication is restored, the original leader becomes the follower, in the phase of the mismatch, any update of this old leader can not be counted as confirmation, must roll back, receive new leader new update.

Four. Pow:proof of work, working proof.

From the point of view of the central ledger system, each node that joins the system must keep a complete ledger, but each node cannot be accounted for at the same time, because the nodes are in different environments, receive different information, if the accounting at the same time, will inevitably lead to inconsistencies in the ledger, causing confusion. Therefore, there is a need for consensus to reach which node has the right to account. The Bitcoin blockchain solves the problem of the consistency of the centralized bookkeeping system by competitive bookkeeping, that is, the mechanism of competing the right of account with the computing ability of each node, namely "Calculating force".

In the bitcoin system, approximately every 10 minutes, a race of counted forces, the winner of the contest, was given the right to account for one time, and the new ledger information was added to the other nodes. However, in a centralized system, who has the right to determine the outcome of competition? The bitcoin system is done through a mechanism called "proof of Work" (Proof of Work,pow).

To put it simply, the POW is a testament to the amount of work done on the work side. The main characteristic of POW system is the asymmetry of computation. The work side needs to do some difficult work to arrive at a result, the verification side is easy to pass the result to check whether the work side does the corresponding work.

For example, given the string "blockchain", the workload requirement is that you can concatenate an integer value string called a nonce at the back of the string, SHA256 hash the concatenated string, If the resulting hash result (in the form of 16 binary) is preceded by a number of 0, the validation passes. To achieve the goal of this workload, we need to continually increment the nonce value and SHA256 hash the resulting new string. According to this rule, 2,688 calculations are required to find the first 3 bits of the hash value of 0, and to find the first 6 bits are 0 of the hash value, you need to do 620,969 calculations.

 1  blockchain1→ 4bfb943cba9fb9926df93f33c17d64b378d56714e8a29c6ba8bdc9690cea8e27  2  Span style= "COLOR: #000000" >blockchain2→01181212a283e760929f6b1628d903127c65e6fb5a9ad7fe94b790e699269221 ... 3  blockchain515→ 0074448bea8027bebd6333d3aa12fd11641e051911c5bab661a9b849b83958a7 ...  4  blockchain2688→ 0009b257eb8cf9eba179ab2be74d446fa1c59f0adfa8814260f52ae0016dd50f ...  5  blockchain48851: 00000b3d96b4db1a976d3a69829aabef8bafa35ab5871e084211a16d3a4f385c ...  6  blockchain6200969: 000000db7fa334aef754b51792cff6c880cd286c5f490d5cf73f658d9576d424 

We have a preliminary understanding of the POW mechanism through the above example, which calculates the results of a particular SHA256 operation. For a string that consists of a random nonce value for a given character, it is necessary to find such a nonce value to satisfy the SHA256 value of 0 for the first n bits, and to calculate the hash value more than once. In general, the larger the N value, the greater the amount of hash computation that needs to be done. Due to the pseudo-random nature of the hash value, to find the 4 leading 0 hash value, it is expected to make 216 attempts, this mathematical expectation of the number of calculations is the required "workload."

Any node in the Bitcoin network, if you want to generate a new chunk and write to the blockchain, you must solve the POW problem of the Bitcoin network. The key 3 elements of this problem are workload proof functions, blocks, and difficulty values. The work proof function is the calculation method of the problem, the block determines the input data of the problem, and the difficulty value determines the amount of calculation needed for the problem.

  1. Workload proof function and block data calculation process

The proof-of-work function used in the bitcoin system is SHA256(bash!) View the issue).

The bitcoin block structure looks like this:

A chunk of Bitcoin consists of the block size and the list of transactions included in the block. The size of the chunk header is 80 bytes, consisting of a 4-byte version number, a hash value of 32 bytes of the previous chunk, a 32-byte Merkle Genhachy value, a 4-byte timestamp (current time), a 4-byte current difficulty value, and a 4-byte random number. The list of transactions included in the Block is appended to the block, the first of which is the Coinbase transaction, a special transaction for the miners to receive bonuses and fees.

A chunk header with a fixed length of 80 bytes is the input string used for the Bitcoin workload proof. Therefore, in order for the chunk header to reflect all the transactions contained in the block, during the construction of the block, the list of transactions to be included in the chunk needs to be generated by the Merkle tree algorithm (bash) to generate the Merkle Genhachy value, and as a hash of the trade list is stored in the chunk size. The algorithm diagram of the Merkle tree is shown.

Shows a calculation of the root hash value of a merkle tree with 4 transactions. First, we construct a complete binary tree with these 4 trades as leaf nodes, and then convert the binary tree into a merkle tree by calculating the hash value.

First, for the 4 transactions: TXA~TXC, calculate the respective hash value HA~HC, and then calculate the hash value of the two intermediate nodes Hab=hash (HA+HB) and Hcd=hash (HC+HD), and finally calculate the root node hash Habcd=hash (hab+ HCD).

The structure of the simplified blockchain is shown. We find that: All transaction information that needs to be recorded in a given timeframe is constructed into a merkle tree, which contains a hash pointer to the Merkle tree, relates the transaction data associated with that chunk, and the chunk contains a hash pointer to the previous chunk. A single block that records different transactions is linked together to form a blockchain.

  2. Mining difficulty

The difficulty value is an important reference for a node in a bitcoin system to generate chunks, which determines how many hashes a node needs to pass before it can produce a valid chunk. Bitcoin chunks are generated approximately every 10 minutes, and if the new blocks are to be maintained at the same rate under different full-network conditions, the difficulty value must be adjusted according to the change of the whole net-count force. To put it simply, the difficulty value is set to the new block generation rate at every 10 minutes regardless of the node's computing power.

The difficulty adjustment is automatically occurring independently of each complete node. Every 2016 blocks, all nodes will automatically adjust the difficulty according to the uniform formula, this formula is from the latest 2016 chunks spent time and expected length (expected time is 20,160 minutes, that is, two weeks, is calculated at the rate of a chunk per 10 minutes of the total time) comparison of the results, Adjust (or become difficult or easy) according to the ratio of the actual time to the desired length. That is, if the block is produced at a rate that is faster than 10 minutes, it becomes more difficult and less difficult than a 10-minute slow.

This formula can be summed up as: New difficulty value = old Difficulty value x (last 2016 blocks spent time/20,160 minutes)

Proof of workload requires a target value. Calculation formula for target value (target) for Bitcoin workload proof: goal value = Maximum target value/difficulty value

Where the maximum target value is a constant value: 0x00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff

The size of the target value is inversely proportional to the difficulty value. The achievement of the Bitcoin workload proves that the miners calculate the chunk hash value must be less than the target value.

  3.PoW process 

The process of the Bitcoin POW can be simply understood as the input of a different nonce value, an attempt to perform a SHA256 hash, and the process of finding a hash value that satisfies a given number of leading 0. The more the number of leading 0 required, the greater the difficulty. The steps of the Bitcoin node to solve the problem of proof of work are summarized as follows:

1) generate a coin transaction and make a list of transactions with all other transactions prepared to be packaged into chunks, generating merkle Genhachy through the Merkle tree algorithm;

2) The Merkle Genhachy and other related fields are assembled into a chunk header, and the 80 byte data of the chunk header is input to the work proof;

3) Keep changing the random number in the head of the chunk, that is, the value of the nonce, and make a double SHA256 operation (i.e. SHA256 (SHA256 (Block_header)) for each changed chunk head, and compare the result value with the target value of the current network, if it is less than the target value, the problem solving is successful. , the work certificate is completed.

Bitcoin's workload proves that it is commonly known as "mining" to do the main work.

  4.PoW can solve the Byzantine general problem

About the Bitcoin POW consensus mechanism the question of whether the Byzantine generals can be solved has been controversial in the industry. In 2015, Juan Garay a formal analysis of Bitcoin's POW consensus algorithm, and concluded that the POW consensus algorithm of bitcoin was a probabilistic Byzantine protocol (probabilistic BA). Garay Two important attributes of the Bitcoin consensus agreement are as follows.

1) Consistency (agreement)

In the case of a dishonest node with a force of less than 50%, the probability of an honest node having the same chunk is high at the same time that there is very little chance of generating each round of synchronization blocks. In the strict language of mathematics said should be: when any two honest node of the local chain intercept K nodes, two of the rest of the chain of the head block of the same probability with the increase of k exponentially decreases exponentially.

2) correctness (validity)

Most chunks must be provided by an honest node. Strictly speaking, when dishonesty is very small, you can make most blocks available to the Honest node.

As a result, it can be seen that when dishonesty is less than 50% of the power of the network, at the same time the mining difficulty is higher, in about 10 minutes out of a block, the concept of the Bitcoin network to achieve consistency will increase exponentially with the number of confirmed chunks. But when dishonesty is a certain scale, not even close to 50%, the bitcoin consensus algorithm does not guarantee correctness, that is, there is no guarantee that most blocks are provided by an honest node.

Therefore, we can see that the bitcoin consensus algorithm is not suitable for private chain and alliance chain. The reason is that it is a final consistency consensus algorithm, not a strong consensus algorithm. The second reason is the low efficiency of their consensus. Providing consensus efficiency also compromises the security of consensus agreements. In addition, Bitcoin improves the security of the network through a clever miner reward mechanism. Miners mining for Bitcoin rewards and the transaction costs of bookkeeping make it more desirable for miners to maintain the proper functioning of the network, and any dishonest behavior that undermines the network will undermine the miners ' own interests. Therefore, even if some bitcoin pools have a strong calculation force, they have no motive to do evil, and instead have the power to maintain the normal operation of bitcoins, as this is related to their practical interests.

There are obvious drawbacks to the POW mechanism. On the one hand, the premise of the POW is that the node and the calculation force is evenly distributed, because through the CPU's computing power to vote, the number of wallets (nodes) and the value of the calculation should be roughly matched, but as people will be the CPU mining gradually upgrade to the GPU, FPGA, until the ASIC mining machine, The number of nodes and the value of the calculated force are also gradually mismatch. On the other hand, the POW is too wasteful. The Bitcoin network can perform trillions SHA256 computations per second, but these calculations do not have much practical or scientific value in addition to making it easy for a malicious attacker to disguise as millions of nodes and defeat the Bitcoin network. Of course, rather than allowing anyone in the world to instantly get through the central and semi-anonymous global currency network, there is little cost to other people to transfer money with little or no fee.

In view of this, a proof of entitlement (Proof of Stake,pos) has been presented.

Five. Pos:proof of Stake, proof of equity.

POS is similar to the property stored in the bank, this mode will be based on the amount and time you hold the digital currency, the corresponding interest is allocated to you.
To put it simply, it is a system based on the amount and time you hold the currency, to give you the interest of an institution, in the equity certificate POS mode, there is a noun called currency age, each coin generated 1 currency per day, such as you hold 100 coins, a total of 30 days, then, at this time your currency age is 3000, If you find a POS block, your currency age will be emptied to 0. Every 365 coins you are emptied, you will receive 0.05 interest from the block (assuming interest is understood as the annual interest rate of 5%), then in this case, interest = 3000 * 5%/365 = 0.41 coins, it is interesting that the holder has interest.

Point Coin (peercoin) is the first to use the money of the proof of interest, the point of currency in the SHA256 of the difficulty of the hash of the introduction of the concept of currency age, making the difficulty and transaction input currency age inversely proportional. In the point currency, the age of currency is defined as the product of the number of coins and the number of days that the currency has, which allows the age to reflect the amount of money the user has at the time of the transaction. In fact, the point-of-interest proof mechanism combines the concept of randomization with the age of coins, where a currency that is not used for at least 30 days can compete in the next chunk, and the longer and larger the currency set is more likely to sign the next chunk.

However, once the currency's equity is used to sign a chunk, the age of the currency is cleared to zero, which must wait at least 30th to sign another chunk. At the same time, to prevent very old or very large benefits from controlling the blockchain, the maximum probability of finding the next chunk reaches its maximum after 90 days, which protects the network and gradually generates new coins over time without consuming a lot of computational power. Point-of-sale developers claim that this will make malicious attacks difficult because there is no centralized digging pool requirement and the overhead of buying more than half of the coins seems to exceed the hashing power of obtaining 51% of the proof of work.

The proof of entitlement must be defined in some way to define the next legal block in any blockchain, depending on the balance of the account, the choice will lead to centrality, such as a single richest member may have a long-term advantage. For this reason, people have also devised different ways to choose the next legal block.

Although the POS mechanism takes into account the lack of POW, but according to the balance of interests to choose, will lead to the richest account of the power more powerful, it is possible to control the right to accounting. The emergence of the mechanism of proof of share authorization (delegated Proof of Stake,dpos) is based on solving such deficiencies as the POW mechanism and POS mechanism.

Six. dpos:delegated Proof of Stake, Certificate of appointment rights

Bit shares (BitShare) are a type of cipher currency that uses the dpos mechanism, and it expects to reduce the negative effects of centrality by introducing a technology-based democracy layer.

The dpos mechanism of the bit shares, the Chinese name is to do share authorization certification mechanism (also known as trustee Mechanism), its principle is to let each hold a bit shares vote, resulting in 101 representatives, we can interpret it as 101 super nodes or pools, and these 101 super nodes each other's rights are exactly equal. From a certain point of view, Dpos is a bit like the parliamentary system or the NPC. If the representative is unable to perform their duties (when it is their turn to not generate chunks), they will be removed and the network will elect a new super node to replace them. The appearance of Dpos is mainly due to the production of mining machine, a lot of calculation in the people do not know or care about Bitcoin, similar to the yellow cattle, a large number of hoarding tickets and do not care about the content of the concert.

The bit shares introduced the concept of witness, witnesses can generate blocks, each holder of a bit shares can vote to elect witnesses. The first n of the total number of votes (n is usually defined as 101) the candidate can be elected as a witness, and the number of witnesses to be elected (n) needs to be met: at least half of the voters believe N is fully centralized.

Candidate list of witnesses updated each maintenance cycle (1 days). Witnesses then randomly arranged, each witness in order to have 2 seconds of permission time to generate chunks, if the witness in a given time slice can not generate chunks, block generation permission to the next time slice corresponding witnesses. This design of Dpos makes the generation of blocks faster and more energy efficient.

Dpos took full advantage of the vote of the shareholders and reached a consensus in a fair and democratic way, and the N witnesses they voted for could be treated as n pools, and the rights of the N pools are equal. Shareholders may at any time vote to replace these witnesses (pools) as long as they provide an unstable computing power, a computer outage, or an attempt to exploit the power of the hand to do evil.

The unit has also designed another type of campaign, representing the campaign. The elected representative has the privilege of proposing changes to the network parameters, including transaction costs, block size, witness fees, and block ranges. If most delegates agree to the proposed change, the shareholder has a two-week review period, during which the representative can be dismissed and the proposed change abolished. This design ensures that the right to technically not modify parameters directly and that all network parameters are changed ultimately requires the consent of the stockholder.

Seven. Ripple consensus algorithm.

Ripple (Ripple) is an open source payment protocol based on Internet, which can realize the function of currency exchange, payment and liquidation. In the Ripple network, the transaction is initiated by the client (application), and the transaction is broadcast to the entire network via the tracking node (tracking node) or the authentication node (validating nodes). The primary function of the tracking node is to distribute transaction information and respond to client ledger requests. The validation node can add new ledger instance data to the ledger, in addition to all the features of the tracking node, through the consensus protocol.

Ripple consensus is reached between the authentication nodes, each authentication node is preconfigured with a list of trusted nodes, called UNL (Unique node list). The nodes on the list can vote on the transaction. Every few seconds, the Ripple network will perform the following consensus process:

1) Each verification node will continue to receive transactions sent from the network, through with the local ledger data verification, illegal transactions directly discarded, legitimate transactions will be aggregated into the trading candidate set (candidate set). The trading candidate set also includes transactions that were left behind by the previous consensus process.

2) Each authentication node sends its own set of trading candidates as a proposal to other authentication nodes.

3) Verify that the node receives the proposal from the other node and ignores the proposal if it is not from a node on the UNL, and if it is from a node on the UNL, it will compare the proposed transaction with the local trading candidate set, and if there is the same transaction, the transaction will receive one vote. Within a certain period of time, when the transaction gets more than 50% votes, the transaction goes to the next round. No more than 50% of the transactions will be confirmed by the next consensus process.

4) Verify that the node sends more than 50% votes to the other nodes, while increasing the threshold of the required number of votes to 60%, repeat step 3, step 4) until the threshold reaches 80%.

5) The Verification node formally writes the transactions confirmed by the 80%UNL node to the local ledger data, called the Last Closed ledger, which is the last (most recent) state of the ledger.

Ripple Consensus process node interaction

Ripple consensus algorithm flow

In the ripple consensus algorithm, the identity of the participating voting nodes is known beforehand, therefore, the efficiency of the algorithm than the POW and other anonymous consensus algorithm to be efficient, the transaction confirmation time only a few seconds. This, of course, also determines that the consensus algorithm is only suitable for scenarios where the permission chain (permissioned chain) is used. The Byzantine Fault tolerance (BFT) capability of the Ripple Consensus algorithm is (n-1)/5, which can tolerate Byzantine errors in 20% nodes throughout the network without affecting the correct consensus.

The above main is the current mainstream consensus algorithm. But what kind of consensus mechanism is better or more alternative? I think dpos to replace Pow,pos or pow+pos is not likely, after all, the existence is reasonable. Each of these algorithms has its own meaning, both technically and in business, in a specific time period and scenario. If we jump out of the technical perspective, more political and economic ways of thinking are in it, there may be more consensus mechanisms.

For the selection of the algorithm, a sentence is summarized as follows:

" in the blockchain network, because of the different application scenarios, the different design goals, various blockchain systems adopt different consensus algorithms." Generally speaking, in the case of the private chain and the alliance chain, there is a strong requirement for consistency and correctness. In general, strong consensus algorithms are used. In the case of the public chain, the consistency and correctness are usually not able to achieve 100%, usually using the final consistency (eventual consistency) consensus algorithm. "

The popular point is: the choice of consensus algorithm is highly correlated with the application scenario, the trusted environment uses Paxos or raft, the Licensed alliance can use the PBFT, the non-license chain can be pow,pos,ripple consensus, etc., according to the Counterparty Trust degree classification, free Choice consensus mechanism.

"Haste, if there is a mistake, please correct me!"   If you write well, thank you for recommending! | |  Welcome to leave your comments! We discuss and learn the blockchain together! "

REFERENCE

1. Diego Ongaro and John ousterhout Stanford University in Search of an understandable Consensus algorithm (Extended Version)
2. Blockchain technology Guide Shang, Zhang Haining, Tang Yu, Li Lei
3. Raft Protocol 48832405/

1.4 [Blockchain] consensus algorithm contention (pbft,raft,pow,pos,dpos,ripple)