[Blockchain] Summary of Common Consensus Mechanisms

public chain

PoW - Proof of Work

Brief description: The nodes in the system compete to generate blocks, and whoever first calculates the block that meets the requirements will get the block reward.
Disadvantages: consumption of electricity and computing power.
Advantages: full participation of all staff, completely decentralized
mining. Source of remuneration: ( 1) Newborn Bitcoin (2) Transaction Fee
Typical Scenario: Bitcoin

PoS - Proof of Stake

Brief description: Select a bookkeeping node, which has a large shareholding, and has a high probability of being selected.
Disadvantages:
(1) Concentrated shareholding, shareholders with small shares, no sense of participation;
(2) The richest man will always hold the bookkeeping right ;
(3) Can't handle the fork problem well;
(4) "Nothing at stake" - (Nothing at stake) mining on every fork chain, no loss anyway! Induce-indiscriminate attack
Advantages: save computing power, do not need to do useless work
The final reward of the selected bookkeeper of POS is calculated according to the age of the currency he owns; the principle of the longest chain of POS is the longest chain accumulated by the age of the currency .

Typical scenario: PP-coin (PP-coin)

PP-coin introduction: In order to prevent the accumulation of coin age, limit the use time. Coins that have not been used for at least 30 days can participate in the competition for the next block. Once the rights and interests of the currency are used to sign the next block, the currency age will be cleared, and then wait at least 30 days before signing the next block; at the same time, in order to prevent the accumulation of currency age, the maximum probability of finding the next block is reached after 90 days maximum value. Purchasing 51% and above coins seems to cost more than getting 51% of the computing power.
PoS

DPoS - Delegate Proof of Stake

Everyone voted for 101 candidate bookkeepers, and then took turns to keep accounts.

Advantages: All shareholders have participated, and the participation rate is relatively high.
Disadvantages:
(1) There are still N candidates who may always be candidates;
(2) Rely on tokens (Token)

DPoS
Bitshare (also known as BitShares) introduces the concept of "witness" . Witnesses can generate blocks, and everyone who holds BitShares can vote for "witnesses". The top N (N is usually defined as 101) candidates who get the total number of votes can be elected as witnesses, and the number of elected witnesses (N) satisfies: At least half of the participating voters believe that N has been fully decentralized

The candidate list of "witnesses" is updated every - maintenance period (1 day) - and the witnesses are then randomly arranged. Each witness has 2 seconds of authorization time to generate blocks in sequence. If the witness is in a given time The block cannot be generated, and the block generation authority is given to the witness corresponding to the next time segment. DPOS makes full use of the votes of shareholders to reach a consensus in a fair and democratic manner. The N witnesses they voted for can be regarded as N mining pools. The power of the N mining pools is completely equal this time. Shareholders can change "witnesses" at any time.

Bitshare also devised another kind of election: Elected representatives have the privilege of proposing changes to network parameters, including transaction fees, block size, witness fees, and block intervals. If a majority of the representatives agree to the proposed changes, the shareholders have a two-week review period during which the representatives can be removed and the proposed changes annulled. This design ensures that technical representatives do not have the power to directly modify parameters and that all changes to network parameters ultimately require the consent of stakeholders.

PoA - Proof of Activity - Proof of Action

Source: Evolved from PoW and PoS

Among them, addr: is the receiving address of the reward (remuneration), and the final reward is divided between the node that obtains the bookkeeping right and the node that writes the transaction into the block body.
PoA

PoB - Proof of Burn

PoB-proof of burn-
used in Silmcoin, borrowing from PoS, burning Silmcoin held by miners (miners send Silmcoin to a specific and irretrievable address), the more they send, the right to bookkeeping more likely

alliance chain

Paxos

The basic idea of the Paxos algorithm is similar to the two-phase commit:

Multiple proposers must first strive for the right to propose (with the support of most decision makers);
Successful proposers send proposals to everyone for confirmation, and proposals that are confirmed by most people become approved proposals.

The Paxos protocol has three roles

Proposer
Acceptor (decision maker)
Learner (decision learner)

The first stage: Prepare

