How to Choose a Consensus Algorithm for Blockchain-Backed Services

Blockchain-as-a-Service comprises providing blockchain infrastructure for a customer, for a fee. The client pays the provider to set up and maintain blockchain-connected nodes and handle a complex backend. There is another working business model related to distributed ledgers where you are paying not for blockchain as it is, but for the services, it provides to the customer. This is exactly how REMChain is built. As a decentralized application developer or private company representative, you don’t need to pay for blockchain maintenance, but for the necessary quantity of blockchain-backed PKI certificates.

Another crucial point that helps you understand what blockchain is: paying for blockchain-backed services, you don’t pay a company that designed the network, but instead pay the network itself. A blockchain’s main feature it that it is community supported, distributed and managed adequately through consensus algo data storage. However, you ideally want the reward distribution to make the network a decentralized and secure place for your information regardless of circumstances. That’s why you need a smart algorithm that will be a guarantee of transparency and correct and reliable behavior of masternodes.

How to decentralize decisions that will not be reversed

Most usable consensus models’ proof-of-work, and proof-of-stake are based on the assumption that the biggest investors wouldn’t attack the system. The attacker will devalue their rewards (in the case of the proof-of-work consensus) or stake (in the case of the proof-of-stake consensus). There are forks in public blockchains that provoke situations where the consensus in the future can refuse accepted blocks. This is perfectly reasonable because blockchain development processes favor randomness to immunize themselves against malicious actions.

Consensuses that serve for business use are of an entirely different nature. Their goal is not so much in maintaining full decentralization, as in the provision of quality services that create added value in comparison with centralized counterparts. To do so, it is necessary to build a system in which it will be problematic to control a critical number of masternodes, with a fast and scalable consensus.

The Byzantine Fault-Tolerant (BFT) algorithms are well suited for such tasks, where blocks voted by consensus cannot be withdrawn. The main feature of the BFT algorithms is that they are resistant to the wrong behavior of nodes if there are strictly more than ⅔ honest masternodes in the network.

I would like to share with you results of the research work that lasted several months for REMME open source. We worked on building a decentralized CA that will update the safety and security of public key infrastructure technology and renew its cybersecurity effectiveness against hackers.

Searching for the best algorithm for REMChain purposes, we have marked Algorand, HoneyBadger, SBFT and Raft. Here are short descriptions of these approaches:

Algorand BA: two-step communication process and option to scale

This BFT algorithm facilitates speedy agreement within a constant expected time. When the leader is honest, the proposed value is agreed upon after a two-step communication process. Algorand BA also features Arbitrary Partition Resilience, meaning that when the network is partitioned, the protocol ensures the safety of the system so that no two honest users will finish the protocol with different outputs.

Algorand BA works via a highly scalable Byzantine Agreement (BA) protocol to reach consensus. There is an option to scale the consensus: a mechanism based on Verifiable Random Functions (VRF) randomly selects users to participate in the BA in a private and non-interactive way, but it lies outside of the BA and is part of the complete Algorand algorithm. This Algorand can reach consensus on a new block with low latency and without the possibility of forks.

SBFT: collectors’ communication solution

This algorithm relies on a masternode collector to reduce communication. Instead of sending to everyone, each masternode sends to the сollector and the collector in turn broadcasts to everyone. SBFT also uses a round-robin revolving collector to reduce the load, as well as multiple collectors to improve fault tolerance and handle slow or faulty collectors.

SBFT works using a primary masternode that accepts certificate requests from clients and signs it. Its consensus algorithm is faster than proof-of-work algos and has better scalability than Practical BFT. Its performance advantage in comparison with others accumulates as the number of clients increase. SBFT is suited to scenarios where there are tens of malicious masternodes.

HoneyBadger: epochs and threshold encryption

With this BFT algorithm, nodes receive transactions as an input and store them in their buffers. The protocol proceeds in epochs, where after each epoch a new batch of transactions is appended to the committed log. At the beginning of each epoch, nodes choose a subset of the transactions in their buffer and provide them as an input to an instance of a randomized agreement protocol.

HoneyBadger works by using threshold encryption, which prevents an adversary from learning which transactions are proposed by which nodes until after an agreement is already reached. HoneyBadger BFT is a natural candidate for use in confederated environments and in permissionless blockchains, since the randomly selected committee can be geographically heterogeneous.

There was also another one, not the Byzantine-fault-tolerant algorithm that we considered for possible implementation — Raft.

Raft: leaders, followers and candidates

The defining features of this algo are Election Safety (only one leader can be elected in a given term) and Leader Append-Only (a leader never overwrites or deletes entries in the log; it only appends new entries). Raft is intended for use in a relatively small cluster of servers of around five or less.

Raft works by assigning each server one of three states: leader, follower or candidate. In normal operations, there is exactly one leader and all of the other servers are followers. Followers issue no requests on their own but simply respond to requests from leaders and candidates. Raft divides time into terms of arbitrary length. The beginning of the term means the start of an election, in which one or more candidates attempt to become a leader. If a candidate wins the election, it will operate as a leader for the rest of the term.

REMChain Proof-of-Service consensus

Analysis of the algorithms described above led us to the idea that we need our own custom consensus. We came to the model in which all the masternodes are equal by roles, and the rewards for the services provided by the network correspond to the size of the stake and reputation.

The mechanism of making changes to the blockchain itself relies on the election of committees that use the additional bet tool. Bets allow individuals to increase the likelihood of selecting a node in the committee, and at the same time serve as a pledge that is taken if the node was selected and its block did not coincide with the proposal of the committee.

Block sizes will have time limits and restrictions on the number of certificates, which, together with the small size of the committee, will allow the algorithm to get high-performance work from the protocol.

What’s important to heed

Given the limited number of nodes and the blockchain’s orientation towards performing specific tasks related to business services, these consensus mechanisms for public blockchains will all encounter difficulties. First of all, the losses from cryptocurrency fluctuations in small blockchains likely won’t be too significant, and the consequences for customers of blockchain-backed services are vital if we are talking about the supply chain or digital identity.

Secondly, the effect of a small number of nodes will be much more decisive for the correct operation of the system. For this, it is necessary to develop more complex consensus mechanisms that work equally effectively with different numbers of nodes and with a certain amount of dishonest participants.

While choosing a consensus algorithm that corresponds to your product, it is important to look at the architecture of decision-making and mathematics that provides a possibility to select masternodes for different functions in a decentralized and secure way. You should balance speed of blockchain and stability with a small number of active nodes, and consider the sound logic of the internal economy, which will encourage the owners of masternodes to play by the rules.