How to Launch Your Own Blockchain: Choosing The Right Consensus [Part II]

We will review different consensus algorithms paying special attention to their features and restrictions (for details, see my previous article).

***

I will base on the fact that the blockchain is designed for fairly complex transactions. All considered solutions are suitable for working with smart contracts and complicated on-chain code

I deliberately excluded the solutions that are at early development stages, are not widely recognized among programmers or do not have important mechanisms that ensure safe blockchain operation: they are unstable to Byzantine behavior of nodes (non-BFT) or can be successfully attacked from a single account. Without these properties, a blockchain has no value and turns into a slow, expensive and inconvenient database.

To decide whether to build a new system or use a ready-made solution, first  you need to decide on consensus - the main algorithm that ensures BFT-properties of a blockchain.

To begin with, let’s consider different types of consensus in terms of running and operating a network. Any BFT consensus must satisfy at least two important properties of distributed systems: safety and liveness.

Safety guarantees that the algorithm will never come to the wrong consensus if most nodes honestly follow the protocol, and liveness - that the algorithm will never “get stuck” without action choice.

These properties must be fulfilled if there are byzantine participants in the network, who intentionally act in the worst way.

The advantage of this consensus type is that there is no need to register validators in the network. Any block that meets the requirements is accepted without confirmation of other participants. This allows us to leave only a logic part that is responsible for changing mining complexity.

In theory, this type of consensus approves of any quantity of validators - after all, indefinite number of validators can compete for a block. In real networks, if there are a lot of validators (miners), and network complexity is high, then a sole miner has small chances to get a block reward. Such consensus requires a pre-planned work scheme of mining pools that combine mining capacities, and the corresponding software.

During network launch, validators must immediately have serious computing power. This is often overlooked in favour of a gradual increase in network complexity and the number of miners. A low hash rate opens the door to 51% low-cost attacks, when an attacker rents a lot of servers for a very short time to get 51% of the network hash rate and conducts a double-spend attack.

Therefore, you will have to plan a more complicated launch procedure for a PoW network. First, the team runs a network with its own validators, and then gradually gives rights for block production to miners that can gradually increase power.

PoA consensuses are algorithms using a predefined set of accounts that can produce blocks and vote to accept or exclude new members. This type of consensus is an obvious choice for enterprise blockchains and test networks. There may be no internal token at all, and 1 validator = 1 vote in voting for blocks and election of validators.

This class of algorithms is represented by the fundamental pBFT algorithm. Its modified form is the basis for a large number of consensuses and allows to agree on any data ensuring high security guarantees.

In the previous article, I already said that there is no guaranteed secure consensus that requires less than 2/3 + 1 messages from validators. pBFT proves this mathematically. The messages, confirming that a validator has accepted the block, are collected at different points in time.

The process of collecting confirmations and further recognition of a block as final is called finalization. The blocks, for which a consensus was reached, are called final. To reduce the number of messages in algorithms, finality is not achieved on all blocks, only on some of them.  That makes consensus significantly faster.

As block validation and finalization are separate procedures, it is difficult to evaluate consensus speeds.

For example, the pBFT algorithm used in Tendermint consensus (Cosmos) requires consensus for each block, i.e. instantly finalizes it, and the EOS algorithm finalizes only one of many blocks, thus finalizing the whole chain. Such finalization algorithm, operating in parallel with the main consensus procedure is called a finality gadget.

Aura is a popular consensus algorithm for Ethereum-based POA networks. It’s commonly used with GRANDPA-based finalization algorithm. Aura applies pseudo-random choice of validators for each block, then, GRANDPA finality gadget finalizes  key blocks to receive more than 2/3 of confirmation signatures from other chain validators, selecting the most “heavy” chain from possible forks. 

The EOS consensus works in a similar way, creating a “schedule” for validators for a certain period of time (epoch) and requiring block finalization at the end of each epoch.

The fact that almost all existing implementations of these algorithms include POA consensus algorithms adds to the confusion. Modern PoS algorithms work as follows: a list of validators is formed (by voting, freezing deposits, etc.) using the balances of the validators (stakes) participating in the elections. For some time, until the list of validators is changed, the network operates using a PoA algorithm, for example, pBFT or Aura + GRANDPA.

The most common algorithms are called Delegated Proof-of-Stake (DPoS), where network accounts vote with their balances for validators in various ways, forming the top of N number of validators.

When choosing a consensus for your blockchain, you should first consider the process of block finalization. It defines the time necessary for the client to receive confirmation of his transactions. Tokenomics, the “election” procedure for validators and getting block rewards should be reviewed separately, as there are many economic mechanisms to choose from.

It's important to mention that corporate networks should not neglect economic mechanisms and PoS algorithms, even if the network does not have any economy and token. Any free transactions are usually a vector for a system attack from a single account. The account balance of a “technical” token can serve as a limit - an attacker simply will not have enough funds for a full-scale attack. Plus, it  allows for more flexible control of access and network load.

When developing a blockchain, you need to choose between a ready-made solution and creating everything from scratch, fully controlling the code.

Blockchain is a world of open source software. Closed-source code is almost impossible - cryptographic protocols have been created during open international competitions, and few people trust closed-source implementations because of high risks.

Use what programmers have created earlier. It is highly likely that your tasks have already been solved, discussed and checked, so you will not have to spend extra effort on them.

If you decide to build your own consensus related to network interaction or you are using new cryptographic concepts that do not architecturally fit into traditional blockchain design; if you want to surpass all existing performance-related solutions, saving every bit; if the transactions in your blockchain are specific and different from the ones existing in the world ... Then your path is a blockchain from scratch.