Understanding Consensus Mechanism and 11 Popular Consensus Algorithms in One Article

Understanding Consensus Mechanism and 11 Algorithms in One Article

This article is a note from the third class of DeSchool’s web3 university tutorial, taught by Uchiha Madara. The content is very dry and straightforward, so it is recommended that you bookmark it and digest it slowly. In addition, for ease of understanding, this article has been modified and supplemented based on the course content.

The main content of the article includes:

1. Introduction to consensus algorithms

2. Classification of consensus algorithms

• Summary of the 162nd Ethereum Execution Layer core developer meeting: The reasonable target time for the Cancun upgrade is October.
• Explaining Futures Contracts in Contango: Low and Predictable Costs
• How has Sui mainnet performed after being online for 3 weeks? A article interpreting its data and community sentiment.

3. Detailed explanation of consensus algorithms (PoW, PoS, PoH, PoA, PBFT, etc.)

Introduction to Consensus Mechanisms

In the communication and learning of blockchain, “consensus algorithm” is a frequently mentioned term, because it is the existence of consensus algorithms that guarantees the credibility of the blockchain.

1. Why is a consensus mechanism needed?

The so-called consensus means reaching a consensus among multiple people. Our lives are full of consensus mechanisms, such as a company needs to make decisions after consulting with shareholders, and signing a contract requires the parties to sit down and negotiate. This process is the process of reaching a consensus.

In the blockchain system, what each node must do is to make its own ledger consistent with the ledgers of other nodes. If it is in a traditional centralized scenario, this is almost not a problem, because there is a central server, that is, the so-called master database, and other slaves follow the master database.

However, in decentralized management, there is no boss, so how to make a decision? At this time, a set of algorithms is needed to ensure consensus. This is what this article is talking about-consensus mechanisms.

2. What is a consensus mechanism?

The consensus mechanism is to verify and confirm transactions through the voting of special nodes in a very short time; for a transaction, if several nodes that are not related to the interests can reach a consensus, we can think that the entire network can reach a consensus on this.

Although consensus and consistency are considered approximately equivalent in many application scenarios, the two have subtle differences: consensus research focuses on the process and algorithm of distributed nodes reaching consensus, while consistency research focuses on the stable state reached by the node consensus process; In addition, most traditional distributed consistency research does not consider the Byzantine fault tolerance problem, that is, it is assumed that there are no Byzantine nodes that maliciously tamper with and forge data. After all, in a completely open and transparent blockchain network, it is impossible to guarantee that all nodes will not do evil.

3. What problems can consensus mechanism solve?

The consensus mechanism can solve the trust problem in distributed systems, ensuring data consistency and security between nodes. In traditional distributed systems, because there is no trust mechanism between nodes, it is vulnerable to attacks and tampering by malicious nodes, leading to system crashes or data tampering. In addition, before the emergence of blockchain encryption technology, like other assets, encrypted digital currencies had unlimited replicability. Without a centralized intermediary, people had no way of confirming whether a digital cash transaction had been spent.

In short, the consensus mechanism can effectively solve two problems: double-spending problem and Byzantine generals problem (malicious nodes tampering with data).

4. Double Spend Problem (Double spend attack)

The consensus mechanism can solve the double-spending problem (double spend attack) to a certain extent: that is, when a sum of money is spent twice or more, also known as “double payment”. In the cat-and-mouse game, Xiao Li committed double-spending behavior by making a fake check. Because verifying the check takes time, he used the information of the same check to buy goods multiple times within this time difference.

As we all know, blockchain nodes always regard the longest chain as the correct chain and continue to work and extend it. If two nodes simultaneously broadcast different versions of new blocks, they will work based on the first block they receive, but they will also keep another chain in case it becomes the longest chain. When the next proof of work is discovered, one of the chains is confirmed to be the longer one, and the nodes working on the other branch chain will switch sides.

How is double-spending implemented? There are two situations:

(1) Double spending before confirmation. Unconfirmed transactions may not be written to the blockchain at all. Unless the amount is small, it is best to wait for confirmation to avoid this kind of double spending.

