One of the biggest innovations about bitcoin was the way it solved the problem of consensus. Satoshi Nakamoto famously solved the Byzantine Generals Problem, eventually creating the bitcoin blockchain we know today.
What does any of this mean? Why do cryptocurrencies need to achieve consensus? What exactly is consensus in the first place? Today, we’re explaining everything you need to know about cryptocurrency consensus algorithms and how they work.
What Is Cryptocurrency Consensus?
Consensus, generally speaking, is an agreement between multiple parties.
In the case of cryptocurrencies like Bitcoin, consensus refers to an agreement about the status of the cryptocurrency network – like a recent transaction or block.
Bitcoin nodes, for example, achieve consensus by verifying proofs of work. When bitcoin nodes achieve consensus, it allows the entire bitcoin blockchain to continue moving forward. After nodes achieve consensus, a block can be added to the bitcoin blockchain and another block of transactions can begin being processed.
Without consensus, cryptocurrency networks would not be able to agree on anything. The bitcoin network would not be able to process transactions. Crypto networks would not be able to agree on a uniform set of rules. Consensus is what provides stability in the crypto industry.
Why Is It So Hard to Create Consensus In Cryptocurrencies?
Why do we have different consensus systems? Well, the problem relates to decentralized networks in the crypto industry.
In the traditional financial system, we didn’t need to create consensus across a network of different people. Instead, we relied on banks to “provide” consensus. Your bank tells you when you have $1000 in your bank account, for example. When you buy something with your debit card, your bank achieves consensus when it singlehandedly confirms you have money in your account, then debits that amount from your balance.
With cryptocurrencies like bitcoin, there’s no centralized entity in control of the network. We can’t turn to a centralized entity – like a bank – to provide consensus.
Instead, crypto networks need to create consensus from a network of different individuals. This decentralized network powers bitcoin – and the network needs to all agree, or come to a consensus, about the rules of the network and the transactions being processed.
Prior to bitcoin, nobody had been able to securely create consensus across a group of decentralized, trustless nodes. Bitcoin was the first to create this consensus. Satoshi Nakamoto achieved consensus by solving the Byzantine Generals Problem.
What Is The Byzantine Generals Problem?
The Byzantine Generals Problem is a logical problem first introduced in a 1982 paper titled, appropriately enough, “The Byzantine Generals’ Problem.” In that paper, authors Leslie Lamport, Robert Shostak, and Marshall Pease discussed the problem of creating consensus within a distributed, electronic system. To explain the issue, the authors relied on a medieval metaphor.
Here’s the basic idea behind the Byzantine Generals Problem:
A group of generals from the Byzantine Empire are besieging a city. Each general commands a division of the Byzantine army. Each general is besieging the city from a different side. The generals can communicate with one another exclusively by messenger.
No general can attack and capture the city on his own. Instead, the generals need to attack simultaneously in order to take the city. When one general makes the decision to attack, it’s crucial that all other generals attack simultaneously.
Compounding the problem further is that the enemy city has sent spies among the besieging camp. These spies spread false messages between the generals. There are also traitorous generals within the Byzantine army that wish to prevent the loyal generals from reaching an agreement.
To solve the Byzantine Generals Problem, we need to create a solution where:
- All loyal generals decide upon the same plan of action and attack at the same time
- A small number of traitors (including spies and disloyal generals) are prevented from influencing the loyal generals to adopt an unreasonable plan of action
The problem, at first glance, might seem simple. However, simple algebra shows that it’s far from simple. Algebra tells us that we need at least 3n+1 loyal generals to cope with n traitors. In other words, we can only solve the Byzantine Generals Problem if two thirds of the generals are loyal. Otherwise, a single traitor can still sabotage the attempts of two loyal generals.
The best way to solve the Byzantine Generals Problem is by using a consensus algorithm. Different cryptocurrencies use different consensus algorithms to solve this problem.
Solving Byzantine Generals Problem Using Consensus Algorithms
The Byzantine Generals Problem can be solved using consensus algorithms. This is a consensus problem – and we need a consensus algorithm to solve that problem.
Ethereum co-founder Vitalik Buterin provided a great explanation of the value of consensus algorithms back in 2014 prior to the launch of Ethereum:
“The purpose of a consensus algorithm, in general, is to allow for the secure updating of a state according to some specific state transition rules, where the right to perform the state transitions is distributed among some economic set. An economic set is a set of users which can be given the right to collectively perform transitions via some algorithm, and the important property that the economic set used for consensus needs to have is that it must be securely decentralized – meaning that no single actor, or colluding set of actors, can take up the majority of the set, even if the actor has a fairly large amount of capital and financial incentive.”
In more straightforward terms, the goal of a consensus algorithm is to boost system reliability by achieving agreement on a single data value between a number of agents or processes. A consensus algorithm is designed to get a bunch of different people with different goals to agree on a specific fact – even when some of the agents are acting in a faulty, unreliable, or even malicious way.
This is where the “fault-tolerant” component of a consensus algorithm comes into play. A consensus algorithm is fault tolerant when it can tolerate faults within the system. In other words, even when multiple agents within the network are specifically trying to spread instability, the consensus algorithm can tolerate these faults and achieve consensus successfully.
Ultimately, consensus algorithms are a requirement for maintaining a consistent, secure, and reliable distributed network. Next, we’ll look at the ways in which different cryptocurrencies tried to solve the Byzantine Generals Problem using their own consensus algorithms.
Proof of Work (PoW)
Bitcoin uses a proof of work (PoW) consensus algorithm. This was the original consensus algorithm that solved the Byzantine Generals Problem mentioned above.
Some people incorrectly attribute PoW consensus algorithms to Satoshi Nakamoto and the bitcoin project. In reality, however, proof of work systems date all the way back to 1993 when proof of work was invented by Cynthia Dwork and Moni Naor. We didn’t see the term “proof of work” first appear online, however, until a 1999 paper written by Markus Jakobsson and Ari Juels.
Proof of work systems were initially proposed as a security measure. Networks could use PoW to deter denial of service attacks and spam, for example. PoW required obtaining a “proof” of “work” from prior to interacting with the service. This “proof” showed that your computer did “work” prior to engaging with the service. Typically, this work involved performing a complex mathematical calculation.
Of course, efficiency was a major concern. For a proof of work system to be cost-effective, the necessary work must be hard to perform (by the person requesting the service) but easy to verify (by the service provider).
Over the years, we saw various attempts to create an efficient proof of work system. Adam Back created Hashcash in 1997, for example, using the SHA-256 algorithm. Hashcash required users to submit proof of calculating a few thousand hashing operations before providing the user with the requested service. Hashcash was proposed as a way to reduce message board spam and avoid DDoS attacks.
Each “hashing operation” is basically just a calculation. You’re inputting random hashes until you get one correct. It would take a user like you hours – even days – to input thousands of different hashes, but computers can do this in seconds.
Later, in 2007, bitcoin would also use the SHA-256 hashing algorithm.
How Bitcoin Generates Proof Using the SHA-256 Hashing Algorithm
Bitcoin uses the SHA-256 hashing algorithm to generate proofs for its proof of work system.
Think of the SHA-256 hashing algorithm like a machine. That machine takes an arbitrary-length data input (basically just a string of characters including numbers and letters) and it produces a 256-bit deterministic output (a fixed length strength of characters that works like a digital fingerprint of the input).
This is where SHA-256 gets innovative: SHA-256 seems random – but it’s deterministic. For any given input, the resulting output (or the hash) will always be the same. The hash can easily be verified by anyone using the same hash algorithm. Again, the hash is difficult to calculate but easy to verify.
When a miner “mines” bitcoin, they’re using two things to create the “input” for the SHA-256 hashing algorithm:
- The header of the block that was just generated. This header, on most cryptocurrency networks, contains all the transactions in the block, the date and time, and other important information that needs to be validated using proof of work.
- Nonce. This is a random number used to vary the output of the hashing function in each iteration.
Using these inputs, miners will run the SHA-256 algorithm quadrillions and quadrillions of times. Eventually, the hash output will match the “difficulty target”. Only the Nonce field will change in subsequent iterations to produce a different hash every time.
The difficulty target is a 256-bit number serving as an upper limit. The SHA-256 output must be lower than or equal to the current difficulty target for the block in order for it to be accepted by the network.
All of this can get confusing. Basically, what a miner is trying to do is come up with a hash, which is a string of letters and numbers. Before a block is added to the blockchain, a miner needs to produce the hash.
The hash of the latest block added to the blockchain looked like this:
In order for this hash to be added to the bitcoin blockchain, we know a miner had to make quadrillions and quadrillions of calculations. There’s no exact way to find the Nonce value needed to construct the string above. Instead, the miner needs to “brute force” quadrillions of different hashes until the miner finds the right one.
When you see the digital fingerprint above, you know that the only way a miner could’ve created that fingerprint is by performing quadrillions of hash operations. In other words, this miner has “proof” that they did the “work” – proof of work.
How Blocks Are Validated Using Proof of Work
Up to this point, we’ve explained how miners “prove” their “work” in a proof of work (PoW) consensus algorithm. They use brute force to attempt quadrillions and quadrillions of hashes until they get the right hash.
Once a miner has created the right hash, that miner has proof they did the work. They’ve collected all recent transactions on the network, used those transactions to create the block header, and went through all the work to find the Nonce before producing the hash (the string of characters above). At this point, the block needs to be validated.
The miner doesn’t validate its own block. Instead, the block is sent to other miners on the bitcoin network. These miners then validate the block’s information. They check the proof and verify that it’s correct.
Other miners will check the block to make sure it satisfies the pre-agreed rules of the cryptocurrency network.
One of the most important things checked by other blocks on the network is the payment rules within the block – the block reward. The miner that submits the block can only pay itself a reward based on the current block number. If the other miners, during the validation process, notice an attempt to tamper with the rules of the network, then they will reject that block.
Ultimately, this leads to a system where miners are incentivized to propose valid blocks and contribute to reliability of the network. Miners that attempt to sabotage the network will be rejected by other miners. Rejected blocks will have created their “proof of work” for nothing: they will have wasted electricity and resources with no chance of receiving a block reward. There’s no incentive for a block to act like this.
Once the other miners have validated the proof of work, the block can be added to the blockchain. The network has achieved consensus by verifying the “proof of work” provided by the miner. That miner will receive the block reward and all miners will work to solve the next block.
What Happens When Two Miners Find Proof of Work Simultaneously?
What happens if two miners within the network find the proof of work at about the same time? What happens if both miners stumble upon the correct hash and submit two candidate blocks to the bitcoin network?
Miners, upon completion of the block, will broadcast their proof to immediate neighbors. These neighbors will then propagate the block across the network. Each node that receives the block will individually verify the block. Then, the node – the miner – will add that block to their version of the blockchain.
What happens if that same node sees another block with the same proof of work solution? What happens if two nodes disagree about which block is added to the chain next?
In this case, we have a “fork”. A fork occurs when two valid blocks both contain a solution to the proof of work and both are directly connected to the same parent chain.
At this point, all miners will have both blocks incorporated into their version of the blockchain as a fork. However, the miners that saw the first proof of work will add blocks onto that block, while the miners that saw the second proof of work first will add blocks onto that block.
The end result is that there will be two separate chains. However, the bitcoin network wouldn’t be able to function if the blockchain was constantly forking. That’s why some blocks will become an “orphan”.
After a fork, there will be two versions of the blockchain for a brief moment. One chain will eventually be longer – it will have more cumulative difficulty. This chain will become the main state of the blockchain. At this point, the majority of miners will use this version of the blockchain as a reference. They’ll start adding blocks to this version of the chain. At this point, the block from the other side of the fork will be dropped as an “orphan”. All orders within that block will be dropped and added to the transaction queue again.
One of the advantages of bitcoin’s long confirmation times (10 minute block interval times) is that there’s a low number of forks. If bitcoin had a shorter block interval time, then there would be a higher number of forks.
Proof of Stake
Proof of work has been developed since the 1990s. It’s the consensus algorithm used by bitcoin and many other major blockchains and cryptocurrencies.
Proof of stake, however, is the second most common consensus algorithm. Proof of stake, or PoS, was launched in 2012 by Sunny King and Scott Nadal, although PoS-related theories date back to the early days of bitcoin.
PoS consensus algorithms were developed to solve a crucial problem in the bitcoin network: electricity consumption. Even in the early days, users recognized that the electricity consumption of the bitcoin network could become a problem in the future. Providing the “proofs” of work for the PoW consensus algorithm required massive amounts of processing power, and that processing power was fueled by electricity.
With that in mind, developers decided to create a consensus algorithm that did not require proofs of work or computer processing power.
Sunny King and Scott Nadal published their “proof of stake” idea in August 2012 when they released their whitepaper for PPCoin, or PeerCoin.
King and Nadal proposed a system where proof of work was used only for the initial part of the mining process, while proof of stake took over from there. The end result was a system that did not rely on large amounts of processing power or electricity, but still provided the security required to solve the Byzantine Generals Problem and create consensus across a distributed network.
Today, cryptocurrencies like Nxt, Lisk, and BitShares all use proof of stake consensus algorithms. Ethereum also plans to transition to a proof of stake consensus algorithm in the future.
So what exactly is a proof of stake consensus algorithm and how does it work? Keep reading to find out.
How Proof of Stake Consensus Algorithms Create & Validate Blocks
In the original proof of stake (PoS) implementation, coin age and randomization are used to pick a validator to create the new block.
Under this system, people are rewarded for “staking” their coins on the network. Someone who has staked a large number of coins for a long period of time is more likely to be picked as a validator – and receive a block reward – than someone who has staked a small number of coins for a short period of time.
You “stake” your coins in different ways. In most cases, PoS implementations require you to stake your coins using a wallet. Sometimes, staking your coins is as easy as leaving your coins within your wallet. At this point, your coins are staked and contributing to processing on the network. In other cases, you need to freeze your coins in a specific fund to qualify for staking rewards.
The age of a coin is typically calculated using an equation like this:
Coin Age = Number of Coins x Holding Period
For example, if John gave 10 coins to Mary, and Mary held those 10 coins for a 50 day period, then Mary will have accumulated 50 x 10, or 500 coin-days of coin age. When Mary spends those coins, the accumulated coin age will be consumed or destroyed.
Some PoS implementations have a minimum amount of coins that need to be staked before you can be considered as a validator. Anyone who has the required number of coins is eligible to become a validator simply by sending a special type of transaction. This transaction will “stake” your coins by locking your coins into a deposit. This is how you stake your coins and begin contributing to the network.
Today, most PoS implementations have a minimum age and a maximum age for validators. When coins reach their maximum age, then those coins are considered to have achieved their “maximum weight”. At this point, your probability of being selected as a validator actually declines.
The probability of a stack of coins getting selected to create and sign a block, at least in the original PeerCoin PoS implementation, will reach its maximum after 90 days. This prevents the oldest stakers from consistently capturing a high number of blocks. Stakers are rewarded for keeping a large amount of coins staked for a long period of time – but only for a 90 day period.
Furthermore, in the original PeerCoin PoS implementation, the same coins cannot be used to sign a new block for at least 30 days after signing a previous problem.
Types Of Proof of Stake Protocols
PeerCoin was the original proof of stake (PoS) implementation. Over the years, however, we’ve seen a number of other proof of stake protocols emerge, including chain-based and BFT-based proof of stake protocols.
A chain-based PoS implementation uses similar mechanics to proof of work. Mining is simulated by randomly selecting a validator and giving the validator the right to create a new block pointing to the last block in the longest chain. PeerCoin used a chain-based PoS protocol, and most early PoS protocols used a similar system.
Byzantine Fault Tolerant, or BFT-based PoS consensus algorithms rely on the Byzantine Generals Problem mentioned up above. It’s been mathematically proven, based on the 30 years of research into the Byzantine Generals Problem, that we need a 2/3 consensus to solve the Byzantine Generals Problem and ensure protocol participants are behaving honestly.
With a BFT-based PoS consensus mechanism, validators will be randomly selected to propose a block. A round of voting takes place, after which every validator “votes” the specific block. If, at the end of this process, at least 2/3 of all validators signed off on the proposed block, that block is added to the blockchain.
If 2/3 of validators do not sign off on the proposed block, then a different validator will propose the block and the process will begin again.
The first cryptocurrency to use the BFT-based PoS mechanism was Tendermint. Ethereum also proposed its own BFT-based PoS consensus mechanism with its Casper update, a PoW/PoS hybrid that may eventually be implemented into Ethereum one day.
What About 51% Attacks?
A 51% attack takes place when a majority of nodes – 51% or more – attempt to disrupt the network.
The idea behind a 51% attack is simple. PoS and PoW implementations above depend on the idea of consensus. Once the majority of nodes have consensus about a block’s proof, that block is added to the network and the network moves onto the next block.
With a 51% attack, however, a majority of nodes are acting maliciously. They are deliberately verifying an incorrect version of the blockchain to disrupt the network, for example.
How Do 51% Attacks Work In PoW Implementations?
With large proof of work (PoW) blockchains, a 51% attack is pretty much impossible. In order for a 51% attack to take place on bitcoin, for example, the attacker would need to acquire 51% of the computing power of the bitcoin network.
This may sound impossible. However, today’s largest bitcoin mining pools control well over 51% of the Bitcoin network’s computing power. It’s possible that these mining pools could join together to form a majority and attack the network.
This is seen as one of the biggest flaws in a proof of work-based cryptocurrency: centralized mining power opens the possibility of a 51% attack. 4 out of the top 5 bitcoin mining pools come from a single country (China) and 80% of the world’s bitcoin mining hashpower is provided by the top 5 mining pools. Furthermore, 70% of bitcoin mining hardware (ASICs) is built by a single manufacturer (Bitmain).
All of this means that it’s possible for someone to launch a 51% attack against the bitcoin network and other proof of work networks.
How Do 51% Attacks Work In PoS Implementations?
With a proof of stake (PoS) implementation, a 51% attack is also a concern – although it works in a significantly different way.
In order for a 51% attack to take place on a PoS consensus algorithm, the attacker would have to own 51% of the coins. By owning these coins, the attacker is effectively controlling 51% of the resources used to process transactions on the PoS network.
It’s feasibly possible for a single person to own 51% of coins on a PoS-based blockchain. However, it’s almost impossible in practice.
If you wanted to launch a PoS attack on Ethereum, for example, then you’d need to purchase 51% of coins in the Ethereum ecosystem. With Ethereum’s market cap hovering around $100 billion, that means you’d need at least $50 billion to purchase 51% of the ETH in the Ethereum network.
There’s another reason why 51% attacks are unlikely on PoS networks. If someone spent $50 billion to acquire 51% of the ETH in the ecosystem, then they’re also the majority stakeholder in the ETH ecosystem. That means they have the most to lose in a 51% attack.
The Risk Of Centralization In PoW And PoS Consensus Algorithms
Both PoW and PoS consensus algorithms face risks related to centralization. However, the risks come in different forms.
Risk Of Centralization In Proof of Work (PoW)
In proof of work consensus systems, there’s a risk of centralization due to the presence of 51% attacks.
Up above, we discussed centralization in the bitcoin network. The vast majority of bitcoin mining power is concentrated in the hands of a few select organizations and companies.
This problem is becoming worse over time due to simple economics. Due to economies of scale, it’s more efficient to run a mining farm with 10,000 miners than it is to run a mining farm with, say, 10 miners. This leads to a concentration of mining power in the hands of a few organizations with huge amounts of resources. These organizations can purchase bitcoin miners at lower bulk rates (or produce bitcoin miners themselves), then run bitcoin miners in massive warehouses near cheap sources of electricity.
You’re free to compete with these centralized mining powers, but you’ll never be as profitable. The end result is that PoW mining power will be funneled into the hands of a few specific groups or individuals, increasing the risk of a 51% attack on a PoW network like bitcoin. All it takes is two or three mining pools to join together and they have enough hashing power to launch a 51% attack on the bitcoin network.
Risk Of Centralization In Proof of Stake (PoS)
Centralization works in a much different way with proof of stake (PoS) consensus mechanisms. PoS supporters take pride in the fact that their favorite consensus mechanism has a significantly reduced risk of centralization – although detractors believe PoS networks face the same risk of centralization.
With cryptocurrencies based on the PoS consensus mechanism, the person who holds 10% of all the coins will have a 10% chance of being selected to propose a new block.
Let’s say you decide to acquire 10% of the total supply of a particular cryptocurrency. You’re making a huge one-time investment, but you would assume that you reap the benefit of that investment over and over again.
Theoretically, this leads to a system where the rich get richer. If someone can afford to purchase 10% of the total supply of Ethereum today for $10 billion, then that person can continue reaping the rewards of staking (including block rewards and transaction fees), and then use those funds to continue buying more Ethereum.
Unlike with bitcoin mining, you don’t need to maintain your equipment over time. You will receive 10% of the mining rewards as long as you hold 10% of the total supply of coins.
Ethereum tackles this problem in their proof of stake FAQ, where they describe it as a benefit:
“[Ethereum has] reduced centralization risks, as economies of scale are much less of an issue. $10 million of coins will get you exactly 10 times higher returns than $1 million of coins, without any additional disproportionate gains because at the higher level you can afford better mass-production equipment.”
While PoS supporters see this as a benefit, it could also be one of the biggest problems of PoS consensus mechanisms in the long run. That’s why some people are proposing different types of consensus mechanism beyond proof of stake and proof of work.
The “Nothing at Stake” Problem With Proof of Stake Consensus Algorithms
One of the biggest criticisms with proof of stake consensus algorithms is the “nothing at stake” issue. This issue was first discussed by Jae Kwon in May 2014, who described it as “the fallacy of false choices” problem.
At its core, the nothing at stake issue is related to incentives on PoS networks. In PoS consensus-based networks, validators can vote for multiple conflicting blocks at a given block height without incurring a cost for doing so.
In other words, validators – the nodes and miners contributing to the network – can disrupt the stability of the network by voting for multiple conflicting blocks. These validators don’t need to spend any money or resources to do so, so they can disrupt the network without incurring significant costs to themselves.
This is different from a PoW network, where validators need to contribute processing power and “prove” their “work” prior to submitting a block for validation. Miners who deliberately submit a problematic block will have incurred costs – like electricity costs – for doing so.
The end result is that in PoS implementations, there’s no penalty for mining multiple conflicting blocks at the same time. In fact, not only is there no penalty, but a validator’s best option is to vote on as many forks as possible to maximize your chances of reaping more block rewards.
How do PoS implementations solve this problem? How do PoS implementations prevent countless forks from being constantly created?
Various solutions have been proposed. Slasher, for example, changes the incentive structure by including an explicit penalty for validators who simultaneously create blocks on multiple chains. Slasher works by providing “proof of misbehavior”. Slasher provides this proof by identifying two conflicting block headers signed by the same validator.
The end result of Slasher is that it replicates the incentive structure of PoW inside PoS implementations. PoW implementations punish hostile validators by forcing them to waste their electricity. Slasher creates an internal penalty: with Slasher, validators who mine blocks on the incorrect chain will lose their staked coins.
Delegated Byzantine Fault Tolernace (dBFT)
Proof of work (PoW) and proof of stake (PoS) consensus algorithms are both designed to solve the Byzantine Generals Problem. A third major consensus algorithm, however, has recently emerged. That algorithm was designed by Erik Zhang. It’s best-known for being the consensus algorithm used by Neo.
The best way to understand the dBFT consensus algorithm is by looking at how Neo works.
How Does Neo Validate Blocks?
In the Neo network, there are two types of nodes, including ordinary nodes and consensus nodes.
Most Neo cryptocurrency holders are ordinary nodes. These nodes can exchange and transfer their Neo tokens, but they don’t participate in the voting process on the Neo network.
Consensus nodes, meanwhile, are active participants in the block validation process on Neo. They have a right to vote – similar to how every miner on bitcoin has the right to vote.
If you’re a NEO token holder who wishes to become a consensus node, then you’ll need a dedicated internet connection, special hardware, and a certain amount of GAS (the utility token that fuels the Neo network).
As a consensus node, you play a crucial role in processing transactions and validating blocks on the Neo network. As blocks on the Neo network are processed, nodes take one of two roles. In every round, one consensus node is elected as the Speaker. This is the node responsible for proposing a block. The remaining nodes are chosen as Delegates. These are the nodes responsible for reaching a consensus on the transaction and validating the block proposed by the Speaker.
How Neo’s Algorithm Works
In order to achieve Byzantine Fault Tolerance within the Neo network, three requirements need to be satisfied, including:
- Delegates must reach a consensus about every transaction before a block can be committed to the Neo network
- Dishonest nodes must be prevented from causing honest nodes to commit faulty transactions
- The number of Delegates in the same state (i.e. the same block height and iteration) must be above the same consensus threshold to start consensus activity without exposing the network to a fault
The process starts with the consensus nodes. A consensus node receives a transaction on the Neo network, then broadcasts that transaction to the entire network. All consensus nodes that receive this transaction will log it into their local memory. This creates the first “view” of the consensus activity.
Once the entire network of available consensus nodes has received the transaction, a Speaker is randomly selected from the pool of nodes for this specific block.
This Speaker has a limited amount of time (with Neo, the limit is set at 15 seconds) to generate the block. At the end of this time period, the Speaker broadcasts a proposal containing information about the block height, the index of the current round, the index of the consensus node elected speaker, the block proposal, and other metadata.
The remaining nodes across the Neo network (which automatically become Delegates after a node has been chosen as Speaker) will receive this proposal, then review it. These Delegates are responsible for confirming that a node is following the rules of the network. Those rules include not broadcasting a transaction already present on the network, for example, and avoiding double-spend transactions.
When a Delegate declares the block proposed by the Speaker to be valid, the Delegate will send a “Validated Proposal Broadcast”. This broadcast gets sent back to the Speaker and simultaneously to all other Delegates. At this point, each Delegate will verify that the number of Validated Proposal Broadcasts they received is the same as – or above – the number required to achieve a safe consensus threshold. If a certain number of Validated Proposal Broadcasts have been received, then the block is validated, and the Delegates sign and publish the block, binding it to the Neo blockchain.
What happens if the Delegates don’t receive the specified number of Validated Proposal Broadcasts? In this case, Delegates may have sent a number of Invalidated Proposal Broadcasts. If Delegates receive a certain threshold of Invalidated Proposal Broadcasts, then the block is rejected, a new Speaker is selected, and another round begins. With Neo, a block will be rejected if at least 1/3 of Delegates have found the block to be faulty.
Conclusion: Which Consensus Algorithm Is Best?
Right now, the market is deciding which consensus algorithm is best. We can compare consensus algorithms based on crucial indicators like:
- Risk of centralization
- Efficiency and electricity consumption
- Effectiveness at solving the Byzantine Generals Problem
The goal of any consensus algorithm is to create consensus across a decentralized network of participants – even when some of those participants are acting maliciously. The value of bitcoin and other cryptocurrencies comes from the unique way in which they solved this problem.
Ultimately, the best consensus algorithm may have already been developed. Or, a new consensus algorithm might emerge and solve all of the problems listed above more effectively than PoS, PoW, and dBFT consensus algorithms. Stay tuned and let the market decide which consensus algorithm works best at solving the Byzantine Generals Problem.