Consensus Protocols That Serve Different Business Needs. Part II

1. Byzantine Fault Tolerance (BFT) protocols. Continued

1.1. SIEVE protocol

1.2. Round Robin Consensus

1.3. Paxos and Raft protocols

1.4. HoneyBadger Byzantine Fault Tolerance (hbBFT)

1.5. Loopchain Fault Tolerance (LFT)

1.6. Cross-Fault Tolerance (XFT)

2. Consensus Algorithms for other Demands

2.1. Proof-of-Asset (PoA)

2.2. Proof-of-Authority (PoA)

2.3. Proof-of-Brain (PoB)

2.4. Proof-of-Capacity (PoC)

2.5. Proof-of-Contribution (PoCo)

2.6. Proof-of-Stake-Time (PoST)

2.7. Leased-Proof-of-Stake (LPoS)

Previously, we have reviewed the most popular consensus protocols. In Part II, we dive into the most exotic algorithms used in distributed ledger technologies (DLTs), from variations of BFT property to Leased Proof-of-Stake, Proof-of-Stake-Time, and Proof-of-Asset consensus protocols.

1. Byzantine Fault Tolerance (BFT) protocols. Continued

Here we will mention a bunch of specifications of a particular property: Byzantine Fault Tolerance. It means that even when a node (one of the validators) fails to perform an action, the rest can still proceed without interrupting the work. Slight differences in protocol specifications help distributed systems adjust to particular conditions and be more reliable and secure.

Byzantine Fault Tolerance (BFT) algorithms ensure safety, requiring something bad will never happen, and liveness, requiring something good will eventually happen. In the early days only networks with known participants could have the BFT property. When Bitcoin and Proof-of-Work were introduced, it became possible in the public setup.

1.1. SIEVE protocol

	SIEVE protocol
Principle:	Executing operations, comparing the outputs in copies, and looking for any disparities.
Speed:	High
DLT setup:	Private permissioned blockchain
Finality:	Immediate
Example of use:	Hyperledger (beta)

Since Hyperledger is a modular framework, you have an option to add variations of consensus, and SIEVE is one of them. The standard option is PBFT or Practical Byzantine Fault Tolerance protocol which we covered last time. SIEVE and XFT are still in beta but the details are below.

SIEVE was designed to handle non-deterministic operations in blockchain code execution. When such operations are present within the code, they can produce a different output when executed by different copies in a distributed network.

SIEVE handles transactions that are usually deterministic, but which may occasionally generate different outputs. After executing all operations, it then compares the outputs across the copies:

• If the protocol detects a minor disparity among a small number of these copies, the values with disparities are sieved out
• If the disparity occurs across several processes, then the offending operation itself is sieved out

1.2. Round Robin Consensus

	Round Robin Consensus
Principle:	Multiple nodes play a key role in validating and voting for transactions, doesn’t depend on a single participant for block validation.
Speed:	High
DLT setup:	Private permissioned blockchain
Finality:	Immediate
Example of use:	Multichain, Tendermint

Round Robin consensus mechanism suits best trade finance and supply chain businesses. This algorithm assumes that validators reach consensus by signing votes for blocks. There are three types of votes:

• a pre-vote
• a pre-commit
• a commit

To receive more than two-thirds of commits means to receive commits from a two-thirds majority of validators. A block is known as committed by the network when the two-thirds majority of validators have signed and broadcasted commits for that block.

1.3. Paxos and Raft protocols

There are protocols that tolerate only crashes (crash-fault tolerant or CFT) known as Paxos and Raft. Both are faster versions of a BFT and act as a state machine replication, used by Microsoft, for example.

1.4. HoneyBadger Byzantine Fault Tolerance (hbBFT)

	HoneyBadger Byzantine Fault Tolerance (hbBFT)
Principle:	Proceeds in epochs, with a new batch of transactions appended to the (shared) committed log at the end of each epoch.
Speed:	High
DLT setup:	Permissionless / permissioned blockchain
Finality:	Immediate
Example of use:	n/a

HoneyBadger Byzantine Fault Tolerance (hbBFT) is “the first BFT atomic broadcast protocol to provide optimal asymptotic efficiency in the asynchronous setting.” Translating into plain English, HoneyBadgerBFT tolerates faults in the wild range of wide-area-networks outcompeting other BFT consensus algorithms. Nodes of HoneyBadger can stay hidden behind anonymizing relays similar to Tor; the transactions occur at different times and, thus, the protocol makes the progress at any rate the network supports.

