​
https://preview.redd.it/j27ayhbw0rh51.png?width=512&format=png&auto=webp&s=f15bd6ff4ac50fa0eb0bbad23d59f55da6d98090
In the Bingo game DApp demo, we’ve already talked about the aelf real random number generator, which can generate unpredictable random numbers between 0 and 255, making it a useful tool. The interaction logic of this DApp’s backend is very much the same as that of blockchain smart contract. But this DApp is so simple that it doesn’t really show what aelf is capable of. In fact, aelf’s got an awful lot more in its arsenal. When it comes to supporting enterprise-level applications, this is where aelf comes in. For someone who is new to aelf, the best way to aquaint yourself with aelf’s technology is to read the aelf technical whitepaper.
​
https://preview.redd.it/yxbt4j9x0rh51.png?width=512&format=png&auto=webp&s=35c371142e08d37c38776dc151c5877f0aa9ca93
If you have read the whitepaper of some blockchain projects, you might find them difficult to understand or even make no sense. As a result, readers (not speculators) are often at a loss as to what these projects are trying to do. Unfortunately, many projects often assume their readers are all experts and can understand the whitepapers with no difficulty. In reality, most blockchain projects are much more complex than Bitcoin. Therefore, if readers only know how Bitcoin works, they still cannot understand these projects’ whitepapers. If you want to draw potential developers to your platform, it is necessary to provide a beginner’s guide to understanding your whitepaper.
That’s why we have prepared this guide. But before reading this guide, you can quickly go through our website, read our slogan, watch the promo video on the homepage, download the whitepaper and before long, you may find something you cannot understand. Don’t worry, let’s start with aelf’s slogan:
Aelf, a Decentralized Cloud Computing Blockchain Network
Cloud computing is the most fundamental feature driving the entire aelf blockchain ecosystem. Running data intensive computation on multiple computers is obviously more cost-effective than on one mainframe computer. Suppose these computers are assembled in a huge building called data center, say thousands of computers, with professional maintenance by a company, say, Amazon, then these data centers are called a cloud, such as Amazon Web Services (AWS).
Having said that, it is still hard for a beginner to understand why cloud computing gives aelf an indispensable edge. This is because most people, including some in the blockchain sector, don’t have a sound knowledge of some of blockchain’s key concepts. As a result, it is difficult for them to move on to the more complex technology, let alone analyze the pros and cons of a blockchain project and its potentials. As far as I know, I think it is necessary to set the record straight on two important blockchain concepts.

What is a blockchain?

This is nonsense! We all know blockchain is a tamper-proof distributed ledger or database technology, as any professional would explain to you. You most probably have memorized this definition by heart and would rattle it off whenever someone asks you what blockchain is. The truth is, this definition is very misleading. Blockchain is not a new invention, nor does it have any magical features (for example: the magical tamper-proof feature). In this sense, it is different from the magical stuff in an alchemist’s furnace. Instead of viewing blockchain as a ledger or database, it is better to see it as a distributed system. So what is a distributed system?
A distributed system is a large number of interconnected computers, which makes it a peer-to-peer system. It was invented around 1960, long before the advent of Internet. There are already a lot of well-known distributed-system-based softwares, such as Bit-torrent and Netflix. In these softwares, people can upload the files on their computers to the P2P network and anyone can download them. But a distributed system can do much more. In the distributed system discipline, people have to solve a big problem, that is, everyone (every node) in the P2P network need to make an unanimous decision no matter what information they receive, and this unanimous decision is what we call a consensus, and this problem is called the Byzantine General Problem.

Say there are three Byzantine generals wanting to attack the same fortress, and they are at three different locations, they could only rely on couriers to send messages. In this situation, any general can only make a decision based on the other two generals’ messages. If one general wants to attack, he let couriers send the “attack” message to the other two generals, so do the other two generals. If the generals are all loyal, each of them should receive “attack, attack” coming from other two generals, and all three generals would attack the fortress. But if one of them is a traitor, he could send one general “attack” and send the other “retreat”, this other general will receive “attack, retreat”, if he follows majority rule, he will not make a decision because the votes on attack and retreat are the same. At the same time, the other general will attack, and the result is that these three generals will not reach a consensus on attack.

The generals are just like the nodes of a distributed system (i.e. blockchain). There are at least two points worth noting: first, all massages (transactions), have to be sent to the other generals (nodes) to keep them informed; second, all the nodes have to reach a consensus.
​
https://preview.redd.it/nlgharoy0rh51.png?width=512&format=png&auto=webp&s=56c022e327526f13d1f3e13efe80de0483550715
The first point means that it takes time for sending a message to all the nodes in a huge network, the second means that after a new block has been broadcast to the entire network, there should be a mechanism for all the nodes to agree on this block (a package of messages or logs), and it also takes time.

​
https://preview.redd.it/45wwtygv2rc51.png?width=567&format=png&auto=webp&s=a5f51ea3c620d478231c39e32f198eb64d801897
Foreword
The consensus mechanism is one of the important elements of the blockchain and the core rule of the normal operation of the distributed ledger. It is mainly used to solve the trust problem between people and determine who is responsible for generating new blocks and maintaining the effective unification of the system in the blockchain system. Thus, it has become an everlasting research hot topic in blockchain.
This article starts with the concept and role of the consensus mechanism. First, it enables the reader to have a preliminary understanding of the consensus mechanism as a whole; then starting with the two armies and the Byzantine general problem, the evolution of the consensus mechanism is introduced in the order of the time when the consensus mechanism is proposed; Then, it briefly introduces the current mainstream consensus mechanism from three aspects of concept, working principle and representative project, and compares the advantages and disadvantages of the mainstream consensus mechanism; finally, it gives suggestions on how to choose a consensus mechanism for blockchain projects and pointed out the possibility of the future development of the consensus mechanism.
Contents
First, concept and function of the consensus mechanism
1.1 Concept: The core rules for the normal operation of distributed ledgers
1.2 Role: Solve the trust problem and decide the generation and maintenance of new blocks
1.2.1 Used to solve the trust problem between people
1.2.2 Used to decide who is responsible for generating new blocks and maintaining effective unity in the blockchain system
1.3 Mainstream model of consensus algorithm
Second, the origin of the consensus mechanism
2.1 The two armies and the Byzantine generals
2.1.1 The two armies problem
2.1.2 The Byzantine generals problem
2.2 Development history of consensus mechanism
2.2.1 Classification of consensus mechanism
2.2.2 Development frontier of consensus mechanism
Third, Common Consensus System
Fourth, Selection of consensus mechanism and summary of current situation
4.1 How to choose a consensus mechanism that suits you
4.1.1 Determine whether the final result is important
4.1.2 Determine how fast the application process needs to be
4.1.2 Determining the degree to which the application requires for decentralization
4.1.3 Determine whether the system can be terminated
4.1.4 Select a suitable consensus algorithm after weighing the advantages and disadvantages
4.2 Future development of consensus mechanism
Last lecture review: Chapter 1 Concept and Function of Consensus Mechanism plus Chapter 2 Origin of Consensus Mechanism
Last lecture review: Chapter 3 Common Consensus Mechanisms
​
Chapter 3 Common Consensus Mechanisms (Part 2)
Figure 6 Summary of relatively mainstream consensus mechanisms
​
https://preview.redd.it/2yepvjjy2rc51.png?width=567&format=png&auto=webp&s=acaed31fa6106ac2f501fe2cb284f66bb2258a0e
Source: Hasib Anwar, "Consensus Algorithms: The Root Of The Blockchain Technology"
The picture above shows 14 relatively mainstream consensus mechanisms summarized by a geek Hasib Anwar, including PoW (Proof of Work), PoS (Proof of Stake), DPoS (Delegated Proof of Stake), LPoS (Lease Proof of Stake), PoET ( Proof of Elapsed Time), PBFT (Practical Byzantine Fault Tolerance), SBFT (Simple Byzantine Fault Tolerance), DBFT (Delegated Byzantine Fault Tolerance), DAG (Directed Acyclic Graph), Proof-of-Activity (Proof of Activity), Proof-of- Importance (Proof of Importance), Proof-of-Capacity (Proof of Capacity), Proof-of-Burn ( Proof of Burn), Proof-of-Weight (Proof of Weight).
Next, we will mainly introduce and analyze the top ten consensus mechanisms of the current blockchain.
》DBFT
-Concept:
Delegated Byzantine fault tolerance. The improved Byzantine fault-tolerant algorithm makes it suitable for blockchain systems. The system consists of nodes, delegators (who can approve blocks), and speakers (who proposes the next block). It is a consensus algorithm that guarantees fault tolerance implemented inside the NEO blockchain.
-Principle:
In this mechanism, there are two participants: the professional bookkeeper "bookkeeping node" and the ordinary users in the system.
Ordinary users vote based on the proportion of holding stake to determine the bookkeeping node. When a consensus is required, a spokesperson is randomly selected from these bookkeeping nodes to draw up a plan, and then other bookkeeping nodes will vote basing on the Byzantine fault tolerance algorithm.That is, majority principle. If more than 66% of the nodes agree to the spokesperson’ plan, a consensus is reached; otherwise, the spokesperson is re-elected and the voting process is repeated.
-Representative application: Neo, etc.
》PoA
-Concept:
Proof of authority. That is, certified by some accredited accounts, these accredited accounts are called "validators". The software that the verifier runs that supports the verifier to place transactions in blocks.
-Principle:
Three conditions:

1. The identity must be formally verified on the chain, and the information can be cross-verified in a publicly available domain;
   
2. The qualifications must be difficult to obtain, so that the rights of the verification block obtained are precious enough;
   
3. The authoritative inspection and procedures must be completely unified.
   