(2) Double spending after confirmation. This requires controlling more than 50% of the computing power to implement. It is like a small fork, putting the transaction to the store in an isolated block. This kind of double-spending after confirmation is difficult to implement and is only theoretically feasible.

The three most common double-spend attacks are:

• 51% attack: A 51% attack refers to an individual or group gaining control of 51% of the hashing power of a blockchain. This means they have the ability to control certain aspects of the project. On a Proof-of-Work blockchain like Bitcoin, this would be achieved by gaining control of the network’s mining power. On the other hand, for a Proof-of-Stake blockchain like Cardano, this would be achieved by controlling 51% of the staked tokens.
• Race attack: A user simultaneously sends two transactions to two merchants (or to a merchant and themselves). The attacker receives two sets of goods or receives the goods and recovers the original transaction cost.
• Finney attack: A miner mines a block (or a series of blocks) that contains a transaction where they send money to one of their own addresses. The mined block(s) are not broadcast, but instead held by the miner. The merchant then releases the goods paid for by the miner before the miner broadcasts the blocks they have mined. The miner then broadcasts the mined blocks, which will overwrite the transaction that was sent to the merchant, leaving the merchant out of pocket.

Classic case of double-spending:

In 2018, an attacker gained control of over 51% of the hashing power on the BTG network. While in control, the attacker sent a certain amount of BTG to their wallet on an exchange, calling this branch A. At the same time, they sent the same BTG to another wallet they controlled, calling this branch B. Once the transactions on branch A were confirmed, the attacker immediately sold the BTG for cash. The attacker then mined on branch B and, due to controlling over 51% of the hashing power, the length of branch B quickly surpassed that of branch A, making branch B the main chain and rolling back the transactions on branch A to the previous state. The BTG the attacker had previously sold for cash was now back in their hands, and the exchange was left out of pocket. Thus, the attacker was able to achieve a double-spend on the same cryptocurrency with over 50% hashing power control.

5. Byzantine failures

The Byzantine Generals Problem is a hypothetical problem posed by Leslie Lamport in the 1980s. Byzantium was the capital of the Eastern Roman Empire, and because the empire was vast, the garrisons of each army were separated by great distances, and the generals had to rely on messengers to communicate. When war broke out, the generals had to formulate a unified action plan.

However, there were traitors among these generals, and they hoped to disrupt the loyal generals’ unified action plan by influencing the formulation and dissemination of the plan. Therefore, the generals must have a predetermined method agreement to enable all loyal generals to reach a consensus. Moreover, a few traitors cannot make loyal generals make the wrong plan. That is to say, the essence of the Byzantine Generals Problem is to find a method to enable the generals to establish a consensus on the battle plan in a non-trusted environment with traitors.

In distributed systems, especially in the blockchain network environment, which is similar to the environment of the Byzantine generals, there are normally running servers (similar to loyal Byzantine generals) and faulty servers, as well as servers that are attackers (similar to rebellious Byzantine generals). The core of the consensus algorithm is to form a consensus on the network state among normal nodes. If there are only three nodes, the Byzantine Generals Problem is unsolvable. When there are x problem nodes in the nodes and the total number of nodes is less than 3x+1, the Byzantine Generals Problem is unsolvable.

The emergence of Bitcoin easily solved this problem. It added costs to information transmission, reduced the rate of information transmission, and added a random element so that only one general could broadcast information in a certain period of time. The first general to broadcast information is the first computer to find a valid hash value. As long as the other generals receive and verify the valid hash value and the attached information, they can only use the new information to update their ledger replication, and then recalculate the hash value. The next general to calculate a valid hash value can attach his updated information to the valid hash value and broadcast it to everyone. Then, the hash calculation competition starts again from a new starting point. Due to the continuous synchronization of network information, all computers on the network are using the same version of the ledger.

Classification of consensus algorithms

1. History of consensus mechanisms

When computers and networks became popular in the 1980s and 1990s, shared databases emerged so that multiple users could access the information they stored. Most had a central database that users could access from different sites. This setup evolved into centralized networks, where administrators granted user permissions and maintained data integrity.

These shared databases are called distributed ledgers because they record information and are interconnected for access by many users in different locations. One of the most important problems to solve is preventing data tampering and unauthorized access, whether malicious or not. An automated method for managing distributed databases was needed to ensure data was not altered.