Proposer generates a globally unique proposal (Proposal) number $N$ to all Acceptors $N$ 's Prepare request;
If the Acceptor receives a number $N$ 's Prepare request, and $N$ is greater than the numbers of all Prepare requests that this Acceptor has responded to, then this Acceptor will feed back the proposal number with the largest number it has accepted as a response to the Proposer, and this Acceptor promises not to accept proposals smaller than N.

The second stage: Accept

If the Proposer receives more than half of the Acceptors, the number issued by it is $In response to N$ 's Prepare request, the Proposer will send a response to $[N, V]$ The Accept request of the proposal is given to more than half of the Acceptors. $V$ is the value of the proposal with the highest number in the received response, if the response does not contain any proposal, then $V$ is determined by the Proposer himself.
2. If the Acceptor receives a target number $The Accept request of N$ 's proposal, as long as the Acceptor does not have a pair number greater than $N$ 's Prepare request has responded, and the Acceptor accepts the proposal.

Paxos does not guarantee that the system is always in a consistent state. However, since more than half of the nodes participate in reaching a consensus each time, the entire system will eventually know the consensus result. If the proposer fails during the proposal process, it can be mitigated by a timeout mechanism.
Paxos can guarantee that when more than half of the nodes are working normally, the system can always reach a consensus with a high probability.

Proposal ID Generation Algorithm

Assume that there is $n$ Proposers, each numbered as $I_r(0<I_r<n)$ , any value of Proposer number $s$ should be greater than its known maximum value, and satisfy $s/n=I_r , s = m*n + I_r$
The maximum value known by Proposal comes from two parts: Proposer's own value after number increment and the value obtained after receiving Acceptor's rejection: For example: 3
Proposers $P_1,P_2, P_3$ , initial $m = 0$ , the numbers are 0,1,2
(1) $P_1$ Found $P_2 when submitting$ Submitted, $P_2$ The number 1 of P1>the number 0 of P1, so $P_1$ Recalculation number: new $P_1 = 1*3 +1 = 4$ ;
(2) $P_3$ Submitted with number 2, found 4 smaller than P1, so P3 is renumbered: new $P_3= 1*3+2=5$

Multi-Paxos

Advantages: Simplify the second phase of Paxos and turn it into a first phase
Disadvantages: There is a problem of lease renewal, when the time is up, the lease must be renewed;

Brief description of Multi-Paxos: Paxos is to agree on a value, and Multi-Paxos is to reach agreement on multiple values through consecutive Paxos instances. There is a Leader in the Multi-Paxos protocol. The Leader is the only Proposer in the system. During the lease period, all proposals have the same Proposal-Id, and the prepare phase can be skipped. The proposal only has the accept process. One Proposal-Id can correspond to multiple Values, so it is called Multi-Paxos . The Multi-Paxos protocol is a simplified version of the classic Paxos protocol, which simplifies the original 2-Phase process to 1-Phase, thus speeding up the submission speed. Multi-Paxos requires that each Proposer has a unique Leader, and the Leader uniquely submits the value to each Acceptor for voting. When there is only one Leader in the system to submit the value, the Prepare process can be skipped, and Leader election can be done by Paxos Lease. PaxosLease: In the Paxos algorithm, if a leader can be elected, it will help improve the success rate of voting. In addition, the leader plays an important role in the election of multiple resolutions (used to obtain the continuous id of the resolution). Therefore, how to get a leader through a certain method is what PaxosLease explains. The process of leader election is as follows: choose one of many Nodes as the leader. If the leader is always alive, no election is required. If the leader is down, other nodes will elect the next leader. The guarantee of correctness of selection is: there can be at most one leader at any time. Logically, the Leader is more like an invisible lock. Any node that gets this lock can become a leader. Therefore, in essence, Leader election is a problem of distributed locks, but it is also risky to solve the election problem entirely by locks: if A Node gets the lock and then crashes, which will cause the lock to fail to be released, that is, deadlock. A feasible solution is to add a time (Lease) to the lock. The Leader who has obtained the lock can only access the locked resource within the validity period of the Lease. After the Lease timeout, other Nodes can continue to compete for the lock, which fundamentally avoids deadlocks. . After the leader gets the lock, if it is always alive, it can "renew" the lock to other nodes, so as to avoid frequent election activities.

