Consensus Models in Public and Consortium Blockchain: Tradeoff Analysis

Authors: Lamine SANO & Othman Darwish

Abstract

In distributed systems, with multiple computing nodes, consensus is a fundamental concept that aims to achieving system reliability, with the fact that some nodes may fail, malfunction or provide malicious information. This conflict in the provided information, requires a mechanism where all nodes agree on some state; this process is called consensus. The problem was first formulated by Leslie Lamport, Robert Shostak and Marshall Pease in their 1982 paper, "The Byzantine Generals Problem,"^[1] and proved then to be unsolvable. Since then,  different algorithms were designed and developed to try and solve this problem under various assumptions. The advent of Bitcoin, and its underlying innovating blockchain technology provided a practical and radical mechanism to solve this problem and make it possible to transfer information in an entirely decentralized and trustless environment. This paper, will briefly explore the historical context for solving the Byzantine Generals Problem, and then describe today mainstream various consensus algorithms for public and consortium  blockchain networks, and analyze consensus key factors, to be able to assess them and take them into account when investing in blockchain based products and services.      

Historical Overview

The consensus model of a blockchain system defines its security and robustness. It allows the secure updating of a distributed shared state across geographically dispersed nodes connected over unreliable communications network.

Achieving consensus is a challenging problem, as the algorithms have to be resilient to nodes failures, partition of networks, delays in relaying messages, out of order and corrupted messages, selfish and intentionally malicious nodes, and still manage to achieve distributed consensus across all nodes to ensure an agreed upon consistent global state of the blockchain.

Consensus might as well be the most crucial aspect to assess when selecting/studying a blockchain platform.

The novelty of blockchain is a genuine combination of well-known research results taken from distributed computing, cryptography and game theory.

The distributed consensus problem was not introduced with the invention of Bitcoin in 2008.  Before the existence of blockchains, the concept of distributed consensus was studied in the context of distributed databases and processes.  However, blockchains systems have rekindled the field of distributed consensus with research interests geared towards the redefinition of the consensus problem in the context of blockchain to help address the major tradeoffs between consistency and performance.

Despite more than three decades of various successes in solving the consensus problem under various assumptions, it has been known to be unsolvable since 1985.

In fact, The Fischer-Lynch-Paterson impossibility result^[2] (FLP result) published in 1985 proved that in a fully asynchronous system, it is impossible to guarantee consensus when messages may be delayed if even one node may fail.

In 1982, Leslie Lamport also proved another impossibility result for 3 processes and 1 fault in his seminal paper illustrating the Byzantine generals problem^[3].

Both are known in the literature as the impossibility results, but let us rightly remark that they say more about the model’s assumptions than the problem, as in practice, solutions to these problems have been implemented.

To better fathom the above concept, a brief review of key elements of distributed systems is in order.

Background on distributed systems

Distributed systems are characterized by the following properties:

• Concurrent components
• Message sharing
• No global clock
• Potential failure of individual components

The notion of correctness of distributed system was specified in Leslie Lamport’s “Proving the Correctness of Multiprocess Programs” (1977)^[4] as follows:

“to prove that a program is correct, i.e., achieves its intended goal, one must prove that it has safety and liveness properties.”

In other words, it has to accomplish:

• Agreement (no two correct processes decide on a different value); Safety property.
• Termination (all correct processes eventually decide a value); Liveness property.

The goal of distributed systems is to have all components agree on the system’s state, i.e. reach a distributed consensus.

Distributed systems have to exhibit resilience and reliability by being fault tolerant to network and node failures, and still be able to reach distributed consensus.

CAP Theorem

Network failures, i.e. loss of connectivity introduce network partitions; this ties right into the CAP theorem which states that an asynchronous distributed system can at most provide two of the three guarantees at once, those being:

• Consistency: guarantee that reading from different nodes will return the same value. (agreement)
• Availability: guarantee that reading from any node will return some value. (termination)
• Partition Tolerance: guarantee that the system will still operate in the face of a network partition, across which some messages between nodes cannot be delivered (fault tolerance)