This need led to the development of distributed autonomous consensus, where programs on the network use encryption technology to achieve consensus on the state of the database. The protocol is designed to be achieved by creating a long string of alphanumeric numbers (hashes) using encryption algorithms, which are then verified by programs running on the network. Hashes are designed to change only when the information inputted to the encryption algorithm changes, so the programs are designed to compare hashes to ensure they match.

When each program running on the network has created a matching hash string, it can be said that the data has achieved consensus on the network. Thus, a consensus mechanism was established, often credited to anonymous Bitcoin creator Satoshi Nakamoto. However, many people had been working on consensus mechanisms for years before Nakamoto published the white paper that made Bitcoin famous.

Data and computer scientists like Moni Naor, Cynthia Dwork, Adam Beck, Nick Szabo, and many others worked to develop network consensus mechanisms and made contributions.

2. Classification of consensus algorithms

Depending on the type of fault tolerance, consensus algorithms can be divided into two categories: CFT type consensus algorithms (non-Byzantine fault tolerance, i.e. not considering malicious nodes) and BFT type consensus algorithms (Byzantine fault tolerance, i.e. considering malicious nodes).

Whether it tolerates Byzantine faults marks whether the algorithm can be applied to low-trust networks. Generally, Byzantine fault-tolerant algorithms must be used in public chain environments, while CFT-type algorithms (non-Byzantine fault tolerance) can be used in consortium chains depending on the level of trust between the consortium participants.

Furthermore, it can be divided into two categories based on consistency: probabilistic consistency algorithms and absolute consistency algorithms. Probabilistic consistency algorithms refer to algorithms that have a high probability of ensuring data consistency between different distributed nodes, but there is still a certain probability that some nodes’ data will not be consistent. For example, Proof of Work (PoW), Proof of Stake (PoS), and Delegated Proof of Stake (DPoS) all belong to probabilistic consistency algorithms.

Absolute consistency algorithms refer to algorithms that ensure that the data between different distributed nodes will remain absolutely consistent at any time, and there is no situation where data between different nodes is inconsistent. For example, the BlockingXOS algorithm and its derivative RAFT algorithm.

The following is a specific division and introduction based on the fault-tolerance type.

3. CFT Consensus Algorithm

Crash Fault Tolerance: suitable for networks with high node trust. Includes Blockingxos and Raft.

4. BFT Consensus Algorithm

Checking whether nodes have malicious Byzantine fault tolerance tendencies tends to be decentralized, including Proof of Work (PoW), Proof of Stake (PoS), Delegated Proof of Stake (DPoS), Proof of Authority (PoA), etc.

Explanation of Consensus Algorithms

If you’re getting tired at this point, bookmark this page, take a break, and come back later to tackle the hardest part of this article! Students with limited time can skip directly to the third PoW algorithm.

1. Blockingxos Algorithm

• Algorithm Introduction: In 1990, the Blockingxos algorithm was proposed by the master Lamport as a message-passing distributed consistency algorithm and won the Turing Award in 2013. Since its inception, the Blockingxos algorithm has continued to dominate distributed consistency algorithms, mainly addressing how to reach consensus on a specific value in distributed systems. The consensus process of the Blockingxos algorithm is for the Proposer to propose a proposal to win the support of the majority of Acceptors. When a proposal receives support from more than half of the nodes, it sends the closing result to all nodes for confirmation. In this process, if the Proposer fails, it can be resolved by triggering a timeout mechanism. If the Proposer fails every time a new round of proposals is made, the system will never reach consensus. However, the probability of this happening is extremely small.

Early versions of the Basic Blockingxos protocol were complex and relatively inefficient, so later versions were proposed, such as Fast Blockingxos, Multi-Blockingxos, and Byzantine Blockingxos.

• Use case: ZooKeeper