PBFT

Advantages: higher efficiency than POW, less computing power consumption
Disadvantages:

The dynamic addition/deletion of nodes cannot be realized
There is no penalty mechanism for malicious masternodes
High requirements for network bandwidth, the more nodes, the higher the bandwidth requirements – improve throughput
Applies only to peer-to-peer nodes

Improvements that currently exist:

In the Beiyou paper: PBFT+DPoS -> first select a batch of candidates, and perform PBFT among the candidates. Advantage: Reduced network bandwidth
Electronic Technology_Zhang Liangsong: DWA-BFT (I really feel good) -> Add weights to consensus nodes, which will be updated every time. If the weights are large, the credibility will be high, and then the lazy nodes or Byzantine nodes will be continuously reduced by the system- yes Countermeasures for malicious nodes - can be used for reference
Shandong University_Che Zhengwei: EB-BFT –> select the number of consensus nodes according to the accumulated transaction quantity and the physical state of the nodes, and at the same time assign different consensus blocks to the consensus nodes in different physical states (involving neural networks) Network, Feedback!)

DDBFT

Byzantine fault-tolerant algorithm for dynamic authorization: ------3:2

advantage:

The consensus speed is improved, because not all nodes participate in the consensus, only 3/5 nodes participate in the consensus

shortcoming:

The fault tolerance rate is reduced to 20%
The workload of the nodes is unbalanced, and the non-consensus nodes have no workload
Message complexity is not reduced when switching views

Consensus flow chart:
DDBFT

IDBFT

Byzantine Fault Tolerance Algorithm for Active Dynamic Authorization - Specific Reference Papers

advantage:

It has better performance when all nodes in the system are trusted
Consensus is fast. (Because not all nodes participate in the consensus process)

shortcoming

System fault tolerance is reduced (because not all nodes participate in the consensus)
No reduction in communication complexity when switching between views

The consensus process is divided into two cases

All nodes in the system are trusted - adopt a simplified consensus process (the first picture)
There are Byzantine nodes in the system (second picture)

Hotstuff

advantage:

From the traditional two-stage consensus to the three-stage consensus, the message complexity during view switching will be polynomial level
Communication complexity between nodes is reduced, reducing communication overhead

shortcoming:

Digital signature algorithm - ECDSA for aggregate signature and threshold signature is more complex and can be optimized

Application Scenario: Libra (Facebook)

The normal consensus process is shown in the figure:

insert image description here
The two-stage consensus becomes a three-stage consensus, which reduces the complexity of view switching that may occur in the two-stage consensus, and O(N³) reduction is called O(N);

Some questions about the three-phase consensus:

Three-stage consensus result: message complexity during view switching is reduced to polynomial level

About view switching:

Why view switching occurs: the main node of the system is a Byzantine node or a large-scale network failure occurs in the system.
The result of view switching:

Mainly solved: the problem of message complexity when the view is replaced – whether the previous block B has reached a consensus
(two-stage consensus) node rotation mechanism: when node rotation is required, let all nodes broadcast all the messages they have received, and then new The publisher of the block then broadcasts the received message. The message complexity of O(N^3) is caused.
When the node reaches the time out, it requests the rotation of the block node, which is equivalent to saying: "I think the block node may be malicious, so I request the node rotation". Then, when the new block producer receives 2f+1 requests, it broadcasts the new block and broadcasts the 2f+1 requests, announcing that he has indeed received these requests.
Analysis:
(1) A two-stage consensus can be reached, which can only ensure that the view has not been replaced!
(2) There are no 2f+1 nodes in the "ready state", and no nodes will confirm block B
(3) [one-stage consensus]: the node receives 2f+1 "received block B" , directly confirm block B;
(4) (two-stage consensus): Make sure that the block producing node has not been replaced!

