Read the consensus mechanism of blockchain in one article

Foreword: This article succinctly illustrates the two main processes for reaching consensus: the block proposal and the block consensus. The block proposal mainly involves the PoW and PoS mechanisms, that is, the proof of work and the mechanism of proof of equity, to resist witch attacks and safely select reliable block proponents. The consensus of the block is related to the consensus algorithm, which mainly includes the Nakamoto consensus and the classic consensus. Nakamoto's consensus adopts the longest chain rule, and the classic consensus can achieve the finality. Each consensus algorithm has its own trade-offs. The authors Julian Koh and Cheryl Sew Hoy are translated by the “Liao L” of the “Blue Fox Notes” community.

The blockchain consensus is one of the most widely discussed blockchain areas in 2017 and 2018. It can be seen that many companies are trying to build a new smart contract platform from scratch and compete with Ethereum, and one of the differences or innovations is in the blockchain consensus algorithm. Trying to understand these algorithms and being able to compare them critically is a full-time job for many crypto investors, and there is no doubt that it is not easy to master them.

In order to uncover the mystery of these "consensus algorithms", many people have done a lot of work. However, for ordinary people, they are too technical. Some concepts, such as synchronization, security/activity certification, and impossible outcomes, help people understand. However, in my opinion, for most people, full understanding is not particularly important.

This article focuses on the consensus algorithm for blockchains, without mentioning the larger and more complex domain of distributed systems. For the sake of simplicity, some technical concepts will be abandoned.

• Bitcoin welcomes the new outbreak window? This policy has spawned the need for trillions of funds to be shuffled.
• Overstock's bitcoin fan CEO is gone, the departure statement does not forget to call the blockchain
• Bitland's confidential data outflow: 600,000 new mining machines in half a year, with a valuation of 12 billion US dollars

At the end of this article, you should understand the difference between PoW and PoS, understand the meaning of BFT, and most importantly, when considering which blockchain to build your application, you should know what their tradeoffs are.

What is consensus? Why is it important?

Simply put, a blockchain is a public database in which users agree on what is right. Bitcoin is a public database that records all transactions, preserving the integrity of the currency system. There are two main issues to understand:

1. What is the consensus?

2. How to reach a consensus?

We need someone to propose and then let others choose until some form of consensus is reached. In the case of a blockchain, we need someone to propose a block and then need the remaining nodes to accept the block.

A simple example is as follows:

4 friends try and arrange time to work together

4 people try and arrange a common time to do things. Everyone proposes their available time (blank). As you can see, there are two time periods that are commonly available, 2 pm and 6 pm. How do they reach a consensus? Before they make available time, they agree on a specific rule: everyone must choose the earliest common time available. Under this rule, this means that they will meet at 2 pm instead of 6 pm. As a result, they reached a consensus.

Following this framework, we extend its analogy to the bitcoin blockchain:

What do people agree on?

People reached a consensus on block data. The block contains valid bitcoin transactions. In Bitcoin, anyone can propose blocks as long as they are the first to solve a computational puzzle (PoW).

How do people reach a consensus?

People agree to accept the blocks on the longest chain. For example, if chain A has a height of 100 and chain B has a height of 200, if you receive block 101 on chain A and block 201 on chain B, you must accept block 201. Some people add blocks to shorter chains, probably because they don't realize longer chains, but the "longest chain rule" ensures that once the blocks spread throughout the network, everyone eventually agrees on the same thing.

The framework supports all consensus algorithms. Different algorithms can use different methods to propose blocks, or different ways to reach consensus on blocks.

Proposed block

When considering a block proposal, the biggest question is who will propose the block. If anyone can propose a block at any time, it will be difficult to reach a consensus, because it is similar to people talking to each other. The representative must be elected in some way so that the remaining one can see a proposal at a time.

The most naïve way is to let the protocol randomly select a person to propose a new block. However, on the Internet, a person can pretend to be a hundred people by running one hundred instances of the same program. Therefore, we need to create some form of scarcity to resist witch attacks. (Blue Fox Note: Witch attack mainly refers to a few nodes in the network to control multiple false identities, and use these identities to control the attack mode of a large number of normal nodes in the network.).

Therefore, this game must be able to withstand the attack of a single hacker manipulating many people. That's what PoW and PoS bring to you: a way to limit your computer to certain resources. (Blue Fox Note: That is to say, by setting thresholds, such as PoW's computing power and PoS's token investment, it solves the problem of who is eligible to propose a block and get rewards through a competitive approach.)