With PoA, every individual has the right to become a verifier, so there is an incentive to maintain the position of the verifier once acquired. By attaching a reputation to the identity, the verifier can be encouraged to maintain the transaction process. Because the verifier does not want to gain a negative reputation, it will lose its hard-won verifier status.
-Representative applications: VeChain, etc.
》DAG
-Concept:
Directed acyclic graph. Each newly added unit in the DAG is not only added to the long chain block, but added to all the previous blocks, verifying each new unit and confirming its parent unit and the parent unit of the parent unit, and gradually confirming until the genesis unit. As the hash of its parent unit is included in its own unit, the blockchains of all transactions are connected to each other to form a graph-like structure with time.
-Principle:
In the DAG network, each node can be a trader and a validator, because the transaction processing in DAG is done by the transaction node itself. Taking IOTA as an example, IOTA’s Tangle led
ger does not need to pay transaction fees while ensuring high-speed transaction processing. However, it does not mean that the transaction is free, because in this ledger, the initiation of each transaction needs to verify the other two random transactions first, and connect the transaction initiated by itself to these two transactions, so the responsibility that miners on the blockchain bear is distributed to all traders. The DAG method of processing transactions can be called asynchronous processing mode.
Figure 10 The difference between the traditional blockchain structure and the DAG structure
​
https://preview.redd.it/1xfssxj03rc51.png?width=553&format=png&auto=webp&s=95c382f81943c9a188a89ac6b2dadf64446589e6
-Representative applications: IOTA, etc.
》PoET
-Concept:
Proof of elapsed time. That is, it is usually used in a permissioned blockchain network. It can determine the mining rights of the block holders in the network. The permissioned blockchain network requires any prospective participants to verify their identity before joining. According to the principles of the fair lottery system, each node is equally likely to become the winner.
-Principle:
Each participating node in the network must wait for a randomly selected period, and the first node to complete the set waiting time will get a new block. Each node in the blockchain network will generate a random waiting time and sleep for a set time. The node that wakes up first, that is, the node with the shortest waiting time, wakes up and submits a new block to the blockchain, and then broadcasts the necessary information to the entire peer-to-peer network. The same process will be repeated to find the next block.
Two factors:

1. Participating nodes will naturally select a random time in nature, rather than deliberately;
   
2. The winner did complete the waiting time.
   

-Representative application: HyperLedger Sawtooth, etc.
》PoSV
-Concept:
Proof of stake velocity. Proposed by Reddcoin, drawing on the concept of "money circulation speed" in economics, it mainly allocates bookkeeping rights based on the coin age of nodes participating in the competition.
-Principle:
PoSV also allocates accounting rights according to the coin age of the nodes participating in the competition, but modifies the coin age calculation formula to a function of exponential decay of growth rate. Taking Reddcoin as an example, Reddcoin sets the half-life of the coin age growth rate to 1 month. Assuming that the unit token can accumulate 1CoinDay coin age on the first day, only 0.5CoinDay coin age can be accumulated on the 31st day, and only 0.25CoinDay coin age can be accumulated on the 61st day, and so on. In this way, the nodes are encouraged to use the token to conduct a transaction after holding the token for a period of time, thereby restarting the calculation of the coin age and increasing the circulation speed of the token in the network.
-Representative applications: Reddcoin, etc.
Table 2 Comparison of the advantages and disadvantages of current mainstream consensus mechanisms
​
https://preview.redd.it/kb04i7eh3rc51.png?width=1236&format=png&auto=webp&s=42de13bc99afaf258c0a740a6618e2d579b59100
Source: network resources
Chapter 4 Summary of the Selection and Status Quo of Consensus Mechanism
4.1 How to choose a consensus mechanism that suits you
Step 1: Determine whether the final result is important
For some applications, the end result is very important. If you are building a new payment system that can support very small amounts, it is acceptable for the transaction result to change. Similarly, if you are creating a new distributed social network, 100% guarantee that the status is updated immediately is not particularly necessary. On the contrary, if you are creating a new distributed protocol, the final result is critical to the user experience. For example, Bitcoin has a final confirmation time of about 1 hour, Ethereum has a final confirmation time of about 6 minutes, and Tendermint Core only has a final confirmation time of 1 second.
Step 2: Determine how fast the application process needs to be
If you are building a game, is it reasonable to wait 15 seconds before each action? Due to the low block processing time of Ethereum, games built on it will cause poor user experience due to Ethereum's throughput. However, the application for the transfer of housing property rights can be run on Ethereum. Use the Cosmos SDK to build an application that allows developers to freely use Tendermint Core. It has a short block processing time and high throughput, and is capable of processing 10,000 transactions per second. You can reduce the required communication overhead and speed up the application by setting the maximum number of validators for the application.
Step 3: Determine the application's demand for decentralization
Some applications such as games may not require very high censorship resistance as a by-product of decentralization. In theory, does it really matter that the validator can create a cartel in the game and reverse the transaction result for profit? If it is not important, a blockchain such as EOS may be more suitable for your needs because of the fast transaction speed and free fees. However, some applications such as autonomous banks are more powerful and decentralized. Although Ethereum is considered to be decentralized, some supporters claim that Ethereum's mining pool is an important part of centralized platform, although there are actually only 11 validators (mining pools). One of the major benefits of building your own blockchain instead of building on a smart contract platform is that you can customize the way the application completes verification. However, it is difficult to build your own blockchain, so the Cosmos SDK is very useful, you can easily build your own blockchain and customize the degree of decentralization you need.
Step 4: Determine whether the system can be terminated
If you are building a new application similar to a distributed ride-sharing service, then ensuring 24/7 service must be the first priority, even if there are occasional errors in accounting similar to transactions. One of the properties of Tendermint Core is that if there is a disagreement between network validators, the network will suspend operations instead of proceeding erroneous transactions. Applications such as decentralized exchanges require correctness at all costs-if there is a problem, it is far better to suspend trading on the decentralized exchange than there may be trading problems.
Summary: Choose a suitable consensus algorithm after weighing the advantages and disadvantages
All in all, there is no single best consensus algorithm. Each consensus algorithm has its own value and advantages. You need to have your own judgments and choices. However, by understanding the relevant processes of the consensus mechanism, including proposals and agreements, and establishing a framework to consider the types of consensus algorithms that your application may require, you should be able to make wiser decisions.
4.2 Future development of consensus mechanism
The consensus algorithm is one of the core elements of the blockchain. Although there are more than 30 consensus mechanisms listed in the article, there are still many niche consensus mechanisms that may not be discussed. As the blockchain technology is gradually known and accepted by the public, more and more newer and better consensus algorithms may appear in the future, which may be brand-new consensus algorithms, and more should be improvement and optimization version based on the current consensus algorithm.
After 2016 and 2017 years’ fast development, the current consensus algorithm does not have a recognized evaluation standard, but is generally more biased towards fairness and decentralization, as well as some technical related issues, such as energy consumption and scalability , Fault tolerance and security, etc. However, blockchain technology must be combined with requirements and application scenarios, and the consensus mechanism algorithm and incentive mechanism are inseparable. How to customize a suitable consensus mechanism according to the characteristics of your own project and optimize the current consensus mechanism will become the future direction of consensus mechanism development
CelesOS
As the first DPOW financial blockchain operating system, CelesOS adopts consensus mechanism 3.0 to break through the "impossible triangle", which can provide high TPS while also allowing for decentralization. Committed to creating a financial blockchain operating system that embraces supervision, providing services for financial institutions and the development of applications on the supervision chain, and formulating a role and consensus ecological supervision layer agreement for supervision.
The CelesOS team is dedicated to building a bridge between blockchain and regulatory agencies/financial industry. We believe that only blockchain technology that cooperates with regulators will have a real future. We believe in and contribute to achieving this goal.
📷Website
https://www.celesos.com/
📷 Telegram
https://t.me/celeschain
📷 Twitter
https://twitter.com/CelesChain
📷 Reddit
https://www.reddit.com/useCelesOS
📷 Medium
https://medium.com/@celesos
📷 Facebook
https://www.facebook.com/CelesOS1
📷 Youtube
https://www.youtube.com/channel/UC1Xsd8wU957D-R8RQVZPfGA

Written by TokenInsight
Published by tokenin.cn

EXECUTIVE SUMMARY

Advantages

1. The team’s overall technical background is good, and the CTO and CEO of the project have rich experience in related industries;
   
2. The current business scope of CoinEx has been expanded, and the development of the public chain has a decisive role in promoting the development of the exchange business;
   
3. The project operation information is transparent, and the development process is consistent with the road map;
   
4. The unlocking schedule is clear, and the token held by the team will be unlocked continuously in the next five years;
   
5. The project uses POS consensus mechanism. At present, it has been launched on the main network, and the block time is stable, between 2–3 seconds.
   

Challenges

1. It is not clear enough yet whether the trichain operation planning can achieve the project’s development goals;
   
2. There is limited information on implementation details about cross-chain and other related technologies, and the development status needs to be assessed based on the later project development disclosure information;
   
3. The team currently hold a large share of the token, hence the distribution of tokens is relatively concentrated;
   
4. There are few application scenarios for project tokens, and more ecosystem scenarios need to be developed;
   
5. As a deflationary token, CET needs to be balanced by dealing with the contradiction between public chain users and token holders.
   

Outlook

The development of CoinEx Chain contributes to the future development of CoinEx’s centralized and decentralized exchanges; the concept of trichain operation simplifies the functions of each chain, improving their performance. At present, there are few exchanges working on the public chain, and no fierce competition has occurred.

Conclusion

Considering the status and development prospects of the project, TokenInsight gives CoinEx a rating of BB with a stable outlook.

1. Multidimensional evaluation

2. Project analysis

CoinEx (CoinEx Technology Limited) was established in December 2017 and is headquartered in Hong Kong, China. It is a sub-brand of the ViaBTC mining pool. At present, CoinEx’s business scope includes CoinEx exchange, CoinEx public chain, and CoinEx decentralized exchange. The current development focus of the CoinEx platform are public chain and exchange. The main purpose of the public chain is to build a decentralized exchange (DEX) infrastructure and an ecosystem around DEX.
​
CoinEx business structure，Source: CoinEx; TokenInsight

2.1 Introduction

“ CoinEx Chain uses the parallel operation of three chains which are DEX, Smart, and Privacy, as well as cross-chain technologies to create a rich decentralized exchange ecosystem and blockchain financial infrastructure.
The core of CoinEx’s early business was the exchange, consisted of two major categories which were spot and derivatives trading. Currently, there are 123 trading currencies online, covering 302 trading pairs. On June 28, 2019, CoinEx released the CoinEx Chain public chain white paper, aiming to build a decentralized trading system (CoinEx DEX) with community-based operations and transparent transaction rules, and providing user-controlled asset trading scenario by the highest technical standards in the industry; CoinEx Chain has become another development focus of CoinEx. CoinEx Token (CET), which was originally a native token of the CoinEx exchange, will also be developed mainly as a built-in token of the public chain.
CoinEx Chain is a public chain based on the Tendermint consensus protocol and Cosmos SDK, and it uses POS mechanism. CoinEx Chain plans to support 42 nodes when the project starts, and any entity in the ecosystem can participate in the validator’s campaign by staking CET. CoinEx Chain will use the new block reward and the transaction fee contained in the block as the reward for running the node.
CoinEx Chain has developed three public chains with different positioning and different functions in order to meet the needs of blockchain transactions for transaction performance, smart contracts, and privacy protection at the same time. They operate in parallel and collaborate with each other through cross-chain technology. At present, the block time of the public chain is between 2–3 seconds. According to the observation of TokenInsight, the block time is stable, but the number of transactions through the CoinEx public chain is still low at present, the number of transactions in 24 hours is about 30,000; The TPS on public chain disclosed by CoinEx can reach up to 1500 per second.
CoinEx Chain uses a trichain parallel model to build a more vibrant ecosystem around DEX. The three chains are DEX public chain, Smart public chain, and Privacy public chain, respectively responsible for decentralized transactions, smart contracts, and on-chain privacy protection.
CETs that need to participate in complex financial contracts can be transferred to the Smart public chain through the DEX public chain, then moved back to the DEX public chain after that. CET tokens that need to participate in token confusion can also be carried out through the privacy transaction of the Privacy public chain, and can eventually be returned to the DEX public chain. The three public chains are responsible for their respective duties, and they are interconnected through the cross-chain technology through the relay mechanism. In addition to ensuring their respective transaction processing speed and functional attributes, they can also jointly provide richer and safer functions, and synergistically constitute the CoinEx decentralized public chain ecosystem.
In addition, CoinEx Chain also supports any participant to issue new tokens on the chain and create new trading pairs for the issued tokens. CoinEx Chain guarantees the circulation of new tokens by establishing a trading pair between the new token and CET.