In a network partition context, the choice is really between Consistency and Availability.

Node Failures

Node failures can be classified into two broad categories:

• Fail-stop failure: crash, power outage, hardware failure, out of memory, which may lead to network partitions.
• Byzantine failure: flaky or malicious nodes; can send conflicting information to different parts of the system.

FLP Impossibility

The first type of node failure (fail-top) relates to the FLP impossibility paper of Fischer, Lynch, and Paterson, who, in their 1985 paper "Impossibility of Distributed Consensus with One Faulty Process" provide the proof that both termination and agreement cannot be satisfied immediately in an asynchronous distributed system, if it is to be resilient to at least one fail-stop node.

Byzantine Generals Problem

The second type of node failure (Byzantine) relates to the Byzantine fault tolerance, which is a characteristic of distributed systems that can reach consensus in the face of Byzantine faults.  This class of failure is illustrated by The Byzantine Generals’ Problem (1982 Lamport,

Shostak, and Pease), where the real issue is the degree of Byzantine failure can be tolerated.

Hence the theorem:

Theorem: No solution with fewer than 3m + 1 generals can cope with m traitors - i.e., consensus is impossible to achieve if ⅓ or more of the generals are traitors.

Therefore, in a Byzantine fault tolerant system, Safety and Liveness are guaranteed so long as more than ⅔ of the nodes are non-faulty and the model assumes synchronicity.

Early solutions to distributed consensus

Paxos

The first solution elaborated to solve the above was Paxos, described in the Part time parliament (Lamport, 1987)^[5].  The approach uses two phase mechanism and majority quorums to accomplish consensus.  It is not byzantine fault tolerant, as it assumes fail-stop failures.  It guarantees safety over liveness.

Paxos model was designed to reach agreement over a single value in a scenario where failure might occur.

Nowadays, it has also found practical applications in distributed ledger based technologies as a consensus mechanism, which we will review in the consortium/private section of this study.

Over the years, several improvements have been made over the original Paxos protocol to introduce efficiency improvements.

Some notable implementations include Byzantine Paxos, EPaxos (Leaderless byzantine)

A novel approach to consensus in Paxos is flexible Paxos from Heidi Howard, where she demonstrates that a majority quorum is not necessary to reach consensus.  This observation makes possible a new breed of scalable, performant, and resilient consensus algorithms.

Raft

The difficulties of understanding and implementing Paxos led to the development of Raft^[6], which was more focused on understandability.

Raft follows a strong leadership model for its implementation.  It achieves consensus through a leader election process and a replicated leader append-only log managed by the leader for the term.

Raft is not BFT tolerant, but there is a proposal called Tangaroa at Stanford University which proof the concept of the possibility of an BFTRaft implementation.

Juno forked Tangaroa as a basis for its hardened BFT Raft implementation which seems to be no longer being actively developed.

Practical Byzantine Fault Tolerant

Introduced in 1999 by Miguel Castro and Barbara Liskov,^[7] PBFT is one of the first solutions to the Byzantine generals problem.

Assumptions of the model:  Medium reliable and all nodes responsives.  Liveness is guaranteed, multistage process.  It runs with pre-selected nodes, mostly in the context of permissioned blockchains.

PBFT runs very efficiently.

• + High transaction throughput

• - Centralized/permissioned

Consensus Mechanisms in Public Blockchain

Nakamoto Proof of Work Consensus

Bitcoin^[8] uses the Hashcash like POW function as the consensus mechanism for miners to cast a vote in the Bitcoin network to secure the blockchain.  It uses external resources, i.e. infrastructure (equipment, power, cooling) to achieve this, therefore ensuring that mining bitcoin is a hard and an expensive proposition.

Consequently, the trust, or security model of bitcoin is achieved through computation of a hard to solve cryptographic hashing puzzle, which is difficulty adjusted every two weeks based on the available hashing power over that period to maintain an average of 10 mins block production interval; this mechanism ensure randomization.

