A Simple Framework for Block Chain Consensus Analysis


In previous sessions, we compared and analyzed the advantages and disadvantages of PoW and POS, and how our CKB improved the POW protocol of Bitcoin. This is the last phase of the consensus section. Let’s take a comprehensive look at the block chain consensus and how to dissect the block chain consensus with a simple analytical framework.

Secret Ape Science and Technology Block Chain Lesson 30

A Simple Framework for Block Chain Consensus Analysis

[1] Delay is the time required for the transaction to be confirmed by consensus. Low: < 10s, medium: 10s-600s, high: > = 600s
[2] The number of consensual nodes allowed while maintaining the performance of consensus. Low: < 100, medium: > = 100, high: no limit
[3] Bitcoin’s Nakamoto Consensus has very low communication overhead, but the bandwidth utilization is low due to the setting of consensus parameters (10-minute block interval, ~4MB block capacity).
[4] EOS propaganda refers to BFT, but I communicated with some friends that it is still NC, that is to say, EOS DPOS and BitShares DPOS should be the same.

Framework thinking

Consensus algorithm is a big topic. Before the emergence of block chains, there had been a lot of research and precipitation of consensus algorithms in the field of distributed systems and databases. However, the consensus of block chains is quite different from previous studies, and it is easy to fall into the old routine of traditional consensus if we do not pay attention to it. In fact, it’s not just the block chain that has its own unique needs. My feeling is that there are many differences between consensus research in database meetings and consensus research in distributed systems. In fact, this is very understandable, because the scenes are different, the design is naturally different.

This paper attempts to propose a simple framework for analyzing block chain consensus, which is convenient for comparing different block chain consensus.

Basic Requirements

The basic measure of consensus includes two aspects: correctness and performance. Correctness simply includes:

  • Consistency – Nodes eventually see the same local state
  • Liveness – Requests / transactions are always processed within a limited time

Correctness is the most basic requirement, which can be achieved by most block chain consensus. It is a very difficult task to always ensure consistency and activity in asynchronous networks. Consensus design usually chooses to guarantee one point and abandons another point in some specific cases, such as the Nakamoto Consensus used by Bitcoin, which chooses priority to guarantee activity, while the BFT Consensus gives priority to ensure consistency.

Performance includes:

  • Throughput – Number of requests that the system can process per unit time
  • Latency – The time required for a request/transaction to be initiated, processed, or fully determined

There are many factors affecting throughput and latency, such as the number of consensus nodes, message complexity of consensus, time required for message validation, bandwidth available for consensus, trend of consensus design, and so on. Generally speaking, throughput and latency are difficult to achieve, because the message complexity of consensus has a lower limit: for each round of consensus, the node participating in consensus receives at least one message (otherwise it doesn’t even know what to agree on). If the delay is to be low, it is necessary to reach agreement on each request/transaction as soon as possible, which means that a single request/transaction requires higher message complexity; if high throughput is to be achieved, it is necessary to batch the request/transaction as much as possible to reduce the message complexity of a single request/transaction, but it will also cause high latency.

For consensus performance, Zhang Ren of Nervos research team proposed a more referential indicator of the utilization rate of consensus to bandwidth: given the same bandwidth, the lower the occupation of consensus to bandwidth, the higher the throughput of consensus.

A Simple Framework for Block Chain Consensus Analysis

Characteristics of Block Chain Consensus

Dynamic set of participants

Whether it’s permissionless or permissioned blockchain, the most important feature is that it’s a long-running open system. As a result of long-term operation and open overlapping, the participants of consensus will always change. At intervals, there will always be old consensus nodes leaving and new consensus nodes joining. Consensus participants are a dynamic set. How to deal with the dynamic changes of consensus participants is a core issue of block chain consensus.

Unlike block chain consensus, traditional consensus research often assumes a fixed set of participants, and then studies how to reach consensus within the set. It occasionally discusses how to deal with changes in the set of participants, and basically does not care what qualifications are needed to participate in consensus. The focus of the research is how to ensure the correctness of consensus (e.g. consistency and activity). The way to form consensus set is only a subsidiary subject. Traditional consensus application scenarios are often centralized control of the network, adding or reducing servers are their own, forming such emphasis is also natural.

Numerous participants

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

Minimum trust model