2.2 Component architecture

“ Tendermint Core and Cosmos SDK have improved the performance and operation capability of the blockchain. The SDK packaging reduces the consideration of non-related logic, hence reducing the development complexity.
CoinEx Chain is based on Tendermint Core and Cosmos SDK, both of which have brought a big boost to the development of CoinEx public chain performance. Cosmos-SDK will implement the application logic of the blockchain. Together with the Tendermint consensus engine, it implements the three-layer architecture of the CoinEx public chain: the application layer, the consensus layer, and the network layer.
Tendermint
Tendermint is based on the state machine replication technology and is suitable for blockchain ledger storage. It is a list of transactions making consensus with Byzantine fault tolerance, the transactions are executed in the same order, and eventually the same state is obtained. Tendermint can be used to build various distributed applications.
Cosmos SDK
Cosmos-SDK is a blockchain framework that supports the construction of multiple assets with a consensus mechanism of POS (Proof of Stake) or POA (Proof of Authority). The goal of the Cosmos SDK is to allow developers to easily build custom blockchains from 0, while enabling the interaction with other blockchains.
Cosmos-SDK is a blockchain framework that supports the construction of multiple assets with a consensus mechanism of POS (Proof of Stake) or POA (Proof of Authority). The goal of the Cosmos SDK is to allow developers to easily build custom blockchains from 0, while enabling the interaction with other blockchains. The blockchain development framework Cosmos SDK implements general functions such as account management, community governance, and staking in a modular form. Therefore, using the Cosmos SDK to build a public chain can simplify development procedures and facilitate operation. Tendermint is a fixed protocol in a partially synchronized environment, which can achieve throughput within a delay range of the network and each process itself. The CoinEx public chain is developed based on both, improving the performance and operability of the blockchain. The SDK packaging further reduces considerations of non-related logic and reduces the complexity of developers creating. The two components of Tendermint and Cosmos SDK are connected and interacted through the Application Blockchain Interface.
Cosmos SDK and Tendermint interworking structure，Source:CoinEx; TokenInsight

2.3 Project public chain planning

The development plan of the CoinEx public chain is to create a series of public chains with specific application directions, including:

1. DEX public chain: solve the problems of lack of security and opacity that are widely criticized by centralized exchanges at present; aim to build a transparent, safe, and permission-free financial platform; restore the experience of central exchanges to the greatest extent；
   
2. Smart public chain: a public chain that specifically supports smart contracts and provides a platform for building complex financial applications;
   
3. Privacy public chain: mainly provides transaction amount, account balance, and information protection and the hiding of both parties to the transaction.
   

In order to achieve the performance of each specific application public chain, each public chain in the CoinEx public chain focuses on the development of a certain function. For example, in order to improve the transaction processing speed of the DEX public chain, the DEX public chain only supports the necessary functions and does not support smart contracts. To achieve the smart contract function support, cross-chain connection between the DEX public chain and the Smart public chain is required.

2.4 Operation analysis

“ The CoinEx platform publishes monthly ecosystem reports with high transparency; but the monthly reports are limited to contents about transactions and development, and lack progress in ecosystem and community construction, making them relatively simple.
2.4.1 Disclosure of ecosystem information
Operational risks have a direct impact on platform users. Whether platform operations are smooth and whether there is transparency are issues that platform users care about.
The CoinEx platform was established in 2017 and has around 3 years of development. It is also one of the platforms that has been developing for a long time in the exchange industry. It has obtained a digital currency trading license issued by the Estonian Financial Intelligence Unit (FIU), and the platform’s compliance is guaranteed to some degree.
The actual operation of the CoinEx platform will be displayed in the form of ecosystem monthly reports. The monthly report contains various types of content such as online currencies, new activities, plans for the next month, and ecosystem dynamics. It involves multiple business dimensions including the CoinEx exchange, CoinEx Public Chain, and CET token.
​
https://preview.redd.it/4mt0999ere551.png?width=631&format=png&auto=webp&s=cba27a7c90275f4c033bdd2445a72e6f294265e8
Snippet of a CoinEx ecosystem monthly report，Source: CoinEx; TokenInsight
2.4.2 Roadmap
CoinEx Chain released its development roadmap for the four quarters of 2020 in January 2020. The roadmap shows that CoinEx Chain will undergo major updates on smart contracts and DEX hard fork upgrades. The project roadmap is basically planned on a monthly basis, with a clear plan and a clear direction of development.
CoinEx Public Chain 2020 Development Roadmap，Source: CoinEx; TokenInsight
In addition to the development route planned in the roadmap, CoinEx public chain also discloses its goals for next month in its monthly ecological report. The project’s main net was launched online in November 2019. According to TokenInsight’s review of the development of CoinEx public chain from January to April and the disclosure of the project’s ecosystem monthly report, the project’s plan about development of the smart contract Demo in February failed to be completed as planned; the project completed launching of the new version of the blockchain browser and the Asian Atlantis upgrade; the smart contract virtual machine development was planned to be completed in April, but the progress related to supporting cross-chain agreements was not disclosed yet.
Overall, the project’s development route planning is clear, and the project’s development schedule is consistent with the plan, but there are still some discrepancies. Operation and development information is disclosed every month, and information transparency is high.

3. Industry & Competitors

The earliest origin of the exchange layout in the public chain field began in early 2018 when Binance released an announcement to start the development of the Binance Public Chain officially. In June of the same year, Huobi announced at its brand upgrade conference that it will combine the technical capabilities of the Huobi technical team and the community developers to develop the Huobi public chain called “Huobi Chain”. In December of the same year, OK Group announced the launch of its self-developed public chain OKchain, dedicating to provide underlying technical support and services for startups stationed in B-Labs.
The successful launch of the public chain brings huge strategic significance to the exchange, which can not only improve the performance of the existing business of the exchange but also achieve further expansion of its influence. As one of the most important blockchain infrastructures, the public chain can benefit the exchanges behind it.
As a platform for developing public chain technology exchanges, CoinEx’s main competitors in the field of public chain development include Binance, Huobi, and OKEx. Although they are all exchange platforms for deploying public chains, the above four are different in terms of specific functions, economic models, and critical points of the public chain.

3.1 Development progress comparison

In 2019, Binance became the first exchange to launch a public chain among all digital asset exchanges, and its main product is Binance exchange (DEX). In April 2020, Binance announced the launch of a second smart contract chain, using Ethereum’s virtual machine, so that developers can build decentralized applications without affecting the performance and functionality of their original chain.
OKEx launched OKChain’s testnet in February 2020 and completed open source two months later. OKChain is designed as the basis of large-scale blockchain-driven business applications, with the characteristics of source code decentralization, point-to-point, irreversibility, and efficient autonomy.
Huobi released Huobi Chain for the first time in July 2019, the code is open source, and the testnet was released in February 2020. As a “regulator-friendly financial blockchain”, Huobi Chain focuses on providing compliance services for companies and financial institutions.
The CoinEx public chain officially completed the main online launch in November 2019 and completed the new block browser’s launch in March 2020. On April 3, 2020, CoinEx DEX uploaded the underlying code to Github to achieve open source. The CoinEx public chain is more inclined to build a full DEX ecosystem to achieve a one-stop solution for issuing, listing, storing, and trading. The long-term goal is to create a blockchain financial infrastructure.

3.2 Comparison of economic models

At present, the exchange is more inclined to use its existing platform currency as the native token of the public chain in the construction of public chain ecology. CoinEx’s CET, Binance’s BNB, and Huobi’s HT all fall into this category. OKEx is the only exchange that issues new tokens for its OKChain, which means OKT is the only ‘inflation token’ in the exchange’s public chain, while CET, HT, and BNB are all deflationary.

3.3 Decentralization of public chain

The initial number of CoinEx public chain verification nodes is 42, which is currently the most decentralized among all exchange public chains, and able to take both efficiency and decentralization into account; OKChain also currently has a relatively high degree of decentralization in the exchange public chain (21 verification nodes), its nodes have a high degree of autonomy; by contrast, Binance still firmly controls the operation of nodes and transactions; In terms of encourages cooperation between regulators and the private financial aspects, Huobi provides a lesser degree of decentralization. Huobi Chain uses a variant of the DPoS consensus algorithm to provide functions such as “supervision nodes”, allowing regulators to become validators.
Comparison of some dimensions of CoinEx, Huobi, Binance and OKEx public chain，Source: TokenInsight

4. Token Economy

CoinEx Token (CET) is a native token of the CoinEx ecosystem. It was issued in January 2018. Token holders can enjoy some user value-added services within the ecosystem. Currently, it is mainly used as a native token on the CoinEx Chain. As of 11 am on April 23, 2020, the current circulation of CET tokens in the market is 3,215,354,906.31, with a total of 5,842,177,609.53. CET tokens will not be further issued or inflated. Currently, daily repurchase and quarterly destruction are carried out. The repurchase destruction dynamics can now be tracked real-time on the CET repurchase system on the platform.

4.1 Token Distribution

