Blockchain circle

One stop hot information platform

About us:

Blockchain circle provides the latest information about blockchain, digital currency, digital wallet, exchange, metauniverse, bitcoin, Ethereum, contract, financial management and so on, and always pays attention to the latest market...

Understand the consensus mechanism of blockchain in one article

Time : 29/07/2021 Author : 8xf45l Click : + -
        Abstract: This paper briefly expounds the two main processes of reaching consensus: block proposal and block consensus. The block proposal mainly involves POW and POS mechanisms, that is, the mechanism of workload proof and equity proof, to resist witch attacks and safely select reliable block proponents. Foreword: the consensus reaching of blocks involves consensus algorithm, mainly including Nakamoto consensus and classic consensus. Nakamoto Cong consensus adopts the longest chain rule, while the classic consensus can achieve finality. Each consensus algorithm has its own trade-offs. This article is written by juliankoh and cherylsewhoy, translated by "Xiao L" of the "blue fox notes" community.
        Blockchain consensus is one of the most widely discussed blockchain sub areas in 2017 and 2018. It can be seen that many companies try to build new smart contract platforms from scratch and compete with Ethereum, and one of the differences or innovations is in the consensus algorithm of blockchain. Trying to understand these algorithms and be able to critically compare them is a full-time job for many encryption investors. 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, proof of safety / activity, impossible results, help people understand.
        However, in my opinion, complete understanding is not particularly important for most people. This paper focuses on the consensus algorithm of blockchain, and does not mention the larger and super complex distributed system field. In order to be easy to understand, some technical concepts will be abandoned. 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 on, you should know what their trade-offs are. In short, 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 monetary system.
        There are two main issues to understand:. We need someone to propose, and then let others choose, until we reach some form of consensus. In the case of blockchain, we need someone to propose blocks, and then we need the remaining nodes to accept the blocks. Four people try and arrange common time to do things. Each person proposes his / her available time (blank box). As you can see, there are two commonly available time periods, 2 p.m. and 6 p.m. How do they reach a consensus? Before they put forward the available time, they agreed on a specific rule: everyone must choose the earliest common available time. Under this rule, it means that they will meet at 2 p.m. instead of 6 p.m.
        Thus, they reached a consensus. People have 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 computing puzzle (POW). People agree to accept blocks on the longest chain. For example, if the height of chain A is 100 and the height of chain B is 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, perhaps because they are not aware of longer chains, but the "longest chain rule" ensures that once blocks are spread throughout the network, everyone will eventually reach a consensus on the same thing.
        The framework supports all consensus algorithms. Different algorithms can adopt different methods to propose blocks, and they can also use different ways to reach a consensus on blocks. When considering the block proposal, the biggest problem is who will propose the block. If anyone can propose blocks at any time, it will be difficult to reach a consensus, because it is similar to people talking to each other constantly. Delegates must be selected in some way so that the remaining people can see one proposal at a time. The most naive way is to let the agreement randomly select a person to propose a new block. However, on the Internet, a person can pretend to be a hundred people by running a hundred instances of the same program. Therefore, we need to create some form of scarcity to resist witch attacks.
        (note to blue fox: Witch attack mainly refers to the attack mode in which a few nodes in the network control multiple false identities and use these identities to control a large number of normal nodes in the network.). Therefore, this game must be able to resist the attack of a single hacker manipulating many people. This is what POW and POS bring to you: a way to make computers subject to certain resource constraints. (note to blue fox: that is to say, by setting thresholds, such as the computational power input of POW and the token input of POS, the problem of who is qualified to propose blocks and obtain rewards is solved in a competitive way.). POW is as follows: in order to obtain the rights of the proposed block, you must take the lead in completing the computing intensive tasks.
        Simulate a virtual computer coin tossing task until it gets the front of the virtual coin for 100 consecutive times. This is computationally intensive, and no one can pretend to be a hundred people, because it is subject to its computing power. However, by adopting this "anti witch attack" mechanism, people have established a mine composed of thousands of computers in order to win the competition in computing power and obtain the right of the proposed block. These server mines consume huge amounts of electricity, so they are concentrated in countries or regions where the cheapest electricity can be obtained. So what does this mean for decentralization when most bitcoin miners are in China? This geographical centralization poses a real threat to the permanence of the system, because these mining companies are easily regulated.
        POS adopts a different "anti witch attack" mechanism from pow. Since you have to spend money on bitcoin mining computers and electricity, why not just use money to select block producers and skip the computing intensive process? The idea of POS is to choose block proponents based on the amount of money people pledge in the system, that is, the proportion of tokens people own in the system. In pow, the more computing power you have, the higher the probability of being selected as the next proposed block. In POS, the more tokens you have, the higher the probability of becoming a block producer. Please note that we haven't started talking about how to reach a consensus on the block.
        There is a common misconception that POW and POS are consensus algorithms. In fact, they are not. They only choose block producers by restricting scarce resources. This is where things have become interesting and where most innovations have taken place in recent years. Once someone proposes a block, how can we reach a consensus? This is a problem that computer scientists have been trying to solve since the 1980s, so that when some computers occasionally crash, their computer clusters can also be synchronized. In the 1990s, these computer scientists began to think about a more difficult problem: what if hackers could control some of these computers? (note to blue fox: the difference between these two problems is that one is that the computer partially crashed, and the other is that the computer did not crash and was maliciously controlled.
        )。 Can they build systems that are robust enough to ensure that all non malicious computers can still reach a consensus? This feature is called Byzantine fault tolerance (BFT), which is based on the Byzantine general problem. BFT system is a relatively small research topic, because most systems do not need this level of robustness, because most computer clusters usually belong to a single company. It was not until the arrival of blockchain that this situation was changed. In blockchain, anyone can run nodes (computers in the cluster) and send information or data to other nodes. This is a truly adversarial environment, because malicious actors can pretend to be honest nodes.
        For example, what if 10 malicious computers in the cluster send conflict information to the other 9 computers?. Since honest computers cannot distinguish between malicious and non malicious computers, this problem becomes very thorny. There are two main ways to solve this problem: Nakamoto consensus and classic consensus. Nakamoto Cong consensus is used in bitcoin and most POW systems, which was initiated by Nakamoto Cong. It has a single rule: "when you see that the proposed block has the most workload proof, accept it." Generally speaking, the block with the highest number has the most workload proof. (note to blue fox: that is, the longest chain rule of bitcoin. This is a probabilistic confirmation. The longer the confirmed block depth is, the harder it is to reverse the transaction.
        )。 This means that you are never 100% sure whether the block you see 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 different blocks at block number 100. According to the consensus rule, you need to "reverse" the previously accepted block a and accept the new block history instead. In this system, attackers who exceed 50% of the computing power of the system will be able to continuously build the longest chain, so they can create any block they want. Through this example, we can see that these rules help people reach an agreement on which chain is acceptable.
        Before the invention of Nakamoto consensus in 2009, computer scientists had different solutions to this problem, which had different characteristics. The first Byzantine fault-tolerant consensus algorithm is called practical Byzantine fault-tolerant algorithm (pbft). Its working principle is: let a group of participants conduct multiple rounds of voting until a certain proportion of voters reach a consensus. Based on mechanisms such as POS, select someone to propose a block. He sends the block to other known participants. Voting by other participants. Since most participants vote for the block, everyone in the system will accept the block as the correct block. Using this type of consensus requires a group of known voters, but once they vote, the block has finality.
        Therefore, there is no block rollback. If there is a dispute, the system will stop. (note to Lanhu: the final certainty of the classical consensus is in sharp contrast to the probability of the Nakamoto consensus.). Pbft algorithm has been used in blockchain. So far, the most prominent BFT algorithm in blockchain is tendermintcore. Tendermintcore is the first consensus algorithm on the blockchain that does not use Nakamoto consensus, but is based on more than 20 years of computer science research. The main limitation of BFT algorithms 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 100000 people to constantly communicate with others to reach a consensus. So far, cosmos has run one of the largest public BFT systems, and its gameofstakes test network has more than 200 verifiers. (note to blue fox: the verifier of harmony has exceeded 200+.). There are other variants of Nakamoto consensus, such as ghost (the new scoring algorithm, not only the longest chain), and there are also other variants of BFT consensus, such as Casper BFT and thunderella. The main difference between these consensus algorithm variants is actually the difference in the way their blocks are proposed or the number of communicators participating in the consensus.
        In most cases, there are similar tradeoffs between them in a family of algorithms. There are also some new forms of consensus, such as avalanche, which do not belong to any series. According to the type of application you want to build, the following is a guide to choose a consensus algorithm, which will also involve choosing a smart contract platform. For some applications, finality is very important, while for others, it is not so important. If you build a new payment system for micro payment, transactions can be reversed, not the end of the world. Similarly, if you are building a decentralized social network, it is not a particularly important feature to ensure that 100% status updates are completed immediately.
        On the contrary, if you build a decentralized exchange, finality is a crucial part of the user experience. It's worse to reverse a deal than not to do it. As a reference, the finality of bitcoin is about 1 hour (note to blue fox: the completion of six blocks of bitcoin can basically confirm the completion of the transaction, but this is not 100% finality, but after the confirmation of six blocks, it is very difficult to reverse the transaction.) The finality of Ethereum is about 6 minutes, while the finality of tendermintcore is 1 second. If you build 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 Ethereum blockchain is poor because its throughput is too low.
        However, an application for transferring the ownership of a house certificate may be very suitable for running on Ethereum. Using cosmossdk to build applications allows developers to use ready-made tendermintcore, which has shorter block time and high throughput, and can reach up to 10000 transactions per second. You can achieve this by setting fewer authenticators for your application, because it can reduce communication overhead and improve application processing speed. Some applications, such as games, may not need significant anti censorship features, which is just a by-product of decentralization. In theory, verifiers can create cartels and realize block / reverse transactions in games to make profits. Are these really important in applications? If it is not so important, a blockchain similar to EOS may be suitable for your application scenario, because it has faster transaction speed 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 Ethereum ore pools is also an important embodiment of the trend of centrization. In fact, it has only 11 verifiers (ore pools). One advantage of building your own blockchain rather than building applications based on other smart contract platforms is that you can customize the verification method for your own applications. However, it is very difficult to build your own blockchain. Therefore, in this regard, using cosmossdk is very useful. You can easily build your own blockchain and customize the degree of decentralization required by the application.
        If you build a decentralized shared riding application, ensuring that the service operates around the clock may be the highest priority, even if there are some accidental errors, such as the reversal of transactions. One attribute of tendermintcore is that if there are differences between network verifiers, the network will choose to stop rather than conduct incorrect transactions. Some applications, such as decentralized exchange applications, need to ensure correctness at all costs. If there are problems, the decentralized trading can be suspended instead of reversible trading. There is no single "best" consensus algorithm. Each algorithm has its own trade-offs.
        However, understanding the consensus process (proposing and reaching consensus) and establishing a framework to think about what consensus algorithm your application may need can help you make more informed decisions when choosing blockchain. Of course, there are other factors to consider, such as developer tools, community, etc. Generally speaking, POW and POS are not consensus algorithms. They are "anti witch attack" mechanisms that can help select areas
Previous:Shanghai insurance exchange blockchain underlying technology platform and technical white paper were officially released
Next:No more

Related articles:

© 2005-2032 | Blockchain Circle & & All Rights Reserved    Sitemap1 Sitemap2 If there is infringement, please contact us at: