A brief introduction to the blockchain consensus mechanism

The consensus mechanism is the core of the distributed system, in which the mutual distrust node finally achieves the consistency of the data through the presupposition mechanism called the consensus. The consensus mechanism is the approach to be adopted in order to achieve this consensus.
Objective of the consensus mechanism: consistency: All honest nodes are saved with the same chunk-chain prefixes. Validity: Messages posted by an honest node will eventually be recorded in their blockchain by all other honest nodes.

How to evaluate the pros and cons of a consensus mechanism: security: Can effectively prevent two payments, mining expansion privately: When the system members and the number of transactions to be confirmed increases, the resulting system load and network traffic changes, usually measured by network throughput Performance efficiency: The amount of transactions that can be processed per second resource consumption: in the process of reaching consensus, the CPU, memory and other computing resources to be consumed

Now the main consensus mechanism has proof of workload, proof of Rights, Byzantine agreement three. Because the purpose of this article is to summarize the consensus mechanism, we do not pay attention to the specific algorithms of each mechanism. Proof of workload

Workload proof mechanism, that is, the node through the "workload" to exchange for trust. Each node must complete a specified amount of work before it is presented with a pending chunk of a stage; not only that, if a node receives multiple pending chunks, which block is longer, it validates which chunk, because a longer chain means more work in the chain .
People may have a problem, why do we have to believe in a lot of work? Or is it because of one of the characteristics of this mechanism: pseudo-randomness. The probability that a node will take precedence over the proof of work depends only on the proportion of computing resources (CPU, memory, etc.) that it occupies that are the sum of the computing resources of all nodes worldwide. To ensure the relative fairness (popularly speaking, is to spell the number of people, the good many. Take the real world for example, if you want to sabotage, you have to buy/conquer more than half the world's population, or you'll have more money than anyone else in the world.
Insufficient: serious efficiency problems too much strong compute node joint, may lead to security problems (current computational resources tend to be centralized, contrary to the original block chain) resource consumption of large rights and benefits proof

Because of the excessive resource consumption and the waste of resources, people pay more and more attention to the mechanism of proof of rights.
Assuming a high degree of network synchronization , the system runs in wheels. At the beginning of each round, the node verifies that it can be selected as a delegate through an equity certificate, and only the representative can propose a new chunk. Represents a new pending block after the longest valid blockchain has been received, and broadcasts a new blockchain generated by itself, waiting for confirmation. At the beginning of the next round, the representative is re-selected to confirm the results of the previous round. An honest representative will continue to work behind the longest effective blockchain. This loops together to maintain the blockchain.
Insufficient: If the network synchronization is poor, then the system is likely to form a fork, breach of consistency. Handle all Byzantine conformance protocols on behalf of the node

The main purpose of this mechanism is to resolve how to make all the correct nodes agree on an input value in a network with faulty nodes. This mechanism has less resource consumption, high efficiency and strong consistency (not easy to fork).
Taking the practical Byzantine fault-tolerant protocol as an example, the protocol requires that the number of failed nodes in a distributed system with 3F+1 nodes not exceed F. Each round of the practical Byzantine fault-tolerant protocol consists of 3 phases: the pre-preparation phase, the preparation phase and the confirmation phase. In the pre-preparation phase, the master node publishes pre-prepared messages containing the records to be validated. After receiving the pre-prepared message, each node enters the preparation phase. During the preparation phase, the master node sends a prepare message to all nodes containing the records to be validated, each node verifies its correctness, saves the correct record, and sends it to the other nodes. Until a node receives the correct record that is sent by a 2f 冋 node that is consistent with the records received during the pre-preparation phase, the node broadcasts a confirmation message to the other node, and the system enters the confirmation phase. During the confirmation phase, until each honest node receives a 2f+1 acknowledgment message, the protocol terminates and the nodes agree on the record.
Insufficient: poor security (fault tolerance is only 1/3, the other two are 1/2) poor scalability (the efficiency of the Protocol depends on the number of nodes, not applicable to the large number of nodes in the blockchain system) to the master node has a dependency on three consensus mechanisms of comparison

resource consumption td> Low

consensus mechanism	conformance	Security (tolerance rate)	extensibility	efficiency
Proof of work	there are forks	<50%	Poor	High Latency	High
proof of entitlement	has fork	<50%	good	Low latency
Byzantine consistency Agreement	no difference	<33%	Poor	Low latency	Low