The CET token used to be based on the ERC-20 token developed by Ethereum. Since the CoinEx Chain mainnet was launched in November 2019, some ERC-20 CET tokens have been mapped to the mainnet CET, and the rest of the CET will be mapped before November 10, 2020. CET holders need to deposit ERC-20 CET to the COinEX exchange, and the exchange will conduct the main network mapping.
At present, CET is mainly circulated in the form of mainnet tokens, and only a small portion of ERC-20 CET has not been mapped. The distribution of token holdings currently circulating on the mainnet can be seen in the figure below. At present, the number of tokens held by the top ten holders accounts for about 60.44% of all mainnet CET tokens.
Distribution of CET token holding addresses，Source: Etherscan; TokenInsight
The following figure shows the initial distribution of tokens after the mainnet mapping preset by CoinEx. From the initial distribution map of CET, it shows that, after mapping, a large portion of CET remains concentrated in the hands of the team (31%), and the actual number of CET circulating in the market only accounts for 49% of the total.
The initial distribution of CET token，Source: CoinEx; TokenInsight
After the main net mapping, the 31% of the total CET (1.8 billion) held by the team will be gradually unlocked in the five years from 2020 to 2024, and 360 million CET will be unlocked each year. By 2024, the CET held by the team will be completely unlocked. From the current CET dynamics, the CET share held by some teams has been used for destruction purposes to achieve the purpose of CET austerity. If the frozen 1.8 billion CET held by the team are used for similar purposes, the development of CET and its platform can benefit from it.
Team’s CET unlocking plan，Source: CoinEx; TokenInsight

4.2 Token economic model

4.2.1 Deflation mechanism
Since the CET token went online in January 2018, CoinEx has increased the circulation of CET through airdrops, transaction fee refunds, operation promotion, and team unlocking. As one of the existing platform coins with long development time, the deflation mechanism of CET token has undergone a series of changes with the development of the industry. In 2018, when the concept of coin-based mining prevailed, CET used transaction mining, stake mining, and pending order mining, which were cancelled in October, December and, April respectively of the following year.
The repurchase and destruction model currently used by CET was updated by CoinEx on April 11, 2020. The original CET quarterly repurchase and destruction policy of the platform will be adjusted to daily repurchase and quarterly destruction. After the implementation of the daily repurchase policy, CoinEx will take out 50% of the daily fee income for CET repurchase in the secondary market and implement quarterly destruction until the total remaining circulation is 3 billion (currently about 5.8 billion).
At the same time that CoinEx updated the repurchase and destruction plan on April 11, the platform also launched a page dedicated to displaying CET repurchase information, so that users can clearly understand the progress of CET repurchase and destruction.
As of April 23, 2020, the platform has destroyed 4,157,822,390.46 CET tokens, accounting for 41.6% of the initial total issuance. At the end of January 2019, it had destroyed 4 billion CETs (single destruction volume peak) at the end of this quarter. The number of CETs to be destroyed is 3,422,983.56.
CET historical destruction data，Source: CoinEx; TokenInsight
4.2.2 Application scenarios
The current usage scenarios of CET are discounted platform transaction fees, VIP services, special activities rights and interests, CoinEx Chain internal circulation fuel, and use of external scenarios.
Deduction and discount of platform transaction fees
CoinEx platform users can use CET to deduct transaction fees when conducting transactions within the platform. At the same time, using CET to pay transaction fees can enjoy the exclusive preferential rates provided by the platform.
CET fee discount amount，Source：CoinEx; TokenInsight
VIP service
Holding a certain number of CETs can make a user become a platform VIP user. Users can also use CET to purchase platform VIPs to obtain corresponding privileges such as discounted rates, accelerated withdrawals, and exclusive customers.
Special activity rights
CET holders can enjoy special rights and interests in platform marketing activities, such as participating in the airdrop of tokens on the platform or accelerating opportunities for high-quality projects.
CoinEx Chain built-in token
CET will serve as a native token of CoinEx Chain, circulate and serve as fuel in CoinEx Chain, and users can also use CET to invest or trade other digital assets. In addition, CET can also serve as transaction fees and function fees (issuing Token, creating new trading pairs, account activation), etc. in the platform, and users can also participate in the campaign of validators by staking CET tokens.
CET is currently used as a circulation token as well for CoinEx DEX to issue tokens, create orders, Bancor, address activation, set address aliases, and other application scenarios.
In general, the types of application scenarios of CET are not plenty enough. In order to better develop the internal ecosystem of the platform, it is necessary to design and develop more CET usage scenarios and incentive mechanisms to increase the retention rate of users while adding new users.
4.2.3 Token incentive
As the native token of the CoinEx public chain, CET will be used as a block incentive to increase community participation after the mainnet of the public chain launched. The 315 million CET held by the foundation in the total CET issuance will be used to incentivize initial verification nodes and Staking participants.
CET annual incentive information，Source：CoinEx; TokenInsight

5. Team & Partners

5.1 Core team members

Among the core team members of CoinEx, the technical members account for a relatively large proportion. The technical team’s overall ability is good and the team members have different technical experience backgrounds including cryptography, underlying protocols, marketing, and operations. The team has rich blockchain industry experience, especially the chief developer, who has about 13 years of development industry experience.
​
https://preview.redd.it/kd0z9q0ese551.png?width=785&format=png&auto=webp&s=7beff33e522165202f6a0b75dba70f32630d8656
https://preview.redd.it/s2klsatese551.png?width=1024&format=png&auto=webp&s=57f03219007d853d754883e2e07cd5eb2c8ed17d
https://preview.redd.it/kuyspmkfse551.png?width=978&format=png&auto=webp&s=fd9c808107d245047f7c74ef34fcf6a02965152c

5.2 Investment institutions and partners

CoinEx’s investment is led by Bitmain and its main partners include Matrixport, Bitcoin.com, CoinBull, Consensus Lab, BTC.com, BTC.top, Hoo Exchange, Wa Yi, ChainFor.com, etc.
Investment institutions and major partners have rich experience in the industry, which can promote the development of projects to a certain extent. However, the current industry involved by the partners is not wide enough, and it will have a limited role in promoting the future of CoinEx’s enriching business lines and increasing ecosystem functions.
https://preview.redd.it/zjgzvv6ise551.png?width=533&format=png&auto=webp&s=a3f7fe3abb2c2d522e289213ae6fbc4e899825e0

6. Community Analysis

According to TokenInsight’s research of the CoinEx platform community, as of April 23, 2020, its official Twitter has 19,800 followers and 932 tweets; the official Telegram has 45 official groups, 3 in Chinese and English, and the other is Korean, Arabic, Vietnamese, Indian and other small language groups, with a total number of 56088 people; the current number of followers on Facebook accounts is 3,107. The overall community followers still have a lot of room for improvement, and community activeness needs to be improved.
Number of followers on the CoinEx social platform，Source:TokenInsight
At present, the project’s search popularity and official website visits are both top-notch, and monthly visits have slowly returned to their previous visit levels after experiencing a significant decline in December 2019.
CoinEx visit popularity，Source: TokenInsight, Similarweb, Google
At present, the visitors of the CoinEx website are distributed in multiple countries, and there are no visits concentration from a single country or region. Therefore, CoinEx’s comprehensive global influence is widely distributed and has a reasonable degree of internationalization.
​
CoinEx official website’s top 5 countries by number of visitors，Source: CoinEx, TokenInsight
Original article
Click here to register on CoinEx!

​
https://preview.redd.it/a51zsja94db51.png?width=567&format=png&auto=webp&s=99e8080c9e9b1fb5e11cbd70f915f9cb37188f81
Foreword
The consensus mechanism is one of the important elements of the blockchain and the core rule of the normal operation of the distributed ledger. It is mainly used to solve the trust problem between people and determine who is responsible for generating new blocks and maintaining the effective unification of the system in the blockchain system. Thus, it has become an everlasting research hot topic in blockchain.
This article starts with the concept and role of the consensus mechanism. First, it enables the reader to have a preliminary understanding of the consensus mechanism as a whole; then starting with the two armies and the Byzantine general problem, the evolution of the consensus mechanism is introduced in the order of the time when the consensus mechanism is proposed; Then, it briefly introduces the current mainstream consensus mechanism from three aspects of concept, working principle and representative project, and compares the advantages and disadvantages of the mainstream consensus mechanism; finally, it gives suggestions on how to choose a consensus mechanism for blockchain projects and pointed out the possibility of the future development of the consensus mechanism.
Contents
First, concept and function of the consensus mechanism
1.1 Concept: The core rules for the normal operation of distributed ledgers
1.2 Role: Solve the trust problem and decide the generation and maintenance of new blocks
1.2.1 Used to solve the trust problem between people
1.2.2 Used to decide who is responsible for generating new blocks and maintaining effective unity in the blockchain system
1.3 Mainstream model of consensus algorithm
Second, the origin of the consensus mechanism
2.1 The two armies and the Byzantine generals
2.1.1 The two armies problem
2.1.2 The Byzantine generals problem
2.2 Development history of consensus mechanism
2.2.1 Classification of consensus mechanism
2.2.2 Development frontier of consensus mechanism
Third, Common Consensus System
Fourth, Selection of consensus mechanism and summary of current situation
4.1 How to choose a consensus mechanism that suits you
4.1.1 Determine whether the final result is important
4.1.2 Determine how fast the application process needs to be
4.1.2 Determining the degree to which the application requires for decentralization
4.1.3 Determine whether the system can be terminated
4.1.4 Select a suitable consensus algorithm after weighing the advantages and disadvantages
4.2 Future development of consensus mechanism
Last lecture review: Chapter 1 Concept and Function of Consensus Mechanism plus Chapter 2 Origin of Consensus Mechanism
Chapter 3 Common Consensus Mechanisms (Part 1)
Figure 6 Summary of relatively mainstream consensus mechanisms
📷
https://preview.redd.it/9r7q3xra4db51.png?width=567&format=png&auto=webp&s=bae5554a596feaac948fae22dffafee98c4318a7
Source: Hasib Anwar, "Consensus Algorithms: The Root Of The Blockchain Technology"
The picture above shows 14 relatively mainstream consensus mechanisms summarized by a geek Hasib Anwar, including PoW (Proof of Work), PoS (Proof of Stake), DPoS (Delegated Proof of Stake), LPoS (Lease Proof of Stake), PoET ( Proof of Elapsed Time), PBFT (Practical Byzantine Fault Tolerance), SBFT (Simple Byzantine Fault Tolerance), DBFT (Delegated Byzantine Fault Tolerance), DAG (Directed Acyclic Graph), Proof-of-Activity (Proof of Activity), Proof-of- Importance (Proof of Importance), Proof-of-Capacity (Proof of Capacity), Proof-of-Burn ( Proof of Burn), Proof-of-Weight (Proof of Weight).
Next, we will mainly introduce and analyze the top ten consensus mechanisms of the current blockchain.
》POW
-Concept:
Work proof mechanism. That is, the proof of work means that it takes a certain amount of computer time to confirm the work.
-Principle:
Figure 7 PoW work proof principle
📷
https://preview.redd.it/xupacdfc4db51.png?width=554&format=png&auto=webp&s=3b6994641f5890804d93dfed9ecfd29308c8e0cc
The PoW represented by Bitcoin uses the SHA-256 algorithm function, which is a 256-bit hash algorithm in the password hash function family:
Proof of work output = SHA256 (SHA256 (block header));
if (output of proof of work if (output of proof of work >= target value), change the random number, recursive i logic, continue to compare with the target value.
New difficulty value = old difficulty value* (time spent by last 2016 blocks /20160 minutes)
Target value = maximum target value / difficulty value
The maximum target value is a fixed number. If the last 2016 blocks took less than 20160 minutes, then this coefficient will be small, and the target value will be adjusted bigger, if not, the target value will be adjusted smaller. Bitcoin mining difficulty and block generation speed will be inversely proportional to the appropriate adjustment of block generation speed.
-Representative applications: BTC, etc.
》POS
-Concept:
Proof of stake. That is, a mechanism for reaching consensus based on the holding currency. The longer the currency is held, the greater the probability of getting a reward.
-Principle:
PoS implementation algorithm formula: hash(block_header) = Coin age calculation formula: coinage = number of coins * remaining usage time of coins
Among them, coinage means coin age, which means that the older the coin age, the easier it is to get answers. The calculation of the coin age is obtained by multiplying the coins owned by the miner by the remaining usage time of each coin, which also means that the more coins you have, the easier it is to get answers. In this way, pos solves the problem of wasting resources in pow, and miners cannot own 51% coins from the entire network, so it also solves the problem of 51% attacks.
-Representative applications: ETH, etc.
》DPoS
-Concept:
Delegated proof of stake. That is, currency holding investors select super nodes by voting to operate the entire network , similar to the people's congress system.
-Principle:
The DPOS algorithm is divided into two parts. Elect a group of block producers and schedule production.
Election: Only permanent nodes with the right to be elected can be elected, and ultimately only the top N witnesses can be elected. These N individuals must obtain more than 50% of the votes to be successfully elected. In addition, this list will be re-elected at regular intervals.
Scheduled production: Under normal circumstances, block producers take turns to generate a block every 3 seconds. Assuming that no producer misses his order, then the chain they produce is bound to be the longest chain. When a witness produces a block, a block needs to be generated every 2s. If the specified time is exceeded, the current witness will lose the right to produce and the right will be transferred to the next witness. Then the witness is not only unpaid, but also may lose his identity.
-Representative applications: EOS, etc.
》DPoW
-Concept:
Delayed proof of work. A new-generation consensus mechanism based on PoB and DPoS. Miners use their own computing power, through the hash algorithm, and finally prove their work, get the corresponding wood, wood is not tradable. After the wood has accumulated to a certain amount, you can go to the burning site to burn the wood. This can achieve a balance between computing power and mining rights.
-Principle:
In the DPoW-based blockchain, miners are no longer rewarded tokens, but "wood" that can be burned, burning wood. Miners use their own computing power, through the hash algorithm, and finally prove their work, get the corresponding wood, wood is not tradable. After the wood has accumulated to a certain amount, you can go to the burning site to burn the wood. Through a set of algorithms, people who burn more wood or BP or a group of BP can obtain the right to generate blocks in the next event segment, and get rewards (tokens) after successful block generation. Since more than one person may burn wood in a time period, the probability of producing blocks in the next time period is determined by the amount of wood burned by oneself. The more it is burned, the higher the probability of obtaining block rights in the next period.
Two node types: notary node and normal node.
The 64 notary nodes are elected by the stakeholders of the dPoW blockchain, and the notarized confirmed blocks can be added from the dPoW blockchain to the attached PoW blockchain. Once a block is added, the hash value of the block will be added to the Bitcoin transaction signed by 33 notary nodes, and a hash will be created to the dPow block record of the Bitcoin blockchain. This record has been notarized by most notary nodes in the network. In order to avoid wars on mining between notary nodes, and thereby reduce the efficiency of the network, Komodo designed a mining method that uses a polling mechanism. This method has two operating modes. In the "No Notary" (No Notary) mode, all network nodes can participate in mining, which is similar to the traditional PoW consensus mechanism. In the "Notaries Active" mode, network notaries use a significantly reduced network difficulty rate to mine. In the "Notary Public Activation" mode, each notary public is allowed to mine a block with its current difficulty, while other notary public nodes must use 10 times the difficulty of mining, and all normal nodes use 100 times the difficulty of the notary public node.
Figure 8 DPoW operation process without a notary node
📷
https://preview.redd.it/3yuzpemd4db51.png?width=500&format=png&auto=webp&s=f3bc2a1c97b13cb861414d3eb23a312b42ea6547
-Representative applications: CelesOS, Komodo, etc.
CelesOS Research Institute丨DPoW consensus mechanism-combustible mining and voting
》PBFT
-Concept:
Practical Byzantine fault tolerance algorithm. That is, the complexity of the algorithm is reduced from exponential to polynomial level, making the Byzantine fault-tolerant algorithm feasible in practical system applications.
-Principle:
Figure 9 PBFT algorithm principle
📷
https://preview.redd.it/8as7rgre4db51.png?width=567&format=png&auto=webp&s=372be730af428f991375146efedd5315926af1ca
First, the client sends a request to the master node to call the service operation, and then the master node broadcasts other copies of the request. All copies execute the request and send the result back to the client. The client needs to wait for f+1 different replica nodes to return the same result as the final result of the entire operation.
Two qualifications: 1. All nodes must be deterministic. That is to say, the results of the operation must be the same under the same conditions and parameters. 2. All nodes must start from the same status. Under these two limited qualifications, even if there are failed replica nodes, the PBFT algorithm agrees on the total order of execution of all non-failed replica nodes, thereby ensuring security.
-Representative applications: Tendermint Consensus, etc.
Next Lecture: Chapter 3 Common Consensus Mechanisms (Part 2) + Chapter 4 Consensus Mechanism Selection and Status Summary
CelesOS
As the first DPOW financial blockchain operating system, CelesOS adopts consensus mechanism 3.0 to break through the "impossible triangle", which can provide high TPS while also allowing for decentralization. Committed to creating a financial blockchain operating system that embraces supervision, providing services for financial institutions and the development of applications on the supervision chain, and formulating a role and consensus ecological supervision layer agreement for supervision.
The CelesOS team is dedicated to building a bridge between blockchain and regulatory agencies/financial industry. We believe that only blockchain technology that cooperates with regulators will have a real future. We believe in and contribute to achieving this goal.
​
📷Website
https://www.celesos.com/
📷 Telegram
https://t.me/celeschain
📷 Twitter
https://twitter.com/CelesChain
📷 Reddit
https://www.reddit.com/useCelesOS
📷 Medium
https://medium.com/@celesos
📷 Facebook
https://www.facebook.com/CelesOS1
📷 Youtube
https://www.youtube.com/channel/UC1Xsd8wU957D-R8RQVZPfGA

​
https://preview.redd.it/7skleasc80a51.png?width=553&format=png&auto=webp&s=fc18cee10bff7b65d5b02487885d936d23382fc8
Table 1 Classification of consensus system
Source: Yuan Yong, Ni Xiaochun, Zeng Shuai, Wang Feiyue, "Development Status and Prospect of Blockchain Consensus Algorithm"
Figure 4 Evolution of consensus algorithm
​
Figure 4 Evolution of consensus algorithm
Source: Network data
​
Foreword
The consensus mechanism is one of the important elements of the blockchain and the core rule of the normal operation of the distributed ledger. It is mainly used to solve the trust problem between people and determine who is responsible for generating new blocks and maintaining the effective unification of the system in the blockchain system. Thus, it has become an everlasting research hot topic in blockchain.
This article starts with the concept and role of the consensus mechanism. First, it enables the reader to have a preliminary understanding of the consensus mechanism as a whole; then starting with the two armies and the Byzantine general problem, the evolution of the consensus mechanism is introduced in the order of the time when the consensus mechanism is proposed; Then, it briefly introduces the current mainstream consensus mechanism from three aspects of concept, working principle and representative project, and compares the advantages and disadvantages of the mainstream consensus mechanism; finally, it gives suggestions on how to choose a consensus mechanism for blockchain projects and pointed out the possibility of the future development of the consensus mechanism.
Contents
First, concept and function of the consensus mechanism
1.1 Concept: The core rules for the normal operation of distributed ledgers
1.2 Role: Solve the trust problem and decide the generation and maintenance of new blocks
1.2.1 Used to solve the trust problem between people
1.2.2 Used to decide who is responsible for generating new blocks and maintaining effective unity in the blockchain system
1.3 Mainstream model of consensus algorithm
Second, the origin of the consensus mechanism
2.1 The two armies and the Byzantine generals
2.1.1 The two armies problem
2.1.2 The Byzantine generals problem
2.2 Development history of consensus mechanism
2.2.1 Classification of consensus mechanism
2.2.2 Development frontier of consensus mechanism
Third, Common Consensus System
Fourth, Selection of consensus mechanism and summary of current situation
4.1 How to choose a consensus mechanism that suits you
4.1.1 Determine whether the final result is important
4.1.2 Determine how fast the application process needs to be
4.1.2 Determining the degree to which the application requires for decentralization
4.1.3 Determine whether the system can be terminated
4.1.4 Select a suitable consensus algorithm after weighing the advantages and disadvantages
4.2 Future development of consensus mechanism
Chapter 1 Concept and Function of Consensus Mechanism
1.1 Concept: The core rules for the normal operation of distributed ledgers
Since most cryptocurrencies use decentralized blockchain design, nodes are scattered and parallel everywhere, so a system must be designed to maintain the order and fairness of the system's operation, unify the version of the blockchain, and reward users maintaining the blockchain and punish malicious harmers. Such a system must rely on some way to prove that who has obtained the packaging rights (or accounting rights) of a blockchain and can obtain the reward for packaging this block; or who intends to harm , and will receive certain penalty. Such system is consensus mechanism.
1.2 Role: Solve the trust problem and decide the generation and maintenance of new blocks
1.2.1 Used to solve the trust problem between people
The reason why the consensus mechanism can be at the core of the blockchain technology is that it has formulated a set of rules from the perspective of cryptographic technologies such as asymmetric encryption and time stamping. All participants must comply with this rules. And theese rules are transparent, and cannot be modified artificially. Therefore, without the endorsement of a third-party authority, it can also mobilize nodes across the network to jointly monitor, record all transactions, and publish them in the form of codes, effectively achieving valuable information transfer, solving or more precisely, greatly improving the trust problem between two unrelated strangers who do not trust each other. After all, trusting the objective technology is less risky than trusting a subjective individual.
1.2.2 Used to decide who is responsible for generating new blocks and maintaining effective unity in the blockchain system
On the other hand, in the blockchain system, due to the high network latency of the peer-to-peer network, the sequence of transactions observed by each node is different. To solve this, the consensus mechanism can be used to reach consensus on transactions order within a short period of time to decide who is responsible for generating new blocks in the blockchain system, and to maintain the effective unity of the blockchain.
1.3 The mainstream model of consensus algorithm
The blockchain system is built on the P2P network, and the set of all nodes can be recorded as PP, generally divided into ordinary nodes that produce data or transactions, and"miner" nodes (denoted as M) responsible for mining operations, like verifying, packaging, and updating the data generated by ordinary nodes or transactions. The functions of the two types of nodes may be overlapped; miner nodes usually participate in the consensus competition process in general, and will select certain representative nodes and replace them to participant in the consensus process and compete for accounting rights in specific algorithms. The collection of these representative nodes is recorded as DD; the accounting nodes selected through the consensus process are recorded as AA. The consensus process is repeated in accordance with the round, and each round of the consensus process generally reselects the accounting node for the round . The core of the consensus process is the "select leader" and "accounting" two parts. In the specific operation process, each round can be divided into four stages: Leader election, Block generation, Data validation and Chain updating namely accounting). As shown in Figure 1, the input of the consensus process is the transaction or data generated and verified by the data node, and the output is the encapsulated data block and updated blockchain. The four stages are executed repeatedly, and each execution round will generate a new block.
Stage 1: Leader election
The election is the core of the consensus process, that is, the process of selecting the accounting node AA from all the miner node sets MM: we can use the formula f(M)→f(M)→AA to represent the election process, where the function ff represents the specific implementation of the consensus algorithm. Generally speaking, |A|=1,|A|=1, that is, the only miner node is finally selected to keep accounts.
Stage 2: Block generation
The accounting node selected in the first stage packages the transactions or data generated by all nodes PP in the current time period into a block according to a specific strategy, and broadcasts the generated new block to all miner nodes MM or their representative nodes DD. These transactions or data are usually sorted according to various factors such as block capacity, transaction fees, transaction waiting time, etc., and then packaged into new blocks in sequence. The block generation strategy is a key factor in the performance of the blockchain system, and it also exposes the strategic behavior of miners such as greedy transactions packaging and selfish mining.
Stage 3: Verification
After receiving the broadcasted new block, the miner node MM or the representative node DD will verify the correctness and rationality of the transactions or data encapsulated in the block. If the new block is approved by most verification/representative nodes, the block will be updated to the blockchain as the next block.
Stage 4: On-Chain
The accounting node adds new blocks to the main chain to form a complete and longer chain from the genesis block to the latest block. If there are multiple fork chains on the main chain, the main chain needs to be based on the consensus algorithm judging criteria to choose one of the appropriate fork chain as the main chain.
Chapter 2 The Origin of Consensus Mechanism
2.1 The two armies problems and the Byzantium generals problem
2.1.1 The two armies
​
​
Figure 2 Schematic diagram of the two armed forces
Selected from Yuan Yong, Ni Xiaochun, Zeng Shuai, Wang Feiyue, "Development Status and Prospect of Blockchain Consensus Algorithm", Journal of Automation, 2018, 44(11): 2011-2022
As shown in the figure, the 1st and 2nd units of the Blue Army are stationed on two sides of the slope, and cannot communicate remotely between each other. While the White Army is just stationed in the middle of the two Blue Army units. Suppose that the White Army is stronger than either of the two Blue Army units, but it is not as strong as the two Blue Army units combined. If the two units of the Blue Army want to jointly attack the White Army at the same time, they need to communicate with each other, but the White Army is stationed in the middle of them. It is impossible to confirm whether the messengers of two Blue Army units have sent the attack signal to each other, let alone the tampering of the messages. In this case, due to the inability to fully confirm with each other, ultimately no effective consensus can be reached between the two Blue Army units, rendering the "paradox of the two armies".
2.1.2 The Byzantine generals problem
​
​
Figure 3 Diagram of the Byzantine generals' problem
Due to the vast territory of the Byzantine roman empire at that time, in order to better achieve the purpose of defense, troops were scattered around the empire, and each army was far apart, and only messengers could deliver messages. During the war, all generals must reach an agreement, or decide whether to attack the enemy based on the majority principle. However, since it is completely dependent on people, if there is a situation where the general rebels or the messenger delivers the wrong message, how can it ensure that the loyal generals can reach agreement without being influenced by the rebels is a problem which was called the Byzantine problem.
The two armies problems and the Byzantine generals problem are all elaborating the same problem: in the case of unreliable information exchange, it is very difficult to reach consensus and coordinate action. The Byzantine general problem is more like a generalization of the "paradox of the two armies".
From the perspective of the computer network, the two armies problem and the Byzantine problem are common contents of computer network courses: the direct communication between two nodes on the network may fail, so the TCP protocol cannot completely guarantee the consistence between the two terminal networks. However, the consensus mechanism can use economic incentives and other methods to reduce this uncertainty to a level acceptable to most people.
It is precisely because of the two armies problem and the Byzantine problem that the consensus mechanism has begun to show its value.
2.2 Development history of consensus mechanism
2.2.1 Classification of consensus mechanism
Because different types of blockchain projects have different requirements for information recording and block generation, and as the consensus mechanism improves due to the development of blockchain technology, there are currently more than 30 consensus mechanisms. These consensus mechanisms can be divided into two categories according to their Byzantine fault tolerance performance: Byzantine fault tolerance system and non-Byzantine fault tolerance system.
​
Table 1 Classification of consensus mechanism
Source: Yuan Yong, Ni Xiaochun, Zeng Shuai, Wang Feiyue, "Development Status and Prospect of Blockchain Consensus Algorithm"
2.2.2 Development frontier of consensus mechanism
-Development of consensus algorithm
According to the proposed time of the consensus algorithm, we can see relatively clearly the development of the consensus algorithm.
Source: Network data
​
Figure 4 Development frontier of consensus algorithm
​
Figure 5 Historical evolution of blockchain consensus algorithm
Source: Yuan Yong, Ni Xiaochun, Zeng Shuai, Wang Feiyue, "Development Status and Prospect of Blockchain Consensus Algorithm"
The consensus algorithm has laid the foundation for the blockchain consensus mechanism. Initially, the research of consensus algorithms was mainly used by computer scientists and computer professors to improve the spam problem or conduct academic discussions.
For example, in 1993, American computer scientist and Harvard professor Cynthia Dwork first proposed the idea of proof of work in order to solve the spam problem; in 1997, the British cryptographer Adam Back also independently proposed to solve the spam problem by use of the mechanism of proof of work for hashing cash and published officially in 2002; in 1999, Markus Jakobsson officially proposed the concept of "proof of work", which laid the foundation for the subsequent design of Satoshi Nakamoto's Bitcoin consensus mechanism.
Next lecture: Chapter 3 Detailed Explanation of Consensus Mechanism Technology
CelesOS
As the first DPOW financial blockchain operating system, CelesOS adopts consensus mechanism 3.0 to break through the "impossible triangle". It provides both high TPS and decentralization. Committed to creating a financial blockchain operating system that embraces regulation, providing services for financial institutions and the development of applications on the regulation chain, and developing a role and consensus eco-system regulation level agreement for regulation.
The CelesOS team is committed to building a bridge between blockchain and regulatory agencies / finance industry. We believe that only blockchain technology that cooperates with regulators will have a bright future and strive to achieve this goal.
📷Website
https://www.celesos.com/
📷 Telegram
https://t.me/celeschain
📷 Twitter
https://twitter.com/CelesChain
📷 Reddit
https://www.reddit.com/useCelesOS
📷 Medium
https://medium.com/@celesos
📷 Facebook
https://www.facebook.com/CelesOS1
📷 Youtube
https://www.youtube.com/channel/UC1Xsd8wU957D-R8RQVZPfGA