The algorithm framework (multiple derivative algorithms can be born) adopts a tree/chain structure, which is very similar to a blockchain. In addition, similar to the traditional blockchain, a node currently has a chain that is regarded as the "main chain", and votes will only be cast for new parts that are currently considered to be extended on the main chain. As with blockchains, if a sidechain is "good" enough, it becomes the new mainchain. In the blockchain, this is determined by the length of the chain (the elder wins), while in HotStuff it is determined by the most recent block that successfully obtained the majority of votes.

Situation: Honest node a successfully passed the preparatory stage, and received 2f+1 confirmation messages of block B (the second round), at this time he believes that there will be no other honest node confirming a different block B', So he confirms B. However, a large-scale network anomaly occurred at this time, causing other honest nodes to fail to receive 2f+1 confirmation messages about block B before the timeout, so most nodes have not yet confirmed B. Send a request to rotate block producers. Then, the new node produces block B' at the height of B, causing inconsistency!

Because in fact, two rounds of consensus have provided the basis for solving this problem - PBFT has made the following changes to solve the contradiction between consistency and liveness: when all nodes broadcast the application for "
replacement of the block producer", they need to broadcast at the same time Its own state, and at the same time give the evidence that it is in this state (for example, if it is in the ready state, submit 2f+1 pieces of preparation information from different nodes). Then, the new block producing node decides whether to replace B according to the state in the received 2f+1 messages:
(1) If no node is in the ready state, then at least f+1 honest nodes have not yet prepared , so there will not be 2f+1 confirmation messages, so there will not be any honest node that has confirmed block B. Therefore, at this time, the new block producing node will place its new block B' at the same height as B, replacing B. Then, at the same time as broadcasting block B', broadcast all rotation applications received - explaining the situation to everyone.
(2) If there is a node in the standby state, it means that at least f+1 honest nodes have received B and are ready to enter the standby state. At this time, we can confirm that it is impossible for some honest nodes to confirm a chain that is inconsistent with B because they are not synchronized (for example, they are always in timeout). Then, the new block producer connects the new block B' after B, and broadcasts all the rotation applications received. At this time, since the rotation application of the node in the standby state includes 2f+1 preparation messages, all nodes that receive the new block B' also receive 2f+1 preparation messages at the same time, so they can enter the standby state. In other words, it doesn't matter who the new block node is, whether it is malicious, or whether the network deactivation causes block B' to fail to reach consensus. As long as the publishers of the new block fast adopt this method, we can ensure that there will be no inconsistencies with the blocks that have reached consensus while ensuring liveness.

(5) (Two-stage consensus): First, when nodes rotate, each node needs to broadcast a rotation request, here is the message complexity of O(N²), and then, the rotation request also needs to include the previously received All the preparatory messages to illustrate the current state, so here is O( $N^3$ ) Message complexity. Not only that, when the next block producing node receives these messages, he needs to include these messages and broadcast them when publishing the block, so there is a message complexity of O(N^3).

（三阶段共识）：诚实出块者广播区块 B，诚实节点收到后发送关于 B 的“预备消息”，然后，当节点收到 2f+1 条预备消息之后，节点进入预备状态并广播“预确认消息”；然后，当节点收到 2f+1 条预确认消息时，节点进入预确认状态并广播“确认消息”；最后，当节点收到 2f+1 条确认消息的时候，确认区块 B
（三阶段共识）节点轮换机制：当节点达到 timeout 还没有达成共识的时候，节点广播自己的状态并申请更换出块者。然后，下一个出块者收集这些状态来决定新区块的高度：如果没有 2f+1 个节点在预备状态，则换掉 B，如果有 2f+1 个节点在预备（或更高）状态，则把新区块出在 B 之后。
分析：
（1）不存在2f+1个节点在“预备状态”，不会有任何一个节点对区块B进行了确认；
（2）有2f+1个（或大于）节点处于“预备状态”及更高状态（预确认状态），不可能有一个诚实节点对区块B＇进行了确认，不可能有一个诚实节点确认了一条不包括 B 的链，所以这个时候新的区块出在 B 之后。

