Importance of consensus modes and governance of DLT

Updated: Jun 9, 2019

The consensus methods of DLTs largely determine the scalability of the infrastructure, and, in general, scalability features need to be implemented. Therefore, these topics should be discussed together. In this article, we discuss consensus. We will discuss scalability in a separate article.

Types of consensus algorithms


Technical developments on consensus modes

Various teams are currently working on their implementation of PoS, DPoS, and PBFT, or a combination of the above, to improve scalability, rapidity and other features. We will cover some scalability aspects in this section. We provided an extensive DLT platforms comparison using different consensus modes in the previous sections.

This may be the time to cover a blind spot; even if it is not new. As yet, we haven’t taken the opportunity to dive into the Federated Byzantine Agreement (FBA) consensus mode (used in particular for Stellar Lumens). Its specifics are interesting, and its impressive characteristics are worth looking at.

The FBA model (used in the Stellar Consensus Protocol), is an approach to the consensus that has nothing to do with PoW or PoS. This means that the network agrees on a statement if a majority of its participants agree on it; the threshold is usually 2/3 of loyal participants to counterbalance a maximum of 1/3 malicious nodes.

With FBA, as opposed to Byzantine Fault Tolerant mechanisms, the list of validating nodes is not established in advance by a central authority. In FBA, anyone can join, and every node decides which other nodes they trust, which forms a “Quorum Slice.” Quorum slices, by design, must overlap, together building the whole network consensus, and thereby gossip on positions by the node can spread across quorum slices.

In a synchronous distributed system—according to the FLP Impossibility Proof—at most, two of the three following properties can be achieved by the consensus method: fault tolerance, safety, and liveness.

Fault tolerance is the guarantee that the system will survive if a validator on the network fails at any time. Most consensus protocols choose fault tolerance as one of their preferred properties. The big tradeoff remains on the choice between safety or liveness as their second favored property.

Safety is the guarantee that nothing wrong will happen, like a fork. Liveness is the guarantee that transactions will always be processed. FBA favors security over liveness; whereas, in blockchains, liveness is favored. Hence forks are possible.

Periodically, the whole network goes through a cycle of validation. First, at the level of the Quorum slices, all participating nodes essentially go through continuous rounds of voting until they can agree on a statement. Once a consensus is reached in the quorum slice, voting then occurs at the higher level. Of course, every node maintains the same view of the ledger.

Consequently, transactions merely need to be passed to the network, and safety means that no confirmation time is required; this allows for fast transaction processing: in the range of 3-5 seconds. Another consequence is the removal of the risk of attack by considerable computing powers. The fee is reduced to the very minimum, which is mainly to prevent spamming the network; and therefore, not a lot of full nodes are running—due to lack of incentive.


All evidence points out that the governance of blockchains is going to be a growing concern. One indication of this is that Ethereum is delaying its Constantinople update, not because the fix to the problem is not ready, but rather to have sufficient time to convince the community and to coordinate miners to ensure avoiding a hard fork. But, as of now, this topic of tediously steering the blockchain protocol evolution is well below the radar, with scalability being the focus. Article writers and panelists in various discussions are identifying the issue, but only limited research efforts have been made to date.

Hard forks

In November we witnessed the fork of Bitcoin Cash, which gave birth to Bitcoin Satoshi Vision. Bitcoin SV claims to strive for address stability, scalability, and security. But for now, it hasn’t changed much since the fork. Furthermore, they are somewhat self-contradictory in wanting to retain the original concept of bitcoin, yet wanting it to evolve.

Check the full version of Blockchain Quarterly (Q1 2019) report for more Insights.

21 views0 comments