1.5. Loopchain Fault Tolerance (LFT)

	Loopchain Fault Tolerance (LFT)
Principle:	Reduces the Round Robin model to only 2 steps, allows a limited number of nodes.
Speed:	High
DLT setup:	Private permissioned blockchain
Finality:	Immediate
Example of use:	ICON

Loopchain Fault Tolerance (LFT) is a continuation of a Tendermint (which combines DPoS + PBFT which we described in Part I) to continue the evolution of Byzantine Fault Tolerance solutions, resulting in a secure, high-performance and scalable blockchain consensus algorithm.

LFT resembles Round Robin with its three steps (a pre-vote, a pre-commit, and a commit) but reduced to only 2 steps, a limited number of nodes for block generator broadcasts, and remaining nodes participating in the voting procedure only. LFT leverages the ‘Spinning’ technique to simplify the perplexed algorithm of selecting the primary node.

1.6. Cross-Fault Tolerance (XFT)

	Cross-Fault Tolerance (XFT)
Principle:	Improved BFT consensus; combines synchronous and asynchronous protocols for communication.
Speed:	Very high
DLT setup:	Private permissioned blockchain
Finality:	Immediate
Example of use:	Hyperledger (beta)

Finally, there is a protocol that uses a combination of asynchronous and synchronous methods for network communications. Cross-Fault Tolerance (XFT) combines the speed of Crash-Fault Tolerance (CFT) and the reliability of Byzantine Fault Tolerance (BFT). As the authors of the technology describe it, “XFT cuts a corner in a smart way and ignores possible attacks that are deemed to be very costly and extremely unlikely today.”

The XFT protocol simplifies the attack model and makes Byzantine Fault tolerance feasible and efficient for practical scenarios. BFT protocols assume a powerful adversary where the adversary is able to control the compromised nodes as well as the message delivery of the entire network.

A snapshot from a study of consensus algorithms by KPMG

2. Consensus Algorithms for other Demands

However, not all enterprises are meant to be private. Some companies imply the usage of decentralized public algorithms and we will explain the most popular one not mentioned in our first article.

2.1. Proof-of-Asset (PoA)

	Proof-of-Asset (PoA)
Principle:	Tokenizing assets, often physical goods.
Speed:	High
DLT setup:	Public / private blockchain
Finality:	Immediate
Example of use:	Digix, BANKEX

When you learn about blockchain’s essence, it is an immutable and amendable ledger. Since such digital ledger allows no accounting error, it can marry a physical asset or a certificate with blockchain technology to always represent a 1:1 relationship. This approach is known as the Proof-of-Asset (PoA) protocol.

What can the PoA algorithm do apart from tokenizing gold? One can use it for

• land title deeds
• ownership titles
• stocks, bonds, debt credits, and other financial derivatives

In this regard, the Proof-of-Asset protocol is simple, flexible and reliable. It takes only slight customization and/or addition of actors into the protocol, and the system will be ready for use with other types of assets.

2.2. Proof-of-Authority (PoA)

	Proof-of-Authority (PoA)
Principle:	Known participants have the authority to validate transactions (BFT)
Speed:	High
DLT setup:	Public / private blockchain
Finality:	Probabilistic
Example of use:	POA network, Parity

Proof-of-Authority (PoA) is an algorithm used in both private and public blockchains that delivers comparatively fast transactions through a consensus mechanism based on identity — the authority of participants. It is just another name for BFT-like private blockchain environment where approved accounts validate transactions and blocks and the process is fully automated.

PoA individuals can earn the right to become validators, so there is an incentive to retain the authority once it is gained. By leveraging a reputation mechanism, validators are incentivized to uphold the transaction process, as they avoid a negative reputation.

2.3. Proof-of-Brain (PoB)

	Proof-of-Brain (PoB)
Principle:	Incentivizing participants to create and curate content stored then in a blockchain.
Speed:	Medium
DLT setup:	Public / private blockchain
Finality:	Probabilistic
Example of use:	Basic Attention Token, Steem