This is bitcoin’s solution to the double-spend problem through mining, which incidentally solves three different problems at once:

• Double-spend problem
• Initial distribution of the currency through coinbase rewards
• Incentivized mining to provide the proof-of-work necessary to secure the network

Miners are incentivized to mine on the longer chain.

Bitcoin is an eventually consistent system, meaning that all nodes on the network will eventually share a common view of the state of the blockchain over a long period of time.  As such, it favors liveness over safety.

Bitcoin’s POW model introduced incentives and randomness as a way around the impossibility results well known in the distributed computing world, but which were intended to study distributed databases using a very specific model which does not fit the paradigm of Bitcoin.  Hence, distributed consensus in Bitcoin is cleverly solved in the specific context of a currency system.

Trade-offs:

• + It has proven to work
• + Permissionless, open

• - Centralization of mining to a few professional firms
• - Excessive energy consumption
• - Throughput and Scaling issues
• - Probabilistic finality of transaction
• - Governance issues
• - No immediate finality

Proof of something else

The general principle behind those alternatives to POW is to expend some resource to cast a vote

Nakamoto Proof of stake Consensus aka virtual mining

The proposition is to remove the wasteful equipment and energy expenditure to mine bitcoins by favoring instead a model based on currency holdings, an internal resource.

Since Bitcoin mining is now akin to an arms race, where what really matters is who can invest the most in equipment and energy to get the most rewards, why not eliminate this wasteful step by directly allocating mining “power” in proportion of currency holdings?

Hence, computational puzzles are replaced by virtual mining and the voting system is maintained.

In this scheme, mining is done by a stakeholder who is selected by the network in proportion to their ownership of the currency. Miners are known as validator nodes.  Unlike PoW, there is no reward for the block miner in the PoS system. The miners get the transaction fees instead for voting on blocks.

The above is referred to as naive PoS, as the biggest issue relates to the nothing-at-stake problem, meaning miners can mine on both chains without any penalties should a fork occur.

This issue has been addressed by introducing a mechanism called slashing, which penalizes bad behavior of miners.  Their stake is generally locked-up as a security deposit, or bonded based on the protocol implementation, for a certain duration based on the implementation.

Another issue which is raised by the above is the long range attack to which the proposed  solution is to make the unbonding period longer compounded with weak subjectivity

PoS has been implemented with different design variants in a number of cryptocurrencies.

Examples of PoS coins include: Peercoin, Blackcoin, NXT

Example of PoS protocol include: Casper (Ethereum), Tendermint

Tradeoffs:

• + Eliminates waste by simplifying the process
• + Reduces environmental footprint
• + Reduced risk of centralization as no need for mining hardware
• + Levels the playing field for miners
• + Incentivizes large stakeholders to be good stewards of the system

• - Puzzle easier for large stakeholders
• - 51% stake holding issue ( The rich getting richer and monopolizing the creation of blocks)
• - Nothing-at-stake problem
• - No immediate finality

Proof of activity

Hybrid between POW and PoS. 2 phase process;It was designed to address the issues of naive PoS.

• Miners solve the crypto-puzzle and submit block headers to system (w/o any transactions, they are more like templates); the winning block will only contain a header and the miner's reward address.
• Validators chosen to vote on valid blocks proportional to their stake, receiving awards for signing.
• Resources: PoW ( Electricity, HW, cooling power) and PoS ( native currency)

Proof of burn 

It is used to show that the miner has done something really hard without expending real resources like electricity, and consists in sending some coins to some unspendable address; more coin burned, higher likelihood of voting

• Also used as bootstrapping mechanism ( tie a coin’s value to some other coin or transition into another cryptocurrency); demonstrate users’ willingness to burn Bitcoin to receive this other coin.
• Resources: currency ( potentially not native) - Waste! 

Proof of space/capacity