• Algorithm principle: The Blockingxos algorithm runs in an asynchronous system that allows for crash faults, does not require reliable message delivery, and can tolerate message loss, delay, disorder, and duplication. It uses the majority mechanism to ensure a fault-tolerant capacity of 2f+1, which allows for f nodes to fail simultaneously in a system of 2f+1 nodes. As long as there are fewer than (n-1)/2 failures, Blockingxos achieves consensus. These failures cannot be Byzantine, otherwise BFT proof will be violated. Therefore, the premise of this algorithm is to assume that messages will never be destroyed and nodes will not collude to destroy the system.

Blockingxos proceeds through a set of negotiation rounds, in which one node has a “leader” status. If the leader is offline, progress will stall until a new leader is elected or the old leader suddenly comes back online.

Blockingxos divides the roles in the system into proposers, acceptors, and final decision learners: Proposer: Proposes a proposal (Proposal). Proposal information includes proposal number (Proposal ID) and proposed value (Value). Acceptor: Participates in decision-making and responds to Proposers’ proposals. After receiving a Proposal, the Acceptor can accept the proposal. If the Proposal is accepted by the majority of Acceptors, it is considered approved. Learner: Does not participate in decision-making, but learns the latest proposal (Value) that has been agreed upon by Proposers/Acceptors.

2. Raft Algorithm

Algorithm overview: The Raft (Replication and Fault Tolerant) algorithm is a simplified implementation of the Blockingxos algorithm, and the name Raft comes from the first letter abbreviation of “Reliable, Replicated, Redundant, And Fault-Tolerant”. Raft simplifies Blockingxos algorithm a lot by using log continuity. It guarantees the consistency of a system in which more than half of the n nodes are working normally. Unlike the Blockingxos algorithm, which directly derives the distributed consistency problem, the Raft algorithm is proposed from the perspective of a multi-replica state machine and is used to manage log replication of multi-replica state machines. For example, in a system of 5 nodes, 2 non-Byzantine errors are allowed, such as node crashes, network partitions, and message delays.

Use case: Database master-slave replication, consortium chain.

Algorithm principle: In the Raft system, there are three roles: leader, follower, and candidate. In normal situations, there is only one leader and the others are followers. The leader is responsible for all external requests, and if a non-leader machine receives a request, it will be redirected to the leader. Usually, the leader sends messages at fixed intervals, called heartbeats, to let followers know that the cluster leader is still working. Each follower has a timeout mechanism, and if no heartbeat is received for a certain period of time (usually 150ms or 300ms), the system enters an election state.

At this time, the cluster enters a new election term and starts the election. If the election is successful, the new leader starts to perform work, otherwise the term is terminated and a new term begins and the next election is started.

The election is initiated by the candidate. When the leader’s heartbeat stops, the candidate needs to nominate himself in a first-come, first-served manner and campaign for votes from other servers. Each server can vote only once per term to indicate support or opposition to the current candidate. If no candidate gets more than half of the votes, the next round of elections will begin. The remaining candidates continue to nominate themselves based on a first-come, first-served basis until a leader is elected.

The advantages of the Raft algorithm: The first point is simplicity. If we delve into where Blockingxos is more complex than Raft, Heidi Howard and Richard Mortier found that Blockingxos’ complexity is reflected in two aspects. First, Raft submits logs in order, while Blockingxos allows logs to be submitted out of order, but an additional protocol is required to fill in potential log holes. Second, all logs in Raft have the same index, term, and command, while in Blockingxos these terms may differ.

The second point is that Raft has an efficient leader election algorithm. The election algorithm given in the Blockingxos paper is to compare the server IDs, and when several nodes compete at the same time, the node with the larger server ID wins. The problem is that if the elected leader is missing some logs, it cannot immediately perform write operations and must first copy some logs from other nodes. Raft can always select a node with a majority of logs, so it does not need to catch up on logs. Although sometimes elections may be retried due to vote splitting, overall it is a more efficient election algorithm.

For the Blockingxos algorithm, if a server is very behind, even a few days behind in logs, but it is selected as a leader at some point, this will cause a certain amount of blocking time. In the Raft algorithm, a node with outdated logs will never be elected.

3. Proof of Work (PoW)