This article is written by the CoinEx Chain lab. CoinEx Chain is the world’s first public chain exclusively designed for DEX, and will also include a Smart Chain supporting smart contracts and a Privacy Chain protecting users’ privacy.
longcpp @ 20200618
This is Part 1 of the serialized articles aimed to explain the Tendermint consensus protocol in detail.
Part 1. Preliminary of the consensus protocol: security model and PBFT protocol
Part 2. Tendermint consensus protocol illustrated: two-phase voting protocol and the locking and unlocking mechanism
Part 3. Weighted round-robin proposer selection algorithm used in Tendermint project
Any consensus agreement that is ultimately reached is the General Agreement, that is, the majority opinion. The consensus protocol on which the blockchain system operates is no exception. As a distributed system, the blockchain system aims to maintain the validity of the system. Intuitively, the validity of the blockchain system has two meanings: firstly, there is no ambiguity, and secondly, it can process requests to update its status. The former corresponds to the safety requirements of distributed systems, while the latter to the requirements of liveness. The validity of distributed systems is mainly maintained by consensus protocols, considering the multiple nodes and network communication involved in such systems may be unstable, which has brought huge challenges to the design of consensus protocols.

The semi-synchronous network model and Byzantine fault tolerance

Researchers of distributed systems characterize these problems that may occur in nodes and network communications using node failure models and network models. The fail-stop failure in node failure models refers to the situation where the node itself stops running due to configuration errors or other reasons, thus unable to go on with the consensus protocol. This type of failure will not cause side effects on other parts of the distributed system except that the node itself stops running. However, for such distributed systems as the public blockchain, when designing a consensus protocol, we still need to consider the evildoing intended by nodes besides their failure. These incidents are all included in the Byzantine Failure model, which covers all unexpected situations that may occur on the node, for example, passive downtime failures and any deviation intended by the nodes from the consensus protocol. For a better explanation, downtime failures refer to nodes’ passive running halt, and the Byzantine failure to any arbitrary deviation of nodes from the consensus protocol.
Compared with the node failure model which can be roughly divided into the passive and active models, the modeling of network communication is more difficult. The network itself suffers problems of instability and communication delay. Moreover, since all network communication is ultimately completed by the node which may have a downtime failure or a Byzantine failure in itself, it is usually difficult to define whether such failure arises from the node or the network itself when a node does not receive another node's network message. Although the network communication may be affected by many factors, the researchers found that the network model can be classified by the communication delay. For example, the node may fail to send data packages due to the fail-stop failure, and as a result, the corresponding communication delay is unknown and can be any value. According to the concept of communication delay, the network communication model can be divided into the following three categories:

• The synchronous network model: There is a fixed, known upper bound of delay $\Delta$ in network communication. Under this model, the maximum delay of network communication between two nodes in the network is $\Delta$. Even if there is a malicious node, the communication delay arising therefrom does not exceed $\Delta$.
• The asynchronous network model: There is an unknown delay in network communication, with the upper bound of the delay known, but the message can still be successfully delivered in the end. Under this model, the network communication delay between two nodes in the network can be any possible value, that is, a malicious node, if any, can arbitrarily extend the communication delay.
• The semi-synchronous network model: Assume that there is a Global Stabilization Time (GST), before which it is an asynchronous network model and after which, a synchronous network model. In other words, there is a fixed, known upper bound of delay in network communication $\Delta$. A malicious node can delay the GST arbitrarily, and there will be no notification when no GST occurs. Under this model, the delay in the delivery of the message at the time $T$ is $\Delta + max(T, GST)$.

The synchronous network model is the most ideal network environment. Every message sent through the network can be received within a predictable time, but this model cannot reflect the real network communication situation. As in a real network, network failures are inevitable from time to time, causing the failure in the assumption of the synchronous network model. Yet the asynchronous network model goes to the other extreme and cannot reflect the real network situation either. Moreover, according to the FLP (Fischer-Lynch-Paterson) theorem, under this model if there is one node fails, no consensus protocol will reach consensus in a limited time. In contrast, the semi-synchronous network model can better describe the real-world network communication situation: network communication is usually synchronous or may return to normal after a short time. Such an experience must be no stranger to everyone: the web page, which usually gets loaded quite fast, opens slowly every now and then, and you need to try before you know the network is back to normal since there is usually no notification. The peer-to-peer (P2P) network communication, which is widely used in blockchain projects, also makes it possible for a node to send and receive information from multiple network channels. It is unrealistic to keep blocking the network information transmission of a node for a long time. Therefore, all the discussion below is under the semi-synchronous network model.
The design and selection of consensus protocols for public chain networks that allow nodes to dynamically join and leave need to consider possible Byzantine failures. Therefore, the consensus protocol of a public chain network is designed to guarantee the security and liveness of the network under the semi-synchronous network model on the premise of possible Byzantine failure. Researchers of distributed systems point out that to ensure the security and liveness of the system, the consensus protocol itself needs to meet three requirements:

• Validity: The value reached by honest nodes must be the value proposed by one of them
• Agreement: All honest nodes must reach consensus on the same value
• Termination: The honest nodes must eventually reach consensus on a certain value

Validity and agreement can guarantee the security of the distributed system, that is, the honest nodes will never reach a consensus on a random value, and once the consensus is reached, all honest nodes agree on this value. Termination guarantees the liveness of distributed systems. A distributed system unable to reach consensus is useless.

The CAP theorem and Byzantine Generals Problem

In a semi-synchronous network, is it possible to design a Byzantine fault-tolerant consensus protocol that satisfies validity, agreement, and termination? How many Byzantine nodes can a system tolerance? The CAP theorem and Byzantine Generals Problem provide an answer for these two questions and have thus become the basic guidelines for the design of Byzantine fault-tolerant consensus protocols.
Lamport, Shostak, and Pease abstracted the design of the consensus mechanism in the distributed system in 1982 as the Byzantine Generals Problem, which refers to such a situation as described below: several generals each lead the army to fight in the war, and their troops are stationed in different places. The generals must formulate a unified action plan for the victory. However, since the camps are far away from each other, they can only communicate with each other through the communication soldiers, or, in other words, they cannot appear on the same occasion at the same time to reach a consensus. Unfortunately, among the generals, there is a traitor or two who intend to undermine the unified actions of the loyal generals by sending the wrong information, and the communication soldiers cannot send the message to the destination by themselves. It is assumed that each communication soldier can prove the information he has brought comes from a certain general, just as in the case of a real BFT consensus protocol, each node has its public and private keys to establish an encrypted communication channel for each other to ensure that its messages will not be tampered with in the network communication, and the message receiver can also verify the sender of the message based thereon. As already mentioned, any consensus agreement ultimately reached represents the consensus of the majority. In the process of generals communicating with each other for an offensive or retreat, a general also makes decisions based on the majority opinion from the information collected by himself.
According to the research of Lamport et al, if there are 1/3 or more traitors in the node, the generals cannot reach a unified decision. For example, in the following figure, assume there are 3 generals and only 1 traitor. In the figure on the left, suppose that General C is the traitor, and A and B are loyal. If A wants to launch an attack and informs B and C of such intention, yet the traitor C sends a message to B, suggesting what he has received from A is a retreat. In this case, B can't decide as he doesn't know who the traitor is, and the information received is insufficient for him to decide. If A is a traitor, he can send different messages to B and C. Then C faithfully reports to B the information he received. At this moment as B receives conflicting information, he cannot make any decisions. In both cases, even if B had received consistent information, it would be impossible for him to spot the traitor between A and C. Therefore, it is obvious that in both situations shown in the figure below, the honest General B cannot make a choice.
According to this conclusion, when there are $n$ generals with at most $f$ traitors (n≤3f), the generals cannot reach a consensus if $n \leq 3f$; and with $n > 3f$, a consensus can be reached. This conclusion also suggests that when the number of Byzantine failures $f$ exceeds 1/3 of the total number of nodes $n$ in the system $f \ge n/3$ , no consensus will be reached on any consensus protocol among all honest nodes. Only when $f < n/3$, such condition is likely to happen, without loss of generality, and for the subsequent discussion on the consensus protocol, $ n \ge 3f + 1$ by default.
The conclusion reached by Lamport et al. on the Byzantine Generals Problem draws a line between the possible and the impossible in the design of the Byzantine fault tolerance consensus protocol. Within the possible range, how will the consensus protocol be designed? Can both the security and liveness of distributed systems be fully guaranteed? Brewer provided the answer in his CAP theorem in 2000. It indicated that a distributed system requires the following three basic attributes, but any distributed system can only meet two of the three at the same time.

1. Consistency: When any node responds to the request, it must either provide the latest status information or provide no status information
2. Availability: Any node in the system must be able to continue reading and writing
3. Partition Tolerance: The system can tolerate the loss of any number of messages between two nodes and still function normally

​
https://preview.redd.it/1ozfwk7u7m851.png?width=1400&format=png&auto=webp&s=fdee6318de2cf1c021e636654766a7a0fe7b38b4
A distributed system aims to provide consistent services. Therefore, the consistency attribute requires that the two nodes in the system cannot provide conflicting status information or expired information, which can ensure the security of the distributed system. The availability attribute is to ensure that the system can continuously update its status and guarantee the availability of distributed systems. The partition tolerance attribute is related to the network communication delay, and, under the semi-synchronous network model, it can be the status before GST when the network is in an asynchronous status with an unknown delay in the network communication. In this condition, communicating nodes may not receive information from each other, and the network is thus considered to be in a partitioned status. Partition tolerance requires the distributed system to function normally even in network partitions.
The proof of the CAP theorem can be demonstrated with the following diagram. The curve represents the network partition, and each network has four nodes, distinguished by the numbers 1, 2, 3, and 4. The distributed system stores color information, and all the status information stored by all nodes is blue at first.

1. Partition tolerance and availability mean the loss of consistency: When node 1 receives a new request in the leftmost image, the status changes to red, the status transition information of node 1 is passed to node 3, and node 3 also updates the status information to red. However, since node 3 and node 4 did not receive the corresponding information due to the network partition, the status information is still blue. At this moment, if the status information is queried through node 2, the blue returned by node 2 is not the latest status of the system, thus losing consistency.
2. Partition tolerance and consistency mean the loss of availability: In the middle figure, the initial status information of all nodes is blue. When node 1 and node 3 update the status information to red, node 2 and node 4 maintain the outdated information as blue due to network partition. Also when querying status information through node 2, you need to first ask other nodes to make sure you’re in the latest status before returning status information as node 2 needs to follow consistency, but because of the network partition, node 2 cannot receive any information from node 1 or node 3. Then node 2 cannot determine whether it is in the latest status, so it chooses not to return any information, thus depriving the system of availability.
3. Consistency and availability mean the loss of the partition tolerance: In the right-most figure, the system does not have a network partition at first, and both status updates and queries can go smoothly. However, once a network partition occurs, it degenerates into one of the previous two conditions. It is thus proved that any distributed system cannot have consistency, availability, and partition tolerance all at the same time.

​
https://preview.redd.it/456x2blv7m851.png?width=1400&format=png&auto=webp&s=550797373145b8fc1471bdde68ed5f8d45adb52b
The discovery of the CAP theorem seems to declare that the aforementioned goals of the consensus protocol is impossible. However, if you’re careful enough, you may find from the above that those are all extreme cases, such as network partitions that cause the failure of information transmission, which could be rare, especially in P2P network. In the second case, the system rarely returns the same information with node 2, and the general practice is to query other nodes and return the latest status as believed after a while, regardless of whether it has received the request information of other nodes. Therefore, although the CAP theorem points out that any distributed system cannot satisfy the three attributes at the same time, it is not a binary choice, as the designer of the consensus protocol can weigh up all the three attributes according to the needs of the distributed system. However, as the communication delay is always involved in the distributed system, one always needs to choose between availability and consistency while ensuring a certain degree of partition tolerance. Specifically, in the second case, it is about the value that node 2 returns: a probably outdated value or no value. Returning the possibly outdated value may violate consistency but guarantees availability; yet returning no value deprives the system of availability but guarantees its consistency. Tendermint consensus protocol to be introduced is consistent in this trade-off. In other words, it will lose availability in some cases.
The genius of Satoshi Nakamoto is that with constraints of the CAP theorem, he managed to reach a reliable Byzantine consensus in a distributed network by combining PoW mechanism, Satoshi Nakamoto consensus, and economic incentives with appropriate parameter configuration. Whether Bitcoin's mechanism design solves the Byzantine Generals Problem has remained a dispute among academicians. Garay, Kiayias, and Leonardos analyzed the link between Bitcoin mechanism design and the Byzantine consensus in detail in their paper The Bitcoin Backbone Protocol: Analysis and Applications. In simple terms, the Satoshi Consensus is a probabilistic Byzantine fault-tolerant consensus protocol that depends on such conditions as the network communication environment and the proportion of malicious nodes' hashrate. When the proportion of malicious nodes’ hashrate does not exceed 1/2 in a good network communication environment, the Satoshi Consensus can reliably solve the Byzantine consensus problem in a distributed environment. However, when the environment turns bad, even with the proportion within 1/2, the Satoshi Consensus may still fail to reach a reliable conclusion on the Byzantine consensus problem. It is worth noting that the quality of the network environment is relative to Bitcoin's block interval. The 10-minute block generation interval of the Bitcoin can ensure that the system is in a good network communication environment in most cases, given the fact that the broadcast time of a block in the distributed network is usually just several seconds. In addition, economic incentives can motivate most nodes to actively comply with the agreement. It is thus considered that with the current Bitcoin network parameter configuration and mechanism design, the Bitcoin mechanism design has reliably solved the Byzantine Consensus problem in the current network environment.

