first level title

Blockchain Consensus Comparison
[1] Delay is the time required for a transaction to be confirmed by consensus. Low: <10s, Medium: 10s-600s, High: >=600s
[2] The number of consensus nodes allowed while maintaining consensus performance. Low: <100, Medium: >=100, High: No limit
[4] The promotion of EOS refers to BFT, but after communicating with some friends, it is learned that NC is still used, which means that the DPoS of EOS and the DPoS of BitShares should be the same.

first level title

Framework ideas

This paper attempts to propose a simple framework for analyzing blockchain consensus, so that different blockchain consensus can be compared together.

first level title

basic requirements

• The basic metrics of consensus include two aspects, correctness and performance. Correctness simply includes:

• Liveness - requests/transactions will always be processed within a finite time

textasynchronous networkmiddlemiddleAlways ensuring consistency and liveness is a very difficult task

, so the consensus design usually chooses to guarantee one point and give up another point in some specific cases. For example, the Nakamoto consensus used by Bitcoin chooses to give priority to ensuring liveness, while the BFT consensus gives priority to ensuring consistency.

• Features include:Throughput

• - The number of requests that the system can handle per unit timeLatency- A request/transaction from initiation to completion/totally sure

time required

There are many factors that affect throughput and latency, such as the number of consensus nodes, the complexity of consensus messages, the time required for message verification, the bandwidth available for consensus, the tendency of consensus design, and so on. Generally speaking, it is difficult to have both throughput and latency, because the consensus message complexity has a lower limit: for each round of consensus, the nodes participating in the consensus must receive the message at least once (otherwise, what is the consensus on? Do not know at all). If you want low latency, you need to agree on each request/transaction as soon as possible, which means that a single request/transaction requires higher message complexity; if you want high throughput, you need to batch process requests/transactions as much as possible. This reduces the message complexity of a single request/transaction, but also causes high latency.For consensus performance, a more informative index proposed by Zhang Ren of the Nervos research team is: Given the same bandwidth, the lower the bandwidth occupied by the consensus, the higher the throughput of the consensus.

first level title

Features of Blockchain Consensus

dynamic set of participantsWhether it is permissionless (translated into "no permission required" is too convoluted,Using "public chain" is not very accurate

, still use words here) or permissioned blockchain, the most important feature is that it is a long-running open system. The result of long-term operation and open superposition is that the participants in the consensus will always change. Every once in a while, there will always be old consensus nodes leaving and new consensus nodes joining. The consensus participants are a dynamic set. How to deal with the dynamic changes of consensus participants is a core issue of blockchain consensus.

Different from blockchain consensus, traditional consensus research often assumes a fixed set of participants first, and then studies how to reach a consensus within this set, and occasionally discusses how to deal with changes in the set of participants, and basically does not care about what is required to participate in the consensus Qualifications. The focus of the research is how to ensure the correctness of the consensus (eg consistency and liveness), and the way to form a consensus set is only a subsidiary topic. The application scenario of the traditional consensus is often a centralized control network, and the increased or decreased servers are all their own, so it is natural to form such a focus.

large number of participants

Decentralization is a unique goal of permissionless blockchain consensus protocols. We usually measure the degree of decentralization by the threshold of participation in consensus (why is this a good measure?), the lower the threshold of participation, the higher the degree of decentralization. The natural result of the low participation threshold is that the set of consensus participants can be very large, so the design of the consensus protocol must take this into account to ensure that the consensus efficiency will not decrease due to the increase of participants.

minimal trust model

The purpose of executing the consensus algorithm is to produce a consistent calculation result for a calculation request. In this process, there must be a node that initiates the request and a node that processes the request. In the traditional consensus model, some consensus algorithms are executed entirely within the set of request processing nodes, and some consensus algorithms are executed by the request initiation node and processing nodes together. In any case, the trust boundary is generally between the request initiation node and the request execution node. , the initiating node sends the calculation request to the execution node, and the execution node calculates the result and returns it to the initiating node, and the initiating node trusts the calculation result of the execution node (conversely, the execution node does not necessarily trust process).