Uses disk space to solve some challenge

• Nowadays used for file storage
• Two variations on implementation:  receive coins after voting or give rewards for storing
• Resource:  Memory

Proof of elapsed time:

Spends time instead of mining power - randomization

• TEE using intel SGX
• Resource consumed:  time

Voting based consensus Algorithms

Delegated proof of stake ( Bitshares, Steem, EOS, Ark, Lisk)

DPoS^[9] aims to address the issues raised in the PoS consensus scheme.  Indeed, the latter more advantageous to large coin holders compared to small balance owners, who are clearly at a disadvantage.

DPoS aims at making PoS more efficient by providing  more decentralization in the issuance of stake rewards to more people.

DPoS uses a reputation system and real-time voting to achieve consensus through a panel of trusted parties (Delegates or Witnesses) which can create blocks.  Those witnesses are voted by the community at large, and can be removed if bad behaviour is observed.

• + Efficient
• + Fast
• + Cost effective

• - Requires a level of trust

Federated Byzantine Agreement ( Stellar, Ripple)

This is another category of solution to the Byzantine generals problem used in Ripple and Stellar cryptocurrencies.

The principle is based on a flexible trust model and quorum slices.

In Ripple, validators are pre-selected by the Ripple foundation.

In Stellar, everyone can be a validator and choose which other validators to trust based on the Stellar Consensus Protocol

• + Fast
• + Immediate finality

• - Requires semi-trust

Others/Proposals:  

Directed Acyclic Graphs based proposals

Tangle (IOTA^[10])

The tangle is used for reaching consensus instead of PoW as in Bitcoin.  The tangle makes use of DAG instead of blocks and as such, it is qualified as a blockless cryptocurrency where every submitted transaction represents a node in the DAG structure.

Every user is a miner, and for a transaction to be verified a user must verify two or more previous transactions by doing some PoW ( for spam and sybill resistance) before the user’s own transaction can get approved.  This structure results in a Tangle network which throughput increases as more people join.

• +Lightweight
• + No fees
• + blockless
• + Fast

• - centralized

Hashgraph^[11] (SWIRLS)

It is a recent alternative to Nakamoto PoW and PoS consensus mechanisms.

The prime mechanism of Hashgraph is its use of the GOSSIP protocol in a similar topology as the Tangle.

The hashgraph is a new data structure which is a hybrid of a hash and a graph.

Message propagation in GOSSIP is exponential and efficient as it happens between pairs of peers randomly selected.

What is rather interesting is the ability of this protocol to gossip about gossip, i.e. nodes propagate the history of the gossip itself for little additional burden on the protocol; every node end up having a copy of the hashgraph and can therefore deduce the voting activity (virtual voting) of each peer without a single vote ever being sent, and reach a Byzantine agreement on any number of decisions.

From what it appears, its is extremely efficient, and exhibits some interesting properties:

• Fair (ordering, filtering)
• Fast (throughput, latency)
• Provable
• Byzantine
• ACID compliant
• Efficient
• Inexpensive
• Timestamped
• DoS resistant
• Non-permissioned

To date, only permissioned implementations have been implemented. It remains to be tested in a permissionless environment.

Consensus Mechanisms in Consortium  Blockchain

Many of today consortium/enterprises  blockchain platforms use Byzantine Fault Tolerance -BFT derivative algorithms to achieve consensus between participating nodes.  Unlike public blockchain consensus models, which depends on probabilistic and incentive-based approaches, such as mining or proof of something , BFT consensus, in consortium blockchain, have to follow a deterministic mechanism to tolerate faulty nodes. Consensus in consortium blockchain networks is usually built with a structure where there is a predefined number of distributed nodes, that will be pre-authorized and reasonable of consensus. And some go further and assume that some nodes may play another particular extra role.

This section describes some notable consensus protocols that are used in today mainstream consortium blockchain platforms:

Hyperledger Fabric – Apache Kafka and PBFT