Algorithm Overview: A computer technology originally used to combat spam. In 2008, Satoshi Nakamoto proposed Bitcoin and blockchain in the Bitcoin white paper, and innovatively designed the PoW algorithm. It is applied to Bitcoin to solve a mathematical problem for consensus. The core content of the algorithm is to use computing power to find a nonce value that satisfies the block hash. However, people soon discovered the problem with this consensus mechanism, namely high energy consumption and the problem of centralization even after the computing power is controlled by large mining pools.

Use case: Bitcoin, ETH1.0, Litecoin, Conflux, Dogecoin.

Algorithm principle: The main feature of the proof of work system is that the client needs to do some difficult work to get a result, but the verifier can easily check whether the client has done the corresponding work. One core feature of this approach is asymmetry: the work is moderate for the requester and easy to verify for the verifier. It is different from captchas, whose design goal is to be easily solved by humans rather than computers.

The proof of work (PoW) calculates a numeric nonce to satisfy the upper limit of the hash value of the concatenated transaction data after successful calculation. After a node finds a hash value that satisfies the requirement, it immediately broadcasts the packaged block to the entire network. When a node receives a broadcast package block, it immediately verifies it.

Disadvantages: Slow; huge energy consumption, not good for the environment; susceptible to the impact of “economies of scale”.

Advantages: Has been extensively tested since 2009 and is still widely used today.

4. Proof of Stake (PoS)

Algorithm Introduction: Quantum proposed PoS in Bitcointalk forum in 2011. In August 2012, the first blockchain project based on PoS consensus, Peercoin, was born. Peercoin was the first application to implement the PoS algorithm. In Peercoin, the “equity” is the coin age, which is the product of the number of coins held by a node and the time it has been held. Initiating a transaction consumes a certain amount of coin age, and every 365 coin age consumed earns an annual interest rate of 5%.

Users: Ethereum (2.0), Conflux, Peercoin.

Algorithm Principle: For example, if someone holds 100 Peercoins in a transaction and has held them for 30 days, then the coin age is 3000. If a PoS block is found later, the coin age is cleared to 0, and the interest earned is 0.05*3000/365=0.41 Peercoins. In the consensus process, nodes gain the right to keep accounts by consuming coin age. The more coin age a node consumes, the greater the chance of gaining the right to keep accounts. The main chain principle set by the algorithm is that the chain with the most consumed coin age is the correct and effective chain in the system.

Advantages: No need for powerful and expensive mining equipment. Reduces resource consumption and reduces the possibility of a 51% attack.

Disadvantages: May lead to the hoarding of cryptocurrency by the wealthy, leading to the Matthew effect and possible cryptocurrency inflation.

5. Proof of History (PoH)

Algorithm Introduction: Proof of History was created by Solana, a high-throughput blockchain launched in 2018. PoH enables network participants to reach consensus on time by using a verifiable delay function, avoiding the “longest chain” rule.

PoH is the network’s clock, while TowerBFT is its watchtower, whose task is to prevent malicious nodes from deceiving the time parameter. Any validator who votes for a certain block must wait for the next block to be generated and obtain confirmation from PoH that “time has passed” from the history proof before voting again.

Solana cleverly separates the hash-based time chain from the state instead of linking the hash of each block together. Validators in the network hash the hash in the block itself, which is the mechanism of PoH. PoH establishes a verifiable event sequence over time by using a high-frequency verifiable delay function (VDF). Essentially, this means that PoH acts like an encrypted clock that helps the network reach consensus on time and event sequence without waiting for messages from other nodes. The continuous output of the blockchain state hash in the history proof can give a verifiable event sequence.

User: Solana

Algorithm Principle: Leader generates a timestamp for each signature data (transaction to be proven), directly sorts the transactions, thus avoiding the problem of time sorting in PoS. Each guarantee validator can independently verify, greatly shortening the problem of verification time reordering, only the verification of transaction proof is required.

Advantages : low cost, the cost of each transaction is only a few cents, fast transaction speed, good scalability,

Disadvantages: concerns about centralization, Solana currently has less than 1,200 validators to verify transactions on its network. Fewer decentralized applications: often referred to as the Ethereum killer. According to its website, over 350 Dapps have been created on Solana, compared to nearly 3,000 on Ethereum, which is exactly where Defi currently needs more development time and innovation.

6. Proof of Authority (PoA)