The purpose of implementing consensus algorithm is to generate consistent results for a computing request. In this process, there must be nodes that initiate requests and nodes that process requests. In the traditional consensus model, some of the consensus algorithms are executed entirely within the request processing node set, others are executed by the request initiating node and the processing node together. In any case, the trust boundary is generally between the request initiating node and the request executing node, and the initiating node sends the computation request to the executing node. Row node, the execution node calculates the results and returns them to the initiator node. The initiator node trusts the results of the execution node (conversely, the execution node does not necessarily trust the message of the initiator node if the initiator node participates in the consensus process).

A Simple Framework for Block Chain Consensus Analysis
The trust model of block chain consensus is quite different, and the requirement of trust is often much smaller. In permissionless blockchain networks, the same node initiates transactions and participates in consensus. The nodes need to verify the consensus results, not simply trust the consensus results of other nodes. Taking Bitcoin as an example, if a whole node participates in mining, it is both a node that initiates (trades) requests and a node that processes (trades). 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 do not trust the results provided by other consensus nodes. Such a full node only chooses the order of transactions following the choice of most arithmetic, and does not believe the trading results given by most arithmetic. This is a minimal trust model.

SPV/light node uses a stronger trust model than the whole node (stronger means more assumptions about trust). It does not verify the execution of transactions, but only the validity of block heads. How to verify the validity of block chains is another core issue in the consensus design of block chains. If the validity is verified only by asymmetric signature attached to the block head, the trust model is basically equivalent to the traditional consensus trust model, because the request processing nodes in the traditional consensus can also add signatures to the results. This model will encounter a series of problems when combining the dynamic participant set. For example, long-range attacks are well known. If the validity of blocks is verified by PoW, there is no such trouble. The main research direction is how to further improve the validation efficiency of blocks.

A Simple Analysis Framework

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

  • Entry mode * – Purchasing power / Mortgage token /…
  • Block mode * – alternate block / PoW random selection / pseudo random on the chain / VRF random selection /…
  • Consensus * – Nakamoto Consensus / BFT /…
  • Exit mode * – Stop mining / Unmortgage /…
  • Consistency – How many malicious nodes / arithmetic / Stake /…
  • Activation – How many malicious nodes / power / Stake /… can be tolerated?
  • Delay – The time required for a transaction to be fully confirmed (the probability of being overturned is less than x)
  • Bandwidth Efficiency – Consensus on Bandwidth Utilization, the Higher the Better
  • Number of nodes – The upper limit of the number of consensus nodes is high or low

Examples are given to illustrate:

A Simple Framework for Block Chain Consensus Analysis

[1] 99% certainty
[2] Consider selfish mining
[3] No matter how small the normal arithmetic is, there is an opportunity to block, but the average delay will increase.
[4] https://github.com/tendermint… 6
[5] https://medium.com/nervosnetw… 6

For a block chain consensus protocol, the first four points (with *) basically determine the characteristics of the latter. Through this framework, it is easy to see that what we usually call “PoW consensus” or “PoS consensus” is a very vague description. PoW/PoS is only the way to select the block nodes, and can not express the concrete consensus process. We can even design some very mixed consensus protocols, such as a protocol that needs to be participated in by mortgage tokens, selected block nodes by PoW, formed the longest (heaviest) chain by Nakamoto Consensus (which can be named Staking PoW, perfect combination of Staking hot spots), or designed a need. Participation through PoW (POW must be provided to meet certain difficulties in order to participate in consensus), selection of block nodes through VRF, and consensus agreement through BFT (this can be called PoW + VRF / BFT, let people see from the bottom of the heart to rise professional feeling).

Incentive Analysis

On top of the above framework, we can also superimpose a dimension that is not found in traditional consensus: consensus incentives. Block chains introduce economic incentives into consensus. Through mechanism design, Nash equilibrium and system objectives are integrated to guide participants to abide by the agreement. The utility function of consensus participants can be easily measured by their economic benefits (i.e., the reward obtained minus the cost of participating in consensus). Consensus rewards are often realized by the original tokens in the system. The reward value is determined by the token value. In a properly designed consensus agreement, the participants should receive the corresponding reward according to the amount of effort they pay. The composition of consensus cost is relatively complex. Corresponding to the above framework, we need to analyze the entry cost, block cost, consensus cost and exit cost of consensus, which together constitute the cost of node participation in consensus. Correct consensus incentive has an impact on network security and de-centralization, so incentive analysis is an important part of consensus analysis.