(The difference between the second phase and the third phase) can be understood as follows: for an honest node, when he reaches two rounds of consensus on block B, he can confirm that there is no consensus on another conflicting block B'. So in the two-stage consensus, if the node rotation is carried out during the two-stage consensus process, we cannot judge only by the current state of the node: (we can only judge that the block has been consensus, but which block is unknown!!! ) (both in the commit stage, how to judge which block is committed)
1. Whether there are nodes that have confirmed B;
2. Whether there are nodes that have reached consensus on another block B'.
Therefore, (two-stage consensus) requires all nodes to broadcast all the messages they have received during node rotation, and then the new block publisher will broadcast the received messages.
However, if a three-phase consensus is adopted, then we can judge only by the current state of the node:

zyzzyva

Leader is an honest node: implement "one-stage consensus"!
Leader dishonest node: first determine that the leader is malicious, and then implement the "two-stage consensus" of PBFT.
If the leader is credible, just do a round of ordinary broadcast with O(N) message complexity. Then, if everyone finds that there is a problem with the leader, they will return to PBFT. So: "When the leader is honest and the network is in good condition, consensus is faster; however, in bad conditions, consensus is slower than PBFT because it needs to wait for the 'assumption-based' algorithm to finish before entering topic"

PoET

Cons: Hardware limitations – Intel

Advantages: Improve consensus efficiency (because there are fewer nodes participating in the consensus); reduce network bandwidth
Disadvantages: When the number of nodes is too large, the impact of the VBF function on the overall efficiency needs to be considered

Proposed in 2018:
Ontology Blockchain (ONT)
|-Basic content: Before the standard three-stage, use a verifiable random function (VRF) to select nodes participating in the consensus in each round

Casper

The essence is: PoW generates blocks, PoS is used as the choice of participating consensus nodes, and BFT is used to judge the validity of the voting of consensus nodes

The improved version of PoS,
insert image description here
Casper, actually has two versions:
the difference is that FFG is more of a transition protocol, enabling Ethereum to successfully transition from PoW to PoS; and CBC is a better version after Ethereum switches to PoS. 1.
Casper FFG:
The main idea of FFG is to use PoS to help the final confirmation of blocks generated by PoW, thereby improving the security of the system while reducing miner rewards; participants become
Validators by mortgaging a certain amount of stake, Validator It is responsible for running the PoS protocol. For the convenience of description, it is assumed that the Validator remains unchanged during the protocol. The PoW Ethereum will generate a tree. If the Validator votes for each block, it will increase the network propagation overhead. In order to reduce the number of votes in Casper, 100 blocks are compressed into a checkpoint, as shown in Figure 1:
insert image description here
After compressing the block, we get Figure 2, and provide a height function for each checkpoint: the number of hops from the block to the root node r:

insert image description here
First, we describe Casper's consensus process as a whole. Validators participating in the consensus will vote on the checkpoints mentioned above. Each Validator casts a checkpoint, starting from the justified checkpoint to a checkpoint after several checkpoints. We stipulate that the first justified checkpoint is the genesis block. When a checkpoint receives more than 2/3 of the votes from the justified checkpoint to it, the block becomes justified.
For example, in Figure 2, if there are more than 2/3 of the votes from the genesis block r, then it becomes justified; when there are more than 2/3 of the votes from to, then it is justified, and so on. When a justified checkpoint receives more than 2/3 votes from it to one of its child checkpoints, then this checkpoint and all checkpoints before it have been confirmed.
Validator voting
After compressing the blocks generated by PoW into checkpoints, the Validator votes on the tree with voting rules such as "vote=<v,s,t,h(s),h(t)>" (where
:
v : the identity information of the Validator;
s: the hash of any justified checkpoint, which can be understood as the source checkpoint. The definition of justified will be explained in detail later; t
: the hash of any descendant node of s;
h(s): the height of s ;
h(t): height of t;)
Two relations of checkpoint
After defining the voting rules, define the relationship between any two checkpoints:
supermajority link: For a pair of checkpoints (a, b), write (a→b), if there are more than 2/3 validator votes, it can be called ( a→b) is a supermajority link, and h(b)≥h(a)+1;
conflicting: If two checkpoints are on different branches, it is called conflicting.
Figure 4: Schematic diagram of Casper structure
Figure 3: checkpoint status
As shown in Figure 3, where (r→)→)(→) is the supermajority link, and is conflicting.
Two states of checkpoint
After defining the relationship between checkpoints, define two states of checkpoint-c:
1. c is justified:
a) c = root: checkpoint c is the root;
b) or exists (c'→c), that is, c ' to the supermajority link of c, and c' is justified; (Figure 4: r, all four checkpoints are justified)

2. c is finalized:
a) c is justified;
b) exists (c→c'), the supermajority link from c' to c; c , c' not conflicting; h(c')=h©+1;

