If you are starting to get into blockchain, you will very likely have asked yourself the following question: Who decides what gets written in the network? Who validates the transactions in a blockchain network?

Well, the most correct answer is ‘it depends’. Each blockchain network decides what the transactions are by using what is known as a consensus algorithm.

What is a consensus algorithm?

Consensus in blockchain networks refers to the process of reaching an agreement among the various participants in the network about the transactions that are going to be written in the chain.

In other words, the consensus is responsible for all nodes in the blockchain network having the same data, which in turn prevents tampering.

The way in which this is represented in the network is what is known as a ‘consensus algorithm or mechanism’ and is part of the former’s core – even though there are some network implementations that allow choosing among several available algorithms.

Below we will see the main consensus mechanisms existing nowadays.

Proof of Work (PoW)

The proof-of-work algorithm was the first of the mechanisms used in blockchain. It dates back 20 years, when Hashcash, the first-ever PoW system, appeared.

The basis for this algorithm is that, in order for two strangers who are going to participate in a system to establish a relationship, it is necessary for both of them to somehow show their interest in doing so, and the way to guarantee this interest is for them to prove that they have allocated a certain amount of resources to this end (the proof of work).

However, not just any proof of work is valid since, in order for a proof of work to be feasible, it must be easy to prove.

An example of a proof of work is shown below:

Finding a page in a book where the fourth letter is an ‘a’ and the second to last an ‘m’.

In order to find it, I would need to check all pages one after the other to see whether the above condition is fulfilled.

I could start at the beginning, the end, the middle, etc. There is no strategy beyond checking pages, which would indeed require some effort on the part of the person who wanted to provide that proof.

In addition, it would be something rather easy to check since, once the interested party shared the number of the page, the other party would only have to go to that page to see whether it was actually so.

The idea behind the proof of work about a data set is to apply a function to the data and check to see whether a previously agreed condition is met.

The most famous proof-of-work algorithm is that of Bitcoin. This algorithm creates a block that contains certain information, the following among which:

A SHA-265 hash function is applied to this ‘block’ (which is a succession of bytes), the result of which is always a collection of 64 hexadecimal digits. It is important to note that a hash function is a deterministic function, that is, it will always produce the same result when it is applied on a specific input.

Once the result is obtained, the algorithm checks whether the calculated number is smaller than a given number by checking to see whether the result starts with a certain number of zeroes (0); if so, it will consider the block to be valid and stop looking for new ‘nonce’ values.

In the Bitcoin and Ethereum networks – and in PoW networks in general, the first node that finds a valid block is rewarded for the work done, so the members of the system compete with each other.

Pros of PoW

Cons of PoW

At the beginning this was not a risk due to the wide distribution of the nodes; however, Bitcoin mining is becoming increasingly specialized, with groups of users investing in complex mining systems.

This entails a risk of centralization around a small group of users who could potentially carry out an attack on the chain, such that only those blocks this group wanted would be accepted.

Proof of Stake (PoS)

The purpose of the proof-of-stake algorithm is to put an end to the inefficiencies associated with the proof-of-work algorithm. In this mechanism there are two node types: Regular nodes, which store a copy of the chain and which can be queried, and validator nodes (not miners).

The probability that a participant has of being selected to validate a block – and getting a reward for it – is decided in connection with the amount of funds (cryptocurrencies or tokens assigned by means of some specific system) they are willing to bet.

These funds will then become a guarantee of the validator’s good faith. If the transaction is found to be illegitimate, the validator will lose their funds; otherwise, they will receive a reward for validating the node.

The idea behind this algorithm is widely accepted, there being different variations that aim to optimize the results, thus preventing e.g. a few nodes with a lot of funds from becoming the only nodes with the capacity to decide.

However, the need to know the identity of the validator nodes and the large power these nodes have compared to the rest render this protocol quite unsuitable for public networks.

Pros of PoS

Cons of PoS

Variations of PoS

Some of the most important variations of the proof-of-stake mechanism are:

Proof of Authority (PoA)

The proof-of-authority mechanism can be understood as a variation of PoS. In PoA, validations are also done by validator nodes. The difference lies in that the capacity for validation is not determined by the amount of funds an account has but by the ‘identity’ or legitimacy thereof.

The ‘validator’ status gaining mechanism must be clear and known beforehand since the maintainability of the network depends on it.

Although some people think this algorithm is not decentralized enough (true), somehow it is a perfect match for consortium networks, whether private or semi-public.

In this type of network, the identity of the nodes is guaranteed by their position in the consortium or society such that a potential loss of reputation of the person who is in charge of a node fully discourages them from acting dishonestly.

Pros of PoA

Cons of PoA

Byzantine Fault Tolerance (BFT)

The BFT mechanism is inspired by the well-known Byzantine generals problem.

In this problem, a number of generals must simultaneously make a Boolean-type decision (yes or no: to attack or not to attack) in order for their military strategy to be successful.

The problem arises when the possibility that one or more of the generals is a traitor and provides erroneous information that can turn the attack into a defeat is introduced.

The idea behind it is to be able to tell whether one of the nodes is telling the truth when it transmits a message.

In the case of a blockchain network with BFT, all nodes must be known, so the network must not need to change frequently. These nodes exchange information which could potentially be correct or incorrect.

The algorithm is based on the honesty of the majority of validators such that, if one of them were dishonest, the others could expose the fraud attempt and repel it.

BFT makes sense when all the participants in the process know each other and are not inclined to change. A good example of this is the voting flat mates do when deciding whether to make home repairs or not.

The most relevant implementation of this kind of mechanism is Istanbul Byzantine Fault Tolerance (IBFT).

Pros of BFT

Cons of BFT

Conclusion

If you have made it all the way down here, now you know a little bit more about the different consensus algorithms and how they affect the characteristics of blockchain networks.

As it is often the case when technologies are compared, one should not think in terms of right or wrong: There are many different approaches, which should all be properly evaluated before choosing the one that best fits the goal in mind – assuming its limitations and mitigating its risks.

Furthermore, most blockchain implementations are open-source, so they is always room for the community to collaborate. And you, are you game?

Tell us what you think.

Comments are moderated and will only be visible if they add to the discussion in a constructive way. If you disagree with a point, please, be polite.

Subscribe