Algorithm Introduction: proposed by Gavin Wood, co-founder of Ethereum (ETH) and Blockingrity Technologies in 2017. The PoA mechanism does not require mining or tokens. In the PoA-based blockchain network, all transactions and blocks are processed by validators. PoA platform maintenance costs are low, but in PoA, transaction and blockchain validators must be people who can pass reliability audits. Therefore, the validator of PoA must pay great attention to its own reputation. Reputation is a very important asset in PoA. Generally, validators will publicly disclose their actual identity. At present, this consensus mechanism formed by blockchain technology is mainly used in consortium chains and private chains with obvious industry characteristics.

User: PoA, Ethereum Kovantestnet, xDai, VeChain, and Walmart’s logistics chain.

Algorithm Principle:

a. Choose an authority certifier;

b. Several validators generate block records of transactions and obtain block rewards and transaction fees. In PoA, validators are the key to the entire consensus mechanism. Validators obtain the right to guarantee the network by placing this identity and exchange block rewards. If the validator behaves maliciously during the entire process or colludes with other validators, the malicious actor can be removed and replaced through on-chain management. Existing legal anti-fraud guarantees will be used to protect participants in the entire network from malicious behavior by validators.

Pros:

a. Requires less computing power, no need for mining, energy-saving and eco-friendly;

b. Fast verification speed, supporting quicker transactions;

c. Validators in the network supervise each other and can vote to add or remove validators at any time;

d. Hard fork is legally protected, and each Validator signs a legal agreement.

Cons:

a. Open identity, privacy and anonymity will be reduced;

b. Validators are specific centralized authoritative nodes supported by the law.

7. Delayed Proof-of-Work (dPoW)

Algorithm introduction: To explain DPoW, we need to first explain what PoB is. PoB (Proof of Burn) is a mechanism for voting who holds the leadership position of the network by burning the tokens in their hands. The more tokens burned, the higher the probability of obtaining the leadership position of the network.

In the dPoW-based blockchain, miners no longer receive reward tokens for mining, but can receive “wood” that can be burned. Miners use their own computing power, hash algorithm, and finally prove their workload to obtain corresponding wood, which cannot be traded. When enough wood is accumulated, it can be burned at the burning site.

After a set of algorithms are calculated, the person or group of BP who burns more wood can obtain the right to produce blocks in the next event segment, and obtain rewards (Token) after successfully producing blocks. Since there may be multiple people burning wood in a time segment, the probability of producing blocks in the next time segment depends on the amount of wood burned by oneself. The more burned, the higher the probability of obtaining the right to produce blocks in the next time segment.

This can balance computing power and mining rights. It is not necessary for miners and mining pools with huge computing power to become block producers. Small miners also have a chance to produce blocks as long as they work hard and accumulate a certain amount of wood. Ensuring efficiency, everyone participates, and the most civilian participation method ensures the concept of decentralization and avoids organizations or coin holders with computing power controlling the network.

User: Komodo

Algorithm Principle: There are two types of nodes in the dPoW system: notary nodes and normal nodes. The 64 notary nodes are elected by stakeholders of the dPoW blockchain, and they can add confirmed blocks to the attached PoW blockchain from the dPoW blockchain. Once a block is added, its hash value is added to a Bitcoin transaction signed by 33 notary nodes, and a dPow block record is created that hashes to the Bitcoin blockchain and is notarized by the majority of notary nodes in the network.

To avoid a mining war between notary nodes and reduce network efficiency, Komodo has designed a mining method that uses a polling mechanism, which has two operating modes. In the “No Notary” mode, all network nodes can participate in mining, similar to the traditional PoW consensus mechanism. In the “Notaries Active” mode, network notaries use a significantly reduced network difficulty rate for mining. In this mode, each notary can mine a block with its current difficulty, while other notary nodes must mine with a difficulty rate 10 times higher, and all normal nodes must mine with a difficulty rate 100 times higher than the notary nodes.

Advantages: Energy-saving; increased security; can add value to other blockchains without directly providing Bitcoin (or any other secure chain) and without incurring the cost of a Bitcoin (or any other secure chain) transaction.

