The Performance of Quorum-Based Consensus Protocols in Blockchain

If Blockchain was an animal, consensus protocols would be its skeleton. As an indispensable part of any decentralized network, a consensus protocol is responsible for the validation of transactions by all nodes in the network. It’s done via the determination of the validity of the block being added, ensuring it’s what all nodes agreed on.

What Are Quorum-Based Consensus Protocols

Quorum-based consensus protocols have been quite a rage within the blockchain space. But what are they? Do they offer any edge over other non-quorum-based consensus protocols? How have they performed?

Quorum is a term that is heavily used in decentralized systems. It refers to the minimum number of votes needed by a distributed transaction before an action can be executed within a distributed system. A consensus protocol is defined as the system. governing what happens in a particular blockchain at any point in time.

A quorum-based consensus protocol is a protocol where the decision to add blocks is preceded by achieving a minimum number of votes. 

Main Difference With Other Consensus Protocols 

All consensus protocols have one basic requirement. All participants in the nodes must arrive at the collective decision to either accept or reject the addition of a new block. The process of arriving at the decision however takes an extra step under quorum-based protocols.

For quorum-based consensus protocols, the nodes’ participants exchange messages with two key initiatives. First, a block has to be proposed to all nodes, something that can only be done by the consensus leader. The second is informing the network that the participant has decided on and validated the block. 

Consensus is achieved after the leader has proposed a block and the majority of the participants decided on and validated the proposed block. 

Edge Over Non-Quorum-Based Consensus Protocols

Quorum-based protocols boast of one key major difference over non-quorum-based ones. That is, the ability to continue operations even when some of the correct participating nodes fail or act maliciously.

The main reason behind consensus not being trivial is that failure could occur during message transmission and decision-making by nodes. The cause may be a power outage or malicious behaviour, resulting in lost or delayed messages.

The allowance of such a failure is referred to as Byzantine fault tolerance. Such protocols can tolerate crash faults or the byzantine fault. Crash faults are where participants don’t respond or perform a new operation when a consensus is being executed. 

A Byzantine fault refers to a failing participant that could be a malicious agent. Such an agent is characterized by the display of random behaviour differing from the laid down protocols and taking any action. 

The maximum number of malicious nodes that can be tolerated in a quorum-based protocol is ⅓ of all participating nodes in the network. The total is inclusive of both honest and malicious nodes.

Performance of Quorum-Based Protocols

To gauge the performance of quorum-based consensus protocols, they shall be subdivided and analysed into three different groups.

Performance of Practical Byzantine Fault Tolerant (BFT) Protocols

The protocols are called so because they practically achieve two key issues. They optimize inter-participant communication and authentication while managing to stay functional in hard-to-sync environments. 

All communication is centralized on the leader called the primary, with all other participants being termed replicas. A view change protocol is implemented when the leading node fails, with the next participant in the circular cue being the new primary. All participants have proper knowledge of all participants and their signatures for better voting decision-making.

While giving a practical solution to the Byzantine fault, the protocol has had a big issue with scalability. To tolerate malicious behaviour, all participants must know all the other node participants and exchange a huge number of messages. It presents a computational complexity in exchanging messages. 

Expansion is also a challenge because adding a participant is close to impossible. Any participant that leaves permanently is deemed a malicious actor. Very vibrant and dynamic blockchain ecosystems would very quickly get to the ⅓ limit and result in the protocol’s collapse.

Performance of Federated Byzantine Agreement  Protocols

Under the federated byzantine agreement (FBA) protocol, the quorum.is split up into several federal units. It does so by having several Byzantine generals, each being responsible for their quorum slice. It allows for a significant increase in transactions, a reduced transaction cost and a smaller number of message exchanges. 

Under the FBA protocol, each participating node is given the ability to choose who they wish to trust. It creates difficulty for any malicious actor since they have to convince a large number of valid nodes to include malicious nodes in their trusted list.

FBA has gained increased popularity over the years, attracting big blockchain names to its fold. The most notable ones are Ripple inc and Stellar. Sybil attacks are the most notable threats, more so for the Ripple blockchain. The existence of Unique Node Lists for validators offers a good solution.

Performance of the Delegated Byzantine Fault Tolerant Protocol

The delegated Byzantine fault-tolerant protocol (dBFT) follows the same execution-style as BFT. It however differs by centralizing the consensus in several participants, thereby solving BFT’s scalability issues. The protocol uses the concept of a reputation for the choice of consensus participants.

NEO is one of the top players with a dBFT protocol. Its uptake has been quite subdued due to the possibility of a dangerous security threat. A malicious leader can exploit its view-change protocol to create a deterministic fork. They can then create 2 new blocks using different messages, with both blocks being valid and accepted by participants, creating two different states in the network. A solution is discarding all messages generated before view change.

Performance of Byzantine Fault Tolerant and Delegated Proof of Stake Protocol

Abbreviated as BFT-dPoS, the hybrid protocol merges the high-performing Proof of Possession protocols with the security of BFT protocols. Under the protocol, each token holder votes for a block producer, with the 21 nodes with the most votes qualifying. Each of the 21 then has fixed 0.5-second time frames to produce blocks, with the process going alphabetically.

EOSIO is one of the blockchains using the protocol. It boasts of tremendous achievements such as 3000 transactions per minute abilities and BFT security levels. The drawback is the limitation to 21 block creators, with the voting being influenced by assets held. It allows for a collision to control the process is possible.

Author’s Note

Quorum-based consensus protocols are quite recent compared to the non-quorum ones. They however pack a punch since they solve the issue of byzantine fault and allow operability as long as malicious nodes don’t form a network majority.

Their performance differs depending on the class of protocol in discussion BFTs offer huge scalability issues while FBAs offer some susceptibilities to Sybil attacks. 

dBFTs solve the scalability issue but with the creation of a view-change protocol exploit. BFT-dPoS offer what could be the best features, but pose the risk control via collusion. Uptake of quorum-based protocols is however expected to rise as the space gets more innovations.