HyperLedger Fabric^[12], separate the execution/validating of chaincode (aka smart contract ) transactions, from those nodes which are responsible of ordering of the block of the transaction and agreement on them ( consensus ); the target of such design is to allow the network scalability and increase the transactions throughput. The ordering service ( consensus protocol ) formed of Kafka cluster with it corresponding ZooKeeper ensemble. Kafka is distributed streaming platform which guaranteed sequence reads of written blocks; when an order service node writes a transactions block to Kafka cluster, all other order service nodes is guaranteed to get the latest created block and append new one on it. Fabric with Kafka consensus can be seen as crash fault tolerance -CFT protocols but not BFT. Due to the modular design of Fabric, where the consensus protocols not hardcoded in the blockchain, a second implementation of the ordering service in under development which based on PBFT, the aims to give the ordering service the ability to achieve agreement even with faulty or malicious nodes^[13]

Sawtooth Lake – Proof of Elapsed Time

Unlike Bitcoin PoW, where validating nodes ( miners ) have to be delayed a duration of time, by solving a cryptographic puzzle, in order to prove their work and self-elected for block creation and reward, Sawtooth Lake^[14], which originally  contributed by Intel as one of HyperLedger project, introduced new consensus protocol called Proof of Elapsed Time -PoET, which imposes stochastically on validating peer a delayed duration of time,  the peer with less wait time is the winner, and elected as leader and can update the ledger and create next block , other validating peer should easily verify that elected peer has waited the time duration and not cheating. Cheating is prevented by using a trusted execution environment, this is done by a hardware module, the Intel Software Guard Extension -SGX available in many modern Intel processor. Every validating node call enclave inside the SGX module, asking for random delay of time, and waiting that time duration accordingly, and then act to be the leader. Attestation implemented by the platform that enable any node to verify the elected leader.  Assuming that SGX module cannot be tamper, and the SGX module run in trusted authentic permissioned nodes, running traditional BFT consensus protocols, in trusted nodes performing much better than PoET, in addition PoET relay on solo hardware provider -Intel SGX .

R3 Corda – Pluggable Consensus

Unlike most of permissioned blockchain, R3 Corda^[15] does not build its distributed ledger on blockchain, instead, it’s based on transactions chain. Corda inherit Bitcoin Unspent Transaction Output- UTXO model, where each transaction on the ledger has zero or more input, and zero or more output. The consensus in Corda is achieved by making sure of transaction uniqueness; in other words, in order to commit new transaction in the transaction chain, special node, namely notary service (one or more node) validate that this transaction input never used (aka double spend) in another chain transaction. Corda designed with pluggable consensus in mind, that enable notary nodes to adopt different consensus mechanisms based on their business requirements, some notary service could run on high speed high trust algorithm such as RAFT, and other may choose to run in low speed low trust BFT algorithm. Participating nodes needs to appoint their notary service when creating transacting each other. They even can ignore the notarization part if both party agree on that. Based on Corda distributed ledger design and philosophy, we can see that consensus mechanism is left freely for businesses to decided based on the level of trust and needed throughput

Tendermint -  variant of PBFT

Tendermint^[16] best described as an invariant of PBFT protocol. It built with a unique design that consists of two component: consensus engine which called Tendermint Core, and the application interface called Application BlockChain Interface-ABCI. This separation enables developers to use Tendermint core as BFT state machine replication from different programming language and development environment. Tendermint most significant invariant form traditional PBFT is the continuous rotation of the leader; the leader changed after every block. Tendermint works as a round-based approach, where each round consists of a three-step process: validator propose block, signal commitment intends, and then sign to commit new blocks. By completing that three-step this constitutes one round, and a block is created. But it may take server rounds before a block is committed to ledger due to network asynchrony. In case the proposer validator become off-line or the network experiencing a latency, Tendermint allows a validator to be ignored; validators will wait a small amount of time, to receive a complete proposal block from the proposer, before deciding to move to next block round. The dependency on timeout from other validators, making Tendermint a weakly synchronous protocol. However, the rest of the protocol is asynchronous, and validators only make progress after hearing from more than two-thirds of the validator set.