Disadvantages: Only blockchains using PoW or PoS can adopt this consensus algorithm; in “Notaries Active” mode, the hash rates of different nodes (notary or normal) must be calibrated, otherwise the difference in hash rates will explode.

8. PoS Authorization (DPoS, Delegated Proof-of-Stake)

Algorithm Introduction: The DPoS mechanism, also known as the “share authorization proof mechanism” and “delegated trustee mechanism,” was proposed by Dan Larimer (BM), the chief developer of Bitshares, in April 2014. From a certain perspective, DPOS is a bit like a parliamentary system or a people’s congress system. If representatives cannot perform their duties (when it is their turn and they fail to generate a block), they will be removed, and the network will elect new super nodes to replace them.

For the sake of convenience, let’s take another example. Imagine a company with a total of 1,000 employees, each of whom holds a different amount of company shares. Every so often, employees can cast their votes for the 10 people they believe should lead the company, with each employee’s voting power proportional to the number of shares they hold. After everyone has cast their votes, the 10 people with the highest vote percentages become the company’s leaders.

If a leader proves to be incompetent or does something detrimental to the company, employees can revoke their votes for that leader, preventing their vote percentage from being counted among the top 10 and effectively removing them from the management team.

Users: BitShares, Steemit, EOS, Lisk, Ark.

Advantages: Energy-efficient, fast, and high-traffic blogging site Steemit uses it. EOS has a block time of 0.5 seconds.

Disadvantages: Slightly centralized, and participants with higher stakes can vote to become validators (as seen recently in EOS).

9. Practical Byzantine Fault Tolerance (PBFT)

Algorithm Overview: In the PBFT algorithm, one node is designated as the primary node, while the others are backup nodes. All nodes in the system communicate with each other, with the ultimate goal of reaching consensus based on the principle of majority rule.

Consensus Process:

a. The client sends a request to the primary node to execute a certain operation

b. The primary node broadcasts the request to the backup nodes

c. All nodes execute the operation and return the result to the client

d. When the client receives f+1 identical results from different nodes, the process ends. f represents the maximum value of nodes that may lie.

Users: HyperLedgerFabric, Stellar, Ripple, DisBlockingtch

Advantages: High speed and scalability.

Disadvantages: Typically used for private and licensed networks.

10. Delegated Byzantine Fault Tolerance (dBFT)

Algorithm Overview: The NEO (formerly Antshares) blockchain community in China proposed an improved Byzantine fault tolerance algorithm called dBFT, which borrows from PoS design principles. First, the bookkeepers are selected according to their node rights, and then the bookkeepers reach consensus through a Byzantine fault tolerance algorithm. This algorithm improves on the lack of finality in PoW and PoS, making blockchain applicable to financial scenarios.

For the purpose of solving the Byzantine Generals’ Problem, “Byzantine Fault Tolerance with Authorization” mechanism is a consensus algorithm implemented within the NEO blockchain to ensure fault tolerance. There are two participants in this mechanism: a “bookkeeping node” that professionally keeps accounts and a regular user in the system.

Based on the proportion of holding rights, ordinary users vote to decide the bookkeeping node. When a consensus is needed, a speaker is randomly selected from these bookkeeping nodes to formulate a plan. Then, other bookkeeping nodes vote according to the Byzantine fault tolerance algorithm, i.e. the principle of minority following majority. If more than 66% of the nodes agree with the speaker’s plan, the consensus is reached; otherwise, a new speaker is selected and the voting process is repeated.

Since all representatives can verify block proposals, it is easy to understand whether the data sent by the speaker is valid or invalid. Therefore, if the speaker is dishonest and sends invalid proposals to two-thirds of the representatives, the block will not match and the node owner will not validate it. Consensus is reached with a two-thirds majority vote, and a new speaker is selected.

User: Neo

Consensus process:

a. Anyone can become a representative as long as they meet the requirements. All NEO token holders can vote, representatives are not anonymous, and becoming a node owner requires 1,000 GAS.

b. A speaker is randomly selected from the representatives.

c. The speaker constructs a new block from the transactions waiting to be verified. Then, the speaker sends the proposal to the elected representatives. They should track all transactions and record them on the network.