In Figure 3, r is justified and finalized.
If a checkpoint state is finalized, then it and all blocks before it will be confirmed.

Punishment Mechanism
In order to prevent Validator from doing evil during operation, Casper has developed a set of penalty mechanism as follows: For the same Validator, two different votes <v,h(),h()> and <v,h( ), h()>, if the following two situations exist, the stake of the mortgage will be penalized.
1. h()= h(): For the same target height, two different votes cannot be initiated.
2. h()<h()<h()<h().
In the case of legal transactions, how does justified and finalized ensure the security of checkpoint? When a checkpoint: c becomes justified, it means that more than 2/3 of the Validators support all checkpoints before c. With the first penalty condition, more than 2/3 of the Validators in h© only support checkpoint c. For finalized checkpoint: f, it will have a supermajority link starting from f and connecting to f's child nodes. In conjunction with the second penalty condition, when a checkpoint f becomes finalized, it means that more than 2/3 of the Validators in the entire network cannot issue votes beyond f, and these 2/3 of the Validators can only vote for checkpoints after f. As shown in Figure 4: For any Validator, vote2 cannot be voted after vote1 is cast, so the checkpoint before f will not be changed, because any vote for the checkpoint before f cannot get more than 2/3 of the votes .

Figure 5: The checkpoint before finalized will be confirmed
Fork selection mechanism:
In order to allow PoS to improve the security of the PoW chain, FFG made some modifications to the heaviest chain when selecting a fork: first find the justified checkpoint with the highest height in the view, and The heaviest chain is selected on the block after the checkpoint. This has two advantages. The first one is that compared with the original GHOST algorithm, block confirmation is probabilistic. After waiting for a sufficient height, there is only a very low probability of overturning the previous block, although the probability Very low, but there is still this possibility; as long as the blocks in FFG are before finalized, they are all confirmed, and there is no possibility of being overturned. The second point is that the security of a confirmed block requires miners to continuously provide their own workload to the block, so in order to motivate miners, more mining rewards are needed; in FFG, as long as the finalized block is It is confirmed, and there is no need for subsequent miners to use the workload to increase the security of the confirmed block, so it can reduce the mining reward and reduce the inflation rate.
Replacement of Validator
As we said at the beginning, it is assumed that the Validator is fixed, but a real blockchain system must allow participants to freely enter and exit, so FFG has its own set of Validator entry and exit principles. First, define the dynasty of block b as: the number of finalized checkpoints between the founding block and the parent block of b.
Mortgage:
A user who wants to become a Validator needs to mortgage a certain amount of stake. When the mortgage transaction of user v is included in a block with dynasty=d, then define a Start Dynasty and write SD(v) = d+2.
redemption:
If Validator v wants to get back the mortgaged stake, it needs to initiate a redemption transaction. When this transaction information is included in a block whose dynasty is d, then define an End Dynasty, written as ED(v) =d +2. In order to avoid dealing with multiple SDs and EDs, a user cannot stake to become a Validator after redemption. At the same time, in order to prevent the bad guys from redeeming the stake immediately after doing evil, the stake still needs to be locked for a certain period of time after the redemption transaction is executed. For a block b, assuming its dynasty is d, only Validators whose d is between ED and SD can vote (that is, nodes that join the network and have not exited can have voting rights).

Ourobros

To be perfected

PoSW

To be perfected

MG-DPoS

To be perfected

RPCA

To be perfected

Algorand

To be perfected

Tendermint

To be perfected

private chain

raft
to be improved