Symbiont – BFT-SMaRt

Symbiont Assembly ^[17] is distributed  ledger platform, that focus its use cases and proposed  applications on the financial industry. It uses Apache Kafka as distributed immutable append only message log, which is scalable message broker and widely used. Unlike Kafka which is Crash Fault Tolerant -CFT, Symbiont Assembly designed to be BFT, by using a consensus protocol called BFT-SMaRt . BFT-SMaRt is an open-source Java-based library implementing robust BFT state machine replication, Symbiont implemented this protocol in another programing language. In BFT-SMaRt consensus , client send a message to all replica, and this trigger the consensus protocol, each consensus instance begin with one replica – the leader – which proposing a batch of transaction to be decided in that consensus, all other replica that receive that proposal verify if the sender is the leader, and the batch is valid, if so, they send write instruction to all other replicas containing cryptographic hash of proposed batch, if the leader receives configured number of write instructions with the same hash of proposed batch, it send accept instruction to all other replicas containing this hash. If some replica receives accept messages for the same hash, it delivers its correspondent batch as the decision for its respective consensus instance. Symbiont report a performance numbers of 80K TPS using a 4-node cluster on a LAN

Chain – Federated Consensus

Like Symbiont , Chain^[18] distributed ledger focus in financial industry , it target  to be infrastructure for consortium to issue and transfer asset on permissioned network . Chain operated by a number of nodes that form the network. One node is statically selected to perform federated consensus. That node called block generator, which periodically batch a number of new, non-executed transactions, and assemble them on a block, then it sends that block requesting for approval from the signer nodes.  Each signer node verifies the signature of the block generator, the transaction batched in the new proposed block, for given block height, and endorse that block. Each signer endorses only one block at each height.  The protocol is resilient to a number of malicious signers but not to a malicious block generator. If the block generator violates the protocol (e.g., by signing two different blocks for the same block height) the ledger might fork. more important, if the generator crashes, the protocol halts and requires manual intervention, and this against standard BFT specification

Quorum^[19] – QuorumChain and Raft

Quorum is an Ethereum-based blockchain, developed by JPMorgan to provide financial industry a platform to use distributed ledger technology that supports transactions and smart contract privacy. Quorum node is based on Ethereum geth node, with a replacement  of Ethereum PoW consensus by  QuorumChain consensus which is vote-base consensus mechanism, QuorumChain uses special smart contract to implement the voting and build the agreement when creating new block; the smart contract deployed at a predefined address, and have predefined roles; voter and maker. Upon deployment of voting smart contract the, contract contain hardcoded maker address, that maker could add or remove another maker later. The voting smart contract track number of votes received from a valid voter and weather number of votes reaches predefined threshold as defined in that contract. One can see following this approach, that there is one maker node, and any act as a malicious node, network chain fork more likely will happen, and running only one maker node, would create a single point of failure, if this node crash, the entire network halt. Quorum has another consensus flavor based on Raft consensus mechanism. Raft consensus is a variant of Paxos mechanism.

Key Factors and Tradeoff

The table below is a summary of the different classes of consensus protocols reviewed in this paper and the tradeoffs identified.

	PoW	PoS	PoET	BFT& variants	Federated BFT	DAG	Hasgraph
Type	permissionless	both	both	permissioned	permissionless	permissionless	both
Trust	untrusted	untrusted	untrusted	semi-trusted	semi-trusted	trustless	Trusted implementations so far
Speed	low	high	medium	high	high	high	high
Finality	probabilistic	probabilistic	probabilistic	immediate	immediate	probabilistic	immediate
Cost	yes	yes	no	no	no	no	no
Token	yes	yes	no	no	yes	yes	no
Scalability	high	high	high	low	medium	medium	medium
Attack threshold	51%	Depends on implementation	?	<= 33%	<= 33%	<= 33%	<= 33%