PoW is as follows: In order to get the right to propose a block, you must take the lead in completing the computationally intensive task. Simulate a virtual computer coin toss task until it gets the front of the virtual coin 100 times in a row. This is computationally intensive and no one can pretend to be a hundred because it is subject to its power.

However, by adopting this "anti-witch attack" mechanism, a mine of thousands of computers has been established to win in the competition for computing power, thereby obtaining the right to propose the block. These server mines consume huge amounts of electricity, so they are concentrated in countries or regions where the cheapest electricity is available.

So what does it mean for decentralization when most bitcoin miners are located in China? This geographical centralization poses a real threat to the longevity of the system, as these mining companies are easily regulated.

Bitcoin mine

PoS uses a different "anti-witch attack" mechanism than PoW. Since you have to spend money on bitcoin mining computers and buying electricity, why not just use money to select block producers and skip the computationally intensive process? PoS is the idea of ​​choosing a block proposer based on how much money people pledge in the system, that is, the proportion of tokens that people have in the system.

In PoW, the more computing power there is, the higher the probability of being selected as the next block. In PoS, the more tokens you have, the higher the probability of becoming a block producer.

Please note that there is no beginning to talk about how to reach a consensus on the block. There is a common misconception that PoW and PoS are consensus algorithms. Actually they are not. They simply select block producers by constraining scarce resources.

Block consensus

This is where things get interesting and where most innovations have taken place in recent years. How can we reach a consensus once someone proposes a block? This is a problem that computer scientists have been trying to solve since the 1980s to synchronize computer clusters when some computers occasionally crash. In the 1990s, these computer scientists began to think about a more difficult question: If a hacker can control some of these computers? (Blue Fox Note: The difference between these two problems is that one is just a partial crash of the computer, and the other is that the computer is not crashed and is maliciously controlled.)

Can they build a robust enough system to ensure that all non-malicious computers still reach a consensus? This feature is known as Byzantine Fault Tolerance (BFT), which is based on the Byzantine General. The BFT system is a relatively small research topic because most systems do not require this level of robustness because most computer clusters are usually single companies. It was not until the arrival of the blockchain that this situation changed.

In a blockchain, anyone can run nodes (computers in a cluster) and can send information or data to other nodes. This is a truly confrontational environment because malicious actors can pretend to be honest nodes. For example, what if 10 malicious computers in a cluster send conflict information to 9 other computers?

Malicious computers send conflict messages to different honest computers

This problem becomes very tricky because honest computers cannot distinguish between malicious and non-malicious computers. There are two main ways to solve this problem: the Nakamoto consensus and the classic consensus.

Nakamoto consensus

Nakamoto's consensus is used in Bitcoin and most PoW systems, created by Nakamoto. It has a single rule: "When you see the proposed block with the most proof of work, accept it." In general, the block with the highest number has the most proof of the workload. (Blue Fox Note: This is the longest chain rule for Bitcoin. This is a probabilistic confirmation. The longer the block depth is confirmed, the harder it is to reverse the transaction.)

This means that you are never 100% certain that the block you are seeing is "correct." For example, if the highest block number you see is 99, you can receive block A at block number 100, so you accept it.

Suddenly, you receive block B at block number 103, and it has a different block at block number 100. According to the consensus rules, you need to "reverse" the block A that was previously accepted and accept the new block history.

In this system, attackers who exceed 50% of the system's power will be able to build the longest chain, so they can create any block they want. Through this example, we can see that these rules help people agree on which chain is acceptable.

Classic consensus

Before the invention of Nakamoto's consensus in 2009, computer scientists had different solutions to this problem, and this problem has different characteristics. The first Byzantine fault-tolerant consensus algorithm is called the Practical Byzantine Fault Tolerant Algorithm (PBFT). It works by having a group of participants vote multiple rounds until a certain percentage of the voters reach a consensus.

Based on a mechanism such as PoS, select someone to propose a block. He sends the block to other known participants. Voted by other participants.

Since most participants voted for the block, everyone in the system will accept the block as the correct block. With this type of consensus, there must be a set of known voters, but once they vote, the block is final. Therefore, there is no block rollback. If there is a dispute, the system will stop. (Blue Fox Note: The final certainty of the classic consensus is in stark contrast to the probability of the Nakamoto consensus.)

The PBFT algorithm has been used in the blockchain. The most prominent BFT algorithm in the blockchain so far is the Tendermint Core. Tendermint Core is the first consensus algorithm in the blockchain that does not use the Nakamoto consensus, but is based on more than 20 years of computer science research.

