Who is in Charge in a Blockchain Network?

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:

  • The address of the preceding block.
  • The transactions to be included in the block.
  • Here is where the key of the proof of work resides. A random value is entered in this field such that the block will change with every different value despite containing the same transactions.

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

  • The proof of work cannot be predicted as it depends on the data themselves and the address of the previous block.
  • The sharing out of the reward among the nodes for taking part is automatic and depends exclusively on the miner’s hash rate.
  • It encourages good behaviour. Since the resources (materials, time and electricity) cost a lot, malicious behaviours are penalized with a loss of profit.
  • It is resistant to Sybil attacks where an agent creates false nodes to suppress actual honest users.
  • The proof cannot be obtained in advance since the appearance of each new block requires launching a new round of calculations (each new block contains a link to the previous block).
  • The system is fairly clear and easy to understand.

Cons of PoW

  • It uses up a lot of power. The Bitcoin network uses huge amounts of power. As new blocks are generated, the difficulty has to be increased, so this consumption tends to be ever greater.
  • It is vulnerable to a 51% attack. In order to be able to fraudulently modify the chain, it is necessary to have 51% of the nodes.

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.

  • The speed of block validation is relatively low owing to the proof-of-work mechanism itself, so certain use cases are incompatible with this system.

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

  • Reduced power consumption. Since there is no proof of work, the only work that is done is building the block and reaching an understanding among several nodes.
  • Very high block rate, which allows using blockchain networks in use cases requiring a quick response.
  • Quicker decision making. Given that the main players get additional votes, it takes less time for a consensus to be reached, which makes the transactions faster.

Cons of PoS

  • There is a tendency for the network to become centralized, particularly in the case of networks which are not very large and in which it is easy for a node to end up having a big influence on the decision-making process.
  • It is susceptible of suffering a 51% attack – although this is complicated since the nodes with the most power are precisely those which are the most interested in the good operation of the network. Since they are the biggest owners of funds, a devaluation thereof would be counterproductive to them.
  • Exposing the wallet over the Internet can represent a security risk.
  • Forking could occur, given that two nodes could meet the block validation conditions at the same time. The network tries to mitigate this risk with a subsequent validation of the remaining nodes, but potentially it could be happen that both branches end up being equally validated.

Variations of PoS

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

  • Delegated proof of stake (DPoS). This mechanism – whereby all the owners of the funds delegate their capacity for validation to a node type known as a representative, thus avoiding directly exposing their funds – has been implemented to avoid the risk involved in exposing the wallet on the network.
  • Proof of Importance (PoI), whereby the reputation of the node is determined by its participation therein.
  • Proof of Authority (PoA), which will discuss next.

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

  • The reliability of the network: How a rather specific group of users is responsible for the decision making and discourage malicious users.
  • There is no mining and, hence, network maintenance costs are low.
  • High transaction rates due to the fact that consensus is reached extremely quickly.

Cons of PoA

  • The transaction validation capacity is highly centralized.

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

  • High network performance; by default, 1 second per block.
  • The transaction-associated cost is very low.
  • There can only be one possible block at any given time, which eliminates the risk of chain forking.
  • The nodes can take the power away from malicious nodes.
  • It requires a large majority (approximately 66%) of the nodes to validate the transactions, so the risk is minimized.

Cons of BFT

  • As is the case with all authority-based systems, there is a tendency toward centralization, which must be countered with modifications that require variations in the validations.
  • It is only works in small networks.

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?

Computer Engineer by UCM. Passionate about technology and, above all, putting it at the service of people. I have worked on J2EE / SOA and Integration projects in numerous clients. Currently working as IT Architect and Presales at Paradigma Digital. I try to keep up with the latest products and take advantage of them to build solutions that are increasingly agile, robust and efficient.

See all Borja Gómez activity

Escribe un comentario