Conclusion

The goal of distributed systems is to have all components agree on the system's state, i.e. reach a distributed consensus. It is obvious that in the distributed system, there is no one consensus algorithm that fit all sizes. The FLP impossibility (1985) and CAP theorem (2000), proof that the asynchronous fault-tolerant systems cannot simultaneously satisfy Liveness (Termination) and Safety (Agreement) properties, Today, Blockchain technology, from technical point of view, is all about a new reformulation of Byzantine General Problem, and challenged to solve the classical Byzantine consensus problem.

In public blockchain, Satoshi PoW consensus presented a practical and radical solution for solving the Byzantine Generals' Problem, in a fully decentralized trustless environment.  In Satoshi consensus, the Correctness, lead miners to select the longest chain, and this well produces  forks in the network. Thus PoW favors liveness (availability) over safety (consistency). The same applied to naive PoS consensus mechanism; deviation in the miner results will lead to network continues forks. Thus, it also favors liveness over safety.

 In consortium blockchain, data inconsistency  is not acceptable, liveness and safety should be satisfied, hence Practical  Byzantine Fault Tolerance -PBFT algorithms improved to satisfy such needs, in which one-third of the network nodes can have  byzantine fault,  liveness and safety simultaneously could be satisfied, given that two-thirds of the consensus nodes are not faulty or malicious , and this requires a synchronicity of the network.

---

[1] LESLIE LAMPORT, ROBERT SHOSTAK, and MARSHALL PEASE SRI International :The Byzantine Generals Problem  http://www-inst.eecs.berkeley.edu/~cs162/fa12/hand-outs/Original_Byzantine.pdf

[2] MICHAEL J. FISCHER  Impossibility of Distributed Consensus with One Faulty Process https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf

[3] Lamport, L.; Shostak R.; and Pease, M. "The Byzantine Generals Problem." ACM Trans. Prog. Lang. Sys. 4, 382-401, 1982. http://research.microsoft.com/users/lamport/pubs/byz.pdf

[4] Proving the Correctness of Multiprocess Programs, IEEE Transactions on Software Engineering SE-3, 2 (March 1977), 125-143.

[5] The Part-Time Parliament, ACM Transactions on Computer Systems 16, 2 (May 1998), 133-169.  Also appeared as SRC Research Report 49.  This paper was first submitted in 1990

[6] D. Ongaro and J. K. Ousterhout. In search of an understandable consensus algorithm. In USENIX Annual Technical Conference, pages 305–319, 2014.

[7] M. Castro and B. Liskov. Practical Byzantine fault tolerance and proactive recovery. ACM Trans. Comput. Syst., 20:398–461, Nov. 2002. http://www.disi.unitn.it/~montreso/ds/papers/PbftTocs.pdf

[8]  S. Nakamoto. Bitcoin: A peer-to-peer electronic cash system. https:// bitcoin.org/bitcoin.pdf, Dec 2008.

[9] http://docs.bitshares.org/bitshares/dpos.html

[10] http://iotatoken.com/IOTA_Whitepaper.pdf

[11]  http://www.swirlds.com/downloads/SWIRLDS-TR-2016-02.pdf

[12] Hyperledger Fabric Project https://hyperledger.org/projects/fabric

[13] Christian Cachin Marko Vukoli´c IBM Research - Zurich Blockchain Consensus Protocols in the Wild https://arxiv.org/pdf/1707.01873.pdf

[14] Hyperledger Sawtooth project :https://hyperledger.org/projects/sawtooth

[15] Corda open source project :https://www.corda.net/

[16] Tendermint BLOCKCHAIN CONSENSUS :https://tendermint.com/

[17] Symbiont Assembly https://symbiont.io/technology/

[18] Chain blockchain  :https://chain.com/

[19]JP-Morgan Quorum distributed ledger :https://www.jpmorgan.com/global/Quorum

  

•