The main limitation of the BFT algorithm is that they are usually limited to a small number of voters because all voters need to know in advance. It is extremely difficult for 100,000 people to constantly communicate with others to reach a consensus. So far, Cosmos has run one of the largest public BFT systems possible, and their Game of Stakes test network has more than 200+ certifiers involved.

There are other variants of the Nakamoto consensus, such as GHOST (new scoring algorithm, not just the longest chain), and other variants of BFT consensus, such as Casper-BFT and Thunderella.

The main difference between these variants of the consensus algorithm is actually that the way in which the block is proposed is different or the number of people participating in the consensus is different. In most cases, there is a similar trade-off between them in an algorithm family. There are also some new forms of consensus, such as Avalanche, which do not belong to any series.

The trade-off between the classic consensus and the Nakamoto consensus comes from Gun Sirer's Avalanche demo

How to choose a consensus algorithm?

Depending on the type of application you want to build, here's a guide to which consensus algorithm to choose, which will also involve which smart contract platform to choose.

1. How much do you want to build an application that is critical to the finality?

For some applications, finality is very important, while others are less important. If you are building a new payment system for micropayments, the transaction can be reversed and not the end of the world. Similarly, if you are building a decentralized social network, 100% guaranteed status updates are not a particularly important feature. Conversely, if you build a decentralized exchange, the ultimate is a vital part of the user experience. Reversing a trade is worse than not trading. For reference, the finality of Bitcoin is about 1 hour (Blue Fox Note: Bitcoin 6 blocks are confirmed, basically confirming the completion of the transaction, but this is not 100% final, but in 6 areas After the block is confirmed, it is very difficult to reverse the transaction.) The finality of the Ethereum is about 6 minutes, and the Tendermint Core has a finality of 1 second.

2. How quickly do you need to build an app?

If you are building a game application, is it reasonable to wait 15 seconds (or even longer) before each action? Due to the block time of Ethereum, the game user experience based on the Ethereum blockchain is bad because its throughput is too low. However, the application of a transfer house ownership may be very suitable for operation on Ethereum. Building applications with the Cosmos SDK allows developers to use off-the-shelf Tendermint Core, which has shorter block times and high throughput and can reach up to 10,000 transactions per second. You can do this by setting a smaller number of certifiers for your application, because you can reduce communication overhead and increase application processing speed.

3. What is the degree of "decentralization" required for the application you are building?

Some applications, such as games, may not require significant anti-censorship features, which are just a by-product of decentralization. In theory, the verifier can create cartels and implement block/reverse transactions in the game to make a profit. Are these really important in the application? If it's not that important, a blockchain like EOS might suit your application because it has faster transaction speeds and no cost.

However, some applications, such as autonomous banks, have high requirements for decentralization. Although Ethereum is considered to be decentralized, some supporters claim that the concentration of the Ethereum mine pool is also an important manifestation of its centralization trend. In fact, it has only 11 verifiers (mine pools).

One of the great benefits of building your own blockchain instead of building applications based on other smart contract platforms is that you can apply custom authentication methods for yourself. However, building your own blockchain is very difficult, so in this respect, using the Cosmos SDK is very useful, you can easily build your own blockchain and customize the decentralization required for your application.

4. If the system is stopped, is it acceptable?

If you're building a shared riding app similar to decentralized, then ensuring that the service is running around the clock may be the highest priority, even if there are some occasional errors, such as a transaction being reversed.

One of the attributes of Tendermint Core is that if there is a disagreement between network verifiers, the network will choose to stop instead of making an incorrect transaction. Some applications, such as decentralized exchange applications, need to ensure correctness at all costs. If there is a problem, you can suspend the decentralized transaction instead of making a reversible transaction.

in conclusion

There is no single "best" consensus algorithm. Each algorithm has its own trade-offs. However, by understanding the consensus process (proposing and reaching consensus) and building a framework to think about what consensus algorithms your application might need, it can help you make more informed decisions when choosing a blockchain. Of course, there are other factors to consider, such as developer tools, communities, and more.

In general, PoW and PoS are not consensus algorithms. They are a "anti-witch attack" mechanism that can help pick block proponents.

The two main consensus families are the Nakamoto consensus and the classic consensus. These algorithms are used to reach consensus on blocks in the blockchain. Each consensus algorithm has its own trade-offs. The consensus algorithm and the smart contract platform are selected according to the application scenario. Factors to consider:

l finality

l speed

l Decentralization

l activity

——

Risk Warning : All articles in Blue Fox Notes can not be used as investment suggestions or recommendations . Investment is risky . Investment should consider individual risk tolerance . It is recommended to conduct in-depth inspections of the project and carefully make your own investment decisions.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!