d. Representatives can freely share and compare the proposals they receive to test the accuracy of the data and the honesty of the speaker. If more than two-thirds of the representatives reach consensus and validate, the block is added to the blockchain.

Advantages: Fast (generating a block takes 15-20 seconds); high transaction throughput, no energy consumption required, scalable, no fork.

Disadvantages: No anonymity, requires real identity operation to be elected. Everyone competes to become the root chain. There may be multiple root chains.

11. Rotation Practical Byzantine Fault Tolerance (RPBFT)

Algorithm introduction: The principles of dBft and RPBFT are similar to PBFT, but not all nodes participate in consensus. Instead, nodes are divided into two types:

a. Consensus Node: a node that executes the PBFT consensus process and has the right to take turns to generate blocks

b. Verification Node: a node that does not execute the consensus process, verifies the legitimacy of the consensus node and the validity of blocks, and will switch to a consensus node after several rounds of consensus

Byzantine fault tolerance is used to alternate consensus nodes with verification nodes.

Use Case: Fisco-BCOS

Advantages: faster propagation speed than gossip, no redundant message packets

Divide and conquer, each node has a bandwidth of O(1), and strong scalability

Disadvantages: middle nodes are single points and require additional fault tolerance strategies

12. AptosBFT

Algorithm Overview: Aptos is a consensus algorithm named after the name. It is a derivative of PBFT and based on HotStuff, which is based on PBFT. This algorithm model is like onions and Russian nesting dolls, which need to be peeled layer by layer. Each node communicates only with the leader, not with the leader and all other “generals.” The leader broadcasts the message to be voted on (proposed block); each node sends its vote to the leader who collects the message.

Use Case: Aptos

Finally, here is a summary of this section:

In addition, there are some uncommon consensus algorithms.

In 2015, David Mazieres, Chief Scientist of Stellar.org, proposed the Stellar Consensus Protocol (SCP). SCP evolved from the federal Byzantine agreement and Ripple protocols. It is the first provably secure consensus mechanism with four key attributes: distributed control, low latency, flexible trust, and asymptotic security.

Also in the same year, the Sawtooth Lake project of Hyperledger combined the Ripple and SCP consensus to propose the Quorum Voting consensus algorithm to deal with applications that require instant transaction finality.

In 2016, Turing Award winner and MIT professor Silvio Micali proposed a fast Byzantine fault-tolerant consensus algorithm called AlgoRand. The algorithm uses cryptographic drawing technology to select validators and leaders for the consensus process, and reaches consensus on new blocks through the BA* Byzantine fault-tolerant protocol designed by him. AlgoRand requires very little computation and has very few forks, and is considered a truly democratic and efficient distributed ledger consensus technology.

In 2017, Cornell University proposed a new algorithm called Sleepy Consensus to address the practical situation in which a majority of consensus nodes in a large-scale network may be offline, leaving only a few nodes participating in the consensus process. The research showed that traditional consensus algorithms cannot guarantee consensus security in such an environment. However, with the Sleepy Consensus algorithm, as long as the number of online honest nodes exceeds the number of faulty nodes, security and robustness can be guaranteed.

Summary

If we take a more political and economic approach and think outside of the developer perspective, perhaps more consensus algorithms will emerge, such as consensus methods that incorporate the PPP concept. Not only can it achieve punitive properties for malicious actors, but it can also achieve the goal of maximizing efficiency and saving computing power.

In summary, the consensus mechanism is the core of blockchain technology, which can solve the trust problem in distributed systems, ensure data consistency and security among nodes, avoid attacks and tampering by malicious nodes, and ensure the stability and credibility of the blockchain system. At the same time, the consensus mechanism can also solve the “double-spend” problem and improve the throughput and processing speed of the blockchain system. However, various consensus algorithms are not absolutely safe, efficient, and decentralized.

There is no best algorithm, only the most suitable algorithm. The choice and application of consensus algorithms are highly related to the application scenario. Blockingxos or RAFT can be used in a trusted environment, PBFT can be used in permissioned consortium chains, and PoW, PoS, Ripple consensus, etc. can be used in non-permissioned chains. The best consensus mechanism is always the mechanism that suits the user’s needs.

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