Practical Byzantine Fault Tolerance, PBFT

It is not an easy task to design the Byzantine fault-tolerant consensus protocol in a semi-synchronous network. The first practically usable Byzantine fault-tolerant consensus protocol is the Practical Byzantine Fault Tolerance (PBFT) designed by Castro and Liskov in 1999, the first of its kind with polynomial complexity. For a distributed system with $n$ nodes, the communication complexity is $O(n²$.) Castro and Liskov showed in the paper that by transforming centralized file system into a distributed one using the PBFT protocol, the overwall performance was only slowed down by 3%. In this section we will briefly introduce the PBFT protocol, paving the way for further detailed explanations of the Tendermint protocol and the improvements of the Tendermint protocol.
The PBFT protocol that includes $n=3f+1$ nodes can tolerate up to $f$ Byzantine nodes. In the original paper of PBFT, full connection is required among all the $n$ nodes, that is, any two of the n nodes must be connected. All the nodes of the network jointly maintain the system status through network communication. In the Bitcoin network, a node can participate in or exit the consensus process through hashrate mining at any time, which is managed by the administrator, and the PFBT protocol needs to determine all the participating nodes before the protocol starts. All nodes in the PBFT protocol are divided into two categories, master nodes, and slave nodes. There is only one master node at any time, and all nodes take turns to be the master node. All nodes run in a rotation process called View, in each of which the master node will be reelected. The master node selection algorithm in PBFT is very simple: all nodes become the master node in turn by the index number. In each view, all nodes try to reach a consensus on the system status. It is worth mentioning that in the PBFT protocol, each node has its own digital signature key pair. All sent messages (including request messages from the client) need to be signed to ensure the integrity of the message in the network and the traceability of the message itself. (You can determine who sent a message based on the digital signature).
The following figure shows the basic flow of the PBFT consensus protocol. Assume that the current view’s master node is node 0. Client C initiates a request to the master node 0. After the master node receives the request, it broadcasts the request to all slave nodes that process the request of client C and return the result to the client. After the client receives f+1 identical results from different nodes (based on the signature value), the result can be taken as the final result of the entire operation. Since the system can have at most f Byzantine nodes, at least one of the f+1 results received by the client comes from an honest node, and the security of the consensus protocol guarantees that all honest nodes will reach consensus on the same status. So, the feedback from 1 honest node is enough to confirm that the corresponding request has been processed by the system.
​
https://preview.redd.it/sz8so5ly7m851.png?width=1400&format=png&auto=webp&s=d472810e76bbc202e91a25ef29a51e109a576554
For the status synchronization of all honest nodes, the PBFT protocol has two constraints on each node: on one hand, all nodes must start from the same status, and on the other, the status transition of all nodes must be definite, that is, given the same status and request, the results after the operation must be the same. Under these two constraints, as long as the entire system agrees on the processing order of all transactions, the status of all honest nodes will be consistent. This is also the main purpose of the PBFT protocol: to reach a consensus on the order of transactions between all nodes, thereby ensuring the security of the entire distributed system. In terms of availability, the PBFT consensus protocol relies on a timeout mechanism to find anomalies in the consensus process and start the View Change protocol in time to try to reach a consensus again.
The figure above shows a simplified workflow of the PBFT protocol. Where C is the client, 0, 1, 2, and 3 represent 4 nodes respectively. Specifically, 0 is the master node of the current view, 1, 2, 3 are slave nodes, and node 3 is faulty. Under normal circumstances, the PBFT consensus protocol reaches consensus on the order of transactions between nodes through a three-phase protocol. These three phases are respectively: Pre-Prepare, Prepare, and Commit:

• The master node of the pre-preparation node is responsible for assigning the sequence number to the received client request, and broadcasting the message to the slave node. The message contains the hash value of the client request d, the sequence number of the current viewv, the sequence number n assigned by the master node to the request, and the signature information of the master nodesig. The scheme design of the PBFT protocol separates the request transmission from the request sequencing process, and the request transmission is not to be discussed here. The slave node that receives the message accepts the message after confirming the message is legitimate and enter preparation phase. The message in this step checks the basic signature, hash value, current view, and, most importantly, whether the master node has given the same sequence number to other request from the client in the current view.
• In preparation, the slave node broadcasts the message to all nodes (including itself), indicating that it assigns the sequence number n to the client request with the hash value d under the current view v, with its signaturesig as proof. The node receiving the message will check the correctness of the signature, the matching of the view sequence number, etc., and accept the legitimate message. When the PRE-PREPARE message about a client request (from the main node) received by a node matches with the PREPARE from 2f slave nodes, the system has agreed on the sequence number requested by the client in the current view. This means that 2f+1 nodes in the current view agree with the request sequence number. Since it contains information from at most fmalicious nodes, there are a total of f+1 honest nodes that have agreed with the allocation of the request sequence number. With f malicious nodes, there are a total of 2f+1 honest nodes, so f+1represents the majority of the honest nodes, which is the consensus of the majority mentioned before.
• After the node (including the master node and the slave node) receives a PRE-PREPARE message requested by the client and 2f PREPARE messages, the message is broadcast across the network and enters the submission phase. This message is used to indicate that the node has observed that the whole network has reached a consensus on the sequence number allocation of the request message from the client. When the node receives 2f+1 COMMIT messages, there are at least f+1 honest nodes, that is, most of the honest nodes have observed that the entire network has reached consensus on the arrangement of sequence numbers of the request message from the client. The node can process the client request and return the execution result to the client at this moment.

Roughly speaking, in the pre-preparation phase, the master node assigns a sequence number to all new client requests. During preparation, all nodes reach consensus on the client request sequence number in this view, while in submission the consistency of the request sequence number of the client in different views is to be guaranteed. In addition, the design of the PBFT protocol itself does not require the request message to be submitted by the assigned sequence number, but out of order. That can improve the efficiency of the implementation of the consensus protocol. Yet, the messages are still processed by the sequence number assigned by the consensus protocol for the consistency of the distributed system.
In the three-phase protocol execution of the PBFT protocol, in addition to maintaining the status information of the distributed system, the node itself also needs to log all kinds of consensus information it receives. The gradual accumulation of logs will consume considerable system resources. Therefore, the PBFT protocol additionally defines checkpoints to help the node deal with garbage collection. You can set a checkpoint every 100 or 1000 sequence numbers according to the request sequence number. After the client request at the checkpoint is executed, the node broadcasts messages throughout the network, indicating that after the node executes the client request with sequence number n, the hash value of the system status is d, and it is vouched by its own signature sig. After 2f+1 matching CHECKPOINT messages (one of which can come from the node itself) are received, most of the honest nodes in the entire network have reached a consensus on the system status after the execution of the client request with the sequence numbern, and then you can clear all relevant log records of client requests with the sequence number less than n. The node needs to save these2f+1 CHECKPOINTmessages as proof of the legitimate status at this moment, and the corresponding checkpoint is called a stable checkpoint.
The three-phase protocol of the PBFT protocol can ensure the consistency of the processing order of the client request, and the checkpoint mechanism is set to help nodes perform garbage collection and further ensures the status consistency of the distributed system, both of which can guarantee the security of the distributed system aforementioned. How is the availability of the distributed system guaranteed? In the semi-synchronous network model, a timeout mechanism is usually introduced, which is related to delays in the network environment. It is assumed that the network delay has a known upper bound after GST. In such condition, an initial value is usually set according to the network condition of the system deployed. In case of a timeout event, besides the corresponding processing flow triggered, additional mechanisms will be activated to readjust the waiting time. For example, an algorithm like TCP's exponential back off can be adopted to adjust the waiting time after a timeout event.
To ensure the availability of the system in the PBFT protocol, a timeout mechanism is also introduced. In addition, due to the potential the Byzantine failure in the master node itself, the PBFT protocol also needs to ensure the security and availability of the system in this case. When the Byzantine failure occurs in the master node, for example, when the slave node does not receive the PRE-PREPARE message or the PRE-PREPARE message sent by the master node from the master node within the time window and is thus determined to be illegitimate, the slave node can broadcast to the entire network, indicating that the node requests to switch to the new view with sequence number v+1. n indicates the request sequence number corresponding to the latest stable checkpoint local to the node, and C is to prove the stable checkpoint 2f+1 legitimate CHECKPOINT messages as aforementioned. After the latest stable checkpoint and before initiating the VIEWCHANGE message, the system may have reached a consensus on the sequence numbers of some request messages in the previous view. To ensure the consistency of these request sequence numbers to be switched in the view, the VIEWCHANGE message needs to carry this kind of the information to the new view, which is also the meaning of the P field in the message. P contains all the client request messages collected at the node with a request sequence number greater than n and the proof that a consensus has been reached on the sequence number in the node: the legitimate PRE-PREPARE message of the request and 2f matching PREPARE messages. When the master node in view v+1 collects 2f+1 VIEWCHANGE messages, it can broadcast the NEW-VIEW message and take the entire system into a new view. For the security of the system in combination with the three-phase protocol of the PBFT protocol, the construction rules of the NEW-VIEW information are designed in a quite complicated way. You can refer to the original paper of PBFT for more details.
​
https://preview.redd.it/x5efdc908m851.png?width=1400&format=png&auto=webp&s=97b4fd879d0ec668ee0990ea4cadf476167a2948
VIEWCHANGE contains a lot of information. For example, C contains 2f+1 signature information, P contains several signature sets, and each set has 2f+1 signature. At least 2f+1 nodes need to send a VIEWCHANGE message before prompting the system to enter the next new view, and that means, in addition to the complex logic of constructing the information of VIEWCHANGE and NEW-VIEW, the communication complexity of the view conversion protocol is $O(n²$.) Such complexity also limits the PBFT protocol to support only a few nodes, and when there are 100 nodes, it is usually too complex to practically deploy PBFT. It is worth noting that in some materials the communication complexity of the PBFT protocol is inappropriately attributed to the full connection between n nodes. By changing the fully connected network topology to the P2P network topology based on distributed hash tables commonly used in blockchain projects, high communication complexity caused by full connection can be conveniently solved, yet still, it is difficult to improve the communication complexity during the view conversion process. In recent years, researchers have proposed to reduce the amount of communication in this step by adopting aggregate signature scheme. With this technology, 2f+1 signature information can be compressed into one, thereby reducing the communication volume during view change.