The trust model of blockchain consensus is quite different, and the requirements for trust are often much smaller. In a permissionless blockchain network, the same node initiates a transaction and participates in consensus. Nodes need to verify the consensus results, rather than simply trusting the consensus results of other nodes. Taking Bitcoin as an example, if a full node participates in mining, it is simultaneously a node that initiates a request (transaction) and a node that processes a request (transaction). Even if it only wants to be a quiet full node and does not participate in mining, it will verify the received request processing results (blocks) by itself, and does not trust the results provided by other consensus nodes. Such a full node just chooses to follow the order of transactions selected by the majority computing power, and does not believe in the transaction results given by the majority computing power. This is a minimal trust model.

SPV/light nodes use a stronger trust model than full nodes (stronger means more assumptions about trust), and do not verify the execution of transactions, only verify the validity of block headers. How to verify the validity of the block header is another core issue in blockchain consensus design. If the validity is only verified by the asymmetric signature attached to the block header, this trust model is basically equivalent to the trust model of the traditional consensus, because the request processing node in the traditional consensus can also add a signature to the result. This model is in A series of problems arise when combining a dynamic set of actors, such as the well-known long-range attack. If the validity of the block header is verified through PoW, there will be no such troubles. The mainstream research direction is how to further improve the verification efficiency of the block header.

A simple analytical framework

• Based on the above analysis, we can sort out a simple blockchain consensus analysis framework for comparing various blockchain consensus:

• How to enter* - Buy computing power / Mortgage tokens / …

• Block generation method* - Block generation in turn/PoW random selection/on-chain pseudo-random/VRF random selection/…

• Consensus Method* - Nakamoto Consensus / BFT /…

• Exit method* - stop mining / unstake / ...

• Consistency - How many malicious nodes/computing power/Stake/… can be tolerated

• Liveness - How many malicious nodes/computing power/Stake/… can be tolerated

• Latency - the time it takes for a transaction to be fully confirmed (probability of being overturned is less than x)

• Number of Nodes - Whether the upper limit for the number of consensus nodes is high or low

for example:

[1] for example:
99% certainty[2] Consider
[3] selfish miningNo matter how small the normal computing power is, there is a chance to produce a block
[4] https://github.com/tendermint...
[5] https://medium.com/nervosnetw...

For a blockchain consensus protocol, the first four points (with *) basically determine the following characteristics. It is also easy to see through this framework that what we usually call "PoW consensus" or "PoS consensus" is a very vague description. PoW/PoS is only a way to select block producers, and cannot express what the specific consensus process looks like. We can even design some very mixed consensus protocols, such as designing a protocol that needs to participate by staking tokens, select block nodes through PoW, and form the longest (heavy) chain through Nakamoto Consensus (you can name it StakingPoW , perfectly combined with Staking hotspots), or design a protocol that needs to participate through PoW (PoW that meets a certain degree of difficulty must be provided to participate in the consensus), select block nodes through VRF, and reach consensus through BFT (this can be called PoW +VRF/BFT, it makes people feel professional from the bottom of their hearts at first sight).

first level title

incentive analysis

On top of the above framework, we can also superimpose a dimension not found in traditional consensus: consensus incentives. The blockchain introduces economic incentives in the consensus, integrates the Nash equilibrium with the system goals through mechanism design, and guides the participants to abide by the agreement. cost of participating in consensus). Consensus rewards are often realized through native tokens in the system, and the reward value is determined by the value of the tokens. In a properly designed consensus protocol, participants should get corresponding rewards according to how much they paid. The composition of the consensus cost is relatively complicated. Corresponding to the above framework, we need to analyze the consensus entry cost, block generation cost, consensus cost, and exit cost. These costs together constitute the cost of nodes participating in the consensus. The correct consensus incentives have an impact on the security and decentralization of the network, so incentive analysis is an important part of consensus analysis.

More…Jan、Do you think this analytical framework makes sense? Feedback is welcome! Thanks for this article、Wan Cen CenGao Yimin

co-authored analysis of .Nervos TalkIf you are interested, try to use this framework to analyze and sort out some blockchain consensus protocols (eg Casper/Ethereum 2.0, EOS, Cardano, Algorand, etc.) and reply to