What if your business is a media, or a social media, a reputation network? What if you connect content creators and advertisers but none of them trusts the current system? Shared economy and value-added economy of our times require new models to solving these problems.

Proof-of-Brain (PoB) stands for user activity and encourages engagement and quality content on the relative platforms. Mining occurs by creating or interacting with content through voting (likes and comments) or real views. The more likes, comments or proved views a page gets, the more coins can be minted. This wisdom-of-the-crowd property makes Proof-of-Brain both smart and social consensus algorithm.

2.4. Proof-of-Capacity (PoC)

	Proof-of-Capacity (PoC)
Principle:	The more hard-drive disk space you dedicate, the higher chances to participate in mining.
Speed:	High
DLT setup:	Public blockchain
Finality:	Probabilistic
Example of use:	Burst

Proof-of-Space, Proof-of-Storage or Proof-of-Capacity (PoC). You name it. Proposed back in 2014, this consensus algorithm is both energy efficient and claims to be equally distributed. With the idea of “megabytes as resources,” one has to have a significant amount of memory storage to fill it with ‘plots’. The more capacity is plotted, the higher the chances to generate, or win, a block. Storj runs on a similar protocol entitled Proof-of-Retrievability which slight modifications (see Part III for this).

2.5. Proof-of-Contribution (PoCo)

	Proof-of-Contribution (PoCo)
Principle:	An off-chain consensus mechanism based on the contributed computational power.
Speed:	Low
DLT setup:	Public blockchain
Finality:	Immediate
Example of use:	iExec, CyberVein

Similar to Proof-of-Research protocol that rewards volunteers for donating their computer time to a great scientific computation [BOINC] such as astronomical observation data research (SETI@Home), Proof-of-Contribution relies on the contributed computer power for the network. That said, iExec is a blockchain-based decentralized cloud computing project.

It leverages the idea of Desktop Grid, also referred to as Volunteer Computing, which means collecting the computer resources that are underutilized on the Web to execute very large parallel applications at the fraction of the cost of a traditional supercomputer.

2.6. Proof-of-Stake-Time (PoST)

	Proof-of-Stake-Time (PoST)
Principle:	Improvement of PoS by giving a mining preference to older nodes (coins).
Speed:	High
DLT setup:	Public blockchain
Finality:	Probabilistic
Example of use:	Peercoin, VeriCoin.

In Proof-of-Stake-Time (PoST) consensus algorithm proofhash weighs less than a multiple of coins, staketime, and target. This way, participants with fewer tokens can still possess sufficient opportunity to participate in the minting (mining in Proof-of-Stake based projects). It is somewhat similar to NEM’s Proof-of-Importance (PoI) we covered in the first article, but with slight differences. For instance, when network strength is lower, the fraction of age deemed idle-time increases.

2.7. Leased-Proof-of-Stake (LPoS)

	Leased-Proof-of-Stake (LPoS)
Principle:	Let everyone participate in the PoS.
Speed:	High
DLT setup:	Public/private blockchain
Finality:	Probabilistic
Example of use:	WAVES

Leased Proof-of-Stake is a hybrid form of the PoS algorithm. In the essence, smaller participants who do not qualify for staking and, thus, minting new coins get a chance to lease their crypto assets to full nodes. This way the former get a chance to participate and earn a profit, the latter receive a higher probability of generating the next block, and the entire network becomes more decentralized.

It reminds Mining Pools, which mostly serve the Bitcoin network at the moment. Moreover, the LPoS system allows participants to do with their coins anything at any time: spend them or exchange them for altcoins. In this case, the “leasing” contract is automatically annulled and the owner of the leased coins can no longer count on the share.

Summary

We have reviewed a bulk of new consensus protocols that help businesses employ blockchain technology and fit their needs best. At the beginning we mentioned most demanded BFT protocols which are mostly present in the private blockchain environment. Then, we proceeded to more specialized algorithms that play a role in tokenization of physical assets, creating, curating, and protecting intellectual property, and ensuring stellar speeds and uptimes even in the public setting.

Based on our two articles, you should just enough about this topic. In the future articles, we will critically analyze the rest of exotic properties and variations of the biggest blockchain projects like Bitcoin, Ethereum, and ZCash. We will specifically focus on zero-knowledge (ZK) proof protocols and discuss why it matters.