Blockchain Consensus Algorithms: A Survey1 Blockchain Consensus Algorithms: A Survey Md Sadek...

1

Blockchain Consensus Algorithms A SurveyMd Sadek Ferdous Member IEEE Mohammad Jabed Morshed Chowdhury

Mohammad A Hoque Member IEEE and Alan Colman

F

AbstractmdashIn recent years blockchain technology has received unpar-alleled attention from academia industry and governments all aroundthe world It is considered a technological breakthrough anticipated todisrupt several application domains touching all spheres of our livesThe sky-rocket anticipation of its potential has caused a wide-scaleexploration of its usage in different application domains This has resul-ted in a plethora of blockchain systems for various purposes Howevermany of these blockchain systems suffer from serious shortcomingsrelated to their performance and security which need to be addressedbefore any wide-scale adoption can be achieved A crucial componentof any blockchain system is its underlying consensus algorithm whichin many ways determines its performance and security Therefore toaddress the limitations of different blockchain systems several existingas well novel consensus algorithms have been introduced A systematicanalysis of these algorithms will help to understand how and why anyparticular blockchain performs the way it functions However the existingstudies of consensus algorithms are not comprehensive Those studieshave incomplete discussions on the properties of the algorithms andfail to analyse several major blockchain consensus algorithms in termsof their scopes This article fills this gap by analysing a wide range ofconsensus algorithms using a comprehensive taxonomy of propertiesand by examining the implications of different issues still prevalent inconsensus algorithms in detail The result of the analysis is presented intabular formats which provides a visual illustration of these algorithmsin a meaningful way We have also analysed more than hundred topcrypto-currencies belonging to different categories of consensus al-gorithms to understand their properties and to implicate different trendsin these crypto-currencies Finally we have presented a decision treeof algorithms to be used as a tool to test the suitability of consensusalgorithms under different criteria

Index TermsmdashBlockchain Distributed Consensus Proof of Work PoWProof of Stake PoS Delegated Proof of Stake DPoS

1 INTRODUCTION

In the last few years blockchain has received wide-spreadattention among the industry the Government and aca-demia alike This interest has been piqued by the success

M S Ferdous is with Shahjalal University of Science and Technology Sylhet3114 Bangladesh and Imperial College London London SW7 2AZ UK E-mail sadek-csesustedu

Mohammad Jabed Morshed Chowdhury is with La Trobe University Mel-bourne Victoria-3086 Australia E-mail mchowdhurylatrobeeduau

Mohammad A Hoque is with University of Helsinki 3835 Helsinki HelsinkiFinland E-mail mohammadahoquehelsinkifi

Alan Coleman is with Swinburne University of Technology HawthornAustralia E-mail acolmanswineduau

of Bitcoin [1] that was introduced in 2008 While crypto-currencies have emerged as the principal and the most pop-ular application of blockchain technology many enthusiastsfrom different disciplines have identified and proposed aplethora of applications of blockchain in a multitude ofapplication domains [2] [3] The possibility of exploitingblockchain in so many areas has created huge anticipationsurrounding blockchain systems Indeed it is regarded asone of the fundamental technologies to revolutionise thelandscapes of the identified application domains

A blockchain system is fundamentally a distributedsystem that relies on a consensus algorithm that ensuresagreement on the states of certain data among distributednodes A consensus algorithm is the core component thatdirectly dictates how such a system behaves and the per-formance it can achieve Distributed consensus has beena widely studied research topic in distributed systemshowever with the advent of blockchain it has receivedrenewed attention A wide variety of crypto-currenciestargeting different application domains has introduced anarray of unique requirements that can only be satisfied bytheir corresponding consensus mechanisms This fact hasfuelled the need not only to examine the applicability ofexisting consensus algorithms in newer settings but also toinnovate novel consensus algorithms Consequently severalconsensus algorithms have emerged each of which pos-sesses interesting properties and unique capabilities

As the characteristics of various types of blockchainsystems are fundamentally dependent on the consensusalgorithms they use a systematic analysis of existing con-sensus algorithms is required It is necessary to examinecompare and contrast these algorithms There have a beena number of attempts aiming to fulfil this goal can be foundin [4] [5] [6] [7] [8] [9] [10] In particular the works carriedout by Cachin et al [4] and Bano et al [5] are noteworthy asthey represent the pioneer works in this scope Cachin et alin their work have explored different aspects of distributedsystems and consensus and focused on consensus algorithmdeployed in blockchain systems that are not to open tothe public On the other hand the focus of the work byBano et al is more general in the sense they have exploredconsensus algorithms used both in public as well as privatesystems Another exceptional work is by Wang et al [6] inwhich the authors have presented a comprehensive surveyof different aspects of consensus mining and blockchainsin a detailed fashion

However all these works have some major shortcom-

arX

iv2

001

0709

1v2

[cs

DC

] 7

Feb

202

0

2

ings For example the factors upon which the consensusalgorithms have been analysed are not comprehensiveImportantly a wide range of consensus algorithms andtheir internal mechanisms utilised in many existing crypto-currencies have not been considered at all In addition allof these studies have failed to capture the practical interrela-tion between blockchain systems (mostly crypto-currencies)and their corresponding consensus algorithms All in allthere is a pressing need for a study that analyses a widerange of existing consensus algorithms and the blockchainsystems in a practical-oriented way and synthesises thisanalyses into a conceptual framework in a concise yet com-prehensive manner The principal motivation of this articleis to fill in this gap

Contributions The main contributions of the article arepresented below

bull A novel taxonomy of consensus properties capturingdifferent aspects of a consensus algorithm has been cre-ated In this taxonomy consensus algorithms have beencategorised in two major categories incentivised andnon-incentivised algorithms which have been againsub-divided as per different considerations Consensusalgorithms belonging to each sub-category analysedtogether using the taxonomy of consensus properties

bull The analysis of each sub-category has been summarisedin tabular formats so as to visually represent it in acomprehensible way

bull For each category (and the sub-category if any) the cor-responding blockchain systems (predominantly crypto-currencies) have been analysed as well The ana-lysis result has been presented in a concise fashionwhich can be used to understand the inter-relationbetween these systems and their underlying consensusalgorithms

bull The major issues in each category of consensus al-gorithm have been examined in detail and their im-plications have been further analysed

bull Over hundred crypto-currencies belonging to differentconsensus algorithms have been examined to under-stand their different properties These properties thenhave been utilised to analyse and identify differenttrends among these crypto-currencies

bull Finally a decision tree of consensus algorithms havebeen presented This tree can be utilised to test the suit-ability of a consensus algorithm under certain criteria

In short with these contributions this article represents oneof the most comprehensive studies of blockchain consensusalgorithms as of now

Structure In Section 2 we present a brief background on dis-tributed consensus highlighting its different componentstypes and properties Section 3 outlines a brief presentationon blockchain covering its different aspects such as typesproperties layers A taxonomy of consensus algorithms andtheir underlying properties is presented in Section 4 Section5 and Section 6 analyse different incentivised consensusalgorithm whereas Section 7 examines the different non-incentivised consensus algorithms Finally we conclude inSection 8 with a detailed discussion on different issuesinvolving the analysed consensus algorithms and the cor-

responding crypto-currencies

2 BACKGROUND DISTRIBUTED CONSENSUS

Consensus mechanisms in distributed systems have beena well studied research problem for nearly three decadesSuch mechanisms enable consensus to be achieved regard-ing a shared statedata among a set of distributed nodesThe need for a shared state originated the notion of replic-ated database systems in order to ensure resilience againstnode failures within a network Such database systemsensure that data is not lost when one or more nodes failto function in an excepted fashion

The notion of the replicated database can be generalisedwith the concept of State Machine Replication (SMR) [11]The core idea behind SMR is that a computing machine canbe expressed as a deterministic state machine The machineaccepts an input message performs its predefined computa-tion and might produce an outputresponse These actionsessentially change its state SMR conceptualises that such astate machine with an initial state can be replicated amongdifferent nodes If it can be ensured that all the participatingnodes receive the same set of input messages in the exactsame order (the phenomenon known as atomic broadcast)then each node would be able to evolve the states of itsstate machine individually in exactly the same fashion Thiscan guarantee consistency and availability regarding thestate of the machine (as well as data it holds) among all(applicable) nodes even in the presence of node failuresOnce this occurs it can be said that a distributed consensushas emerged among the participating nodes It is imperativethat a protocol is defined to ensure timely disseminationand atomic broadcast of input messages among the nodesand in many ways dictates how a distributed consensus isachieved and maintained Hence such a protocol is aptlycalled a consensus protocol

Designing and deploying a consensus protocol is a chal-lenging task as it needs to consider several crucial issuessuch as resiliency against node failures node behaviournetwork partitioning network latency corrupt or out-of-order inputs and so on [7] Schneider pointed out thatthere are two crucial requirements to reach and maintainconsensus among distributed nodes The first requirementis a deterministic state machine The second requirement isa consensus protocol to disseminate inputs in a timely fashionand to ensure atomic broadcast among the participatingnodes At the same time the consensus protocols mustensure the properties of the atomic broadcast [12] [13][4] [5] The properties of atomic broadcast in distributedconsensus is illustrated in Table 1

One way to achieve the design goals of such a protocolis to make certain assumptions under which the protocol isproved to function properly These assumptions influencethe critical characteristics of a consensus protocol Nextwe explore two sets of widely-used assumptions for anydistributed consensus protocol

The first set of assumptions are about the underly-ing networking type Dwork et al categorised three typesof networks exhibiting different properties synchronousasynchronous and partiallyeventually synchronous [22]The latency involved in delivering a message to all nodes

3

Properties Note

ValidityThis guarantees that if a message is broadcast bya valid node it will be correctly included withinthe consensus protocol

AgreementThis is to guarantee that if a message is de-livered to a valid node it will ultimately bedelivered to all valid nodes

Integrity This is to ensure that a message is broadcastonly once by a valid node

Total Order This is to ensure that all nodes agree to the orderof all delivered messages

Table 1 Atomic broadcast Properties of Distributed Con-sensus Protocols

Properties Note

Safety Con-sistency

A consensus protocol is considered safe (or con-sistent) only when all nodes produce the samevalid output according to the protocol rules forthe same atomic broadcast

Livenessavailability

If all non-faulty participating nodes produce anoutput (indicating the termination of the pro-tocol) the protocol is considered live

FaultTolerance

It exhibits the networkrsquos capability to performas intended in the midst of node failures

Table 2 Properties of Distributed Consensus Protocols

in a synchronous network is bound by some time denotedas ∆ On the other hand the latency in an asynchronousnetwork cannot be reliably bound by any∆ Finally in a par-tiallyeventually synchronous network it is assumed thatthe network will eventually act as a synchronous networkeven though it might be asynchronous over some arbitraryperiod of time

The second set of assumptions is about the differentproperties of a consensus protocol According to [7] a con-sensus protocol should have the following three propertiesnamely consistency availability and fault tolerance Theseproperties are elaborated in Table 2 A well-known theoremby Fischer Lynch and Paterson [23] called FLP Impossibilityhas shown that a deterministic consensus protocol cannotsatisfy all three properties described above in an asynchron-ous network It is more common to tend to favour safety andliveness over fault tolerance in the domain of distributedsystem applications A related theorem is the CAP theorem[24] which states that a shared replicated datastore (or moregenerally a replicated state machine) cannot achieve bothconsistency and availability when a network partitions insuch a way that an arbitrary number of messages might bedropped

In addition to the above assumptions there are twomajor fault-tolerance models within distributed systemscrash failure (or tolerance) and Byzantine failure [5] [7][4] The crash failure model deals with nodes that simplyfail to respond due to some hardware or software failuresIt may happen any time without any prior warning andthe corresponding node remains unresponsive until furtheractions are taken Byzantine failure on the other hand dealswith nodes that misbehave due to some software bugs orbecause of the nodes being compromised by an adversaryThis type of failure was first identified and formalised byLeslie Lamport in his seminal paper with a metaphorical

Byzantine Generalrsquos problems [14] A Byzantine node canbehave maliciously by arbitrarily sending deceptive mes-sages to others which might affect the security of distrib-uted systems Hence such nodes are mostly relevant inapplication with security implications

To handle these two failure models two correspondingmajor types of consensus mechanisms have emerged Crash-tolerant consensus and Byzantine consensus [4] Next webriefly discuss each of them along with their associatedproperties

1) Crash-tolerant consensus Algorithms belonging to thisclass aim to guarantee the atomic broadcast (total or-der) of messages within the participating nodes in thepresence of certain number of node failures Thesealgorithms utilise the notion of views or epochs whichimply a certain duration of time or events A leaderis selected for each epoch who takes decisions regard-ing the atomic broadcast and all other nodes complywith its decision In case a leader fails due to a crashfailure the protocols elect a new leader to functionThe best known algorithms belonging to this class cancontinue to function if the following condition holdst lt n2 where t is the number of faulty nodes and nis the total number of participating nodes [4] Examplesof some well-known crash-tolerant consensus protocolare Paxos [15] [16] Viewstamped Replication [17]ZooKeeper [18] and Raft [19]

2) Byzantine consensus This class of algorithms aim toreach consensus amid of certain nodes exhibiting Byz-antine behaviour Such Byzantine nodes are assumedto be under the control of an adversary and behave un-predictably with malicious intent Similar to any crash-tolerant consensus protocol these protocols also utilisethe concept of viewsepochs where a leader is electedin each view to order messages for atomic broadcastand other honest nodes are assumed to follow the in-structions from the leader One of the most well-knownalgorithms under this class is called Practical ByzantineFault Tolerant (PBFT) which can achieve consensus inthe presence of a certain number of Byzantine nodesunder an eventual synchronous network assumption[20] The tolerance level of PBFT is f lt n3 wheref the number of Byzantine nodes and n denotes thenumber of total nodes participating in the network [4]As we will explore later PBFT algorithms have beenwidely utilised in different blockchain systems

3 BACKGROUND BLOCKCHAIN

In this section we present a brief introduction to the block-chain technology and it related terminologies At the centreof the blockchain technology is the blockchain itself storedby the nodes of a P2P network A blockchain is a type ofdistributed ledger consisting of consecutive blocks chainedtogether following a strict set of rules Here each block iscreated at a predefined interval or after an event occurs ina decentralised fashion by means of a consensus algorithmWithin each block there are transactions by which a value istransferred in case of crypto-currencies or a data is stored forother blockchain systems The consensus algorithm guar-

4

antees several data integrity related properties (discussedbelow) in blockchain

Even though the terms blockchain and DLT (DistributedLedger Technology) are used inter-changeably in the literat-ure there is a subtle difference between them which is worthhighlighting A blockchain is just an example of a particulartype of ledger there are other types of ledger When a ledger(including a blockchain) is distributed across a network itcan be regarded as a Distributed Ledger

Since the blockchain technology has been introducedwith Bitcoin it will be useful to understand how Bitcoinworks In Section 31 we discuss a brief primer of Bitcoinand its associated terminologies Then we describe differ-ent properties and types of blockchains in Section 32 andSection 33 respectively Finally we present the concept ofblockchain layers in Section 34

31 Bitcoin

The Bitcoin network consists of nodes within a P2P (Peer-to-Peer) network Each node needs to download the Bitcoinsoftware to connect to the network There are different typesof nodes in the network with miner nodes and generalnodes being the major ones A general node is mostly usedby users to transfer bitcoin in the network whereas a minernode is a special node used for mining bitcoins (see below)

Each user within a node needs to utilise wallet softwareto create identities An identity in the Bitcoin network con-sists of a privatepublic key pair and a bitcoin address isderived from the corresponding public key A sender needsto know such an address of the receiver to transfer anybitcoin Bitcoin is transferred between two entities using thenotion of a transaction where the sender utilises a walletsoftware for this purpose This transaction is propagated tothe network which is collected by all miner nodes Eachminer node combines these transactions into a block andthen engages in solving a cryptographic puzzle with otherminers in which it tries to generate a random number whichsatisfies the required condition (the random number mustbe less than a target value called the difficult target) Whena miner successfully solves the puzzle that miner is saidto have generated a valid block which is then propagatedin the network The Bitcoin protocol generates a certainamount of new Bitcoins for each new valid block andrewards the miner for its effort in creating the block Otherminers validate this newly mined block and then add it tothe blockchain Each new block refers to the last block in thechain which in turn refers to its previous block and so onThe very first block in the chain known as the genesis blockhowever has no such reference

The decentralised nature of this mining process mightresult in multiple valid blocks generated by different minersand propagated at the same time in the network All of themare added to the blockchain and they refer to the same lastblock in the chain Consequently multiple branches emergefrom the same blockchain This is a natural phenomenonin blockchain and is aptly known as fork The fundamentalgoal of the corresponding consensus protocol is to resolvethis fork so that only one branch remains and other branchesare discarded The consensus algorithm utilised in Bitcoinfollows a simple rule it lets the branches grow As soon as

Figure 1 Block Generation Process of Bitcoin

A Each miner collects transactions that are broadcastin the network and uses her hashpower to try togenerate a block via repeated invocation of a hashfunction on data The data consists of the transactionsthat she saw fit to include the hash of the previousblock her public key address and a nonce

B When a miner succeeds in generating a block mean-ing that the hash of her block data is smaller than thecurrent difficulty target she broadcasts her block tothe network

C The other miners continue to extend the blockchainfrom this new block only if they find that this blockis valid ie it refers the hash of the previous blockof the longest chain and meets the current difficultytarget

D The block reward (newly minted coins) and the feesfrom the transactions go to the minerrsquos public addressThis means that only the miner can spend those bysigning with her corresponding private key

E The difficulty level readjusts according to the miningpower of the participates by updating the hash targetvalue every 2016 blocks (asymp2 weeks) so that blocks getgenerated once every 10 minutes on average

F The block reward starts at 50 coins and halves in every210 000 blocks ie about every 4 years

one branch grows longer than the others (more specificallythe total cumulative computational effort of one branch ex-ceeds the others) all miners select the longest branch (or thebranch with the highest computational effort) discarding allother branches Such a branch is known as the main branchand other branches are known as orphan branches Onlythe miners in the main branch are entitled to receive theirBitcoin rewards When a fork is resolved across the networka distributed consensus emerges in the network

The frequency of Bitcoin block generation depends onthe difficulty parameter which is adjusted after 2016 blocksThe protocol adjusts the difficulty parameter in such a waythat a block is generated in every 10 minutes on averageHowever the Bitcoin reward is halved after every 210 000blocks or approximately after every 4 years At the initialstage the reward for generating a valid block had been50 Bitcoins which was halved to 25 Bitcoins in 2012 and125 Bitcoins in 2016 The next halving will occur in 2020where the reward will be reduced to 625 bitcoins per blockThis geometric reduction in every four years underlinesa maximum total supply of 21 million of Bitcoins It isexpected that this supply will be exhausted in the year of2140 when the rewarded bitcoin will be infinitesimally smallfor each block

The process of Bitcoin protocol is presented in Figure 1

32 Properties of blockchainA blockchain exhibits several properties that make it asuitable candidate for several application domains [25] Theproperties are discussed below

5

bull Distributed consensus on the chain state One of thecrucial properties of any blockchain is its capability toachieve a distributed consensus on the state of the chainwithout being reliant on any trusted third party Thisopens up the door of opportunities to build and utilisea system where states and interactions are verifiableby the miners in public blockchain systems or by theauthorised entities in private blockchain systems

bull Immutability and irreversibility of chain stateAchieving a distributed consensus with the participa-tion of a large number of nodes ensures that the chainstate becomes practically immutable and irreversibleafter a certain period of time This also applies to smart-contracts and hence enabling the deployment and exe-cution of immutable computer programs

bull Data (transaction) persistence Data in a blockchain isstored in a distributed fashion ensuring data persist-ence as long as there are participating nodes in the P2Pnetwork

bull Data provenance The data storage process in anyblockchain is facilitated by means of a mechanismcalled the transaction Every transaction needs to bedigitally signed using public key cryptography whichensures the authenticity of the source of data Combin-ing this with the immutability and irreversibility of ablockchain provides a strong non-repudiation instru-ment for any data in the blockchain

bull Distributed data control A blockchain ensures thatdata stored in the chain or retrieved from the chain canbe carried out in a distributed manner that exhibits nosingle point of failure

bull Accountability and transparency Since the state ofthe chain along with every single interactions amongparticipating entities can be verified by any authorisedentity a blockchain promotes accountability and trans-parency

33 Blockchain type

Depending on the application domains different blockchaindeployment strategies can be pursued Based on thesestrategies there are predominantly two types of block-chains namely Public and Private blockchain as discussedbelowbull Public blockchain A public blockchain also known as

the Unpermissioned or permissionless Blockchain allowsanyone to participate in the blockchain to create andvalidate blocks as well as to modify the chain state bystoring and updating data through transactions amongparticipating entities This means that the blockchainstate and its transactions along with the data storedis transparent and accessible to everyone This raisesprivacy concerns for particular scenarios where theprivacy of such data needs to be preserved

bull Private blockchain A private blockchain also knownas the Permissioned Blockchain has a restrictive notion incomparison to its public counterpart in the sense thatonly authorised and trusted entities can participate inthe activities within the blockchain By allowing onlyauthorised entities to participate in activities within theblockchain a private blockchain can ensure the privacy

of chain data which might be desirable in some use-cases

34 Blockchain Layers

There are several components in a blockchain system whosefunctionalities range from collecting transactions propagat-ing blocks mining achieving consensus and maintainingthe ledger for its underlying crypto-currencies and so onThese components can be grouped together according totheir functionalities using different layers similar to thewell-known TCPIP layer In fact there have been a fewsuggestions to design a blockchain system using a layeredapproach [26] [27] The motivation is that a layered designwill be much more modular and easier to maintain Forexample in case a bug is found in a component of a layerin a blockchain system it will only affect the functionalitiesof that corresponding layer while other layers remain unaf-fected For example David et al [27] suggest four layersconsensus mining propagation and semantic Howeverwe believe that the proposed layers do not reflect the propergrouping of functionalities For example consensus andmining should be part of the same layer as mining canbe considered an inherent part of achieving consensus Inaddition to this some blockchain systems might not haveany mining algorithms associated with it In this paperwe therefore will define four layers (Figure 2) networkconsensus application and meta-application The function-alities of these layers are briefly presented below

Meta-Application Layer The functionalities of the meta-application layer in a blockchain system (see Figure 2) is toprovide an overlay on top of the application layer to exploitthe semantic interpretation of a blockchain system for otherpurposes in other application domains For example Bitcoinhas been experimented to adopt in multiple applicationdomains such as DNS like decentralised naming system(Namecoin [28]) decentralised immutable time-stampedhashed record (Proof of Existence [29]) and decentralisedPKI (Public Key Infrastructure) such as Certcoin [30]

Application Layer The application layer (in Figure 2)defines the semantic interpretation of a blockchain systemAn example of a semantic interpretation would be to definea crypto-currency and then set up protocols for how sucha currency can be exchanged between different entitiesAnother example is to establish protocols to maintain a statemachine embodying programming capabilities within theblockchain which can be exploited to create and deployimmutable code (the so-called smart contract) The applic-ation also defines the rewarding mechanism if any in theblockchain system

Consensus Layer The consensus layer as presented in Fig-ure 2 is responsible for providing the distributed consensusmechanism in the blockchain that essentially governs theorder of the blocks A critical component of this layer is theproof protocol (eg proof of work and proof of stake) that isused to verify every single block which ultimately is usedto achieve the required consensus in the system

Network Layer The components in the network layer areresponsible for handling network functionalities which in-clude joining in the underlying P2P network remaining

6

Consensus

Orphaned

branchX

X Orphaned

branch

Main

branch

Crypto-currency SMART Contract

e-Voting PKI Escrowing CasinoDNS

Network

Layer

Consensus

Layer

Application

Layer

Meta-Ap

plication

Layer

Figure 2 Blockchain Layers

in the network by following the underlying networkingprotocol disseminating the current state of the blockchain tonewly joined nodes propagating and receiving transactionsand blocks and so on

4 CONSENSUS TAXONOMY amp PROPERTIES

With the introduction and advancement of different block-chain systems there has been a renewed interest in distrib-uted consensus with the consequent innovation of differenttypes of consensus algorithms These consensus algorithmshave different characteristics and functionalities In thissection we first distinguish between two major types ofconsensus and then present a taxonomy of their propertiesLater in Section 5 and 6 we explore numerous cryptocurrencies and discuss incentivised consensus algorithmsSimilarly we focus on non-incentivised consensus and theblockchain applications in Section 7

Consensus mechanisms used by the various blockchainsystems can be classified based on the reward mechanismthat participating nodes might receive Therefore we firstclassify the consensus mechanisms in blockchain systemsinto two categories incentivised and non-incentivised al-gorithms

Incentivised Consensus Some consensus algorithms re-ward participating nodes for creating and adding a newblock in the blockchain Such algorithms belong to thiscategory These algorithms are exclusively used in public

Consensus properties

Structural properties

Block amp reward properties

Security properties

Performance properties

Figure 3 Taxonomy of consensus properties

blockchain systems and the reward provided acts as anincentive for participating nodes to behave accordingly andto follow the corresponding consensus protocol rigorously

Non-incentivised Consensus Private blockchain systemsdeploy a type of consensus algorithms that do not relyon any incentive mechanism for the participating nodesto create and add a new block in the blockchain Suchalgorithms belong to this category With the absence of anyreward mechanism these nodes are considered trusted asonly authorised (allowed) nodes can participate in the blockcreation process of the consensus algorithm

41 Consensus properties

Each consensus algorithm has different characteristics andserves different purposes To compare these disparategroups of consensus algorithms we need to define eval-uation criteria In this section we present this evaluationcriteria in the form of taxonomies of consensus proper-ties These properties have been collected from existingresearches such as [5] [4] and compiled as a taxonomy inthis work

The taxonomy is presented in Figure 3 According to thistaxonomy a consensus mechanism has four major groups ofproperties Structural Block amp reward Security and Perform-ance properties Each of these properties is briefly discussedbelow

411 Structural propertiesStructural properties define how different nodes within ablockchain network are structured to participate in a con-sensus algorithm These properties can be sub-divided intodifferent categories as illustrated in Figure 4 We brieflydescribe each of these categories belowbull Node types It refers to different types of nodes that

a consensus algorithm is required to engage with toachieve its consensus The types will depend on theconsensus algorithm which will be presented in thesubsequent section

bull Structure type It refers to the ways different nodes arestructured within the consensus algorithm using theconcept of a committee The committee itself can beof two types single and multiple committees Each ofthese committees is described below

bull Underlying mechanism It refers to the specific mechan-ism that a consensus algorithm deploys to select a particularnode The mechanism can utilise lottery the age of aparticular coin or a voting mechanism A lottery can

7


Node type

Structure type

Single

TypeOpen

Close

FormationImplicit

Explicit

ConfigurationStatic

Dynamic

Multiple

TopologyFlat

Hierarchichal

ConfigurationStatic

Dynamic

Underlying mechanism

LotteryProbabilistic

Randomised

VotingSingle

MultipleCoin-age

Figure 4 Taxonomy of structural properties

utilise either a cryptography based probabilistic mech-anism or other randomised mechanisms In a votingmechanism voting can be carried out either in a singleor multiple rounds The coin-age on the other handutilises a special property which depends on how longa particular coin has been owned by its owner

Next we explore different types of voting committees forexisting consensus algorithms

Single committee A single committee refers to a spe-cial group of nodes among the participating nodes whichactively participate in the consensus process by producingblocks and extending the blockchain Each single committeecan have different properties Next we briefly explore theseproperties

bull Committee type A committee can be open or close Acommittee is open if it is open to any participating nodesor closed if it is restricted to a specific group of nodes

bull Committee formation A committee can be formedeither implicitly or explicitly An implicit formationdoes not require the participating nodes to followany additional protocol rules to be in the committeewhereas an explicit formation requires a node to followadditional protocol steps to be a part of the committee

bull Committee configuration A committee can be con-figured in a static or a dynamic fashionndash Static In a static configuration the members of the

committee are pre-selected and fixed No new mem-bers can join and participate in the consensus process

ndash Dynamic In a dynamic configuration the committeemembers are defined for a time-frame (known asepoch) after which new members are added andold members are removed based on certain sets ofcriteria In such a committee nodes are selected usinga voting mechanism where voting is carried eitherin a single or multiple rounds Some consensus al-

Block amp Reward properties

Genesis date Block reward Total supply Block time

Figure 5 Taxonomy of block amp reward properties

gorithms however do not specify any specific time-frame and hence members can join or leave anytime at will Nodes in such configuration are selectedusing a lottery mechanism which utilises either acryptography based probabilistic mechanism or otherrandomised mechanisms

Multiple committee It has been observed that the timeit takes to achieve consensus in a single committee tendsto increase as the number of the member starts to increase[5] thereby reducing performance To alleviate this problemthe concept of multiple committee has been introducedwhere each committee consists of different validators [5]A multiple committee can have different properties Nextwe explore two propertiesbull Topology It refers to the way different committees

are organised For example the topology can be flatto indicate that different committees are at the samelevel or can be hierarchical where the committees can beconsidered in multiple layered levels

bull Committee configuration In addition like a singlecommittee the multiple committees can be configuredin a static or dynamic way

412 Block amp reward propertiesProperties under this category can be utilised as quantitat-ive metrics to differentiate different crypto-currencies Theproperties are (Figure 5) genesis date block reward totalsupply formula and block creation time These proper-ties do not necessarily characterise different consensus al-gorithm directly however most of them (except the genesisdate) have a direct and indirect impact on how consensus isachieved in a particular crypto-currency based blockchainsystem For example block reward incentivises miners toact accordingly by solving a cryptographic puzzle which isthen ultimately used to achieve consensus The propertiesare described belowbull Genesis date represents the timestamp when the very

first block was created for a particular crypto-currencybull Block reward represents the reward a node receives for

creating a new blockbull Total supply represents the total supply of a crypto-

currencybull Block time represents the average block creation time

of a crypto-currency

413 Security propertiesA consensus algorithm must satisfy a number of securityproperties as shown in (Figure 6) and are described belowbull Authentication This implies if nodes participating in

a consensus protocol need to be properly verifiedau-thenticated

8

Security properties

Authentication

Non-repuditation

Censorship reistance

Attack vectors

Adversary tolerance

Sybil protection

DoS

Nothing At Stake (NAS)

Bribing

Long-range

Accumulation

Grinding

Cartel

Figure 6 Taxonomy of security properties

bull Non-repudiation This signifies if a consensus protocolsatisfies non-repudiation

bull Censorship resistance This implies if the correspond-ing algorithm can withstand against any censorshipresistance

bull Attack vectors This property implies the attack vectorsapplicable to a consensus mechanism Here we presenta set of attack vectors that are applicable to any con-sensus algorithm The other attack vectors presented inFigure 6 are applicable to a specific class of consensusalgorithm Therefore we will discuss them in the up-coming sections when we explore such algorithmsndash Adversary tolerance This signifies the maximum

byzantine nodes supportedtolerated by the respect-ive protocol

ndash Sybil protection In a Sybil attack [34] an attackercan duplicate his identity as required in order toachieve illicit advantages Within a blockchain sys-tem a sybil attack implicates the scenario when anadversary can createcontrol as many nodes as re-quired within the underlying P2P network to exertinfluence on the distributed consensus algorithm andto taint its outcome in her favour

ndash DoS (Denial of Service) resistance This implies ifthe consensus protocol has any built-in mechanismagainst DoS attacks

414 Performance properties

The properties belonging to this group can be utilisedto measure the quantitative performance of a consensusprotocol A brief description of each property is presentedbelow with its illustration in Figure 7

bull Fault tolerance signifies the maximum faulty nodes therespective consensus protocol can tolerate


Fault tolerance Throughput Scalability Latency Energy

consumption

Figure 7 Taxonomy of performance properties

bull Throughput implies the number of transactions theprotocol can process in one second

bull Scalability refers to the ability to grow in size andfunctionalities without degrading the performance ofthe original system [31]

bull Latency (Finality) refers to rdquothe time it takes from when atransaction is proposed until consensus has been reached onitrdquo [5] It is also known as finality

bull Energy consumption indicates if the algorithm (orthe utilising system) consumes a significant amount ofenergy

5 INCENTIVISED CONSENSUS POW amp POSIn this section we explore different incentivised consensusalgorithms Such algorithms can be grouped in three majorcategories Proof of Work (PoW) Proof of Stake (PoS) andHybrid Consensus Among them this section discussesPoW and PoS algorithms in Section 51 and Section 52 re-spectively For readability hybrid algorithms are presentedin Section 6

51 Proof of Work (PoW)

A Proof of Work (PoW) mechanism involves two differentparties (nodes) prover (requestor) and verifier (provider)The prover performs a resource-intensive computationaltask intending to achieve a goal and presents it to a verifieror a set of verifiers for validation that requires significantlyless resource The core idea is that the asymmetry in termsof resource required between the proof generation andvalidation acts intrinsically as a deterrent measure againstany system abuse

Within this aim the idea of PoW was first presentedby Dwork and Naor in their seminal article in 1993 [33]They put forward the idea of use PoW to combat emailspamming According to their proposal an email senderwould be required to solve a resource-intensive mathem-atical puzzle and attach the solution within the email as aproof that the task has been performed The email receiverwould accept an email only if the solution can be success-fully verified

Within the blockchain setting a similar concept has beenadopted Each PoW mechanism is bound to a thresholdknown as the difficulty parameter in many blockchain sys-tems The prover would carry out the computational task inseveral rounds until a PoW is generated that matches therequired threshold and every single round is known as asingle proof attempt

PoW has been the most widely-used mechanism toachieve a distributed consensus among the participants

9

regarding the block order and the chain state In particu-lar a PoW mechanism in a blockchain serves two criticalpurposesbull A deterrent mechanism against the Sybil Attack In

PoW every mining node would require a significantmonetary investment to engage in a resource-intensivePoW mechanism during the block creation process Tolaunch a Sybil attack the monetary investment of anattacker will be proportional to the number of Sybilidentities which might outweigh any advantage gainedfrom launching a Sybil attack

bull The PoW mechanism is used as an input to a functionwhich ultimately is used to achieve the required distrib-uted consensus when a fork happens in a blockchain[44]

We differentiate between three major classes of PoWconsensus mechanisms Compute-bound PoW Memory-boundPoW and Chained PoW Each of these is explored in thefollowing sections

511 Compute-bound PoW

A Compute-bound PoW also known as CPU-bound PoWemploys a CPU-intensive function that carries out the re-quired computational task by leveraging the capabilities ofthe processing units (eg CPUGPU) without relying onthe main memory of the system These particular charac-teristics facilitate the scenario in which the computationcan be massively optimised for faster calculation usingApplication-specific Integrated Circuit (ASIC) rigs This hasdrawn criticisms among the crypto-currency enthusiasts asgeneral people cannot participate in the mining process withtheir general purpose computers and the mining process ismostly centralised among a group of mining nodes

Hashcash by Back et al [45] is the earliest example toleverage a PoW mechanism in practical systems Similar tothe proposal of Dwork and Naor in [33] Hashcash is alsodesigned to combat spams In this scheme the email senderwould require to generate a SHA-1 hash with a certain prop-erty using as the input a number of information includingrecipientrsquos email address and date The property dictatesthat the generated hash must have at least 20 bits of leadingzeroes Generating an SHA-1 hash with this property wouldrequire the senders to engage in several proof attempts ina pseudo-random fashion Once the hash is generated itis added within the email header The verification on therecipientrsquos side is rather trivial which requires comparing anewly generated hash using the required information withthe supplied hash If they match it proves that the emailsender has engaged in the required amount of computa-tional work The effectiveness of this approach of fightingspams depends on the hypothesis that spammers rely onthe revenue model requiring a mere amount of cost to senda single email When they would need to engage in sucha computationally intensive task for sending every singleemail the aggregated associated cost might heavily affecttheir profit margin and thus deter them from spamming

Nakamoto consensus is the compute-bound PoW con-sensus algorithm leveraged in Bitcoin It is based on theapproach of Hashcash modified to be applied within the

blockchain setting As discussed in Section 31 all miningnodes (miners) compete with each other to generate a validblock by finding a solution smaller than the difficulty targetSimilar to the idea of HashCash the miners need to engagein several proof attempts until the solution is found Ineach of these proof attempts each miner generates a hashusing either the SHA-256 or SHA-256d (a double hashingmechanism using SHA-256) algorithm and checks if thegenerated hash is smaller than the difficulty target Theeffect of this distributed engagement is that forks happenand then the Nakamoto consensus algorithm is utilised toresolve the fork and to achieve a network-wide distributedconsensus The reader is referred back to Section 31 (andFigure 1) for a brief description of Nakamoto consensus

Currently there are many crypto-currencies that utilisethe Nakamoto consensus algorithm Table 3 shows the top10 of such currencies according to their market capitalisationas rated by CoinGecko 1 (a website which tracks differentactivities related to crypto-currencies) as of July 24 2019The table also presents their Block and reward propertiesas presented in Figure 5 It is to be noted that informationregarding the properties in Table 3 for these (and othersubsequent) currencies has been collected by consultingtheir corresponding whitepapers websites and introductoryannouncements on Reddit website 2

512 Memory-bound PoW

To counteract the major criticism of compute-bound PoWsallowing the utilisation of ASIC-based rigs for the miningpurpose (see Section 511) memory-bound PoWs have beenproposed A memory-bound PoW requires the algorithm toaccess the main memory several times and thus ultimatelybinds the performance of the algorithm within the limitof access latency andor bandwidth as well as the size ofmemory This restricts ASIC rigs based on a memory-boundPoW to have the manifold performance advantage overtheir CPUGPU based counterparts In addition the profitmargin of developing ASIC with memory and then buildingmining rigs with them is not viable as of now for theseclasses of PoWs Because of these memory-bound PoWsare advocated as a superior replacement for compute-boundPoWs in de-monopolising mining concentrations aroundsome central mining nodes

There is a large variety of consensus algorithms be-longing to this class unlike the consensus algorithms ofcompute-bound PoW which are largely based on HashcashThese algorithms can be further categorised as followsCryptonight Scrypt and its variants Equihash EthhashD-agger Neoscript and Timetravel We now describe eachof these different types of memory-bound PoW consensusalgorithm

1) CRYPTONIGHT Cryptonight is a class of PoW consensusalgorithms that in principle is a memory-hard hash func-tion [32] It utilises the Keccak hashing function [46] intern-ally and relies on a 2MB scratchpad residing on the memoryof a computer The scratchpad is extensively used to per-form numerous readwrite operations at pseudo-random

1 httpswwwcoingeckocom2 httpswwwredditcom

10

Table 3 Top ten crypto-currencies that utlise Nakamoto consensus algorithm

Currency Genesis date(ddmmyyyy)

Block reward Total supply(Million)

Block Time

BitcoinBitcoin Cash[69] [70]

03012009 125 21 10m

Syscoin [71] 16082014 8004659537 888 1mPeercoin [72] 19082012 5517265345 2000 10mCounterparty [73] 01022014 All currency in circulation 26m -Emercoin [75] 11122013 Smooth emission 41 10mNamecoin [76] 19042011 1250000000 21 10mSteem Dollars [77] 04062016 Smooth emission Unlimited 3sCrown [78] 08092014 18 42 1mXP 24082016 2220 NAOmni (Mastercoin) [79] 31072013 1671249999 Omni 06 20s

addresses within that scratchpad In the final step thedesired hash is generated by hashing the entire scratchpad

Its reliance on a large scratchpad on the memory of asystem makes it resistant towards FPGA and ASIC miningas the economic incentive to create FPGA and ASIC mininghardware might be too low for the time being As suchCryptonight introduces the notion of so called Egalitarianproof of work [32] or proof of equality which enables anyoneto join in the mining process using any modern CPU andGPU

One prominent property of the coins belonging to thisclass is that all of them support stronger sender-receiverprivacy by facilitating anonymous transactions

Current currencies utilising Cryptonight according toCoingeko as of July 24 2019 is presented in Table 4 LikeTable 3 Table 4 also presents their Block and reward prop-erties as presented in Figure 5

2) SCRYPT AND ITS VARIANTS Scrypt is a password basedkey driving function (KDF) that is currently used in manycrypto-currencies [47] A KDF is primarily used to gen-erate one or more secret values from another secret keyand is widely used in password hashing Previous keyderiving functions such as DES-based UNIX Crypt-functionFreeBSD MD5 crypt Public-Key Cryptography Standards5(PKCS5) and PBKDF2 do not impose any specific hard-ware requirements This enables any attacker launch attacksagainst those functions using specific FPGA or ASIC en-abled hardware the so-called custom hardware attacks [48]Scrypt has been designed to counteract this threat

Toward this aim one of the core characteristics of Scryptis its reliance on the vast memory of a system making itdifficult to perform using FPGA and ASIC enabled cus-tom hardware In the underneath Scrypt utilises Salsa208Core [49] as its internal hash function A simplified versionof Scrypt is used in the corresponding crypto-currencieswhich is much faster and easier to implement and can beperformed using any modern CPU and GPU Hence anyonecan join in the mining process for crypto-currencies usingthis function However the ever-increasing price of crypto-currencies has incentivised miners to produce custom ASIChardware for some crypto-currencies utilising Scrypt inrecent times An example of such hardware that can be usedto mine different Scrypt crypto-currencies is Antminer L3+[50]

To tackle this issue of exploiting ASIC for mining sev-eral Scrypt variants have been proposed Scrypt-NScrypt

JaneScrypt Chacha and Scrypt-OG each providing particu-lar advantages over others Scrypt-N and Scrypt Chacha relyon SHA256 and ChaCha [52] as their internal hash functionsrespectively whereas Scrypt Jane utilises a combination ofdifferent hash functions All of them support progressiveand tunable memory requirements which can be adjustedafter a certain period This is to ensure that custom ASIChardware is rendered obsolete once the memory require-ment is changed Finally Scrypt-OG (Optimised for GPU)is optimised to be eight times less memory intensive thanScrypt [51]

Table 5 shows the top 10 currencies which either useScrypt or one of its variants as per their market capitalisa-tion according to CoinGecko as of July 24 2019

3) EQUIHASH Equihash is one of the recent PoW algorithmsthat has been well received in the blockchain community[55] It is a memory-bound PoW that requires to find a solu-tion for the Generalised Birthday problem using Wagnerrsquosalgorithm [56] Equihash has been designed to decentralisethe mining procedure itself similar to other memory-boundapproaches However so far very small portions of suchalgorithms have succeeded One of the crucial reasons forthis is that their underlying time-memory complexity trade-off is largely constant This means that reducing memoryrequirement in these algorithms have little effect on theircorresponding time complexity

Wagnerrsquos solution has a steep time-memory complexitytrade-off reducing memory increases time complexity sub-stantially This premise has been exploited by Equihash toensure that mining is exclusively proportional to the amountof memory a miner has Thus it is more suitable for a gen-eral purpose computer rather than any ASIC-enabled hard-ware which can only have relatively small memory in orderto make their production profitable for the mining processDue to this reason it has been claimed that Equihash cansupport ASIC resistance at least for the foreseeable futureIn addition the verification is extremely lightweight andeven can be carried out in resource-constrained mobiledevices Table 6 shows the eight currencies which utiliseEquihash according to CoinGecko as of July 24 20194) ETHASH (DAGGER-HASHIMOTO)DAGGER Ethash is amemory-bound PoW algorithm introduced for Ethereumwith the goal to be ASIC-resistant for a long period oftime [58] It was previously known as Dagger-Hashimotoalgorithm [59] because of its utilisation of two differentalgorithms Dagger [60] and Hashimoto [60]

11

Table 4 Top ten crypto-currencies that utilise Cryptonight with Bytecoin being the first to use this algorithm


Block reward Total supply (Million) Block Time

Monero 18042014 486930501 Starting at M = 264 minus 1infinite supply

20m

Bytecoin 04072012 66676 18446 billion 20mAeon 06062014 548 Starting at M = 264 minus 1

infinite supply40m

Boolberry 17052014 485 185 Million 20Karbowanec 30052016 883 Starting with 10 Million in-

finite supple40m

Fantomcoin 06052014 smooth emission 50 coins will beemitted in 6 years and block rewarddecreases with a similar Starting atM = 264 minus 1

infinite supply 10m

Dashcoin fork ofBytecoin

05072014 155 20m

QuazarCoin 08052014 smooth emission 20BipCoin 20082016 smooth emission 20Cannabis IndustryCoin

16102016 7000000000 21 M 20

Table 5 Top ten crypto-currencies using Scrypt



Block Time

Litecoin [80] 13102011 2500 84 million 25mVerge [82] 15022016 73000 165 billion 05mBitmark [83] 13072014 (no longer monitored

after 2016)2758 million 20m

Dogecoin [84] 06122013 1000000 Total supply NAGameCredits [85] 01062015 fixed (125 coins) 84 million 15mEinsteinium [86] 01032014 2 29 billion 10mVoxels [87] 03112015 smooth emission 21 billion 25mViacoin [88] 18072014 063 23 million 05mHempcoin [89] 9032014 smooth emission 25 billion 10m

Table 6 Crypto-currencies utilising Equihash algorithm



Block Time

Zcash [90] 28102016 10 21 million 25mBitcoin Gold [91] 24102017 125 21 million 10mKomodo [92] 15102016 3 200 million 1mZclassic [93] 6112016 125 21 million 25mZenCash [94] 30052017 75 21 million 25mHush [95] Genesis date 1125 21 million 25mBitcoinZ [96] 10092017 1250000 21 billion 25mVoteCoin [97] 31082017 125 22 billion 25m

Dagger is one of the earliest proposed memory-boundPoW algorithm which utilises Directed Acyclic Graph(DAG) for memory-hard puzzle solving with trivial verific-ation that requires less memory to be used in resource con-strained devices However the Dagger algorithm is provento be vulnerable towards a shared memory hardware ac-celeration attack as discussed in [61] That is why it hasbeen dropped as a PoW candidate for Ethereum Hashimotoalgorithm on the other hand relies on the delay incurred forreading data from memory as the limiting factor and thusis known as an I-O bound algorithm

Ethash combines these two algorithms to be ASIC-resistant and functions as follows Ethash depends on alarge pseudo-random dataset which is recomputed duringeach epoch Each epoch is determined by the time it takesto generate 30000 blocks in approximately five days Thisdataset is essentially a directed acyclic graph and hence is

called DAG During the DAG generation process a seed isgenerated at first which relies on the length of the chainThe seed is then used to compute a 16 MB pseudo-randomcache Then each item of the DAG is generated by utilisinga certain number of items from the pseudo-random cacheThis entire process enables the DAG to grow linearly withthe growth of the chain Then the latest block header andthe current candidate nonce are hashed using Keccak (SHA-3) hash function and the resultant hash is mixed and hashedseveral times with data from the DAG The final hasheddigest is compared to the difficulty target and accepted ordiscarded accordingly

Every mix operation in Ethash requires to have a read ina pseudo-random fashion from the DAG which is randomlyaccessed from the memory This serves two purposes

bull The read operation is limited by the speed of thememory access bandwidth which is thought to be

12

theoretically optimal and thus more optimisation isless likely

bull Even though the mixing circuitry can be built within anASIC the bottleneck would still be the memory accessdelay

That is why Ethash is thought to be suitable for use oncommodity computing capacity with good powerful GPUsTo achieve the same level of performance an ASIC wouldrequire to accommodate as large memory as a generalpurpose computer providing a financial disincentive

There are currently two currencies utilising Ethereumaccording to coingecko as of July 24 2019 [62] Even thoughDagger algorithm is proven not to be ASIC resistant it isbeing used in 6 currencies [63] All of these are presented inTable 7

5) NEOSCRYPT NeoScrypt an extension of Scrypt is a keyderivation function that aims to increase the security andperformance on CPUs and GPUs while being strong ASICresistant [146] Internally it utilises a combination of Salsa2020 [49] and ChaCha 2020 [52] along with Blake2s [74]Its constructions impose larger memory segment size andhence larger temporal buffer requirements This makes it125 times more memory intensive than Scrypt The motiva-tion is that this higher requirement of memory will act as adeterrent towards building ASICs for NeoScrypt

Currently there are 10 currencies utilising NeoScryptaccording to Coingecko as of 18 July 2019 [147] which arepresented in Table 8

513 Chained PoWA chained PoW utilises several hashing functions chainedtogether in a series of consecutive steps Its main motiv-ation is to ensure ASIC resistance which is achieved bythe underlying mechanisms by which the correspondinghashing functions are chained together In addition to thisthe PoW algorithms belonging to this series aim to ad-dress one particular weakness of any compute-bound andmemory-bound PoW algorithm their reliance on a singlehashing function With the advent of quantum computingthe security of a respective hashing algorithm might beadversely affected which undermines the security of thecorresponding blockchain system If this happens the oldalgorithm needs to be discarded and a new quantum res-istant hashing algorithm needs to be incorporated to therespective blockchain using a mechanism called hard-forkA hard-fork is a mechanism by which a major update isenforced in a blockchain system This is quite a disruptiveprocedure that has negative effect on any blockchain systemIn such scenarios a chained PoW algorithm would continueto function until all its hashing functions are broken

There are several chained PoW algorithms that are cur-rently available

1) X11X13X15 X11 is a widely-used hashing algorithm inmany crypto-currencies In X11 eleven hashing algorithmsare consecutively carried our one after another The hash-ing algorithms are blake bmw groestl jh keccak skein luffacubehash shavite simd and echo

One advantage of X11 is that it is highly energy effi-cient GPUs computing X11 algorithm requires approxim-ately 30 less wattage and remains 30 minus 50 cooler in

comparison to Scrypt [54] Even though the algorithm hasbeen designed in such a way that it can only be used withCPUs and GPUs the economic incentives have allowed thecreation of ASIC to be used during the mining process

It has different variants where the number of chainedhashing functions differs For example X13 utilises 13 hash-ing functions and X15 utilises 15 hashing functions

Table 9 presents the top 10 crypto-currencies utilisingthese three algorithms as per their market capitalisation asof July 24 2019 according to CoinGecko

2) QUARK Quark PoW algorithm relies on six differenthashing functions BLAKE [74] Blue Midnight Wish [64]Groslashstl [65] [140] JH [66] Keccak and Skein [67] Thesefunctions are implemented in mixed series with nine steps[138] Within these nine steps three functions are randomlyapplied in three steps depending on the value of a bit Themain motivations of mixing these six functions in nine stepsare as followsbull To alleviate the risk of a compromised system in light of

its underlying single hashing algorithm being brokenbull To impose restrictions so that Quark can only be

mined using CPUs while making it difficult to mineusing GPUs and ASICs because of the usage of ASIC-resistant mechanisms (eg Keccak)

However it did not take long before ASIC mininghardware for Quark appeared in the market so that thiscould be mined using a GPU and ASIC [68] Howeverthe profitability and performance of such hardware are notobvious

The currencies utilising Quark according to CoinGeckoas per July 24 2019 [139] are presented in Table 10

3) LYRA2RE Lyra2RE is a class of chained PoW which util-ises five hash functions BLAKE Keccak Lyra2[13] Skeinand Groslashstl It has been developed by the developers ofVertcoin a currency based on Lyra2RE It was designedto be CPU friendly however it was discovered in 2015that the majority of the hashing power utilised for miningVertCoin in its network was facilitated by a botnet stealingCPU cycles from a large number of infected computers Thismotivated the Vertcoin developers to release Lyra2REv2which utilises six hash functions BLAKE Keccak Cube-Hash Lyra2 Skein and Blue Midnight Wish with GPUonly PoW Currently there are only three currencies utilisingLyra2REv2 according to CoinGecko as of 31 December 2017which are presented in Table 11

4) MAGNIFICENT 7 Magnificent 7 (M7) is a class of chainedPoW which utilises seven hash functions to generate thecandidate hash during the mining process of Cryptonitecoin (not to be confused with the Cryptonight PoW al-gorithm) [143] The utilised hash functions are SHA-256SHA-512 Keccak RIPEMD HAVAL Tiger and WhirlpoolInternally the header of the candidate block sequentiallyhashed by the corresponding functions and then multipliedto generate the final hash which is then compared againstthe difficulty threshold Even though it a not memory-bound PoW it has been claimed that the multiplicationoperation enables it to run on a general purpose CPU easilyhowever makes it difficult to run on GPUs and ASICs[143] Even so there are is at least one GPU miner available

13

Table 7 Crypto-currencies utilising Ethash algorithm The block rewards are in the corresponding currencies



Block Time

Ethereum [98] 30072015 2 infinite supply 10-20sEthereum Clas-sic [99]

30072015 388 10-20s

Ubiq [100] 28012017 6 NA 88sShift [101] 01082015 1 infinite supply 27sExpanse [102] 13092015 4 314 Million 10mDubaiCoin-DBIX [103]

27032017 6 Total supply 15m

SOILcoin [104] 03102015 30 Total supply 52sKrypton [105] 15022016 025 267 Million 1m 44s

Table 8 Crypto-currencies utilising NeoScrypt and Timetravel 10 algorithms The block rewards are in the correspondingcurrencies

Currency Algorithm Genesis date(ddmmyyyy)


Block Time

Red Pulse [106] 17102017 NA 136 Billion NAFeathercoin [107] NeoScrypt 16042013 40 336 Million 10mGoByte [108] NeoScrypt 17112017 371 318 Million 25mUFO Coin [109] NeoScrypt 03012014 625 4 Billion 15mInnova [110] NeoScrypt 19102017 264 129 Million 2mVivo [88] NeoScrypt 20082017 45 11 Million 2m18sDesire [113] NeoScrypt Genesis date 1045 117 Million 25mOrbitcoin [114] NeoScrypt 28072013 05 377 Million 60mPhoenixcoin [115] NeoScrypt 08052013 125 98 Million 15mBitcore [116] Timetravel 10 April 24 2017 313 21 Million 25m

Table 9 Crypto-currencies utilising X11X13 algorithms The block rewards are in the corresponding currencies



Block Time

Dash [117] X11 January 19 2014 155 22 Million 25mStratis [118] X13 August 09 2016 NA NA NACloakcoin [119] X13 Genesis date 49600 45 Million 10mStealthcoin [120] X13 July 04 2014 NA 207 Million 10mDeepOnion [121] X13 July 13 2017 4 189 Million 4mHTMLcoin [122] X15 September 12 2014 NA 90 Billion 10mRegalcoin [123] X11 September 28 2017 NA 72 Million NAMemetic [124] X11 March 05 2016 NA NA NAExclusiveCoin [125] X11 June 12 2016 NA NA NACreditbit [126] X11 November 02 2015 NA 100 Million 10m

Table 10 Crypto-currencies utilising Quark algorithm The block rewards are in corresponding currencies



Block Time

Quark [67] July 21 2013 1 247 Million 05sPIVX [128] NA 5 NA 10mMonetaryUnit [129] July 26 2014 18 1 Quadrillion 067mALQO [130] October 30 2017 3 NA 1mBitcloud [131] August 15 2017 225 200 Million 65mZurcoin [132] NA 125 NA 075mAmsterdamCoin [133] November 01 2015 10 84 Million 10mAnimecoin [134] NA NA NA NA

Table 11 Crypto-currencies utilising Lyra2RE algorithm The block rewards are in corresponding currencies



Block Time

Vertcoin [135] January 10 2014 25 84 Million 25mMonacoin [136] January 01 2014 25 105 Million 15mCrypto [137] April 30 2015 NA 658 Million 05m

for M7 [144] Its performance though is not known Thecorresponding information for Cryptonite is presented inTable 12

514 PoW Limitations

PoW (Nakamoto) consensus algorithm has been widelyaccoladed for its breakthrough in the distributed consensus

14

Table 12 Information regarding Cryptonite utilising M7 algorithm



Block Time

Cryptonite July 28 2014 Dynamic 184 Billion 1 Minute

01020304050607080

2017-02-10

hellip2017-03-27

hellip2017-05-11

hellip2017-06-25

hellip2017-08-09

hellip2017-09-23

hellip2017-11-07

hellip2017-12-22

hellip2018-02-05

hellip2018-03-22

hellip2018-05-06

hellip2018-06-21

hellip2018-08-05

hellip2018-09-19

hellip2018-11-03

hellip2018-12-18

hellip2019-02-01

hellip2019-03-18

hellip2019-05-02

hellip2019-06-16

hellipEstimated TWh per Year Minimum TWh per Year

Figure 8 Bitcoin energy consumption over the last years

paradigm starting with Bitcoin It had laid down thefoundation for the subsequent advancement which resul-ted in different PoW algorithms and crypto-currencies asdiscussed in the earlier sections Even so there are somesignificant limitations Next we briefly discuss these limita-tions

bull Energy consumption Each PoW algorithm needs toconsume electricity to compute the hash As the dif-ficulty of the network starts to increase so does theenergy consumption The amount of consumed energyis quite significant when calculated over the whole net-work consisting of ASICGPU mining rigs all aroundthe world Digiconomist 3 website tracks the electricityconsumption of Bitcoin and Ethereum According doit the energy consumption of Bitcoin and Ethereumare around 40 TWh (Tera-Watt Hour) and 10 TWhrespectively Their energy consumption graphs for thelast one year are presented in Figure 8 [148] and Figure9 [149]

Figure 9 Ethereum energy consumption over the last year

3 httpsdigiconomistnet

To put this into perspective we present Figure 10whose data has been collected from [148] This figureillustrates Bitcoinrsquos energy consumption relative to theelectricity consumption of different countries For ex-ample the electricity consumed by Bitcoin in a yearcould power up 6 770 506 American households andis much more than what Czech Republic consumes ina year [148] The utilisation of this huge amount ofelectricity has raised the question of sustainability ofPoW-based crypto-currencies

Figure 10 Bitcoin energy consumption relative to differentcountries

bull Mining centralisation With the ever-increasing diffi-culty rate miners within a PoW-based crypto-currencynetwork need to upgrade the capability of their AS-ICGPU mining rigs to increase their chance of cre-ating a new block Even so it becomes increasinglydifficult for a single miner to join in the mining processwithout substantial investment in the mining rigs Theconsequence is that the economies of scale phenomenonstrongly impacts the PoW algorithms The economiesof scale in economic theory is the advantage a pro-ducer can gain by increasing its output [150] Thishappens because the producer can spread the cost ofper-unit production over a larger number of goodswhich increases the profit margin This analogy alsoapplies to PoW mining as explained next A miningpool can be created where the mining resources ofdifferent miners are aggregated to increase the chanceof creating a new block Once a mining pool receivesa reward for creating the next block the reward isthen proportionally divided among the participatingminers Unfortunately this has led to the centralisationproblems where block creations are limited among ahandful of miners For example Figure 11 illustratesthe distribution of network hashrate among differentminers in Bitcoin [152] As evident from the figure onlyfive mining pools control the 75 of hashrate of the

15

whole network There is a fear that they could colludewith each other to launch the 51 attack to destabilisethe whole bitcoin network

Known Blocks

Relayed By count

BTCcom 74

Unknown 41

F2Pool 39

Poolin 38

AntPool 37

SlushPool 27

BTCTOP 26

ViaBTC 16

An estimation of hashrate

distribution amongst the largest mining poolsThe graph below shows the market share of the most popular bitcoin mining pools It should only be used as a

rough estimate and for various reasons will not be 100 accurate A large portion of Unknown blocks does not

mean an attack on the network it simply means we have been unable to determine the origin

24 hours - 48 hours - 4 Days

Bitcoin Hashrate Distribution - Blockchaininfo httpswwwblockchaincomenpoolstimespan=48hours

1 of 1 27072019 1008 pm

Figure 11 Bitcoin hashrate distribution of mining pools

bull Tragedy of commons Many PoW algorithms suffer aneconomic problem called the Tragedy of the commons Ineconomic theory the tragedy of the commons occurswhen each entity rushes to maximise its profit from adepleting resource without considering the well-beingof all that share the same resource [151] This situationoccurs in a crypto-currency if it is deflationary in naturewith limited supply eg Bitcoin It has been arguedwhen the reward of creating a new block in Bitcoinwill reach nearly zero the miners will have to solelyrely on the transaction fees to cover their expensesThis might create an unhealthy competition among theminers to include as many transactions as possible justto maximise onersquos profit The consequence of this isthat transaction fees will keep decreasing which mightlead to a situation that miners cannot make enoughprofit to continue the mining process Eventually moreand more miners will leave the mining process whichmight lead toward 51 attacks or other scenarios thatde-stabilise the Bitcoin network

bull Absence of penalty All PoW algorithms (both com-pute and memory bound) are altruistic in nature inthe sense that they reward behaving miners howeverdo not penalise a misbehaving miner One example isthat a miner can collude with a group of miners (aphenomenon known as selfish mining) to increase itsprofitability in an illegitimate way [153] In additiona miner can engage in Denial-of-Service attack by justnot forwarding any transaction or block within thenetwork Furthermore such malicious miners can joinforces to engage in the spawn-camping attack in whichthey launch DoS attacks simultaneously over and overagain to render the network useless for the corres-ponding crypto-currency [156] A penalty mechanismwould disincentivize any miner to engage in any typeof malicious misbehave

515 AnalysisIn this section we summarise the properties of differentPoW algorithms in Table 13 Table 14 and Table 15 utilisingthe taxonomies presented in Section 4 In these tables alsquo rsquo symbol is utilised to indicate if a particular property issupported by the corresponding algorithm For other prop-erties explanatory texts have been used for any particularproperty

As presented in Table 13 different types of PoW al-gorithms share exactly similar characteristics In these al-gorithms they are mainly two types of nodes clients andminers Miners are responsible for creating a block usinga randomised lottery mechanism Conversely clients arethe nodes that are responsible for validating each block aswell as utilised to transact bitcoin between different usersCommittees in these algorithms represent the set of minersexhibiting the property of a single open committee structurewhere anyone can join as a miner The respective committeeis formed implicitly in a dynamic fashion indicating anyminer can join or leave whenever they wish

As per Table 14 none of the algorithms requires anynode to be authenticated to participate in the algorithm Allof them have strong support for non-repudiation in the formof digital signature as part of every single transaction Thesealgorithms have a high level of censorship resistance whichmeans that it will be difficult for any regulatory agencyto impose any censorship on these algorithms As for theattack vector each PoW algorithm requires every minernode to invest substantially for mining hardware in orderto participate in these consensus algorithms This featurethus acts as a deterrent against any Sybil or DoS attack inany PoW algorithm The adversary tolerance is based on theassumption that PoW suffers from 51 attacks and thusadversary nodes need to have less than 50 of the totalhashing power of the network

According to Table 15 these algorithms have lowthroughput and unfortunately do not scale properly Fur-thermore most of the algorithms require a considerable timeto reach finality and their energy consumption is consider-ably high as explained in Section 514 The fault tolerance inthese algorithms is 2f + 1 like any BFT algorithm implyingthey can achieve consensus as long as more than 50 ofnodes function correctly

52 Proof of Stake

To counteract the limitations of any PoW algorithm anothertype of consensus algorithm called Proof of Stake (PoS) hasbeen proposed The earliest proposal of a PoS algorithmcan be found on the bitcointalk forum in 2011 [154] Soonafter several projects started experimenting with the ideaPeercoin [72] released in 2012 was the first currency toutilise the PoS consensus algorithm

The core idea of PoS evolves around the concept that thenodes who would like to participate in the block creationprocess must prove that they own a certain number of coinsat first Besides they must lock a certain amount of itscurrencies called stake into an escrow account in order toparticipate in the block creation process The stake acts asa guarantee that it will behave as per the protocol rulesThe node escrows its stake in this manner is known as the

16

Table 13 Structural properties of PoW consensus algorithms

Single committeeNode type Type Formation Configuration Mechanism

Clients amp Miners Open Implicit Dynamic Lottery Randomised

Table 14 Security properties of PoW consensus algorithms

Attack VectorsAuthentication Non-repudiation Censorshipresistance Adversary tolerance Sybil protection DoS Resistance

x High 2f + 1

Table 15 Performance properties of PoW consensus algorithms

Fault tolerance Throughput Scalability Latency Energy consumption

2f + 1 Low Low Medium-High High

stakeholder leader forger or minter in PoS terminologyThe minter can lose the stake in case it misbehaves

In essence when a stakeholder escrows its stake itimplicitly becomes a member of an exclusive group Only amember of this exclusive group can participate in the blockcreation process In case the stakeholder gets the chance tocreate a new block the stakeholder will be rewarded in oneof the two different ways Either it can collect the transactionfees within the block or it is provided a certain amount ofcurrencies that act as a type of interest against their stake

It has been argued that this incentive coupled with anypunitive mechanism can provide a similar level of securityof any PoW algorithm Moreover it can offer several otheradvantages Next we explore a few benefits of a PoS mech-anism [156]

bull Energy Efficiency A PoS algorithm does not requireany node to solve a resource-intensive hard crypto-graphic puzzle Consequently such an algorithm isextremely energy efficient compared to their PoW coun-terpart Therefore a crypto-currency leveraging anyPoS algorithm is likely to be more sustainable in thelong run

bull Mitigation of Centralization A PoS algorithm is lessimpacted by the economies of scale phenomenon Sinceit does not require to build up a mining rig to solveany resource-intensive cryptographic puzzle there isno way to maximise gain by increasing any outputTherefore it is less susceptible to the centralisationproblem created by the mining pool

bull Explicit Economic Security A carefully designed pen-alty scheme in a PoS algorithm can deter any misbe-having attack including spawn-camping Anyone en-gaging in such attacks will lose their stake and mightbe banned from any block creation process in the fu-ture depending on the protocol This eventually canstrengthen the security of the system

Initial supply One of the major barriers in a PoSalgorithm is how to generate the initial coins and fairlydistribute them among the stakeholders so that they can beused as stakes We term this barrier as the bootstrap problemThere are two approaches to address the bootstrap problem

bull Pre-mining A set of coins are pre-mined which arethen sold before the launch of the system in an IPO

(Initial Public Offering) or ICO (Initial Coin Offering)bull PoW-PoS transition The system starts with a PoW

system to fairly distribute the coins among the stake-holders Then it slowly transitions towards the PoSsystem

Reward process Another important aspect is the re-warding process to incentivise the stakeholder to take partin the minting process Unlike any PoW where a miner isrewarded with new coins for creating a valid block there isno reward for creating a valid block Instead to incentivisea minter two types of reward mechanisms are availablewithin a PoS algorithmbull Transaction Fee The minter can collect fees from the

transactions included within the minted blockbull Interest rate A lower interest rate is configured which

allows the currency to inflate over time This interestis paid to the minter as a reward for creating a validblock

Selection process A crucial factor in any PoS algorithmis how to select the stakeholder who can mint the next blockIn a PoW algorithm a miner is selected based on who canfind the resource-intensive desired hash Since PoS does notrely on hind such a hash as the mechanism to find thenext block there must be a mechanism to select the nextstakeholder

Currently there three different approaches to Proof ofStake Chained BFT and Delegated

CHAINED POS The general idea of a chained PoS is todeploy a combination of PoW and PoS algorithms chainedtogether to achieve any consensus Because of this therecan be two types of blocks PoW and PoS blocks withinthe same blockchain system To accomplish this the cor-responding algorithm relies on different approaches to se-lectassign a particular miner for creating a PoW block orselect a set of validators for creating a PoS block in differentepochs or after a certain number of blocks created Ingeneral a chain based PoS can employ any of the followingthree different approaches to select the minerstakeholderbull Randomised PoW Mining A miner who can solve the

corresponding cryptographic PoW puzzle is selected ina random fashion

bull Randomised Stakeholder Selection A randomised PoS util-ises a probabilistic formula that takes into account the

17

staked currencies and other parameters to select thenext stakeholder The other parameters ensure that astakeholder is not selected only based on the number oftheir staked coins and act as a pseudo-random seed forthe probabilistic formula

bull Coin-age based selection A coin-age is defined as theholding period of a coin by its owner For example ifan owner receives a coin from a sender and holds it forfive days then the coin-age of the coin can be definedas five coin-days Formally

coin minus age = coin lowast holdingperiod

Algorithms belonging to this class select the stake-holder using staked coins of the stakeholders and theircorresponding coin-age

In general a chained PoS algorithm favours towardsavailability over consistency when network partition occursas per the CAP theorem

BFT POS BFT PoS is a multi-round PoS algorithm In thefirst step a set of validators are pseudo-randomly selected topropose a block However the consensus regarding commit-ting this block to the chain depends on the gt 23 quorumof super-majority among the validators on several rounds Itinherits the properties of any BFT consensus and as such ittolerates up to 13 of byzantine behaviour among the nodes

In general a BFT PoS algorithm favours towards con-sistency over availability when network partition occurswithin the setting of CAP theorem

DELEGATED PROOF OF STAKE Delegated Proof of Stake(or DPoS in short) is a form of consensus algorithm in whichreputation scores or other mechanisms are used to select theset of validators [184] Even though it has the name Proof ofStake associated with it it is quite different from other PoSalgorithms

In DPoS users of the network vote to select a groupof delegates (or witnesses) who are responsible for creatingblocks Users utilise reputations scores or other mechanismsto choose their delegates Delegates are the only entitieswho can propose new blocks For each round a leader isselected from the set of delegates who can propose a blockHow such a leader is chosen depends on the respectivesystem The leader gets rewards for creating a new blockand is penalised and de-listed from the set of validators if itmisbehaves

The delegates themselves compete with each other to getincluded in the validator list In such each validator mightoffer different levels of incentives for the voters who vote forit For example if a delegate is selected to propose a blockit might distribute a certain fraction of its reward among theusers who have selected it Since the number of validatorsis small the consensus finality can be fast

Next we explore several crypto-currencies or mechan-isms that use the above mentioned PoS approaches

521 Chained PoSNext we present two examples of a chained PoS algorithmto illustrate how this approach has been applied in practice

1) PEERCOIN (PPCOIN) Peercoin is the first crypto-currency to formalise the notion of PoS by utilising a hybrid

PoW-PoS protocol [174] The Peercoin protocol is based onthe assumption that coin-age can be leveraged to create aPoS algorithm which is as secure as any PoW algorithmwhile minimising the disadvantages associated with a PoWalgorithm

Peercoin protocol recognises two different kinds ofblocks PoW blocks and PoS blocks within the same block-chain These blocks are created by two separate entitiesminers and minters Miners are responsible for creatingPoW blocks similar to Bitcoin whereas minters are respons-ible for creating PoS blocks Irrespective of the last blocktype the next block either can be a PoW block or a PoSblock and these entities compete with each other to createthe next block [175] Miners compete with other miners tofind a valid PoW block that matches the PoW difficultytarget similar to Bitcoin Similarly minters compete amongthemselves to find a valid PoS block that matches the PoSdifficulty target (similar to a PoW algorithm but requiresmuch less computation) As soon as any PoW or PoS blockis found it is broadcast to the network and other nodesvalidate it

Within a PoS block a minter utilise their holding coinsas a stake and the minter is rewarded approximately 1per annum based on the coin-age of the staked coins Thereward is paid out for each block in a newly created specialtransaction called the coinstake transaction Each coinstaketransaction consists of the number of staked inputs and akernel containing the hash that meets the PoS difficultyThe hash itself is calculated over a small space and hencenot computationally intensive at all It utilises the numberof staked inputs and a probabilistic variable whereas thedifficulty condition is calculated utilising the coin-age ofthe staked inputs as well as a difficulty parameter Thisparameter is adjusted dynamically to ensure that one blockis created in 10 minutes In other words the valid kerneldepends on the coin-age of the staked inputs and the higherthe coin-age the higher is the probability to match thedifficulty

The coinstake transaction is paid to the minter whichcontains the coins staked along with the reward Once aPoS block is added to the chain the coin-age of the stakedcoins is reset to zero This indicates that all the stacked coinsare consumed This ensures that the same coins cannot beused over and over again to create a PoS block within ashort period of time The main chain in Peercoin is selectedbased on the highest total coin-age consumed in all blocksThat means if a PoW block and PoS block are receivedsimultaneously as the next block by a node the algorithmdictates the PoS block to be selected over the PoW block

The block reward for a PoW block in Peercoin decreasesand will cease to be significant after a certain period of timeIt is currently used for the coin generation and distributionpurpose and will be completely phased out in the future[205] It has no role whatsoever on securing the networkwhich is largely based on the PoS algorithm Once the PoWalgorithm is phased out it is suggested that the energyconsumption of Peercoin will be significantly low whileproviding similar security as any PoW algorithm

Peercoin is highly regarded for formalising the firstalternative mechanism to PoW however it suffers from allthe attack vectors of PoS as presented in Section 524 Two

18

other coins Black and Nxt removes age from the equationin order to avoid the exploitation of the system by thedishonest entities having a significant amount of coins

2) CASPER FFG Casper the Friendly Finality Gadget(CFFG) is a PoW-PoS hybrid consensus algorithm proposedto replace the Ethereumrsquos PoW consensus algorithm [181] Infact CFFG provides an intermediate PoS overlay on top ofits current PoW algorithm so that Ethereum is transformedto a pure PoS protocol called Casper the Friendly Ghost(CTFG) described below (Section 522)

The PoS layer requires the participation of validatorsAny node can become a validator by depositing some Eth-ereumrsquos native crypto-currency called Ether to a designatedsmart-contract which acts as a security bond The networkitself will mostly consist of PoW miners who will mineblocks according to its current PoW algorithm Howeverthe finalisationcheck-pointing of blocks will be carried outby PoS validators The check-pointingfinalisation is theprocess to ensure that the chain becomes irreversible upto a certain block and thus short and low range attacks(particular types of PoS only attacks presented in Section524) as well as the 51 attack cannot be launched beyondthe check-pointing block

The check-pointing occurs every 50 blocks and thisinterval of 50 blocks is called an epoch [158] The finalisationprocess requires two rounds of voting in two successiveepochs The process is as follows In an epoch the validatorsvote on a certain checkpoint c (a block) A super-majority(denoted as +23) occurs when more than 23 of the valid-ators vote for the checkpoint c In such a case the checkpointis regarded as justified If in the next epoch (+23) of thevalidators vote on the next checkpoint cprime (a block whichis a child of the block belonging to C) cprime is consideredjustified whereas c is considered finalised A checkpointcreated in this manner for each epoch is assumed to createa checkpoint tree where cprime is a direct child of c The processcan be summarised in the following way +23 Vote c rarrJustify crarr +23 Vote cprime rarr Finalize c and Justify cprime

Once a checkpoint is finalised the validators are paidThe payment is interest-based and is proportional to thenumber of ethers deposited If it occurs that there are twocheckpoints it signifies that a fork has occurred This canonly happen when a validator or a set of validators has de-viated from the protocol In such cases a penalty mechanismis imposed in which the deposit of the violating validator(s)is destroyed

In essence CGGF is a combination of Chained and BFTconsensus mechanisms with strong support for availabilityover consistency Its properties ensure that block finalisationoccurs quickly and the protocol is mostly secure against allPoS attacks except the cartel formation attack (a particulartype for PoS only presented in Section 524) However it isto be noted that this consensus mechanism has not beenimplemented yet Therefore it is yet to be seen how itperforms in reality

522 BFT PoS

In this section we describe three notable BFT PoS algorithmsthat have had significant uptake in practice TendermintCTFG and Ouroboros

1) TENDERMINT Tendermint is the first to showcase howthe BFT consensus can be achieved within the PoS settingof blockchain systems [178] [179] [180] It consists of twomajor components a consensus engine known as Tender-mint Core and its underlying application interface calledthe Application BlockChain Interface (ABCI) The Tendermintcore is responsible for deploying the consensus algorithmwhereas the ABCI can be utilised to deploy any blockchainapplication using any programming language

The consensus algorithm relies on a set of validators It isa round-based algorithm where a proposer is chosen froma set of validators In each round the proposer proposesa new block for the blockchain at the latest height Theproposer itself is selected using a deterministic round-robinalgorithm which ultimately relies on the voting power ofthe validators The voting power on the other hand isproportional to the security deposit of the validators

The consensus algorithm consists of three steps (pro-pose pre-vote and pre-commit) in each round bound bya timer equally divided among the three steps thus makingit a weakly synchronous protocol These steps signify thetransition of states in each validator Figure 12 illustrates thestate transition diagram for each validator At the beginningof each round a new proposer is chosen to propose a newblock The proposed block needs to go through a two-stagevoting mechanism before it is committed to the blockchain

When a validator receives the proposed block it val-idates the block at first and if okay it pre-votes for theproposed block If the block is not received within thepropose timer or the block is invalid the validator submitsa special vote called Prevote nil Then the validator waitsfor the pre-vote interval to receive pre-votes from the super-majority (denoted as +23) of the validators A +23 pre-votes signifies that the super-majority validators have votedfor the proposed block implying their confidence on theproposed block and is denoted as a Polka in Tendermintterminology At this stage the validator pre-commits theblock If the validator does not receive enough pre-votes forthe proposed block it submits another special vote calledPrecommit nil Then the validator waits for the pre-committime-period to receive +23 pre-commits from the super-majority of the validators Once received it commits theblock to the blockchain If +23 pre-commits not receivedwithin the pre-commit time-period the next round is initiatedwhere a new proposer is selected and the steps are repeated

To ensure the safety guarantee of the algorithm Tender-mint is also coupled with locking rules Once a validatorpre-commits a block after a polka is achieved it must lockitself onto that block Then it must obey the following tworulesbull it must pre-vote for the same block in the next round

for the same blockchain heightbull the unlocking is possible only when a newer block

receives a polka in a later round for the same blockchainheight

With these rules Tendermint guarantees that the con-sensus is secure when less than one-third validators exhibitbyzantine behaviour meaning conflicting blocks will neverbe committed at the same blockchain height In other wordsTendermint guarantees that no fork will occur under this as-sumption Since Tendermint favours safety over availability

19

Propose

Pre-Vote NilPre-commit Nil

Propose Block

New Height

Wait for pre-

commits from +23

Propose BlockCommit New Round

Wait for pre-vote

from +23

Valid block

No +23 pre-vote

for block

+23 pre-vote for block

+23 pre-commit for block

No +

23

pre-

com

mit

for b

lock

Invalid block

or not

received

in time

Figure 12 Tendermint consensus steps

it has one particular weakness It requires 100 uptime ofits +23 (super-majority) validators If more than one-third(+13) are validators are offline or partitioned the systemwill stop functioning [178] In such cases out-of-protocolsteps are required to tackle this situation

Unlike PoW or other PoS algorithms that come withdefined reward mechanisms and crypto-currency applica-tions the latest version of Tendermint more likely acts as theconsensus plugin which can be retro-fit to other blockchainsystems For example Tendermint has been integrated witha private instantiation of Ethereum in a Hyperledger projectcalled Burrows [209] That is why there is no rewardpun-ishment mechanism defined in Tendermint However it canbe easily introduced in the application layer via the ABCIFor example a reward mechanism can be introduced forthe proposer and the validator to motivate them to engagein the consensus process A node can become a validator bybonding a certain amount of security deposit The deposit isdestroyed in case the corresponding validator misbehavesand thus acts as a deterrent for the validator to launchany attack in the network Together with the consensusalgorithm and a carefully designed reward and punishmentmechanism all PoS attacks can be effectively handled

2) CASPER THE FRIENDLY GHOST (CTFG) CTFG is a pureBFT PoS algorithm that aims to transform Ethereum to aPoS-only blockchain system in the future [182] As describedabove CFFG is geared towards a gentle transition from aPoW to a PoS model for Ethereum where CTFG will takecontrol of the consensus mechanism ultimately

CTFG is based upon a rigorous formal model calledCorrection by Construction (CBC) that utilises the GHOST(Greedy Heaviest-Observed Subtree) primitive as its con-sensus rule during fork [183] The idea is that the CTFGprotocol will be partially specified at the initial stage alongwith a set of desired properties Then the rest of the protocolis dynamically derived in such a way that it satisfies the de-sired properties - hence the name correction by constructionThis is in contrast to the traditional approach for designinga protocol where a protocol is fully defined at first and thenit is tested to check if it satisfies the desired properties [156]

To achieve this CTFG introduces a safety oracle actingas an ideal adversary which raises exceptions when a faultoccurs and also approximates the probability of any future

failure Based on this the oracle can dynamically fine-tunethe protocol as required to evolve it towards its completion

Similar to CFFG CTFG also requires a set of bondedvalidators that will bond ethers as a security deposit in asmart-contract However unlike any other PoS mechanismsthe validators will bet on the block which has the highestprobability to be included in the main chain according totheir own perspective If that particular block is included inthe main chain the validators receive rewards for voting infavour of the block Otherwise the validators receive certainpenalties

Like any PoW algorithm CTFG favours availability overconsistency This means that blocks are not finalised in-stantly like Tendermint Instead as the chain grows andmore blocks are added a previous block is considered impli-citly final A major advantage of CTFG over Tendermint isthat it can accommodate dynamic validators This is becausethe finality condition in Tendermint requires that its blockinterval is short which in turn demands a relatively lowernumber of pre-determined validators Since CTFG does notrely on any instant finality it can theoretically accommodatea higher number of dynamic validators

CTFG is currently is the most comprehensive proposalwhich addresses all PoS attack vectors However it is to benoted that this is just a proposal at the current stage There-fore its performance in real settings is yet to be analysed

3) OUROBOROS Ouroboros is a provably secure PoS al-gorithm [185] [186] utilised in the Cardano platform [187]Cardano is regarded as third-generation blockchain systemsupporting smart-contract and decentralised applicationwithout relying on any PoW consensus algorithm

In Ouroboros only a stakeholder can participate in theblock minting process A stakeholder is any node that holdsthe underlying crypto-currency of the Cardano platformcalled Ada Ouroboros is based on the concept of epochwhich is essentially a predefined time period Each epochconsists of several slots A stakeholder is elected for eachslot to create a single block meaning a block is created ineach slot The selected stakeholder is called a slot leader andis elected by a set of electors An elector is a specific type ofstakeholder which has a certain amount Ada in its disposal

In each epoch the electors select the set of stakeholdersfor the next epoch using an algorithm called Follow the

20

Satoshi (FTS) The FTS algorithm relies on a random seedto introduce a certain amount of randomness in the elec-tion process A share of the random seed is individuallygenerated by all electors who participate in a multipartycomputation protocol Once the protocol is executed allelectors posses the random seed constructed with all oftheir shares The FTS algorithm utilises the random seedto select a coin for a particular slot The owner of the coin isthen elected as the slot leader Intuitively the more coins astakeholder possesses the higher is its probability of beingselected as the slot leader

Ouroboros is expected to provide a transaction fee basedreward to incentivise stakeholders to participate in theminting process However the details are in the processof being finalised It has been mathematically proven tobe secure against almost all PoS attack vectors except thecartel formation [185] Nevertheless how it will performonce deployed is yet to be seen

523 DPoSThere are several mechanisms deployed by different crypto-currencies under the general category of DPoS Next wepresent a few prominent approaches of some well-knownDPoS based crypto-currencies Our analysis of these crypto-currencies are summarised in Table 16

1) EOS EOS is the first and the most widely knownDPoS crypto-currency and smart-contract platform as ofnow [188] With the promise of greater scalability andhigher transactions per second than Ethereum it raised 4billion USD in the highest ever ICO event to date [190]Initial EOS currency was created on the Ethereum platformand later migrated to their own blockchain network TheDPoS consensus algorithm of EOS utilises 21 validatorsalso known as Block Producers (BPs) These 21 validators areselected with votes from EOS token (currency) holders Thenumber of times a particular BP is selected to produce ablock is proportional to the total votes received from thetoken holders

Evey DPoS currency must create an initial supply beforethe network is operational This supply is used to select 21BPs (with voting) as well as to reward the BPs for creatingblocks and thus securing the network EOS had an initialsupply of 1 Billion EOS tokens with an annual inflation of5 Among the inflated currencies 1 is used to rewardthe block producers whereas the rest of the 4 are keptfor future RampD for EOS [191] Currently an EOS block iscreated in 05s Blocks in EOS are produced in rounds whereeach round consists of 21 blocks [192] At the beginning ofeach round 21 BPs are selected Next each of them gets achance to create a block in pseduo-random fashion withinthat particular round Once a BP produces a block otherBPs must validate the block and reach into a consensus Ablock is confirmed only when (+23) majority of the BPsreach the consensus regarding the validity of the block Oncethis happens the block and the associated transactions areregarded as confirmed or final so no fork can happen

2) TRON Tron is another popular DPoS based crypto-currency [193] With an initial supply of 99 Billion Trontokens (represented with TRX) it is another smart-contractsupported blockchain platform very similar to Ethereum

and EOS in functionality Its consensus mechanism utilises27 validators known as Super Representatives (SRs) [194]The SRs are selected in every six hours with votes by TRXholders who must freeze a certain amount of TRX to vote foran SR The deposits amount can be frozen back after threedays once the voting is cast [195] A block in Tron is createdin every 3s for the corresponding SR receives a reward of 32TRX Another important feature of Tron is that there is noin-built inflation mechanism in the protocol which impliesthat the total supply will remain constant throughout itslifespan

3) TEZOS Tezos is like EOS and Tron a smart-contract plat-form which utilises a variant of DPoS consensus algorithm[196] With a block reward of 16 XTZ (Tezos currency) andblock creation time of 60s Tezos does not require any pre-defined number of stakeholders (or Bakers as defined inTezos) [197] This differs Tezos from other DPoS currenciesInstead the consensus mechanism utilises a dynamic rangeof stakeholders where anyone holding a substantial amountof XTZ can be a stakeholder This limits general usersto participate in the consensus mechanism To rectify thisproblem Tezos provides a mechanism by which anyone candelegate their XTZ to someone so that it can accumulate therequired number of XTZ to be a baker In return the bakerwould return a certain proportion of their received blockreward to the delegating party Tezos started with an initialsupply of 765 Million XTZ tokens It relies on an annualinflation of 551 and the inflated currencies are used toreward the bakers

4) LISK Lisk is a unique DPoS blockchain platform whichenables the development of DApps using JavaScript [200]Another unique feature of Lisk is its ability to accommodateand then to operate with multiple blockchains known assidechains along with a central blockchain called mainchainEach sidechain can be deployed and maintained by aparticular application provider which needs to be syncedwith the mainchain as per the Liskrsquos protocol rule In thisway different applications can leverage different sidechainssimultaneously without burdening off the mainchain Eventhough the responsibility of maintaining a sidechain relieson the particular application provider the mainchain mustbe maintained with the Lisk DPoS consensus protocolwhich utilises 101 delegates [201] Only these delegates canproduce a block These delegates are selected using votesfrom Lisk currency (denoted with LSK) owners whereeach holder has 101 votes The weight of each vote isproportional to the amount of LSK owned by the respectiveowner The selection of delegates happens before a roundwhere each round consists of 101 block generation cycleThus in a round each delegate is randomly selected tocreate a block It has a block creation time of 10 secondsand block reward of 5 LSK Started with an initial supplyof 100 million LSK Lisk has a current supply of 132 millionwith an annual inflation of 565

5) ARK Ark is yet another DPoS based blockchain platform[202] It utilises 51 delegates to create 51 blocks in eachround [203] With a block creation time of 8s each roundlasts for 408s Each delegate receives 2 ARK (the nativecurrency of the ARK platform) for creating a block It had

21

an initial supply of 125 million With an annual inflationof 555 the supply was around 142 million (as of June2019) Like other DPoS blockchains the delegates in Arkare also selected with votes by Ark currency owner wherethe weight of each is proportional to the amount of ARKowned by the voter

524 Limitations of PoSEven though the variants of different PoS algorithms offerseveral significant advantages there are still a few disad-vantages in these classes of algorithms We explore thesedisadvantages belowbull Collusion If the number of validators is not large

enough it might be easier to launch a 51 attack on thecorresponding consensus algorithm by colluding withother validators

bull Wealth effect The sole reliance on coin-wealth in aconsensus algorithm or for the selection of validatorscreates an environment where people with a large por-tion of coins can exert greater influence

In addition to these disadvantages there have been a fewother attack vectors identified for the PoS algorithmsbull Nothing-at-stake (NAS) attack [157] During a block-

chain fork an attacker might attempt to add its newlycreated block in all forked branches to increase theirprobability to add their block as the valid block Suchscenario is unlikely to occur in any PoW algorithmThis is because a miner would need to share theirresources in order to mine at different branches Thiswould eventually decrease their chance of finding anew block because of the resources shared in multiplebranches Since it does not cost anything for a minterin a PoS algorithm to add blocks in multiple parallelbranches the attacker is motivated to do so Applyinga penalty for such misbehaviour could effectively tacklethis problem

bull Bribing (short-range SR) attack [157] [176] In thisattack an attacker tries to double spend by creating afork An example of this attack would be as follows Theattacker pays to a seller to buy a good The seller waitsfor a certain number of blocks (eg six blocks) beforethe good is delivered to the attacker Once deliveredthe attacker forks the main chain at the block (eg sixblocks back which is relatively short and hence thename) in which the payment was made Then the at-tacker bribes other minters to mint on top of the forkedbranch As long as the bribed amount is lower thanthe price of the delivered good it is always profitablefor the attacker The colluding minter has nothing tolose if it is coupled with the nothing-at-stake attack ontheir part but can gain from the bribery Again it canbe tackled by introducing a penalty mechanism for allmisbehaving parties

bull Long-range (LR) attack [157] In this attack the attackerattempts to build an alternative blockchain startingfrom the earliest blocks if the attacker can collude withthe majority of the stakeholders The motivation mightbe similar to double spending or related issues provid-ing advantages to the attacker as well as the colludedstakeholders As explained above the colluded stake-holder has nothing to lose if it can be coupled with the

nothing-at-stake attacks Check-pointing is one of themethods by which it can be tackled The check-pointingcodifies a certain length of the blockchain to make itimmutable up to that point and thereby underminingthe attack This is because the attacker cannot fork theblockchain before that check-point

bull Coin-age accumulation (CAC) attack [157] [176] ThePoS algorithms that rely on the uncapped coin-ageparameter are susceptible to this attack In this attackthe attacker waits for their coins to accumulate enoughcoin-age to exploit the algorithm for launching doublespends by initiating a fork This attack can be tackledby introducing a cap on the coin-age which minimisesthe attack vector

bull Pre-computing (PreCom) attack [157] [155] A pre-computing attack also known as Stake-grinding attackwould allow an attacker to increase the probability ofgenerating subsequent blocks based on the informationof the current block If there is not enough randomnessincluded in the PoS algorithm the attacker can attemptto pre-compute subsequent blocks by fine-tuning in-formation of the current block For a particular set ofinformation (eg a set of transactions) if the attackerfinds that the probability of minting a few subsequentblocks is less than desired the attacker can updatethe set of transactions to increase their probability ofdetermining the next few blocks It can be effectivelytackled by introducing a secure source of randomnessin the algorithm

bull Cartel formation (CAF) attack [158] In economic the-ory an oligopoly market is dominated by a small set ofentities having greater influence or wealth than otherentity They can collude with one another by forming acartel to control price or reduce competition within themarket It has been argued that rdquoBlockchain architectureis mechanism design for oligopolistic marketsrdquo [159] whichaffects both PoW and PoS algorithms Such a cartel canlaunch 51 attacks on the PoS algorithm or exploit thestakes to monopolise the PoS algorithm

525 AnalysisIn this section we summarise the properties of differentPoS algorithms utilising the taxonomies and PoS attackvectors in Table 17 Table 18 Table 19 and Table 20 Likebefore a lsquo rsquo symbol has been utilised to indicate if thecorresponding algorithm supports a particular propertyand the lsquoXrsquo symbol signifies that the particular propertyis not supported The lsquo-rsquo symbol implies that the propertyis not applicable whereas the symbol lsquorsquo indicates that noinformation has been found for that particular feature Forother properties explanatory texts have been used as well

From Table 17 only chained algorithms are based onmultiple committee utilising a flat topology with a dynamicconfiguration These algorithms also use a probabilistic lot-tery to select a minter Conversely other PoS algorithms ex-cept Tendermint are based on the single committee havingan open type and explicit formation with a dynamic config-uration and mostly rely on voting mechanisms Tendermintuses a closed committee with a static configuration

As per Table 18 none of the algorithms except Tender-mint requires any node to be authenticated to participate

22

Table 16 Comparison of DPoS Currencies with lsquo-rsquo signifying not applicable


Initial supply Inflation Current supply(23052019)

Block reward Block Time Validatornos

EOS 01072017 1 Billion 5 104 Billion 1 of inflatedcurrency dividedamong 21validators

05s 21

Tron 28082017 99 Billion - 99 Billion 32 TRX 3s 27Tezos 30062018 765 Million 551 795 Million 16 XTZ 60s Not pre-

definedLisk 24052016 100 Million 567 132 Million 5 LSK 10s 101Ark 21032017 125 Million 555 142 Million 2 ARK 8s 51

in the algorithm All of them have strong support for non-repudiation in the form of digital signature as part of everysingle transaction These algorithms have a high level ofcensorship resistance as do all PoW algorithms As forthe attack vector each PoS algorithm requires every minernode to invest substantially to participate in this algorithmThis feature thus acts as a deterrent against any Sybil orDoS attack in any PoS algorithm The adversary tolerancefor Chained systems can be calculated using this formulamin(2f + 1 3f + 1) = 3f + 1 This is because a chainedalgorithm utilises both PoW and PoS algorithms and thusneeds to consider the adversary tolerance for both of themWe consider the minimum of these two (3f + 1) Thesupported adversary tolerance for other algorithms is 3f +1except BFT Ouroboros whose adversary tolerance is 2f + 1

According to Table 20 all BFT and DPoS algorithmshave considerably high throughput low latency and highscalability Their energy consumption is negligible How-ever the chained algorithms have a comparatively lowerthroughput lower scalability and higher latency with re-spect to their BFT and DPoS counterparts The fault toler-ance of chained and BFT algorithms is 2f + 1 like any BFTalgorithm implying they can achieve consensus as long asmore than 50 of nodes function properly However DPoSalgorithm requires a 3f + 1 fault tolerance

Table 19 outlines a comparison of additional attack vec-tors with symbols representing the usual semantics CTFGTentermint and Ouroboros have mitigation mechanismsagainst these attack vectors However Casper FFG andany DPoS algorithms cannot successfully defend againstthe cartel formation attack Peercoin on the other handhas mechanism against this cartel formation attack unfor-tunately suffers from all other attack vectors

Finally a comparison of the selected DPoS crypto-currencies is presented in Table 16

6 INCENTIVISED CONSENSUS BEYOND POW ANDPOS

Some consensus algorithms take a different approach inwhich they do not solely rely on any PoW or PoS mech-anism Instead they use an approach in which a PoW-PoS mechanism is combined with another approach Weconsider such algorithms as hybrid algorithms which arepresented in Section 61 Other approaches adopt a moredrastic approach in which they do not leverage anytype PoWPoS algorithm whatsoever Such algorithms are

tagged as N-POSPOW (to symbolise Non-PoSPoW) al-gorithms and discussed in Section 62

61 Hybrid ConsensusIn this section we outline a new breed of consensusesalgorithms that combine either a PoW or PoS algorithmor both with another novel algorithm or mechanism thuscreating a hybrid mechanism

1) PROOF OF RESEARCH (POR) Proof of research is ahybrid approach that combines proof-of-stake with theproof-of-BOINC [160] BOINC stands for Berkeley OpenInfrastructure for Network Computing [162] It is a gridcomputing platform widely used by scientific researchersin different domains by allowing them to exploit the idlecomputing resources of personal computers around theworld With the proof-of-BOINC a researcher has to provehis contribution for the BOINC research work

The PoR mechanism is leveraged by Gridcoin [160][161] a crypto-currency that can be earned by anyone bysharing their computing resources with the BOINC pro-ject The mechanism by which PoS and Proof-of-BOINCare tied together for the PoR is explained next [161] ThePoS mechanism is similar to the traditional PoS algorithmAnyone can become a minter known as Investor in Gridcointerminology by owning a certain amount of Gridcoin andparticipating in the minting process In addition to thisother users known as Researchers in Gridcoin terminologycan also participate in the minting process Interestingly aninvestor can also be a researcher and thus can increase theiramount of grid coin earned

For this a researcher installs the BOINC software andregisters a project from the BOINC whitelist with his emailaddress The researcher is assigned a unique cross projectidentifier (CPID) and starts downloading the work shareOnce the computation is completed the researcher returnsthe result with a credit recommendation for the completedworkload The recommendation is compared with that ofanother researcher and the minimum credit is rewardedThis workload credit data is stored in the header of eachblock and the researcher is rewarded with the correspondingamount of Gridcoin To summarise the consensus mechan-ism is mostly dominated by the PoS mechanism with Proof-of-BOINC acts as a reward mechanism for sharing unusedcomputing resources available to the researchers Hence itssecurity is similar to that of the traditional PoS algorithm

2) SLIMCOINrsquoS PROOF-OF-BURN (POB) The Proof-of-Burnis a consensus algorithm proposed by Ian Stewart as an

23

Table 17 Comparing structural properties of PoS Consensus Algorithms

Single committee Multiple committeeConsensusSystem Node type Type Formation Configuration Topology Configuration Mechanism

Chained(PeerCoin)

Clients Minersamp Minters

- - - Flat Dynamic Probabilistic lottery

Chained(CFFG)

Clients Minersamp Validators


BFT(Tendermint)

Clients ampValidators

Open (Close) Explicit Dynamic (Static) - - Voting

BFT (CTFG) Clients ampValidators

Open Explicit Dynamic - -

BTFG(Ouroboros)

ClientsElectors amp

Stakeholders

Open Explicit Dynamic Voting

DPoS Clients ampValidators

Open Explicit Dynamic - - Voting

Table 18 Comparing security properties of PoS Consensus Algorithms

Attack VectorsConsensusSystem Authentication Non-repudiation Censorship

resistance Adversary tolerance Sybil protection DoS Resistance

Chained(PeerCoin)

X High 3f + 1

Chained(CFFG)

X High 3f + 1

BFT(Tendermint)

(In closetype) X (Inopen type)

High 3f + 1

BFT (CTFG) X High 3f + 1

BFT(Ouroboros)

X High 2f + 1

DPoS X High 3f + 1

Table 19 Comparison of additional attack vectors protection among PoS Consensus Algorithms

ConsensusSystem Nothing-at-Stake Bribing Long-range Coin-age Pre-computing Cartel formation

Chained (PeerCoin) X X X X XChained (Casper FFG) X

BFT (Tendermint)BFT (CTFG)

BFT (Ouroboros)DPoS X

Table 20 Comparing performance properties of PoS Consensus Algorithms

ConsensusSystem Faulttolerance

Throughput Scalability Latency Energy consumption

Chained (PeerCoinCFFG)

2f + 1 Medium Medium Medium Medium

BFT (TendermintCTFG Ouroboros)

2f + 1 High High Low Low

DPoS 3f + 1 High High Low Low

alternative to PoW [163] In PoW miners need to invest inbuilding a mining rig in order to participate in the miningprocess In PoB miners need to burn their coins in order toparticipate in the mining process Burning coins mean thatsending coins to an address without the private key andthus never usable Thus burning coins is an analogous ideato the investment for building a mining rig The amountof burning has a positive correlation with the possibilityof being selected for mining the next block This is similarto the PoW system where the miners increasingly investin modern equipment to maintain the hash power as theincentive decays with the complexity

Slimcoin is a crypto-currency which utilises the idea of

PoB in combination with PoW and PoS [164] [165] thuscreating a hybrid consensus mechanism Algorithmicallytheir idea is similar to the chained PoS algorithm of Peercoinas presented in in Section 521 with additional PoB mech-anism sandwiched in between PoW and PoS algorithmsThe PoW is used to generate the initial coin supply usingthe mechanism of Bitcoin When the system has sufficientamount of money supply it plans to switch to a hybrid ofPoW and PoS mechanism similar to Peercoin where PoB willbe used to select the miner As this happens the minterswill need to burn their accumulated coins in order to beeligible to participate in the PoS minting process Since PoB

24

algorithm is mostly used for minter selections it has hardlyany effect on the security of the system Hence its securityand other properties are mostly similar to that of Peercoin

3) PROOF OF STAKE-VELOCITY (POSV) One of the majorlimitations of coin-age based PoS is that there is no incentive(or lack of penalty thereof) for the minters to be online toparticipate in the staking process This is because that thecoin-age increases linearly over time without the need forthe stakeholders to be online and participate in the stakingprocess They can therefore choose to participate for a shortperiod and then collect the reward and may go offline againThe lack of participants may facilitate attacks at a certaintime

To counteract this problem a crypto-currency calledReddcoin proposed a novel hybrid algorithm called Proof ofStake-Velocity (PoSV) [166] [168] The central to the PoSV isthe idea of a mechanism called the velocity of stakes coupledwith any traditional PoS algorithm Conceptually the velo-city of stake mirrors the notion of the velocity of moneya terminology from Economics implying the frequency ofmoney flow within the society [169] Indeed the velocityof stakes evolves around the idea of increasing the flow ofstakes during the PoS consensus mechanism [167] This (theflow of stakes) can be achieved if the minters are encour-aged to actively participate in the consensus mechanism bystaking their crypto-currency instead of holding their coinsoffline This process in a way will also increase the overallsecurity of the system and counteract the lack of participantissue in PoS

To facilitate this PoSV introduces a non-linear coin-ageing function in which the coin-age of a particular coinis gained much faster in the first few days and weeks thanthe gain in later weeks For example it has been estimatedthat minters who stake their coins every two weeks or lesscan earn up to 20 more than people who do not participatein the staking process [167] Such incentives encourage theminters to increase the velocity of stakes in the wholenetwork Note that PoSV is similar to any PoS mechanismalong with its properties and hence not explored in detailhere

62 N-POSPOWThe consensuses algorithms presented in this category donot rely any way on either PoW or PoS algorithms Insteadthey rely on completely novel mechanisms Therefore wecall them N-POSPoW algorithms for the convenience ofgroup naming1) PROOF-OF-COOPERATION (POC) The Proof-of-Cooperation is a consensus algorithm introduced by theFairCoin crypto-currency [170] [171] This consensusalgorithm relies on several special nodes known as CertifiedValidating Nodes (CVNs) CVNs function similar to the wayvalidators act in a DPoS consensus algorithm as utilised byEOS or Tron crypto-currencies as they are nodes which cancreate blocks in Faircoin using the PoC consensus algorithmHowever unlike any DPoS validators each CVN node isauthenticated by their corresponding Faircoin identifier aswell as trusted following a set of community-based rulesand technical requirements [171] The community rulesstate that a candidate node willing to be a CVN must

participate in Faircoin community activities by performingsome tasks Examples of these tasks are running a localnode or contributing to any technical or management issuerelated to Faircoin which must be confirmed by at least twoactive members of the community Besides the candidatenode must follow a set of technical requirements suchas 247 network availability and a special cryptographichardware used for signature generation

With the involvement of CVNs selected in the previouslydiscussed manner the core mechanism for PoC consensusalgorithm is briefly discussed next Blocks in Faircoin arecreated in a round-robin fashion in every three minutesof epoch by one of the CVNs To create a new blocka CVN needs to be selected using a deterministic votingmechanism individually carried out by every single CVN inthe network The steps of this mechanism arebull Each CVN finds the CVN which has created a block

furthest in the chain by traversing backwards throughthe chain

bull Next it is checked if the found CVN has been activerecently in the network by looking for its signature inthe last few blocks If so this CVN will be selected asthe next CVN

bull Then each node creates a data set consisting of the hashof the last block the ID of the selected CVN for the nextblock and its own CVN ID which is then signed by thespecified cryptographic hardware The created datasetalong with the signature is then propagated throughthe network

bull The selected CVN receives this dataset along with theirsignature from multiple CVNs and verifies each signa-ture As soon as the selected CVN finds that more than50 CVNs have selected it to be the next block creatorit can be certain that its turn is next at the end of thecurrent epoch ie three minutes

bull The selected CVN adds all pending transactions into anew block along with all the received signatures andpropagates the block in the network

bull Upon receiving the block other CVNs verify the blockby checking the if the CVN who created the block isactually the one selected as the block creator as wellas validating all signatures in it and its transactions Ifthe verification is successful the block is added to theblockchain and the same mechanism continues

2) PROOF OF IMPORTANCE (POI) PoS gives an unfairadvantage to coin hoarders The more coins they keep intheir accounts the more they earn This means the rich getricher and everyone has an incentive to save coins instead ofspending them To solve these issues NEM has introduceda novel consensus mechanism called ldquoProof of Importance(PoI)rdquo [172] It functions similarly to PoS nodes need torsquovestrsquo an amount of currency to be eligible for creating blocksand are selected for creating a block roughly in proportion tosome score In Proof-of-stake this rsquoscorersquo is onersquos total vestedamount but in PoI this score includes more variables Allthe nodes that have more than 10000 XEM (the correspond-ing crypto-currency of XEM) are theoretically given equalpositive importance and with 9B XEM coins there can bemaximum 900K such nodes However the actual numberof such nodes and their importance vary with time and their

25

amount of transaction in XEMThe calculations borrow from the math of network clus-

tering and page ranking At a high level the primary inputsarebull Net transfers how much has been spent in the past

30 days with more recent transactions weighted moreheavily

bull Vested amount of currency for purposes of creatingblocks

bull Cluster nodes accounts that are part of interlinkedclusters of activity are weighted slightly more heavilythan outliers or hubs (which link clusters but not partof them)

In NEM the importance of an account depends onlyon the net transfers of XEMs from that account To beconsidered for the importance estimation at a certain blockheight h a node must have transferred at least 100 XEMsduring the last 30 days or 43 200 blocks The ldquoimportancescorerdquo addresses two primary criticisms of proof-of-stake

One risk is that people hoard many coins as possibleand reap the rewards from block creation This concentrateswealth while discouraging transactions The importancescore means that hoarding will result in a lower score whilespreading XEM around will increase it Being a merchantpays better than having a hoard

63 AnalysisIn this section we summarise the properties of different Hy-brid and N-PowPoS algorithms utilising the taxonomies inTable 21 Table 22 Table 23 and Table 24 Like before lsquo-rsquosignifies that the corresponding property is not applicablefor the respective consensus algorithm lsquorsquo indicates that theinformation the property has not been found a lsquo rsquo is usedto indicate an algorithm satisfies a particular property andlsquoXrsquo is used to imply the reverse (not satisfied)

Table 21 presents the comparison of structural propertiesfor the corresponding consensus algorithms Among themPoR and PoB depend on a multiple committee formationwith a flat topology and dynamic configuration ConverselyPoSV and PoI use an open single committee with a dynamicconfiguration and probabilistic lottery as their underlyingmechanism PoC has an implicit open and dynamic singlecommittee which relies on voting mechanism

All these algorithms have an adversary tolerance of3f+1 with the support of non-repudiation Sybil protectionDoS resistance and high censorship resistance as reportedin Table 22 Entities in PoB PoSV and PoI do no require to beauthenticated while PoC entities must be authenticated andresearchers in PoR need to be authenticated However otherentities in PoW can remain non-authenticated as indicatedwith the lsquoXrsquo symbol in the table All of them except PoCand PoI have 3f + 1 adversary tolerance because of theirusage of PoS algorithms We have not found any regardingadversary tolerance for PoC and PoI

Table 23 presents the comparison of some additionalattack vectors for the Hybrid algorithms As evident fromthe table since these algorithms utilise PoS as one of theirconsensus algorithms they suffer from the similar limita-tions of any PoS algorithm For example none of them hasany guard against most of these additional attack vectors

The only exception is PoB which is because of its use ofPeercoin like functionality can resist the cartel formationattack

The comparison of the performance properties for thesealgorithms is presented in Table 24 All of them have 2f + 1fault tolerance except PoC and PoI as we have not foundany information fault tolerance for PoC and PoI In terms ofScalability Latency and Energy every algorithm except PoBexhibits similar characteristics they have high throughputconsume low energy and have low latency meaning theyreach finality quickly Because of its reliance on PoW PoBhas low scalability low latency and also consume meidumenergy In terms of throughput PoR PoSV and PoI havehigh throughput whereas PoC has a low throughput andPoB has a medium throughput

Finally a comparison of the selected Hybrid and N-PoWPoS crypto-currencies is presented in Table 25

7 NON-INCENTIVISED CONSENSUS

In this section we present non-incentivised consensusalgorithms that are used in private blockchain systemswell-suited for non-crypto-currency applications These al-gorithms are mostly based on classical consensus algorithmswith special features added for their adoption for the corres-ponding blockchain systems

One of the major initiatives within the private blockchainsphere is the Hyperledger project which is an industry-wide effort [206] Founded by the Linux Foundation it isa consortium of some of the major tech vendors of theworld It provides an umbrella to facilitate the developmentof different types of open source projects utilising privateblockchains with a specific focus to address issues involvingbusiness and governmental use-cases Currently there aresix major projects within Hyperledger Hyperledger Fabric[207] Hyperledger Sawtooth [208] Hyperledger Burrow[209] Hyperledger Iroha [210] and Hyperledger Indy [211]Each of them is analysed below with a brief introduction

71 Hyperledger FabricHyperledger Fabric is the first major private blockchainsystem that originated from the Hyperledger ecosystem[207] It has been designed with strong privacy in mindto ensure that different businesses organisations includinggovernmental entities can take advantage of a blockchainsystem in different use-cases A crucial capability of Fabricis that it can maintain multiple ledgers within its ecosystemThis is a useful feature which separates Fabric from otherblockchain systems consisting of only one ledger in each oftheir domains

A key strength of Fabric is its modular design andpluggable features For example Fabric is not dependanton a particular format of ledger data which is useful inseveral use-cases In addition the consensus mechanismis fully pluggable Therefore different types of consensusalgorithms can be used in different situations

As part of its consensus process Fabric utilises a specialentity called Orderer which is responsible for creating anew block and extending the ledger by adding the blockin the appropriate order In addition there are other entit-ies known as endorsers Each endorser is responsible for

26

Table 21 Comparing structural properties of Hybrid and N-POSPOW Consensus Algorithms


PoR Clients(Researchers) amp

Minters


PoB Clients Minersamp Minters


PoSV Clients ampMinters

Open Implicit Dynamic Probabilistic lottery

PoC Clients amp CVNs Open Explicit Dynamic - - VotingPoI Clients amp

transactionpartners

Open Implicit Dynamic - - Probabilistic lottery

Table 22 Comparing security properties of Hybrid and N-POSPOW Consensus Algorithms

Attack VectorsConsensus Authentication Non-repudiation Censorshipresistance

Adversary tolerance Sybil protection DoS Resistance

PoR X High 3f + 1

PoB X High 3f + 1

PoSV X High 3f + 1

PoC High PoI X High

Table 23 Comparison of additional attack vectors protection for Hybrid and N-POSPOW Consensus Algorithms


PoR X X X X X XPoB X X X X X

PoSV X X X X X X

Table 24 Comparing performance properties of Consensus Algorithms of Hybrid and N-POSPOW

Consensus Faulttolerance

Throughput Scalability Latency Energy

PoR 2f + 1 High Medium Low LowPoB 2f + 1 Medium Low Medium MediumPoSV 2f + 1 High Medium Low LowPoC LoW (106 TPS [173]) Medium Low LoWPoI High Medium Low Low

Table 25 Hybrid amp Non-PoWPoS currencies


Block reward Total supply Consensus Block Time

Gridcoin 24 Mar 2016 Minting 42 Million PoR PoS 1 minuteSlimcoin May 2014 50-250 coins 133 Million PoB PoW PoS 15 minutesReddcoin January 20

2014Block reward 28 Billion PoSV 1 minute

Faircoin 6th of March2014

Block reward 53 Million PoC Depends onTime-weightParameter

Burst 11 August 2014 Reduces at a fixed rateof 5 percent each month

204 Million PoC 4 minutes

NEM March 31st2015

transaction fees only +node rewards

899 Million PoI 1 minute

validating and endorsing a transaction where it checks ifan entity is allowed to perform a certain action in a ledgerencoded within the transaction Other participating entitiesare general users who create transactions All the entitiesincluding the Orderer(s) and the endorsers are registeredand authenticated via a Fabric specific special entity calledMembership Service Provider (MSP) The MSP is responsiblefor managing the identities of all participants in the ledger

Using this identity layer it is possible to create securitypolicies that dictate which entities can perform what actionswithin a specific ledger A simple flow of a consensusprocess in Fabric is illustrated in Figure 13

The number of Orderer can be increased to distribute theordering service Currently it supports SOLO and Kafka ASOLO ordering service consists of just one single ordererand hence cannot provide any type of fault tolerance That

27

A All required entities are registered in the MSPB A channel with a ledger is initiated In addition a

policy is created containing the endorsement criteriaas well as other security and privacy criteria

C A chaincode (smart-contract written either in Java orGo) is deployed in the ledger

D When an entity wishes to invoke certain functions inthe chaincode to read data from the ledger or to writedata into the ledger it submits a transaction proposalto all the required endorsers as dictated in the policy

E Each endorser validates the proposal executes thechaincode and returns a proposal response consistingof other ledger data

F The proposal its response and other ledger data areencoded as a transaction and sent to the Orderer

G The Orderer creates a block using the transaction andreturns the block to the endorsers

H Each endorser validates the block and if validatedextends the ledger by attaching the new block Thisessentially updates the state of the ledger

Figure 13 A simple flow of a consensus process in Fabric

is why it is not recommended to utilise the SOLO modelin the deployed system and has only been provided forinitial testing On the other hand the Kafka Orderer utilisesa Kafka cluster for deploying distributed Orderers Kafkais a distributed streaming platform with a pub-sub archi-tecture [212] and is coupled with Zookeeper a distributedcoordination service [213] At this point the Kafka Ordereris the only recommended setting for achieving consensusin Fabric An SBFT (Simplified Byzantine Fault Tolerance)based consensus algorithm is currently being developed andis to be released soon

72 Hyperledger Sawtooth

Hyperledger Sawtooth initially developed by Intel is asoftware framework for creating distributed ledgers suitablefor a variety of use cases [208] Sawtooth utilises a novelconsensus algorithm called Proof-of-Elapsed-Time (PoET)which depends on Intel SGX (Software Guard Extension)Intel SGX is a new type of Trusted Execution Environment(TEE) integrated into the new generation of Intel processorsSGX enables the execution of code within a secure enclaveinside the processor whose validity can be verified using aremote attestation process supported by the SGX

PoET similar to the Nakamoto consensus algorithm inBitcoin relies on the concept of electing a leader in eachround to propose a block to be added in the ledger Thedifference is that the Nakamoto algorithm and its variantsselect a leader by a lottery mechanism which utilises com-puting power to generate a proof as described previouslyHowever PoET solely relies on the Intel SGX capability toelect a leader During each round every validator nodein the network requests for a wait time from a trustedfunction in the SGX enclave The validator that is assignedthe shortest waiting time is elected as the leader for thatround The winning validator then can propose a block

consisting of a series of transactions from the defined trans-action family Other validators can utilise a trusted functionsupported by SGX to assess whether a trusted function hasassigned the shortest time to the winning validator andthe winning validator has waited the specified amount oftime Furthermore other validators verify the validity ofthe block before it is included in the ledger The inclusionof the PoET as a consensus algorithm enables Sawtooth toachieve massive scalability as it does not need to solve ahard computationally intensive cryptographic puzzle Inaddition it allows Sawtooth to be used not only for apermissioned ledger but also for a public ledger

73 Hyperledger BurrowHyperledger Burrow is a private (permissioned) deploy-ment of the Ethereum platform [209] It has been createdand then deposited to the Hyperledger code-base by MonaxIndustries Limited [214] The core component in Burrowis a permissioned version of the EVM (Ethereum VirtualMachine) to ensure that only authorised entities can executecode Two additional components have been added Byz-antine fault-tolerant Tendermint protocol [179] [221] andthe RPC gateway

The Tendermint consensus falls under the category ofa Byzantine Fault Tolerance (BFT) algorithm which canbe used to achieve consensus even under the Byzantinebehaviour of a certain number of nodes as presented inSection 522

Burrow depends on several validators which are known(authorised) entities with the duty to validate each blockutilising the Tendermint consensus algorithm This al-gorithm allows consensus to be achieved in Burrow with13 nodes exhibiting Byzantine behaviour either actingmaliciously or having been down due to network or systemfailure

Since Burrow utilises the EVM a wide-range of smart-contracts and DApps (Decentralised Applications) couldbe deployed Using the Tendermint algorithm with a setof known validators allows Burrow to scale at a muchfaster rate than Ethereum while preserving the privacy oftransactions by allowing only known entities to participatein the network

74 Hyperledger IrohaHyperledger Iroha is a private blockchain system initiallydeveloped by Soramitsu Hitachi NTT Data and Coluand is currently hosted by Linux foundation under theHyperledger Project [210] [215] Iroha aims to create asimple blockchain infrastructure which can be incorporatedinto any system which requires a blockchain architectureunderneath to function The major emphasis while design-ing Iroha is on a simpler construction with a strong focuson mobile-friendly application development using a novelconsensus mechanism called YAC (Yet Another Consensus)[215] [216] One fundamental different of Iroha from otherHyperledger project is its fine-grained permission controlmechanism which allows defining permissions for all relev-ant commands queries and even joining in the network

The core architecture consists of several components[216] [219] A brief description of its major components ispresented below

28

bull Troii represents the entry point of any application tothe Iroha network It utilises gRPC (gRPC Remote Pro-cedure Calls [218]) an open source RPC frameworkto interact with different peers and entities within theblockchain network

bull Model represents how different entities are representedwithin the system and defines the mechanism to inter-act with them

bull Network provides the network functionalities requiredto maintain the P2P network and to propagate transac-tions in the network

bull Consensus facilitates the functionalities related toachieving consensus in the network using the YACconsensus protocol a practical byzantine fault-tolerantalgorithm (discussed below)

bull Simulator provides a mechanism to simulate the effectsof transactions on the chain by creating a temporarysnapshot of the chain state

bull Validator allows the validation of transactions by veri-fying its formats and signature along with the veri-fication of business rules and policies involved in thetransactions There are two types of validations in Irohandash Stateless validation checks for transaction formats and

signaturendash Stateful validation checks the business rules and

policies eg if a certain action is allowed by an entitybull Synchroniser is a part of the consensus component and

is responsible for synchronising the chain to a new ordisconnected node

bull Ametsuchi is the storage component of Iroha and isused to store the blocks and the chain state known asWorld State View (WSV)

These components are used by three core entities withinthe architecture [216]bull Clients are applications that they can query data from

the allowed Iroha chain as well as can perform certainactions called commands by which the state of thechain is updated For each of these clients need tointeract with the peer

bull Peers are nodes that have the following two functional-itiesndash To maintain a copy of the ledger Applications can

thus interact with a peer to query a chain or to submittransactions to update the chain

ndash To participate in the consensus process by maintain-ing its address identity and trust as a single entity inthe network

bull Ordering service node(s) Like Fabric ordering servicenodes are responsible for ordering transactions andcreating a proposal of a block

With these components and entities a flow of transac-tions in Iroha is briefly presented in Figure 14 [216]

75 Hyperledger Indy

Hyperledger Indy is a private blockchain system purpose-fully built for providing an ecosystem for blockchain-basedself-sovereign identity [211] [222] The concept of Self-Sovereign Identity has been initially promoted by the Sovrinfoundation [223] a non-profit international entity consisting

A A client prepares and sends a transaction to a peerusing Troii

B The peer performs stateless validation to the trans-action and forwards the transaction to the orderingservice using an ordering gate

C The ordering service combines and orders transac-tions from different peers in a transaction proposalwhich is then broadcast to the peers

D Each peer performs a stateful validation of the pro-posal using the simulator and creates a block con-sisting of only verified transactions Each peer signsthe block generates a hash of the proposed blockand finally creates a tuple containing the hash andthe signature Such a tuple is called a vote The blockand the vote are then internally sent to the consensusgate to initiate the YAC mechanism

E The YAC mechanism in each peer prepares anordered list of voting peers utilising the hashescreated in the previous step The first peer in thelist is regarded as the leader and is responsible foraggregating votes from other voting peers

F After aggregating all votes from the voting peers theleader computes the supermajority (usually 23rd)of votes for a certain hash (signifying a block)

G Once a supermajority for a proposed block isachieved the leader propagates a commit messagefor this particular block to all voting peers

H Each voting peer verifies the commit message andadds the block to the blockchain

Figure 14 A flow of transactions in Iroha

of several private organisations to promote the notion ofSelf-sovereign Identity The Indy project is closely associatedwith the Sovrin foundation focusing on materialising thisnotion of a self-sovereign identity system as a public identityutility

Currently Indy consists of the following two major com-ponentsbull Indy-plenum Plenum is the underlying distributed

ledger (blockchain) construct of the Indy platform Likeany distributed ledger the Plenum ledger is fundament-ally an ordered log of transactions In addition it consistsof several nodes among which a single or a few chosenones act as the leader responsible for ordering the trans-actions The nodes execute a consensus protocol whichutilises a three-phase commit to reach agreement amongthemselves regarding the order of the transactions

bull Indy-SDK This provides the required software APIs andtools to enable other software to interact with the Plenumledger It hides all the intricate internals from the users ofthe platform so that the platform can be utilised withouteven knowing the complexities of the ledger and its asso-ciated consensus protocol

The consensus protocol utilised in Indy is called RBFT(Redundant Byzantine Fault Tolerance) [224] Like any otherbyzantine fault tolerance protocol it relies on 3f + 1 nodes(a participant in the consensus protocol) in order to handlef byzantine nodes [224] [225] For example it requires

29

four deployed nodes in order to handle a single byzantinenode Each participating node in RBFT deploys two (ormore) protocol instances aptly called Master and Backupprotocol instance each of which is executed in parallel Aseparate primary node (also called a leader) is selected fromthe master and the backup protocol instance The leader isresponsible for ordering the transactions Its performancesie latency and throughput are periodically observed bythe other instances If its performance degrades a differentleader is selected from the backup instance

Indy maintains a number of ledgers for different pur-poses unlike many other blockchain systems which employa solo ledger For example separate ledgers are maintainedfor node maintenance for identity transactions and so onClients (users via their appropriate software interfaces) caninteract with these ledgers via different nodes for updatingthe ledger via transactions and for reading from the ledgervia queries A fine-grained permission mechanism can beused to dictate which client has to write permissions how-ever any client can read from the ledger

Once a node receives a transaction from a client it per-forms some validation and then broadcasts the transactionto other nodes in the network When the transaction reachesenough nodes the primary node starts a new consensusround using a three-phase commit mechanism In the endall nodes agree to the order proposed by the primary nodeand add the transaction into the corresponding ledger

76 Analysis

In this section we analyse the non-incentive consensus pro-tocols against the criteria selected before Block and rewardproperties are not considered as they are not relevant fornon-incentivised consensus protocols We use the notationlsquo rsquo to indicate an algorithm satisfies a particular propertyand the notation lsquo-rsquo to indicate that there is no informa-tion regarding that specific property For other propertiesexplanatory texts are added

STRUCTURAL PROPERTIES Tn Table 26 we present thecomparison of structural properties among the non-incentivised consensus algorithms discussed in this sectionAs evident from the table different algorithms use differenttypes of nodes and all algorithms are based on single com-mittee with closed committee type and explicit committeeformation Only YAC relies on a dynamic configurationwhich utilises the reputations of the nodes from previousinteractions all others have the static configuration

Voting is the predominantly used underlying mechan-ism which is utilised by Tendermint Burrow YAC andRBFT whereas PoET relies on a lottery mechanism Fabriccurrently utilises the ordering services by the orderer Inthe future it might utilise SBFT which leverages the votingmechanism

SECURITY PROPERTIES The comparison of security prop-erties among the non-incentivised consensus algorithmsis presented in Table 27 All algorithms support non-repudiation via digital signature and have a significantlylow censorship resistance This is because the identities ofall participating nodes are known In case any node startsmisbehaving because of an attacker taking control of that

node it can be easily identified and proper actions can betaken The same logic applies for the Sybil protection andtowards DoS resistance Being mostly based BFT algorithmsall algorithms except PoET have 3f + 1 adversarial tol-erance It has been found that PoET has an adversarialtolerance of Θ

(log log nlog n

)[220] where n is the number of

nodes

PERFORMANCE PROPERTIES The comparison of perform-ance properties among the non-incentivised consensus al-gorithms is presented in Table 28 All algorithms canprovide a good throughput and do not require to consumeany significant amount of energy PoET utilising a lotterymechanism can be scaled with a large number of valid-ators however this will increase the latency (finality) oftransactions [217] All other algorithms employing a votingmechanism cannot be scaled with a large number of val-idators providing low latency for the transactions FabricYAC and RBFT provide a 2f + 1 fault tolerance whereasthe information regarding the fault tolerance for PoET andTendermint Burrow is not specified formally

8 DISCUSSION

As per our analysis in different sections it is clear that PoWconsensus algorithms have major limitations specifically interms of power consumption and scalability Many regardPoS and it is variant DPoS to be the most suitable altern-atives To understand the applications of these algorithmsin public blockchain systems we have analysed the top 100crypto-currencies as reported on CoinMarketCap 4 as of 18July 2019

In the first analysis we have calculated the numberof consensus algorithms used in these (top 100) crypto-currencies The distribution of consensus algorithms ispresented in Figure 15 As per our analysis PoW is stillthe most widely used (57) consensus algorithms to datewhereas DPoS is the second most with 11 and PoS is thethird most with 6 used consensus algorithms All otherconsensus algorithms represent the remaining 26 Thismeans that even though many consider that PoS and DPoSare the best alternatives to PoW their adoption is still farbehind PoW

To investigate it further we have analysed a year-wise distribution of the genesis dates of different crypto-currencies It is to understand if there is any inclinationtowards an alternative consensus algorithm over PoW inrecent years The distribution is illustrated in Figure 16which represents a surprising observation PoW is still themost widely used algorithms for crypto-currencies whichhave been created in recent years For example the numbersof crypto-currencies created with PoW algorithms in lastthree years (2017 2018 amp 2019) are 11 19 and 4 respectivelyin comparison to 4 2 and 2 for PoS and DPoS combinedlyThis implies that PoW is still the most popular consensusalgorithm among the crypto-currency community A deeperinvestigation reveals another insight though The top 100 listretrieved from Coinmarketcap also contains crypto-tokensgenerated on top of any smart-contract platform such asEthereum EOS and Tron with majority tokens are built on

4 httpscoinmarketcapcom

30

Table 26 Comparing structural properties of Consensus Algorithms of Hyperledger Systems

Single committeeConsensusSystem Mechanism Node type Type Formation ConfigurationFabric OrderingVoting (SBFT) Client (Regular peer) En-

dorsing peer amp OrdererClose Explicit Static

PoET Lottery Client Transactionprocessor amp Validator

Close Explicit Static

Tendermint Burrow Voting As Tendermint (3) Close Explicit StaticYAC Voting Client Peer amp Ordering Ser-

vice nodeClose Explicit Dynamic

RBFT Voting Client amp Node Close Explicit Static

Table 27 Comparing security properties of Consensus Algorithms of Hyperledger Systems

Attack VectorsConsensus Non-repudiation Censorship resistance Adversary tolerance Sybil protection DoS Resistance

Fabric Low 3f + 1

PoET Low Θ(

log log nlog n

)Tendermint Burrow Low 3f + 1

YAC Low 3f + 1

RBFT Low 3f + 1

Table 28 Comparing performance properties of Consensus Algorithms of Hyperledger Systems

Consensus Fault tolerance Throughput Scalability Latency Energy

Fabric 2f + 1 Good Medium Low LowPoET - Good Good Medium Low

Tendermint Burrow - Good Medium Low LowYAC 2f + 1 Good Medium Low LowRBFT 2f + 1 Good Medium Low Low

top of Ethereum Most of these tokens have emerged after2016 with Ethereum utilising PoW This could be the reasonwhy the most recent crypto-currencies have been found toutilise PoW

Another indication of PoW domination over other al-gorithms is the market-cap distribution of their correspond-ing crypto-currencies The distribution is presented in Table29 and illustrated in Figure 17 Not surprisingly PoW cur-rencies with a market-cap of around 221 Billion USD havea massive 93 dominance over other currencies DPoS andPoS currencies are the nearest rivals with a market-cap ofaround 6 Billion USD and dominance of only 3 for eachgroup

Table 29 Market capitalisation of major consensus al-gorithms in top 100 Crypto-currencies

Consensus Algorithms Market-cap (USD)

PoW 221 238 526 412DPoS 6 483 606 020PoS 6 287 224 485

PoW+PoS 2 436 683 929Proof of Authority 572 188 935Proof of Activity 274 066 240

From our investigation it is clearly evident that PoWalgorithm even with its major limitations is still the mostpopular consensus algorithm to be utilised in differentcrypto-currencies Currencies which utilise PoW algorithmsconsume a significant amount of energy as illustrated inSection 514 Besides they have a reduced throughput (interms of transaction number) compared to PoS and DPoS

currencies For example the reported TPS (Transactions PerSecond) for Bitcoin and Ethereum are 7 and 15minus25 respect-ively [226] while DPoS currencies EOS has a reported andestimated TPS of 50 and 4000 respectively [226] and Tronhas a claimed TPS of 2000 [227] Clearly DPoS currencieshave better performance at least in terms of TPS overany PoW currency Therefore one might ask the underlyingreason behind this counter-intuitive trend of PoW being themost popular consensus algorithm We have identified a fewreasons behind this as presented belowbull Bitcoin is the most dominant crypto-currency in terms

of market-cap As of 18 July it has a market cap ofaround 171 Billion USD In addition to this its differentforked variants (Bitcoin Cash 5 and Bitcoin SatoshiVision 6) also have a combined market-cap of 8 BillionUSD If we exclude Bitcoin and its variants we havea slightly different distribution of market-cap as illus-trated in Figure 18 Here the market-cap percentage ofPoW algorithm is reduced from 93 to 71 percentwhich is still significant in comparison to DPoS andPoS its nearest rivals

bull PoW has the first-mover advantage because of Bit-coin and Ethereum both being the pioneer in theirrespective domain Bitcoin has been the first successfulcrypto-currency while Ethereum is the first blockchain-based smart-contract platform Other crypto-currenciesbeing motivated by their success might have adoptedthe approach of utilising PoW as their correspondingconsensus algorithm

5 httpswwwbitcoincashorg6 httpsbitcoinsvio

31

PoW

58

DPoS

9

PoS

8

PoW+PoS

4

Proof of Activity (PoA)

1

Delegated Byzentine Fault

Tollerance (dBFT)

3

Practical Byzentine Fault Tollerance

(PBFT)

2

Loop Fault Tolerance (LFT)

1XRP Ledger

Protocol

1Stellar

Consens

us

Protocol

(SCP)

1

Tangle

1

VBFT

(verifiabl

e random

function)

1

Proof of authority

2

Proof-of-Service (PoS)

1

Other

1

POI

1

Proof of retrivility

1

BFT

3

Proof-of-Believability (PoB)

1

Other

10

PoW DPoS PoS

PoW+PoS Proof of Activity (PoA) Delegated Byzentine Fault Tollerance (dBFT)

Practical Byzentine Fault Tollerance (PBFT) Loop Fault Tolerance (LFT) XRP Ledger Protocol

Stellar Consensus Protocol (SCP) Tangle VBFT (verifiable random function)

Proof of authority Proof-of-Service (PoS) Other

POI Proof of retrivility BFT


Figure 15 Consensus algorithms in Top 100 Crypto-currencies

bull Another strong argument in favour of PoW is its un-derlying security The number of miners is far greaterin Bitcoin than the number of validators in PoS andDPoS This implies a better decentralisation in Bitcointhan PoS or DPoS For example EOS has only 21 valid-ators while Tron has 27 validators The probability ofcollusion among these validators is far greater than thatof any popular PoW currency For this reason many inthe blockchain community have been doubtful of thesecurity of any PoSDPoS currency However there isa counter argument against this Because of the miningcentralisation issue ( highlighted in Section 514) manypoint out that a PoW algorithm might also be proneto centralisation Therefore a PoW currency might alsosuffer from collusion attack

With the dominance of PoW over other consensus al-gorithms one might wonder what lies ahead and might askif there will be any shift of balance among the consensusalgorithms We believe that we will most definitely experi-ment with a shifting of balance in the near future In thisregard the PoS transformation process of Ethereum willbe a crucial factor The proposed Ethereum PoS consensusmechanisms both CFFG and CTFG are highly regardedby the academics and industrial enthusiasts for their strongguarantee of security With their strong focus on economicincentive and game-theoretic based approach it is believedthat their security will be as close as PoW and much betterthan any current PoSDPoS algorithm can provide In par-ticular the number of validators will be much higher thanany number leveraged in the current PoSDPoS algorithms

However it is yet to be seen how they will perform oncedeployed in real-life settings

The existence of numerous algorithms and wide vari-ations in their properties impose a major challenge to com-prehend them properly In particular it is often difficult totest the suitability of a particular algorithm under certaincriteria A visual tool would be a great help in this regardTowards this aim we present a decision tree in Figure 19which can be used to determine the suitable consensusalgorithms under certain criteria in different scenarios Forexample such a decision tree diagram can be leveragedto select a particular consensus algorithm while design-ingdeveloping a new blockchain system

The tree utilises five critical criteria to achieve its goalincentives energy consumption scalability security (withrespect to adversary tolerance) and ASIC-resistance If thesystem needs to incentivise the minervalidating nodesthen proof-of-work(PoW) and proof-of-stake (PoS) con-sensus are appropriate choices Because of their underlyingincentives mechanisms the primary applications of theseconsensus algorithms are public crypto-currencies On theother hand a private blockchain network usually does notrely on any crypto-currencies to motivate or incentiviseany validators to run the blockchain network In additionto incentives energy consumption is another determiningfactor in choosing appropriate consensus algorithms PoW-type algorithms consume high energy whereas PoS al-gorithms and their derivatives consume a moderate amountof energy PoW-types algorithms are very slow as of nowand can process only a limited number of transactions

32

PoW

DPoS

dBFT

PoW + PoS02468

101214161820

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019

PoW PoS DPoS Proof of Activity dBFT Proof of Authority PoW + PoS

Figure 16 Year-wise distribution of consensus algorithms in Top 100 Crypto-currencies

93

310

0

0

3

3

PoWDPoSPoW+PoSProof of ActivitydBFTProof of AuthorityPoS

Figure 17 Percentage of market capitalisation of consensus algorithms in top 100 Crypto-currencies

However compromising a popular PoW-based blockchainnetwork is very difficult and therefore they are more securethan their counterparts PoW-based algorithms can also beclassified based on computational complexity As discussedearlier ASIC is a specialised hardware designed and usedto solve hash-based computational problems ASIC is ex-pensive and hinders common people from participatingin the blockchain network Therefore memory-based PoWhas been designed Now it is widely used in differentcrypto-currencies Non-incentivised consensus algorithmsare mostly used in private blockchain systems They con-sume a very low amount of energy compared to other typesof consensus algorithms and are also very scalable Thatmeans the miners can verify the transactions and createblocks really fast However a comparatively low number of

validating nodes makes these algorithms more vulnerableto attacks

For clarity we provide a few examples to utilise thedecision tree diagram presented in Figure 19 If an incentiv-ised algorithm is required for a highly scalable blockchainsystem that aims to consume low energy DPoS and BFTderivatives such as Tendermint CTFG and Ouroboros arethe preferred options However they will have moderatesecurity as described earlier On the other hand if securityis of the highest priority PoW algorithms are more suitableIn this scenario there are two options memory-bound orCPU bound If ASIC resistance is desired one should optfor memory-bound PoW algorithms However in such acase one has to sacrifice scalability and such algorithmswill consume high energy

33

71

11

4 0

21

1114


Figure 18 Percentage of market capitalisation excluding Bitcoin and its variants

Note that this is just an example of how such a diagramcan be developed using our selected four criteria Othercriteria can be utilised to generate a different diagram whichmight be suitable for other specific scenarios Wheneversuch a diagram is to be developed the tables (Table 13 Table14 Table 15 Table 17 Table 18 Table 19 Table 20 Table 21Table 22 Table 23 Table 24 Table 26 Table 27 and Table 28)utilised to compare different consensus algorithms againstthe defined properties in the taxonomy will be crucial asthe these tables will provide the required template by whichsuch a diagram can be created

9 CONCLUSION

With the popularisation of crypto-currencies and block-chain in general there has been a renewed interest in thepractical implications of different distributed consensus al-gorithms Most of the existing systems struggle to properlysatisfy the need for any wide-scale real-life deployment asthey have serious limitations Many of these limitations aredue to the underlying consensus algorithm used in a partic-ular system Therefore in the quest to create more suitablepractical blockchain systems the principal focus has beenon distributed consensus This has led to the explorationseither existing consensus algorithms have been exploitedor novel consensus mechanisms have been introduced Theultimate consequence of this phenomenon is a wide-rangeof consensus algorithms currently in existence To advancethe knowledge of this domain it is essential to synthesisethese consensus algorithms under a systematic study whichis the main motivation of this article

Even though there have been several similar works thisis the first paper to introduce a taxonomy of propertiesdesirable for a consensus algorithm and then utilise thattaxonomy to analyse each algorithm in a detailed fash-ion In addition different consensus algorithms have beengrouped into two major categories Incentivised and Non-incentivised consensus algorithms An incentivised con-sensus algorithm exclusively utilised by public blockchainsystems and crypto-currencies relies on incentives for theparticipants in order to motivate them to behave as inten-ded On the other hand in any non-incentivised algorithm

the participants are considered as trusted and hence it isassumed that no incentives are required to ensure intendedbehaviour As such these algorithms are mostly used in theprivate blockchain sphere We have again grouped incentiv-ised algorithms into three major sub-categories PoW (Proofof Work) Proof of Stake (PoS) and consensus algorithmsbeyond PoW and PoS

A PoW algorithm relies on computational complexit-ies or memory sizeperformance to solve a cryptographicpuzzle There are three major approaches followed by PoWconsensus algorithms i) a compute-bound PoW leveragingthe capabilities of the processing unit ii) a memory-boundPoW which is more reliant on the size and performance ofthe main memory and iii) a chained PoW utilises a num-ber of hashing algorithms executed consecutively one afteranother Blockchain systems utilising such a mechanism hasspecial nodes called miner nodes who are responsible forsolving this puzzle and creating a new and valid blockand extending the chain by appending this block in theexisting chain The probability to solve this puzzle dependson a network parameter called difficulty which is adjustedautomatically after a certain period of time As more minersparticipate in the network the network parameters areadjusted in such a manner that requires more computa-tional power to mine a new block As the correspondingsystems become more popular it attracts more minerswhich increases the security of the system However theincreased computational power results in more energy beingconsumed Apart from this PoW systems generally have alow throughput and do not scale properly PoS algorithmsand their corresponding mechanisms have been analysed ingreater detail in Section 51

To alleviate the major issues of PoW Proof of Stake (PoS)has been proposed In PoS the nodes who would like toparticipate in the block creating process are called mintersand they need to own and lock a certain amount of thecorresponding crypto-currency called stake Such a stake isused to ensure that the minters will act as required sincethey will lose their stakes when acting maliciously PoS hasseveral variants Chained PoS BFT PoS and DPoS The coreidea of a chained PoS is to leverage a combination of PoWand PoS algorithms chained together to achieve consensus

34

Consensusalgorithm

Yes

High

Low

No

Low

Low

HighMedium

Medium

High

Yes No

Medium

Incentivised

Energy

Scalable

Security

AISC Resistant

RBFTSBFTYACPoET

Burrow

Chained

PoW

Memory Bound PoW (eg Cryptonight Scrypt and NeoScrypt consensus)

Chained PoW (eg X11X13X15 Quark and Lyra2RE consensus)

CPU-Bound PoW (eg Nakamoto consensus)

DPoSTendermint

CTFG Ouroboros

Low

PoRPoSVPoCPoI

Medium

Medium

Low

Medium

Figure 19 Decision tree to choose appropriate consensus algorithms

BFT PoS uses a multi-round PoS mechanism in which avalidator (minter) is selected from a set of validators bythe agreement of super-majority quorum among other val-idators On the other hand DPoS selects a minter from aset of minters using votes from other clients of the networkPoS algorithms are generally fast and scalable having highthroughput However they also need to consider severalother attack vectors such as Nothing-at-stake bribing long-range attack cartel formation and so on Detailed analysisof different aspects of PoS algorithms has been presented inSection 52

There are also some Hybrid consensus algorithms thatcombine the mechanisms of PoW andpr PoS with anothernovel algorithm Proof of Research Proof of Burn Proof ofStake-Velocity are examples of such an algorithm Againthere are mechanisms that are novel and have no relianceon PoWPoS whatsoever Proof of Cooperation and Proofof Importance are examples of such novel algorithms Thediscussion and analysis of these consensus algorithms havebeen presented in Section 6

Finally there are also a few non-incentivised consensus

algorithms which are exclusively utilised in private block-chain systems Hyperledger is the leading private block-chain foundation under which different private blockchainsystems such as Hyperledger Fabric Hyperledger SawtoothHyperledger Burrow Hyperledger Iroha Hyperledger Indyand so on These systems rely on different other consensusmechanisms such as SBFT PoET Tendermint Burrow YACand RBFT Key characteristics of these consensus algorithmsare high throughput and low latency with acceptable scalab-ility Also the algorithms require that every entity thatparticipates in the network must be properly authenticatedA detailed analysis of these algorithms has been presentedin Section 7

Our analysis in Section 8 suggests that PoW with itsmany disadvantages still is the most dominant in terms ofmarket capitalisation (indicating its adoption) and crypto-currency in the world As discussed earlier DPoS and PoSalgorithms PoWrsquos closest rivals aim to tackle many ofPoWrsquos limitations However their adoption is still limitedIn addition to this analysis we have presented an exemplary

35

decision tree-based figure which can be utilised to filter outor select consensus algorithms that fit certain criteria Sucha figure will be a useful tool for any who would like to testthe suitability of a certain consensus algorithm under certaincriteria

There is one issue that must be highlighted before weconclude this article The principal focus of this article hasbeen to explore and synthesise the consensus algorithmsavailable in different blockchain systems However thereare other distributed ledger systems which do not rely onany blockchain-type structure Instead they utilise otherstructures to represent their respective ledgers Examplesof two such prominent crypto-currencies are IoTA 7 andNANO 8 Both of their ledgers are based on DAG (DirectedAcyclic Graph) a specific type of directed graph with nocycle However IoTA uses a novel consensus algorithmcalled Tangle [229] while NANO utilises a representativebased consensus mechanism [228] These two systems havereceived significant attention because of their fee-less struc-ture and fast transaction rates However we do not considerthese systems any further as they are out of scope for thisarticle We plan to investigate such novel systems in thefuture in a different exploration

There is high anticipation among the blockchain enthu-siasts that blockchain technology will disrupt many existingapplication domains However to unlock its true potential ablockchain system must adopt a suitable consensus that canenable it to satisfy its intended properties This is becausea consensus algorithm is the core component of any block-chain system and it dictates how a system behaves and theperformance it can achieve However as our analysis in thisarticle suggests an ideal consensus algorithm is still elusiveas almost all algorithms have significant disadvantages inone way or another with respect to their security andperformance Until a consensus algorithm finds the correctbalance between these crucial factors we might not see thewide-scale adoption as many crypto-currency enthusiastsare hoping

REFERENCES

[1] Nakamoto Satoshi ldquoBitcoin A peer-to-peer electronic cash systemrdquo2008 [online] Available httpsbitcoinorgbitcoinpdf

[2] Pilkington Marc ldquo11 Blockchain technology principles and applic-ationsrdquo Research handbook on digital transformations 225 2016

[3] Crosby Michael and Pattanayak Pradan and Verma Sanjeev andKalyanaraman Vignesh and others ldquoBlockchain technology Bey-ond bitcoinrdquo Applied Innovation 2(6-10) p 71 2016

[4] Cachin C and Vukoli M ldquoBlockchains Consensus Protocols in theWildrdquo arXiv preprint arXiv170701873 2017

[5] Bano S Sonnino A Al-Bassam M Azouvi S McCorry PMeiklejohn S and Danezis G ldquoConsensus in the Age of Block-chainsrdquo arXiv preprint arXiv171103936 2017

[6] Wang W Hoang DT Hu P Xiong Z Niyato D Wang P WenY and Kim DI ldquoA survey on consensus mechanisms and miningstrategy management in blockchain networksrdquo IEEE Access 7pp22328-22370 2019

[7] Baliga A ldquoUnderstanding Blockchain ConsensusModelsrdquo April 2017 [Online] Available httpswwwpersistentcomwp-contentuploads201704WP-Understanding-Blockchain-Consensus-Modelspdf

7 httpswwwiotaorg8 httpsnanoorgen

[8] Sankar Lakshmi Siva and Sindhu M and Sethumadhavan MldquoSurvey of consensus protocols on blockchain applicationsrdquo 4thInternational Conference on Advanced Computing and Commu-nication Systems (ICACCS) IEEE 1ndash5 2017

[9] Seibold Sigrid and Samman George ldquoConsensusImmutable agreement for the Internet of valuerdquohttpsassetskpmgcomcontentdamkpmgpdf201606kpmgblockchain-consensus-mechanismpdf KPMG 2016

[10] Mukhopadhyay Ujan and Skjellum Anthony and HamboluOluwakemi and Oakley Jon and Yu Lu and Brooks Richard ldquoAbrief survey of cryptocurrency systemsrdquo In Proceedings of the 14thannual conference on privacy security and trust (PST) IEEE 745ndash752 2016

[11] Schneider F B ldquoImplementing fault-tolerant services using thestate machine approach A tutorialrdquo ACM Computing Surveys(CSUR) 22(4) 299-319 1990

[12] C Cachin R Guerraoui and L Rodrigues ldquoIntroduction toReliable and Secure Distributed Programmingrdquo (Second Edition)Springer 2011

[13] V Hadzilacos and S Toueg ldquoFault-tolerant broadcasts and relatedproblemsrdquo In S J Mullender editor Distributed Systems (2ndEd) New York 1993

[14] Lamport L Shostak R and Pease M ldquoThe Byzantine generalsproblemrdquo ACM Transactions on Programming Languages andSystems (TOPLAS) 4(3) 382-401 1982

[15] Lamport L ldquoThe part-time parliamentrdquo ACM Transactions onComputer Systems 16(2)133169 May 1998

[16] Lamport L ldquoPaxos made simplerdquo SIGACT News 32(4)51582001

[17] B M Oki and B Liskov ldquoViewstamped replication A newprimary copy method to support highly- available distributed sys-temsrdquo In Proc 7th ACM Symposium on Principles of DistributedComputing (PODC) pages 817 1988

[18] P Hunt M Konar F P Junqueira and B Reed ldquoZooKeeper Wait-free coordination for internet- scale systemsrdquo In Proc USENIXAnnual Technical Conference 2010

[19] D Ongaro and J K Ousterhout ldquoIn search of an understandableconsensus algorithmrdquo In Proc USENIX Annual Technical Confer-ence pages 305319 2014

[20] M Castro and B Liskov ldquoPractical Byzantine fault tolerance andproactive recoveryrdquo ACM Transactions on Computer Systems20(4)398461 Nov 2002

[21] Bessani A Sousa J and Alchieri E E ldquoState machine replicationfor the masses with BFT-SMaRtrdquo In 44th Annual IEEEIFIPInternational Conference on Dependable Systems and Networks(DSN) pp 355-362 June 2014

[22] C Dwork N Lynch and L Stockmeyer ldquoConsensus in thepresence of partial synchronyrdquo Journal of the ACM (JACM)35(2)288323 1988

[23] M J Fischer N A Lynch and M S Paterson ldquoImpossibility ofdistributed consensus with one faulty processrdquo Journal of the ACM(JACM) 32(2)374382 1985

[24] Brewer E A ldquoTowards robust distributed systemsrdquo In PODC(Vol 7) July 2000

[25] M J M Chowdhury and M S Ferdous and K Biswas and NChowdhury and A S M Kayes and M Alazab and P WattersldquoA Comparative Analysis of Distributed Ledger Technology Plat-formsrdquo IEEE Access 7167930-167943 2019

[26] Iot Joi ldquoThe Fintech Bubblerdquo 2018 [Online] Available httpsjoiitocomweblog20160614-the-fintech-buhtml June 142016 Accessed on May 12 2019

[27] Xiao David ldquoThe Four Layers of the Blockchainrdquo2018 [Online] Available httpsmediumcomcoriaceticthe-four-layers-of-the-blockchain-dc1376efa10f June 22 2016 Ac-cessed on April 12 2019

[28] Namecoin 2018 [Online] Available httpsnamecoinorgAccessed on May 20 2019

[29] Proof of Existence 2018 [Online] Available httpsproofofexistencecom Accessed on May 20 2019

[30] Fromknecht C Velicanu D and Yakoubov S CertCoin ANameCoin Based Decentralized Authentication System May14 2014 6857 Unpublished class project 2018 [On-line] Available httpcoursescsailmitedu68572014files19-fromknecht-velicann-yakoubov-certcoinpdf Accessed on May20 2019

[31] Ferdous Md Sadek and Biswas Kamanashis and ChowdhuryMohammad Jabed Morshed and Chowdhury Niaz and Muthukku-

36

marasamy Vallipuram rdquoIntegrated platforms for blockchain enable-mentrdquo Advances in Computers Elsevier 2019

[32] Seigen Max Jameson Tuomo Nieminen Neocortex and AntonioM Juarez ldquoCryptoNight Hash Functionrdquo March 2013 [Online]Available httpscryptonoteorgcnscns008txt

[33] Dwork Cynthia and Naor Moni ldquoPricing via processing or com-batting junk mailrdquo Annual International Cryptology Conference139ndash147 1992

[34] Douceur J R ldquoThe sybil attackrdquo In International workshop onpeer-to-peer systems (pp 251-260) 2002

[35] Bentov Iddo and Lee Charles and Mizrahi Alex and RosenfeldMeni ldquoProof of Activity Extending Bitcoinrsquos Proof of Work viaProof of Stake [Extended Abstract]rdquo SIGMETRICS Perform EvalRev Volume 43 issue 3

[36] Andrew Miller Yu Xia Kyle Croman Elaine Shi and Dawn SongldquoThe Honey Badger of BFT Protocolsrdquo In Proceedings of the2016 ACM SIGSAC Conference on Computer and CommunicationsSecurity (CCS rsquo16) ACM New York NY USA 31-42 DOI ht-tpsdoiorg10114529767492978399

[37] Athanasios N Nikolakopoulos and John D GarofalakisldquoNCDawareRank a novel ranking method that exploits the decom-posable structure of the webrdquo In Proceedings of the sixth ACMinternational conference on Web search and data mining (WSDMrsquo13) ACM New York NY USA 143-152

[38] Stefan Dziembowski Sebastian Faust Vladimir Kolmogorov andKrzysztof Pietrzak ldquoProofs of Spacerdquo Cryptology ePrint ArchiveReport 2013796 [Online] Available httpseprintiacrorg2013796

[39] Ren Ling and Devadas Srinivas ldquoProof of Space from Stacked Ex-pandersrdquo Proceedings Part I of the 14th International Conferenceon Theory of Cryptography - Volume 9985 2016

[40] Sunoo Park Krzysztof Pietrzak Albert Kwon Joe l Alwen andGeorg Fuchsbauer and Peter Gazi ldquoSpaceMint A CryptocurrencyBased on Proofs of Spacerdquo Cryptology ePrint Archive Report2015528 [Online] Available httpseprintiacrorg2015528

[41] Hamza Abusalah and Joel Alwen and Bram Cohen and DanyloKhilko and Krzysztof Pietrzak and Leonid Reyzin ldquoBeyond Hell-manrsquos Time-Memory Trade-Offs with Applications to Proofs ofSpacerdquo Cryptology ePrint Archive Report 2017893 [Online]Available httpseprintiacrorg2017893

[42] Weichbrodt Nico and Kurmus Anil and Pietzuch Peter andKapitza Rudiger ldquoComputer Security ESORICS 2016rdquo Pages 440ndash457 Springer International Publishing

[43] Brasser F Muller U Dmitrienko A Kostiainen K Capkun SSadeghi A-R ldquoSoftware Grand Exposure SGX Cache AttacksAre Practicalrdquo In proceedings of the 11th USENIX Workshop onOffensive Technologies (WOOT 17) USENIX Association

[44] Keir Finlow-Bates ldquoA Lightweight Blockchain Consensus Pro-tocolrdquo August 2017 [Online] Available httpwwwchainfrogcomwp-contentuploads201708consensuspdf

[45] Back Adam Hashcash-a denial of service counter-measure 2002[46] Bertoni Guido and Daemen Joan and Peeters Michael and Van

Assche Gilles ldquoKeccakrdquo In Annual International Conference on theTheory and Applications of Cryptographic Techniques pp 313ndash3142013

[47] Percival C and Josefsson S ldquoThe scrypt Password-Based KeyDerivation Functionrdquo [Online] Available httpstoolsietforghtmlrfc7914 August 2016

[48] ldquoWikipedia entry on Custon Hardware Attackrdquo [Online] Avail-able httpsenwikipediaorgwikiCustom hardware attackAccessed on 21 May 2019

[49] Bernstein Daniel J ldquoThe Salsa20 family of stream ciphersrdquo Newstream cipher designs pp 84ndash97 Springer 2008

[50] ldquoSThe Scrypt Mining Algorithm Everything You Need to Knowrdquo[Online] Available httpswwweasypciocrypto-miningscrypt-hardware Accessed on 21 May 2019

[51] Buntinx JP ldquoScrypt vs X11 vs SHA-256rdquo [Online] Avail-able httpsthemerklecomscrypt-vs-x11-vs-sha-256 March23 2017

[52] Bernstein Daniel J ChaCha a variant of Salsa20 ldquoNew streamcipher designsrdquo Vol 8 pp 3ndash5 2008

[53] ldquoAnnouncement of Aiden - Scrypt-OG crypto-currencyrdquo [On-line] Available httpsbitcointalkorgindexphptopic=5584140Accessed on July 24 2019

[54] ldquoCryptocurrency Mining Hash Algorithmsrdquo httpwwwbitcoinlioncomcryptocurrency-mining-hash-algorithms [On-line] Available July 24 2019 Accessed on July 24 2019

[55] Biryukov Alex and Khovratovich Dmitry ldquoEquihash Asym-metric proof-of-work based on the generalized birthday problemrdquoLedger(2) 2017

[56] Wagner David ldquoA generalized birthday problemrdquo Cryptor(2442)pages 288ndash303 2002

[57] ldquoCrypto-currencies utilising Equihashrdquo [Online] Available httpswwwcoingeckocomenhashing algorithm=Equihash Ac-cessed on July 24 2019

[58] ldquoEthashrdquo [Online] Available httpsgithubcomethereumwikiwikiEthash Accessed on July 24 2019

[59] ldquoDagger-Hashimotordquo [Online] Available httpsgithubcomethereumwikiblobmasterDagger-Hashimotomd Accessed onJuly 24 2019

[60] Buterin Vitalik ldquoDagger A Memory-Hard to Compute Memory-Easy to Verify Scrypt Alternativerdquo httpwwwhashcashorgpapersdaggerhtml Accessed on July 24 2019

[61] Lerner Sergio ldquoEthereum Dagger PoW function is flawedrdquo[Online] Available httpsbitslogwordpresscom20140117ethereum-dagger-pow-is-flawed 17 January 2017 Accessed onJuly 24 2019

[62] ldquoCrypto-currencies utilising Ethashrdquo [Online] Available httpswwwcoingeckocomenhashing algorithm=Ethash Accessed onJuly 24 2019

[63] ldquoCrypto-currencies utilising Daggerrdquo [Online] Available httpswwwcoingeckocomenhashing algorithm=Dagger Accessedon July 24 2019

[64] Gligoroski Danilo and Klima Vlastimil and Knapskog SveinJohan and El-Hadedy Mohamed and Amundsen Joslashrn ldquoCryp-tographic hash function blue midnight wishrdquo In Proceedings ofthe 1st International Workshop on Security and CommunicationNetworks pp 1ndash8 2009

[65] Gauravaram Praveen and Knudsen Lars R and MatusiewiczKrystian and Mendel Florian and Rechberger Christian andSchlaffer Martin and Thomsen Soslashren S ldquoGroslashstl-a SHA-3 candid-aterdquo Dagstuhl Seminar Proceedings 2009

[66] Wu Hongjun ldquoThe hash function JHrdquo Submission to NIST (round3) Vol 6 2011

[67] ldquoQuark Coinrdquo [Online] Available httpwwwquarkcoinscomAccessed on July 24 2019

[68] ldquoFirst Impressions from the Baikal Mini Miner ASICrdquo[Online] Available httpscryptomining-blogcomtagquark-asic-miner July 24 2019 Accessed on July 24 2019

[69] ldquoBitcoinrdquo [Online] Available httpwwwbitcoinorg Accessedon April 24 2019

[70] ldquoBitcoin Cashrdquo [Online] Available httpswwwbitcoincashorg Accessed on July 24 2019

[71] ldquoSyscoinrdquo [Online] Available httpsyscoinorg Accessed onJuly 24 2019

[72] ldquoPeer Coinrdquo [Online] Available httpspeercoinnet Accessedon July 24 2019

[73] ldquoCounterpartyrdquo [Online] Available httpscounterpartyioAccessed on July 24 2019

[74] Aumasson Jean-Philippe and Neves Samuel and Wilcox-OHearnZooko and Winnerlein Christian ldquoBLAKE2 simpler smaller fastas MD5rdquo International Conference on Applied Cryptography andNetwork Security pp 119ndash135 2013

[75] ldquoEmercoin [Online] Available httpsemercoincom Accessedon July 24 2019

[76] ldquoNamecoinrdquo [Online] Available httpsnamecoinorgAccessed on July 24 2019

[77] ldquoSteem Dollarsrdquo [Online] Available httpssteemio Accessedon July 24 2019

[78] ldquoCrownrdquo [Online] Available httpscrowntech Accessed onJuly 24 2019

[79] ldquoOmmi (Mastercoin)rdquo [Online] Available httpwwwomnilayerorg Accessed on July 24 2019

[80] ldquoLitecoinrdquo [Online] Available httpwwwomnilayerorgAccessed on July 24 2019

[81] ldquoBitconnectrdquo [Online] Available httpsbitconnectco Ac-cessed on May 24 2019

[82] ldquoVergerdquo [Online] Available httpsvergecurrencycom Accessedon July 20 2019

[83] ldquoBitmarkrdquo [Online] Available httpsbitmarkcom Accessedon July 20 2019

[84] ldquoDogecoinrdquo [Online] Available httpdogecoincom Accessedon July 20 2019

37

[85] ldquoGamecredit)rdquo [Online] Available httpsgamecreditscomAccessed on July 20 2019

[86] ldquoEinsteinniumrdquo [Online] Available httpswwwemc2foundation Accessed on July 20 2019

[87] ldquoVoxelsrdquo [Online] Available httpthevoxelcom Accessed onJuly 20 2019

[88] ldquoViacoinrdquo [Online] Available httpsviacoinorg Accessed onJuly 10 2019

[89] ldquoHempcoinrdquo [Online] Available httphempcoinorg Ac-cessed on July 10 2019

[90] ldquoZcashrdquo [Online] Available httpszcash Accessed on July10 2019

[91] ldquoBitcoin Goldrdquo [Online] Available httpsbitcoingoldorgAccessed on July 10 2019

[92] ldquoKomodordquo [Online] Available httpskomodoplatformcomen Accessed on July 10 2019

[93] ldquoZclassicrdquo [Online] Available httpzclassicorg Accessed onJuly 10 2019

[94] ldquoZenCashrdquo [Online] Available httpszensystemio Accessedon July 10 2019

[95] ldquoHushrdquo [Online] Available httpsmyhushorg Accessed onJuly 10 2019

[96] ldquobitcoinzrdquo [Online] Available httpsbtczrocksen Accessedon July 10 2019

[97] ldquoVote Coinrdquo [Online] Available httpsvotecoinsite Accessedon July 10 2019

[98] ldquoEthereumrdquo [Online] Available httpswwwethereumorgAccessed on July 10 2019

[99] ldquoEthereum Classicrdquo [Online] Available httpsethereumclassicgithubio Accessed on July 10 2019

[100] ldquoUbiqrdquo [Online] Available httpsubiqsmartcom Accessedon July 10 2019

[101] ldquoShifrdquo [Online] Available httpwwwshiftnrgorg Accessedon July 10 2019

[102] ldquoExpanserdquo httpswwwexpansetech Accessed on July 102019

[103] ldquoDubaiCoinrdquo [Online] Available httpwwwarabianchainorg Accessed on July 10 2019

[104] ldquoSOILcoinrdquo [Online] Available httpsgithubcomSoilcoinAccessed on July 10 2019

[105] ldquoKryptonrdquo [Online] Available httpkryptonrocks Accessedon July 10 2019

[106] ldquoRed Pulserdquo [Online] Available httpswwwred-pulsecomlanding Accessed on July 10 2019

[107] ldquoFeathercoinrdquo [Online] Available httpswwwfeathercoincom Accessed on July 10 2019

[108] ldquoGoByterdquo [Online] Available httpsgobytenetworkAccessed on July 10 2019

[109] ldquoUFO Coinrdquo [Online] Available httpsufocoinnet Accessedon July 10 2019

[110] ldquoInnovardquo [Online] Available httpsinnovacoininfoAccessed on July 10 2019

[111] ldquorowdCoinrdquo [Online] Available httpcrowdcoinsiteAccessed on July 10 2019

[112] ldquoVivordquo [Online] Available httpswwwvivocryptocomAccessed on July 10 2019

[113] ldquoDesirerdquo [Online] Available httpswwwdesire-cryptocomAccessed on July 10 2019

[114] ldquoOrbitcoinrdquo [Online] Available httpswwworbitcoinorgAccessed on July 10 2019

[115] ldquoPhoenixcoinrdquo [Online] Available httpphoenixcoinorgAccessed on July 10 2019

[116] ldquoBitcorerdquo [Online] Available httpsbitcorecc Accessed onJuly 10 2019

[117] ldquoDashrdquo [Online] Available httpswwwdashorg Accessedon July 10 2019

[118] ldquoStratis [Online] Available httpsstratisplatformcomAccessed on July 10 2019

[119] ldquoCloakcoinrdquo [Online] Available httpswwwcloakcoincomAccessed on July 10 2019

[120] ldquoStealthcoinrdquo [Online] Available httpswwwstealthcoincom Accessed on July 10 2019

[121] ldquoDeepOnionrdquo [Online] Available httpsdeeponionorgAccessed on July 10 2019

[122] ldquoHTMLcoinrdquo [Online] Available httpshtmlcoincomAccessed on July 10 2019

[123] ldquoRegal Coinrdquo [Online] Available httpsregalcoincoAccessed on July 10 2019

[124] ldquoMemeticrdquo [Online] Available httpsmemeticai Accessedon July 10 2019

[125] ldquoExclusive Coinrdquo [Online] Available httpsexclusivecoinpw Accessed on July 10 2019

[126] ldquoCreditbitrdquo [Online] Available httpswwwcreditbitorgAccessed on July 10 2019

[127] ldquoQuarkrdquo [Online] Available httpwwwqrknetinfo Ac-cessed on July 10 2019

[128] ldquoPIVXrdquo [Online] Available httpspivxorg Accessed on July10 2019

[129] ldquoMonetaryUnitrdquo [Online] Available httpswwwmonetaryunitorg Accessed on July 10 2019

[130] ldquoALQOrdquo [Online] Available httpsalqoorg Accessed onJuly 10 2019

[131] ldquoBitcloudrdquo [Online] Available httpsbit-cloudinfo Ac-cessed on July 10 2019

[132] ldquoZurcoinrdquo [Online] Available httpzurcoinorg Accessedon July 10 2019

[133] ldquoAmsterdamCoinrdquo [Online] Available httpsamsterdamcoincom Accessed on July 10 2019

[134] ldquoAnimecoinrdquo [Online] Available httpsgithubcomtestzcryptoAnimecoinreleasestag0832 Accessed on July 102019

[135] ldquoVertcoinrdquo [Online] Available httpsvertcoinorg Accessedon July 10 2019

[136] ldquoMonacoinrdquo [Online] Available httpsmonacoinorgAccessed on July 10 2019

[137] ldquoCryptordquo [Online] Available httptailflickwixsitecomofficial-crypto Accessed on July 10 2019

[138] ldquoQuark Coin Wikirdquo [Online] Available httpcoinwikiinfoenQuark Accessed on July 10 2019

[139] ldquoCrypto-currencies utilising Quarkrdquo [Online] Available httpswwwcoingeckocomenhashing algorithm=Quark Accessedon July 10 2019

[140] ldquoLyra2RE-A new PoW algorithm for an ASIC-free futurerdquo[Online] Available httpsvertcoinorgwp-contentuploads201710Vertcoin Lyra2RE Paper 11292014pdf Accessed on July10 2019

[141] ldquoWikipedia entry on Vertcoinrdquo [Online] Available httpsenwikipediaorgwikiVertcoin Accessed on July 10 2019

[142] ldquoCrypto-currencies utilising Lyra2RErdquo [Online] Available httpswwwcoingeckocomenhashing algorithm=Lyra2RE Accessedon July 10 2019

[143] ldquoWiki entry on M7rdquo [Online] Available httpcryptoniteinfowikiindexphptitle=M7 PoW Accessed on July 10 2019

[144] ldquoCudaMiner - a multi-threaded GPU miner for Cryptoniterdquo[Online] Available httpsgithubcomMiniblockchainProjectCudaMiner Accessed on July 10 2019

[145] ldquoBitcore announcement on Bitcointalkrdquo [Online] Availablehttpsbitcointalkorgindexphptopic=18839020 Accessed onJuly 10 2019

[146] Doering John ldquoNeoScrypt a Strong Memory Intensive Key De-rivation Functionrdquo httpphoenixcoinorgarchiveneoscryptv1pdf [Online] Available July 26 2014 Accessed on July 10 2019

[147] ldquoCrypto-currencies utilising NeoScryptrdquo [Online] Avail-able httpswwwcoingeckocomenhashing algorithm=NeoScrypt Accessed on July 10 2019

[148] ldquoBitcoin energy consumptionrdquo [Online] Available httpsdigiconomistnetbitcoin-energy-consumption Accessed on July10 2019

[149] ldquoEthereum energy consumptionrdquo [Online] Available httpsdigiconomistnetethereum-energy-consumption Accessed on July10 2019

[150] ldquoWikipedia entry on Economies of scalerdquo [Online] AvailablehttpsenwikipediaorgwikiEconomies of scale Accessed onJuly 10 2019

[151] ldquoWikipedia entry on Tragedy of the commonsrdquo [Online] Avail-able httpsenwikipediaorgwikiTragedy of the commonsAccessed on July 10 2019

[152] ldquoBitcoin hashrate distributionrdquo [Online] Available httpsblockchaininfopools Accessed on July 10 2019

[153] Eyal I and Sirer EG ldquoMajority is not enough Bitcoin mining isvulnerablerdquo International Conference on Financial Cryptographyand Data Security pages 436ndash454 March 2014

38

[154] QuantumMechanic ldquoProof of stake instead of proof of workrdquo[Online] Available httpsbitcointalkorgindexphptopic=277870 July 11 2011 Accessed on May 11 2019

[155] ldquoProof of Stake FAQrdquo [Online] Available httpsgithubcomethereumwikiwikiProof-of-Stake-FAQ Accessed on August 52019

[156] Choi Jon ldquoEthereum Casper 101rdquo [Online] Available httpsmediumcomjonchoiethereum-casper-101-7a851a4f1eb0 Oc-tober 22 2017 Accessed on July 10 2019

[157] ldquoProof of Stake versus Proof of Workrdquo [Online]Available httpbitfurycomcontent5-white-papers-researchpos-vs-pow-102pdf September 13 2015 Accessed on August 52019

[158] ldquoConsensus Compare Casper vs Tendermintrdquo[Online] Available httpsblogcosmosnetworkconsensus-compare-casper-vs-tendermint-6df154ad56aeNovember 16 2017 Accessed on July 10 2019

[159] Zamfir Vlad ldquoThe History of Casper - Chapter 4rdquo[Online] Available httpsmediumcomVlad Zamfirthe-history-of-casper-chapter-4-3855638b5f0e December 12 2016Accessed on July 10 2019

[160] ldquoGridcoinrdquo [Online] Available httpsgithubcomgridcoin-communityGridcoin-Wikiwiki Accessed on June 222019

[161] ldquoGridcoin Whitepaper [Online] Available httpsgridcoinusassetsimgwhitepaperpdf Accessed on 24 June 2019

[162] ldquoWikipedia entry on Berkeley Open Infrastructurefor Network Computing (BOINC)rdquo [Online] AvailablehttpsenwikipediaorgwikiBerkeley Open Infrastructurefor Network Computing Accessed on 21 June 2019

[163] ldquoProof of Burnrdquo [Online] Available httpsenbitcoinitwikiProof of burn Accessed on 21 June 2019

[164] ldquoSlimcoinrdquo [Online] Available httpslimcoin Accessed on24 June 2019

[165] ldquoSlimcoin Whitepaperrdquo [Online] Availablehttpswwwdocicacuksimidsrealdotdotcrypto papers etcworth readingproof of burnslimcoin whitepaperpdf Accessedon 24 June 2019

[166] ldquoReddcoinrdquo [Online] Available httpswwwreddcoincomAccessed on 24 June 2019

[167] ldquoReddcoin Whitepaper [Online] Available httpswwwreddcoincompapersPoSVpdf Accessed on 24 June 2019

[168] ldquoReddcoin Wikirdquo [Online] Available httpswikireddcoincomProof of Stake Velocity (PoSV) Accessed on 24 June 2019

[169] ldquoThe Velocity of Money for Beginnersrdquo [On-line] Available httpswwwjoshuakennoncomthe-velocity-of-money-for-beginners Accessed on 25 June2019

[170] ldquoFaircoin Crypto-currencyrdquo [Online] Available httpsfair-coinorg Accessed on 24 June 2019

[171] ldquoFaircoin Whitepaper Version 12rdquo [Online] Available httpsfair-coinorgsitesdefaultfilesFairCoin2 whitepaper V12pdfJuly 2018 Accessed on 24 June 2019

[172] ldquoNEM Technical Reference Version 121rdquo [Online] Avail-able httpsnemiowp-contentthemesnemfilesNEMtechRefpdf February 23 2018 Accessed on 24 June 2019

[173] ldquoFaircoin FAQrdquo [Online] Available httpsfair-coinorgenfaircoin-faqs Accessed on 24 June 2019

[174] King Sunny and Nadal Scott ldquoPPCoin Peer-to-Peer Crypto-Currency with Proof-of-Stakerdquo [Online] Available httpspeercoinnetassetspaperpeercoin-paperpdf August 19 2012Accessed on May 5 2019

[175] ldquoPeercoin discussion forum discussion3043rdquo[Online] Available httpstalkpeercoinnettppc-switching-between-pos-and-pow3043 November 4 2014Accessed on May 5 2019

[176] Bentov Iddo and Gabizon Ariel and Mizrahi Alex ldquoCrypto-currencies without proof of workrdquo International Conference onFinancial Cryptography and Data Security pages 142ndash157 2016

[177] ldquoDecred Platformrdquo [Online] Available httpsdecredorgAccessed on June 23 2019

[178] ldquoTendermint introductionrdquo [Online] Availablehttptendermintreadthedocsioprojectstoolsenmasterintroductionhtml Accessed on July 30 2019

[179] Kwon Jae ldquoTendermint Consensus without Miningrdquo [Online]Available httpstendermintcomstaticdocstendermintpdf2014 Accessed on July 30 2019

[180] ldquoTendermint wikirdquo [Online] Available httpsgithubcomtenderminttendermintwikiByzantine-Consensus-AlgorithmAccessed on July 30 2019

[181] Buterin Vitalik and Griffith Virgil ldquoCasper the Friendly FinalityGadgetrdquo [Online] Available httpsgithubcomethereumresearchblobmasterpaperscasper-basicscasper basicspdfAccessed on August 1 2019

[182] Zamfir Vlad ldquoCasper the Friendly Ghost-A Correct-by-Construction Blockchain Consensus Protocolrdquo [Online] Avail-able httpsgithubcomethereumresearchblobmasterpapersCasperTFGCasperTFGpdf Accessed on August 1 2019

[183] Sompolinsky Y and Zohar A ldquoSecure high-rate transactionprocessing in bitcoinrdquo International Conference on Financial Cryp-tography and Data Security pp 507-527 January 2015

[184] JP Buntinx ldquoWhat is Delegated Proof-of-Stakerdquo [Online] Avail-able httpsthemerklecomwhat-is-delegated-proof-of-stakeApril 20 2017 Accessed on August 1 2019

[185] Kiayias A Russell A David B and Oliynykov R ldquoOuroborosA provably secure proof-of-stake blockchain protocolrdquo AnnualInternational Cryptology Conference pp 357-388 August 2017

[186] ldquoOUROBOROS PROOF OF STAKE ALGORITHMrdquo [Online]Available httpscardanodocscomcardanoproof-of-stakeAccessed on August 2 2019

[187] ldquoCardano Platformrdquo [Online] Available httpswwwcardanohuborgenhome Accessed on August 2 2019

[188] ldquoEOS Platformrdquo [Online] Available httpseosio Accessedon 24 May 2019

[189] ldquoEOS Whitepaperrdquo [Online] Available httpsgithubcomEOSIODocumentationblobmasterTechnicalWhitePapermdAccessed on 24 May 2019

[190] Kim Jonathan ldquoEOS Raises Record-Breaking $4 Billion fromCrowdsalerdquo [Online] Available httpscryptoslatecomeos-raises-record-breaking-4-billion-from-crowdsale 29 May2018 Accessed on 24 May 2019

[191] ldquoWhat is EOS Most Comprehensive Guide Part 2rdquo [Online]Available httpsblockgeekscomguideswhat-is-eos-part-2Accessed on 24 May 2019

[192] Rosic Ameer ldquoWhat is EOS Blockchain Beginners Guiderdquo [On-line] Available httpsblockgeekscomguideseos-blockchainAccessed on 24 May 2019

[193] ldquoTron Platformrdquo [Online] Available httpstronnetworkAccessed on 24 May 2019

[194] ldquoTron Whitepaperrdquo [Online] Available httpstronnetworkstaticdocwhite paper v 2 0pdf Accessed on 24 May 2019

[195] ldquoTRONs Consensus ldquoHow it worksrdquordquo [On-line] Available httpsmediumcomTRONNewstrons-consensus-how-it-works-6fd231b63715 11 November2018 Accessed on 24 May 2019

[196] ldquoTezos Platformrdquo [Online] Available httpstezoscomAccessed on 24 May 2019

[197] Goodman LM ldquoTezos Whitepaperrdquo [On-line] Available httpstezoscomstaticwhitepaper-2dc8c02267a8fb86bd67a108199441bfpdf 2 September2014 Accessed on 24 May 2019

[198] Arluck Jacob ldquoLiquid Proof-of-Stakerdquo [Online]Available httpsmediumcomTRONNewstrons-consensus-how-it-works-6fd231b63715 31 July 2018Accessed on 24 May 2019

[199] Arluck Jacob ldquoOverview of Tezos Economics Modelrdquo [Online]Available httpswwwinfinitystonesiotezos Accessed on 24May 2019

[200] ldquoLisk Platformrdquo [Online] Available httpsliskio Accessedon 1 June 2019

[201] ldquoLisk Whitepaperrdquo [Online] Available httpsgithubcomslashekslisk-whitepaperblobdevelopmentLiskWhitepapermdAccessed on 1 June 2019

[202] ldquoArk Platformrdquo [Online] Available httpsarkio Accessedon 1 June 2019

[203] ldquoArk Whitepaperrdquo [Online] Available httpsarkioWhitepaperpdf Accessed on 1 June 2019

[204] Ateniese Giuseppe and Bonacina Ilario and Faonio Antonio andGalesi Nicola ldquoProofs of Space When Space Is of the EssencerdquoIn proceedings of 9th International Conference on Security andCryptography for Networks SCN 2014 Amalfi Italy September3-5 2014

39

[205] ldquoPeercoin discussion forum discussion2524rdquo [Online] Avail-able httpstalkpeercoinnettthe-complete-guide-to-minting2524 June 15 2014 Accessed on May 5 2019

[206] ldquoHyperledgerrdquo [Online] Available httpswwwhyperledgerorg Accessed on July 10 2019

[207] ldquoHyperledger Fabricrdquo [Online] Available httpswwwhyperledgerorgprojectsfabric Accessed on July 10 2019

[208] ldquoHyperledger Sawtoothrdquo [Online] Available httpswwwhyperledgerorgprojectssawtooth Accessed on July 10 2019

[209] ldquoHyperledger Burrowrdquo [Online] Available httpswwwhyperledgerorgprojectshyperledger-burrow Accessed on July10 2019

[210] ldquoHyperledger Irohardquo [Online] Available httpswwwhyperledgerorgprojectsiroha Accessed on July 10 2019

[211] ldquoHyperledger Indyrdquo [Online] Available httpswwwhyperledgerorgprojectshyperledger-indy Accessed on July 102019

[212] ldquoApache Kafkardquo [Online] Available httpskafkaapacheorgAccessed on July 10 2019

[213] ldquoApache Zookeeperrdquo [Online] Available httpszookeeperapacheorg Accessed on July 10 2019

[214] ldquoMonax Industries Limitedrdquo [Online] Available httpsmonaxio Accessed on July 10 2019

[215] ldquoIroha Codebaserdquo [Online] Available httpsgithubcomhyperledgeriroha Accessed on July 10 2019

[216] Palanivel C ldquoHyperledger Iroha - ArchitectureFunctionalLogical Flow amp Consensus(YAC) Mechanismrdquo[Online] Available httpswwwlinkedincompulsehyperledger-iroha-architecture-functionallogical-chandrasekaranApril 30 2018 Accessed on July 10 2019

[217] ldquoHyperledger Architecture Volume 1rdquo [Online] Avail-able httpswwwhyperledgerorgwp-contentuploads201708Hyperledger Arch WG Paper 1 Consensuspdf August 2017Accessed on July 10 2019

[218] ldquogRPCrdquo [Online] Available httpsgrpcio Accessed on July10 2019

[219] ldquoIroha Documentationrdquo [Online] Available httpsirohareadthedocsioenlatestindexhtml Accessed on July 10 2019

[220] Chen L Xu L Shah N Gao Z Lu Y amp Shi W ldquoOn Se-curity Analysis of Proof-of-Elapsed-Time (PoET)rdquo In InternationalSymposium on Stabilization Safety and Security of DistributedSystems pp 282-297 November 2017

[221] ldquoBurrow Codebase on Githubrdquo [Online] Available httpsgithubcomhyperledgerburrow Accessed on July 10 2019

[222] Ferdous MS Chowdhury F and Alassafi M ldquoIn Search ofSelf-Sovereign Identity Leveraging Blockchain Technologyrdquo IEEEAccess 7 pp103059-103079 2019

[223] ldquoSovrin Foundationrdquo [Online] Available httpssovrinorgAccessed on March 27 2018

[224] Aublin P L Mokhtar S B and Quma V ldquoRbft Redundantbyzantine fault tolerancerdquo In IEEE 33rd International Conferenceon Distributed Computing Systems (ICDCS) 2013 pp 297-306 July2013

[225] ldquoIroha Consensus Discussionrdquo [Online] Availablehttpsgithubcomhyperledgerindy-plenumblobmasterdocsmainmd Accessed on July 10 2019

[226] Dogan T ldquoWho Scales It Best Blockchainsrsquo TPS Ana-lysisrdquo [Online] Available httpshackernooncomwho-scales-it-best-blockchains-tps-analysis-pv39g25mg Accessedon July 27 2019

[227] OrsquoNeal S ldquoWho Scales It Best Inside Block-chains Ongoing Transactions-Per-Second Racerdquo [On-line] Available httpscointelegraphcomnewswho-scales-it-best-inside-blockchains-ongoing-transactions-per-second-raceJanuary 22 2019 Accessed on July 27 2019

[228] LeMahieu C ldquoNano A Feeless Distributed CryptocurrencyNetworkrdquo [Online] Available httpsnanoorgenwhitepaperAccessed on July 27 2019

[229] Popov S ldquoThe Tanglerdquo [Online] Available httpsassetsctfassetsnetr1dr6vzfxhev2t4uxvsIqk0EUau6g2sw0g45eae33637ca92f85dd9f4a3a218e1eciota1 4 3pdf April 30 2018Accessed on July 27 2019

1 Introduction

2 Background Distributed Consensus

3 Background Blockchain

31 Bitcoin

32 Properties of blockchain

33 Blockchain type


4 Consensus taxonomy amp properties


411 Structural properties

412 Block amp reward properties

413 Security properties


5 Incentivised Consensus PoW amp PoS




513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS

524 Limitations of PoS

525 Analysis

6 Incentivised Consensus Beyond PoW and PoS

61 Hybrid Consensus

62 N-POSPOW

63 Analysis

7 Non-incentivised Consensus

71 Hyperledger Fabric


73 Hyperledger Burrow

74 Hyperledger Iroha

75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

2

ings For example the factors upon which the consensusalgorithms have been analysed are not comprehensiveImportantly a wide range of consensus algorithms andtheir internal mechanisms utilised in many existing crypto-currencies have not been considered at all In addition allof these studies have failed to capture the practical interrela-tion between blockchain systems (mostly crypto-currencies)and their corresponding consensus algorithms All in allthere is a pressing need for a study that analyses a widerange of existing consensus algorithms and the blockchainsystems in a practical-oriented way and synthesises thisanalyses into a conceptual framework in a concise yet com-prehensive manner The principal motivation of this articleis to fill in this gap

Contributions The main contributions of the article arepresented below

bull A novel taxonomy of consensus properties capturingdifferent aspects of a consensus algorithm has been cre-ated In this taxonomy consensus algorithms have beencategorised in two major categories incentivised andnon-incentivised algorithms which have been againsub-divided as per different considerations Consensusalgorithms belonging to each sub-category analysedtogether using the taxonomy of consensus properties

bull The analysis of each sub-category has been summarisedin tabular formats so as to visually represent it in acomprehensible way

bull For each category (and the sub-category if any) the cor-responding blockchain systems (predominantly crypto-currencies) have been analysed as well The ana-lysis result has been presented in a concise fashionwhich can be used to understand the inter-relationbetween these systems and their underlying consensusalgorithms

bull The major issues in each category of consensus al-gorithm have been examined in detail and their im-plications have been further analysed

bull Over hundred crypto-currencies belonging to differentconsensus algorithms have been examined to under-stand their different properties These properties thenhave been utilised to analyse and identify differenttrends among these crypto-currencies

bull Finally a decision tree of consensus algorithms havebeen presented This tree can be utilised to test the suit-ability of a consensus algorithm under certain criteria

In short with these contributions this article represents oneof the most comprehensive studies of blockchain consensusalgorithms as of now

Structure In Section 2 we present a brief background on dis-tributed consensus highlighting its different componentstypes and properties Section 3 outlines a brief presentationon blockchain covering its different aspects such as typesproperties layers A taxonomy of consensus algorithms andtheir underlying properties is presented in Section 4 Section5 and Section 6 analyse different incentivised consensusalgorithm whereas Section 7 examines the different non-incentivised consensus algorithms Finally we conclude inSection 8 with a detailed discussion on different issuesinvolving the analysed consensus algorithms and the cor-

responding crypto-currencies

2 BACKGROUND DISTRIBUTED CONSENSUS

Consensus mechanisms in distributed systems have beena well studied research problem for nearly three decadesSuch mechanisms enable consensus to be achieved regard-ing a shared statedata among a set of distributed nodesThe need for a shared state originated the notion of replic-ated database systems in order to ensure resilience againstnode failures within a network Such database systemsensure that data is not lost when one or more nodes failto function in an excepted fashion

The notion of the replicated database can be generalisedwith the concept of State Machine Replication (SMR) [11]The core idea behind SMR is that a computing machine canbe expressed as a deterministic state machine The machineaccepts an input message performs its predefined computa-tion and might produce an outputresponse These actionsessentially change its state SMR conceptualises that such astate machine with an initial state can be replicated amongdifferent nodes If it can be ensured that all the participatingnodes receive the same set of input messages in the exactsame order (the phenomenon known as atomic broadcast)then each node would be able to evolve the states of itsstate machine individually in exactly the same fashion Thiscan guarantee consistency and availability regarding thestate of the machine (as well as data it holds) among all(applicable) nodes even in the presence of node failuresOnce this occurs it can be said that a distributed consensushas emerged among the participating nodes It is imperativethat a protocol is defined to ensure timely disseminationand atomic broadcast of input messages among the nodesand in many ways dictates how a distributed consensus isachieved and maintained Hence such a protocol is aptlycalled a consensus protocol

Designing and deploying a consensus protocol is a chal-lenging task as it needs to consider several crucial issuessuch as resiliency against node failures node behaviournetwork partitioning network latency corrupt or out-of-order inputs and so on [7] Schneider pointed out thatthere are two crucial requirements to reach and maintainconsensus among distributed nodes The first requirementis a deterministic state machine The second requirement isa consensus protocol to disseminate inputs in a timely fashionand to ensure atomic broadcast among the participatingnodes At the same time the consensus protocols mustensure the properties of the atomic broadcast [12] [13][4] [5] The properties of atomic broadcast in distributedconsensus is illustrated in Table 1

One way to achieve the design goals of such a protocolis to make certain assumptions under which the protocol isproved to function properly These assumptions influencethe critical characteristics of a consensus protocol Nextwe explore two sets of widely-used assumptions for anydistributed consensus protocol

The first set of assumptions are about the underly-ing networking type Dwork et al categorised three typesof networks exhibiting different properties synchronousasynchronous and partiallyeventually synchronous [22]The latency involved in delivering a message to all nodes

3

Properties Note






Properties Note

Safety Con-sistency




FaultTolerance












4




31 Bitcoin















5







33 Blockchain type











6

Consensus

Orphaned

branchX

X Orphaned

branch

Main

branch



Network

Layer

Consensus

Layer

Application

Layer

Meta-Ap

plication

Layer










Security properties












7


Node type

Structure type

Single

TypeOpen

Close

FormationImplicit

Explicit

ConfigurationStatic

Dynamic

Multiple

TopologyFlat

Hierarchichal

ConfigurationStatic

Dynamic



Randomised

VotingSingle

MultipleCoin-age
























8

Security properties

Authentication

Non-repuditation


Attack vectors

Adversary tolerance

Sybil protection

DoS


Bribing

Long-range

Accumulation

Grinding

Cartel













consumption












9
















10




Block Time


03012009 125 21 10m













11





20m


infinite supply40m


finite supple40m


infinite supply 10m


05072014 155 20m


16102016 7000000000 21 M 20




Block Time







Block Time







12





















13




Block Time


30072015 388 10-20s







Block Time





Block Time





Block Time





Block Time



514 PoW Limitations


14




Block Time


01020304050607080

2017-02-10

hellip2017-03-27

hellip2017-05-11

hellip2017-06-25

hellip2017-08-09

hellip2017-09-23

hellip2017-11-07

hellip2017-12-22

hellip2018-02-05

hellip2018-03-22

hellip2018-05-06

hellip2018-06-21

hellip2018-08-05

hellip2018-09-19

hellip2018-11-03

hellip2018-12-18

hellip2019-02-01

hellip2019-03-18

hellip2019-05-02

hellip2019-06-16










15


Known Blocks

Relayed By count

BTCcom 74

Unknown 41

F2Pool 39

Poolin 38

AntPool 37

SlushPool 27

BTCTOP 26

ViaBTC 16







1 of 1 27072019 1008 pm








52 Proof of Stake



16






x High 2f + 1






















17




















18







522 BFT PoS










19

Propose


Propose Block

New Height

Wait for pre-

commits from +23


Wait for pre-vote

from +23

Valid block

No +23 pre-vote

for block



No +

23

pre-

com

mit

for b

lock

Invalid block

or not

received

in time














20











21
















22






05s 21















23



Chained(PeerCoin)



Chained(CFFG)



BFT(Tendermint)





BTFG(Ouroboros)

ClientsElectors amp

Stakeholders







Chained(PeerCoin)

X High 3f + 1

Chained(CFFG)

X High 3f + 1

BFT(Tendermint)


High 3f + 1


BFT(Ouroboros)

X High 2f + 1

DPoS X High 3f + 1

















24















25





















26




Minters







transactionpartners





PoR X High 3f + 1

PoB X High 3f + 1

PoSV X High 3f + 1

PoC High PoI X High




PoSV X X X X X X














NEM March 31st2015






27





















28


















75 Hyperledger Indy
















29




76 Analysis






(log log nlog n


nodes


8 DISCUSSION





30











Fabric Low 3f + 1

PoET Low Θ(

log log nlog n


YAC Low 3f + 1

RBFT Low 3f + 1









PoW 221 238 526 412DPoS 6 483 606 020PoS 6 287 224 485







31

PoW

58

DPoS

9

PoS

8

PoW+PoS

4


1


Tollerance (dBFT)

3


(PBFT)

2


1XRP Ledger

Protocol

1Stellar

Consens

us

Protocol

(SCP)

1

Tangle

1

VBFT

(verifiabl

e random

function)

1

Proof of authority

2


1

Other

1

POI

1


1

BFT

3


1

Other

10

PoW DPoS PoS













32

PoW

DPoS

dBFT

PoW + PoS02468

101214161820

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019



93

310

0

0

3

3






33

71

11

4 0

21

1114




9 CONCLUSION






34

Consensusalgorithm

Yes

High

Low

No

Low

Low

HighMedium

Medium

High

Yes No

Medium

Incentivised

Energy

Scalable

Security

AISC Resistant

RBFTSBFTYACPoET

Burrow

Chained

PoW




DPoSTendermint

CTFG Ouroboros

Low

PoRPoSVPoCPoI

Medium

Medium

Low

Medium







35




REFERENCES

































36























































37






































































38




















































39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

3

Properties Note






Properties Note

Safety Con-sistency




FaultTolerance












4




31 Bitcoin















5







33 Blockchain type











6

Consensus

Orphaned

branchX

X Orphaned

branch

Main

branch



Network

Layer

Consensus

Layer

Application

Layer

Meta-Ap

plication

Layer










Security properties












7


Node type

Structure type

Single

TypeOpen

Close

FormationImplicit

Explicit

ConfigurationStatic

Dynamic

Multiple

TopologyFlat

Hierarchichal

ConfigurationStatic

Dynamic



Randomised

VotingSingle

MultipleCoin-age
























8

Security properties

Authentication

Non-repuditation


Attack vectors

Adversary tolerance

Sybil protection

DoS


Bribing

Long-range

Accumulation

Grinding

Cartel













consumption












9
















10




Block Time


03012009 125 21 10m













11





20m


infinite supply40m


finite supple40m


infinite supply 10m


05072014 155 20m


16102016 7000000000 21 M 20




Block Time







Block Time







12





















13




Block Time


30072015 388 10-20s







Block Time





Block Time





Block Time





Block Time



514 PoW Limitations


14




Block Time


01020304050607080

2017-02-10

hellip2017-03-27

hellip2017-05-11

hellip2017-06-25

hellip2017-08-09

hellip2017-09-23

hellip2017-11-07

hellip2017-12-22

hellip2018-02-05

hellip2018-03-22

hellip2018-05-06

hellip2018-06-21

hellip2018-08-05

hellip2018-09-19

hellip2018-11-03

hellip2018-12-18

hellip2019-02-01

hellip2019-03-18

hellip2019-05-02

hellip2019-06-16










15


Known Blocks

Relayed By count

BTCcom 74

Unknown 41

F2Pool 39

Poolin 38

AntPool 37

SlushPool 27

BTCTOP 26

ViaBTC 16







1 of 1 27072019 1008 pm








52 Proof of Stake



16






x High 2f + 1






















17




















18







522 BFT PoS










19

Propose


Propose Block

New Height

Wait for pre-

commits from +23


Wait for pre-vote

from +23

Valid block

No +23 pre-vote

for block



No +

23

pre-

com

mit

for b

lock

Invalid block

or not

received

in time














20











21
















22






05s 21















23



Chained(PeerCoin)



Chained(CFFG)



BFT(Tendermint)





BTFG(Ouroboros)

ClientsElectors amp

Stakeholders







Chained(PeerCoin)

X High 3f + 1

Chained(CFFG)

X High 3f + 1

BFT(Tendermint)


High 3f + 1


BFT(Ouroboros)

X High 2f + 1

DPoS X High 3f + 1

















24















25





















26




Minters







transactionpartners





PoR X High 3f + 1

PoB X High 3f + 1

PoSV X High 3f + 1

PoC High PoI X High




PoSV X X X X X X














NEM March 31st2015






27





















28


















75 Hyperledger Indy
















29




76 Analysis






(log log nlog n


nodes


8 DISCUSSION





30











Fabric Low 3f + 1

PoET Low Θ(

log log nlog n


YAC Low 3f + 1

RBFT Low 3f + 1









PoW 221 238 526 412DPoS 6 483 606 020PoS 6 287 224 485







31

PoW

58

DPoS

9

PoS

8

PoW+PoS

4


1


Tollerance (dBFT)

3


(PBFT)

2


1XRP Ledger

Protocol

1Stellar

Consens

us

Protocol

(SCP)

1

Tangle

1

VBFT

(verifiabl

e random

function)

1

Proof of authority

2


1

Other

1

POI

1


1

BFT

3


1

Other

10

PoW DPoS PoS













32

PoW

DPoS

dBFT

PoW + PoS02468

101214161820

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019



93

310

0

0

3

3






33

71

11

4 0

21

1114




9 CONCLUSION






34

Consensusalgorithm

Yes

High

Low

No

Low

Low

HighMedium

Medium

High

Yes No

Medium

Incentivised

Energy

Scalable

Security

AISC Resistant

RBFTSBFTYACPoET

Burrow

Chained

PoW




DPoSTendermint

CTFG Ouroboros

Low

PoRPoSVPoCPoI

Medium

Medium

Low

Medium







35




REFERENCES

































36























































37






































































38




















































39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

4




31 Bitcoin















5







33 Blockchain type











6

Consensus

Orphaned

branchX

X Orphaned

branch

Main

branch



Network

Layer

Consensus

Layer

Application

Layer

Meta-Ap

plication

Layer










Security properties












7


Node type

Structure type

Single

TypeOpen

Close

FormationImplicit

Explicit

ConfigurationStatic

Dynamic

Multiple

TopologyFlat

Hierarchichal

ConfigurationStatic

Dynamic



Randomised

VotingSingle

MultipleCoin-age
























8

Security properties

Authentication

Non-repuditation


Attack vectors

Adversary tolerance

Sybil protection

DoS


Bribing

Long-range

Accumulation

Grinding

Cartel













consumption












9
















10




Block Time


03012009 125 21 10m













11





20m


infinite supply40m


finite supple40m


infinite supply 10m


05072014 155 20m


16102016 7000000000 21 M 20




Block Time







Block Time







12





















13




Block Time


30072015 388 10-20s







Block Time





Block Time





Block Time





Block Time



514 PoW Limitations


14




Block Time


01020304050607080

2017-02-10

hellip2017-03-27

hellip2017-05-11

hellip2017-06-25

hellip2017-08-09

hellip2017-09-23

hellip2017-11-07

hellip2017-12-22

hellip2018-02-05

hellip2018-03-22

hellip2018-05-06

hellip2018-06-21

hellip2018-08-05

hellip2018-09-19

hellip2018-11-03

hellip2018-12-18

hellip2019-02-01

hellip2019-03-18

hellip2019-05-02

hellip2019-06-16










15


Known Blocks

Relayed By count

BTCcom 74

Unknown 41

F2Pool 39

Poolin 38

AntPool 37

SlushPool 27

BTCTOP 26

ViaBTC 16







1 of 1 27072019 1008 pm








52 Proof of Stake



16






x High 2f + 1






















17




















18







522 BFT PoS










19

Propose


Propose Block

New Height

Wait for pre-

commits from +23


Wait for pre-vote

from +23

Valid block

No +23 pre-vote

for block



No +

23

pre-

com

mit

for b

lock

Invalid block

or not

received

in time














20











21
















22






05s 21















23



Chained(PeerCoin)



Chained(CFFG)



BFT(Tendermint)





BTFG(Ouroboros)

ClientsElectors amp

Stakeholders







Chained(PeerCoin)

X High 3f + 1

Chained(CFFG)

X High 3f + 1

BFT(Tendermint)


High 3f + 1


BFT(Ouroboros)

X High 2f + 1

DPoS X High 3f + 1

















24















25





















26




Minters







transactionpartners





PoR X High 3f + 1

PoB X High 3f + 1

PoSV X High 3f + 1

PoC High PoI X High




PoSV X X X X X X














NEM March 31st2015






27





















28


















75 Hyperledger Indy
















29




76 Analysis






(log log nlog n


nodes


8 DISCUSSION





30











Fabric Low 3f + 1

PoET Low Θ(

log log nlog n


YAC Low 3f + 1

RBFT Low 3f + 1









PoW 221 238 526 412DPoS 6 483 606 020PoS 6 287 224 485







31

PoW

58

DPoS

9

PoS

8

PoW+PoS

4


1


Tollerance (dBFT)

3


(PBFT)

2


1XRP Ledger

Protocol

1Stellar

Consens

us

Protocol

(SCP)

1

Tangle

1

VBFT

(verifiabl

e random

function)

1

Proof of authority

2


1

Other

1

POI

1


1

BFT

3


1

Other

10

PoW DPoS PoS













32

PoW

DPoS

dBFT

PoW + PoS02468

101214161820

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019



93

310

0

0

3

3






33

71

11

4 0

21

1114




9 CONCLUSION






34

Consensusalgorithm

Yes

High

Low

No

Low

Low

HighMedium

Medium

High

Yes No

Medium

Incentivised

Energy

Scalable

Security

AISC Resistant

RBFTSBFTYACPoET

Burrow

Chained

PoW




DPoSTendermint

CTFG Ouroboros

Low

PoRPoSVPoCPoI

Medium

Medium

Low

Medium







35




REFERENCES

































36























































37






































































38




















































39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

5







33 Blockchain type











6

Consensus

Orphaned

branchX

X Orphaned

branch

Main

branch



Network

Layer

Consensus

Layer

Application

Layer

Meta-Ap

plication

Layer










Security properties












7


Node type

Structure type

Single

TypeOpen

Close

FormationImplicit

Explicit

ConfigurationStatic

Dynamic

Multiple

TopologyFlat

Hierarchichal

ConfigurationStatic

Dynamic



Randomised

VotingSingle

MultipleCoin-age
























8

Security properties

Authentication

Non-repuditation


Attack vectors

Adversary tolerance

Sybil protection

DoS


Bribing

Long-range

Accumulation

Grinding

Cartel













consumption












9
















10




Block Time


03012009 125 21 10m













11





20m


infinite supply40m


finite supple40m


infinite supply 10m


05072014 155 20m


16102016 7000000000 21 M 20




Block Time







Block Time







12





















13




Block Time


30072015 388 10-20s







Block Time





Block Time





Block Time





Block Time



514 PoW Limitations


14




Block Time


01020304050607080

2017-02-10

hellip2017-03-27

hellip2017-05-11

hellip2017-06-25

hellip2017-08-09

hellip2017-09-23

hellip2017-11-07

hellip2017-12-22

hellip2018-02-05

hellip2018-03-22

hellip2018-05-06

hellip2018-06-21

hellip2018-08-05

hellip2018-09-19

hellip2018-11-03

hellip2018-12-18

hellip2019-02-01

hellip2019-03-18

hellip2019-05-02

hellip2019-06-16










15


Known Blocks

Relayed By count

BTCcom 74

Unknown 41

F2Pool 39

Poolin 38

AntPool 37

SlushPool 27

BTCTOP 26

ViaBTC 16







1 of 1 27072019 1008 pm








52 Proof of Stake



16






x High 2f + 1






















17




















18







522 BFT PoS










19

Propose


Propose Block

New Height

Wait for pre-

commits from +23


Wait for pre-vote

from +23

Valid block

No +23 pre-vote

for block



No +

23

pre-

com

mit

for b

lock

Invalid block

or not

received

in time














20











21
















22






05s 21















23



Chained(PeerCoin)



Chained(CFFG)



BFT(Tendermint)





BTFG(Ouroboros)

ClientsElectors amp

Stakeholders







Chained(PeerCoin)

X High 3f + 1

Chained(CFFG)

X High 3f + 1

BFT(Tendermint)


High 3f + 1


BFT(Ouroboros)

X High 2f + 1

DPoS X High 3f + 1

















24















25





















26




Minters







transactionpartners





PoR X High 3f + 1

PoB X High 3f + 1

PoSV X High 3f + 1

PoC High PoI X High




PoSV X X X X X X














NEM March 31st2015






27





















28


















75 Hyperledger Indy
















29




76 Analysis






(log log nlog n


nodes


8 DISCUSSION





30











Fabric Low 3f + 1

PoET Low Θ(

log log nlog n


YAC Low 3f + 1

RBFT Low 3f + 1









PoW 221 238 526 412DPoS 6 483 606 020PoS 6 287 224 485







31

PoW

58

DPoS

9

PoS

8

PoW+PoS

4


1


Tollerance (dBFT)

3


(PBFT)

2


1XRP Ledger

Protocol

1Stellar

Consens

us

Protocol

(SCP)

1

Tangle

1

VBFT

(verifiabl

e random

function)

1

Proof of authority

2


1

Other

1

POI

1


1

BFT

3


1

Other

10

PoW DPoS PoS













32

PoW

DPoS

dBFT

PoW + PoS02468

101214161820

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019



93

310

0

0

3

3






33

71

11

4 0

21

1114




9 CONCLUSION






34

Consensusalgorithm

Yes

High

Low

No

Low

Low

HighMedium

Medium

High

Yes No

Medium

Incentivised

Energy

Scalable

Security

AISC Resistant

RBFTSBFTYACPoET

Burrow

Chained

PoW




DPoSTendermint

CTFG Ouroboros

Low

PoRPoSVPoCPoI

Medium

Medium

Low

Medium







35




REFERENCES

































36























































37






































































38




















































39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

6

Consensus

Orphaned

branchX

X Orphaned

branch

Main

branch



Network

Layer

Consensus

Layer

Application

Layer

Meta-Ap

plication

Layer










Security properties












7


Node type

Structure type

Single

TypeOpen

Close

FormationImplicit

Explicit

ConfigurationStatic

Dynamic

Multiple

TopologyFlat

Hierarchichal

ConfigurationStatic

Dynamic



Randomised

VotingSingle

MultipleCoin-age
























8

Security properties

Authentication

Non-repuditation


Attack vectors

Adversary tolerance

Sybil protection

DoS


Bribing

Long-range

Accumulation

Grinding

Cartel













consumption












9
















10




Block Time


03012009 125 21 10m













11





20m


infinite supply40m


finite supple40m


infinite supply 10m


05072014 155 20m


16102016 7000000000 21 M 20




Block Time







Block Time







12





















13




Block Time


30072015 388 10-20s







Block Time





Block Time





Block Time





Block Time



514 PoW Limitations


14




Block Time


01020304050607080

2017-02-10

hellip2017-03-27

hellip2017-05-11

hellip2017-06-25

hellip2017-08-09

hellip2017-09-23

hellip2017-11-07

hellip2017-12-22

hellip2018-02-05

hellip2018-03-22

hellip2018-05-06

hellip2018-06-21

hellip2018-08-05

hellip2018-09-19

hellip2018-11-03

hellip2018-12-18

hellip2019-02-01

hellip2019-03-18

hellip2019-05-02

hellip2019-06-16










15


Known Blocks

Relayed By count

BTCcom 74

Unknown 41

F2Pool 39

Poolin 38

AntPool 37

SlushPool 27

BTCTOP 26

ViaBTC 16







1 of 1 27072019 1008 pm








52 Proof of Stake



16






x High 2f + 1






















17




















18







522 BFT PoS










19

Propose


Propose Block

New Height

Wait for pre-

commits from +23


Wait for pre-vote

from +23

Valid block

No +23 pre-vote

for block



No +

23

pre-

com

mit

for b

lock

Invalid block

or not

received

in time














20











21
















22






05s 21















23



Chained(PeerCoin)



Chained(CFFG)



BFT(Tendermint)





BTFG(Ouroboros)

ClientsElectors amp

Stakeholders







Chained(PeerCoin)

X High 3f + 1

Chained(CFFG)

X High 3f + 1

BFT(Tendermint)


High 3f + 1


BFT(Ouroboros)

X High 2f + 1

DPoS X High 3f + 1

















24















25





















26




Minters







transactionpartners





PoR X High 3f + 1

PoB X High 3f + 1

PoSV X High 3f + 1

PoC High PoI X High




PoSV X X X X X X














NEM March 31st2015






27





















28


















75 Hyperledger Indy
















29




76 Analysis






(log log nlog n


nodes


8 DISCUSSION





30











Fabric Low 3f + 1

PoET Low Θ(

log log nlog n


YAC Low 3f + 1

RBFT Low 3f + 1









PoW 221 238 526 412DPoS 6 483 606 020PoS 6 287 224 485







31

PoW

58

DPoS

9

PoS

8

PoW+PoS

4


1


Tollerance (dBFT)

3


(PBFT)

2


1XRP Ledger

Protocol

1Stellar

Consens

us

Protocol

(SCP)

1

Tangle

1

VBFT

(verifiabl

e random

function)

1

Proof of authority

2


1

Other

1

POI

1


1

BFT

3


1

Other

10

PoW DPoS PoS













32

PoW

DPoS

dBFT

PoW + PoS02468

101214161820

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019



93

310

0

0

3

3






33

71

11

4 0

21

1114




9 CONCLUSION






34

Consensusalgorithm

Yes

High

Low

No

Low

Low

HighMedium

Medium

High

Yes No

Medium

Incentivised

Energy

Scalable

Security

AISC Resistant

RBFTSBFTYACPoET

Burrow

Chained

PoW




DPoSTendermint

CTFG Ouroboros

Low

PoRPoSVPoCPoI

Medium

Medium

Low

Medium







35




REFERENCES

































36























































37






































































38




















































39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

7


Node type

Structure type

Single

TypeOpen

Close

FormationImplicit

Explicit

ConfigurationStatic

Dynamic

Multiple

TopologyFlat

Hierarchichal

ConfigurationStatic

Dynamic



Randomised

VotingSingle

MultipleCoin-age
























8

Security properties

Authentication

Non-repuditation


Attack vectors

Adversary tolerance

Sybil protection

DoS


Bribing

Long-range

Accumulation

Grinding

Cartel













consumption












9
















10




Block Time


03012009 125 21 10m













11





20m


infinite supply40m


finite supple40m


infinite supply 10m


05072014 155 20m


16102016 7000000000 21 M 20




Block Time







Block Time







12





















13




Block Time


30072015 388 10-20s







Block Time





Block Time





Block Time





Block Time



514 PoW Limitations


14




Block Time


01020304050607080

2017-02-10

hellip2017-03-27

hellip2017-05-11

hellip2017-06-25

hellip2017-08-09

hellip2017-09-23

hellip2017-11-07

hellip2017-12-22

hellip2018-02-05

hellip2018-03-22

hellip2018-05-06

hellip2018-06-21

hellip2018-08-05

hellip2018-09-19

hellip2018-11-03

hellip2018-12-18

hellip2019-02-01

hellip2019-03-18

hellip2019-05-02

hellip2019-06-16










15


Known Blocks

Relayed By count

BTCcom 74

Unknown 41

F2Pool 39

Poolin 38

AntPool 37

SlushPool 27

BTCTOP 26

ViaBTC 16







1 of 1 27072019 1008 pm








52 Proof of Stake



16






x High 2f + 1






















17




















18







522 BFT PoS










19

Propose


Propose Block

New Height

Wait for pre-

commits from +23


Wait for pre-vote

from +23

Valid block

No +23 pre-vote

for block



No +

23

pre-

com

mit

for b

lock

Invalid block

or not

received

in time














20











21
















22






05s 21















23



Chained(PeerCoin)



Chained(CFFG)



BFT(Tendermint)





BTFG(Ouroboros)

ClientsElectors amp

Stakeholders







Chained(PeerCoin)

X High 3f + 1

Chained(CFFG)

X High 3f + 1

BFT(Tendermint)


High 3f + 1


BFT(Ouroboros)

X High 2f + 1

DPoS X High 3f + 1

















24















25





















26




Minters







transactionpartners





PoR X High 3f + 1

PoB X High 3f + 1

PoSV X High 3f + 1

PoC High PoI X High




PoSV X X X X X X














NEM March 31st2015






27





















28


















75 Hyperledger Indy
















29




76 Analysis






(log log nlog n


nodes


8 DISCUSSION





30











Fabric Low 3f + 1

PoET Low Θ(

log log nlog n


YAC Low 3f + 1

RBFT Low 3f + 1









PoW 221 238 526 412DPoS 6 483 606 020PoS 6 287 224 485







31

PoW

58

DPoS

9

PoS

8

PoW+PoS

4


1


Tollerance (dBFT)

3


(PBFT)

2


1XRP Ledger

Protocol

1Stellar

Consens

us

Protocol

(SCP)

1

Tangle

1

VBFT

(verifiabl

e random

function)

1

Proof of authority

2


1

Other

1

POI

1


1

BFT

3


1

Other

10

PoW DPoS PoS













32

PoW

DPoS

dBFT

PoW + PoS02468

101214161820

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019



93

310

0

0

3

3






33

71

11

4 0

21

1114




9 CONCLUSION






34

Consensusalgorithm

Yes

High

Low

No

Low

Low

HighMedium

Medium

High

Yes No

Medium

Incentivised

Energy

Scalable

Security

AISC Resistant

RBFTSBFTYACPoET

Burrow

Chained

PoW




DPoSTendermint

CTFG Ouroboros

Low

PoRPoSVPoCPoI

Medium

Medium

Low

Medium







35




REFERENCES

































36























































37






































































38




















































39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

8

Security properties

Authentication

Non-repuditation


Attack vectors

Adversary tolerance

Sybil protection

DoS


Bribing

Long-range

Accumulation

Grinding

Cartel













consumption












9
















10




Block Time


03012009 125 21 10m













11





20m


infinite supply40m


finite supple40m


infinite supply 10m


05072014 155 20m


16102016 7000000000 21 M 20




Block Time







Block Time







12





















13




Block Time


30072015 388 10-20s







Block Time





Block Time





Block Time





Block Time



514 PoW Limitations


14




Block Time


01020304050607080

2017-02-10

hellip2017-03-27

hellip2017-05-11

hellip2017-06-25

hellip2017-08-09

hellip2017-09-23

hellip2017-11-07

hellip2017-12-22

hellip2018-02-05

hellip2018-03-22

hellip2018-05-06

hellip2018-06-21

hellip2018-08-05

hellip2018-09-19

hellip2018-11-03

hellip2018-12-18

hellip2019-02-01

hellip2019-03-18

hellip2019-05-02

hellip2019-06-16










15


Known Blocks

Relayed By count

BTCcom 74

Unknown 41

F2Pool 39

Poolin 38

AntPool 37

SlushPool 27

BTCTOP 26

ViaBTC 16







1 of 1 27072019 1008 pm








52 Proof of Stake



16






x High 2f + 1






















17




















18







522 BFT PoS










19

Propose


Propose Block

New Height

Wait for pre-

commits from +23


Wait for pre-vote

from +23

Valid block

No +23 pre-vote

for block



No +

23

pre-

com

mit

for b

lock

Invalid block

or not

received

in time














20











21
















22






05s 21















23



Chained(PeerCoin)



Chained(CFFG)



BFT(Tendermint)





BTFG(Ouroboros)

ClientsElectors amp

Stakeholders







Chained(PeerCoin)

X High 3f + 1

Chained(CFFG)

X High 3f + 1

BFT(Tendermint)


High 3f + 1


BFT(Ouroboros)

X High 2f + 1

DPoS X High 3f + 1

















24















25





















26




Minters







transactionpartners





PoR X High 3f + 1

PoB X High 3f + 1

PoSV X High 3f + 1

PoC High PoI X High




PoSV X X X X X X














NEM March 31st2015






27





















28


















75 Hyperledger Indy
















29




76 Analysis






(log log nlog n


nodes


8 DISCUSSION





30











Fabric Low 3f + 1

PoET Low Θ(

log log nlog n


YAC Low 3f + 1

RBFT Low 3f + 1









PoW 221 238 526 412DPoS 6 483 606 020PoS 6 287 224 485







31

PoW

58

DPoS

9

PoS

8

PoW+PoS

4


1


Tollerance (dBFT)

3


(PBFT)

2


1XRP Ledger

Protocol

1Stellar

Consens

us

Protocol

(SCP)

1

Tangle

1

VBFT

(verifiabl

e random

function)

1

Proof of authority

2


1

Other

1

POI

1


1

BFT

3


1

Other

10

PoW DPoS PoS













32

PoW

DPoS

dBFT

PoW + PoS02468

101214161820

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019



93

310

0

0

3

3






33

71

11

4 0

21

1114




9 CONCLUSION






34

Consensusalgorithm

Yes

High

Low

No

Low

Low

HighMedium

Medium

High

Yes No

Medium

Incentivised

Energy

Scalable

Security

AISC Resistant

RBFTSBFTYACPoET

Burrow

Chained

PoW




DPoSTendermint

CTFG Ouroboros

Low

PoRPoSVPoCPoI

Medium

Medium

Low

Medium







35




REFERENCES

































36























































37






































































38




















































39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

9
















10




Block Time


03012009 125 21 10m













11





20m


infinite supply40m


finite supple40m


infinite supply 10m


05072014 155 20m


16102016 7000000000 21 M 20




Block Time







Block Time







12





















13




Block Time


30072015 388 10-20s







Block Time





Block Time





Block Time





Block Time



514 PoW Limitations


14




Block Time


01020304050607080

2017-02-10

hellip2017-03-27

hellip2017-05-11

hellip2017-06-25

hellip2017-08-09

hellip2017-09-23

hellip2017-11-07

hellip2017-12-22

hellip2018-02-05

hellip2018-03-22

hellip2018-05-06

hellip2018-06-21

hellip2018-08-05

hellip2018-09-19

hellip2018-11-03

hellip2018-12-18

hellip2019-02-01

hellip2019-03-18

hellip2019-05-02

hellip2019-06-16










15


Known Blocks

Relayed By count

BTCcom 74

Unknown 41

F2Pool 39

Poolin 38

AntPool 37

SlushPool 27

BTCTOP 26

ViaBTC 16







1 of 1 27072019 1008 pm








52 Proof of Stake



16






x High 2f + 1






















17




















18







522 BFT PoS










19

Propose


Propose Block

New Height

Wait for pre-

commits from +23


Wait for pre-vote

from +23

Valid block

No +23 pre-vote

for block



No +

23

pre-

com

mit

for b

lock

Invalid block

or not

received

in time














20











21
















22






05s 21















23



Chained(PeerCoin)



Chained(CFFG)



BFT(Tendermint)





BTFG(Ouroboros)

ClientsElectors amp

Stakeholders







Chained(PeerCoin)

X High 3f + 1

Chained(CFFG)

X High 3f + 1

BFT(Tendermint)


High 3f + 1


BFT(Ouroboros)

X High 2f + 1

DPoS X High 3f + 1

















24















25





















26




Minters







transactionpartners





PoR X High 3f + 1

PoB X High 3f + 1

PoSV X High 3f + 1

PoC High PoI X High




PoSV X X X X X X














NEM March 31st2015






27





















28


















75 Hyperledger Indy
















29




76 Analysis






(log log nlog n


nodes


8 DISCUSSION





30











Fabric Low 3f + 1

PoET Low Θ(

log log nlog n


YAC Low 3f + 1

RBFT Low 3f + 1









PoW 221 238 526 412DPoS 6 483 606 020PoS 6 287 224 485







31

PoW

58

DPoS

9

PoS

8

PoW+PoS

4


1


Tollerance (dBFT)

3


(PBFT)

2


1XRP Ledger

Protocol

1Stellar

Consens

us

Protocol

(SCP)

1

Tangle

1

VBFT

(verifiabl

e random

function)

1

Proof of authority

2


1

Other

1

POI

1


1

BFT

3


1

Other

10

PoW DPoS PoS













32

PoW

DPoS

dBFT

PoW + PoS02468

101214161820

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019



93

310

0

0

3

3






33

71

11

4 0

21

1114




9 CONCLUSION






34

Consensusalgorithm

Yes

High

Low

No

Low

Low

HighMedium

Medium

High

Yes No

Medium

Incentivised

Energy

Scalable

Security

AISC Resistant

RBFTSBFTYACPoET

Burrow

Chained

PoW




DPoSTendermint

CTFG Ouroboros

Low

PoRPoSVPoCPoI

Medium

Medium

Low

Medium







35




REFERENCES

































36























































37






































































38




















































39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

10




Block Time


03012009 125 21 10m













11





20m


infinite supply40m


finite supple40m


infinite supply 10m


05072014 155 20m


16102016 7000000000 21 M 20




Block Time







Block Time







12





















13




Block Time


30072015 388 10-20s







Block Time





Block Time





Block Time





Block Time



514 PoW Limitations


14




Block Time


01020304050607080

2017-02-10

hellip2017-03-27

hellip2017-05-11

hellip2017-06-25

hellip2017-08-09

hellip2017-09-23

hellip2017-11-07

hellip2017-12-22

hellip2018-02-05

hellip2018-03-22

hellip2018-05-06

hellip2018-06-21

hellip2018-08-05

hellip2018-09-19

hellip2018-11-03

hellip2018-12-18

hellip2019-02-01

hellip2019-03-18

hellip2019-05-02

hellip2019-06-16










15


Known Blocks

Relayed By count

BTCcom 74

Unknown 41

F2Pool 39

Poolin 38

AntPool 37

SlushPool 27

BTCTOP 26

ViaBTC 16







1 of 1 27072019 1008 pm








52 Proof of Stake



16






x High 2f + 1






















17




















18







522 BFT PoS










19

Propose


Propose Block

New Height

Wait for pre-

commits from +23


Wait for pre-vote

from +23

Valid block

No +23 pre-vote

for block



No +

23

pre-

com

mit

for b

lock

Invalid block

or not

received

in time














20











21
















22






05s 21















23



Chained(PeerCoin)



Chained(CFFG)



BFT(Tendermint)





BTFG(Ouroboros)

ClientsElectors amp

Stakeholders







Chained(PeerCoin)

X High 3f + 1

Chained(CFFG)

X High 3f + 1

BFT(Tendermint)


High 3f + 1


BFT(Ouroboros)

X High 2f + 1

DPoS X High 3f + 1

















24















25





















26




Minters







transactionpartners





PoR X High 3f + 1

PoB X High 3f + 1

PoSV X High 3f + 1

PoC High PoI X High




PoSV X X X X X X














NEM March 31st2015






27





















28


















75 Hyperledger Indy
















29




76 Analysis






(log log nlog n


nodes


8 DISCUSSION





30











Fabric Low 3f + 1

PoET Low Θ(

log log nlog n


YAC Low 3f + 1

RBFT Low 3f + 1









PoW 221 238 526 412DPoS 6 483 606 020PoS 6 287 224 485







31

PoW

58

DPoS

9

PoS

8

PoW+PoS

4


1


Tollerance (dBFT)

3


(PBFT)

2


1XRP Ledger

Protocol

1Stellar

Consens

us

Protocol

(SCP)

1

Tangle

1

VBFT

(verifiabl

e random

function)

1

Proof of authority

2


1

Other

1

POI

1


1

BFT

3


1

Other

10

PoW DPoS PoS













32

PoW

DPoS

dBFT

PoW + PoS02468

101214161820

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019



93

310

0

0

3

3






33

71

11

4 0

21

1114




9 CONCLUSION






34

Consensusalgorithm

Yes

High

Low

No

Low

Low

HighMedium

Medium

High

Yes No

Medium

Incentivised

Energy

Scalable

Security

AISC Resistant

RBFTSBFTYACPoET

Burrow

Chained

PoW




DPoSTendermint

CTFG Ouroboros

Low

PoRPoSVPoCPoI

Medium

Medium

Low

Medium







35




REFERENCES

































36























































37






































































38




















































39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

11





20m


infinite supply40m


finite supple40m


infinite supply 10m


05072014 155 20m


16102016 7000000000 21 M 20




Block Time







Block Time







12





















13




Block Time


30072015 388 10-20s







Block Time





Block Time





Block Time





Block Time



514 PoW Limitations


14




Block Time


01020304050607080

2017-02-10

hellip2017-03-27

hellip2017-05-11

hellip2017-06-25

hellip2017-08-09

hellip2017-09-23

hellip2017-11-07

hellip2017-12-22

hellip2018-02-05

hellip2018-03-22

hellip2018-05-06

hellip2018-06-21

hellip2018-08-05

hellip2018-09-19

hellip2018-11-03

hellip2018-12-18

hellip2019-02-01

hellip2019-03-18

hellip2019-05-02

hellip2019-06-16










15


Known Blocks

Relayed By count

BTCcom 74

Unknown 41

F2Pool 39

Poolin 38

AntPool 37

SlushPool 27

BTCTOP 26

ViaBTC 16







1 of 1 27072019 1008 pm








52 Proof of Stake



16






x High 2f + 1






















17




















18







522 BFT PoS










19

Propose


Propose Block

New Height

Wait for pre-

commits from +23


Wait for pre-vote

from +23

Valid block

No +23 pre-vote

for block



No +

23

pre-

com

mit

for b

lock

Invalid block

or not

received

in time














20











21
















22






05s 21















23



Chained(PeerCoin)



Chained(CFFG)



BFT(Tendermint)





BTFG(Ouroboros)

ClientsElectors amp

Stakeholders







Chained(PeerCoin)

X High 3f + 1

Chained(CFFG)

X High 3f + 1

BFT(Tendermint)


High 3f + 1


BFT(Ouroboros)

X High 2f + 1

DPoS X High 3f + 1

















24















25





















26




Minters







transactionpartners





PoR X High 3f + 1

PoB X High 3f + 1

PoSV X High 3f + 1

PoC High PoI X High




PoSV X X X X X X














NEM March 31st2015






27





















28


















75 Hyperledger Indy
















29




76 Analysis






(log log nlog n


nodes


8 DISCUSSION





30











Fabric Low 3f + 1

PoET Low Θ(

log log nlog n


YAC Low 3f + 1

RBFT Low 3f + 1









PoW 221 238 526 412DPoS 6 483 606 020PoS 6 287 224 485







31

PoW

58

DPoS

9

PoS

8

PoW+PoS

4


1


Tollerance (dBFT)

3


(PBFT)

2


1XRP Ledger

Protocol

1Stellar

Consens

us

Protocol

(SCP)

1

Tangle

1

VBFT

(verifiabl

e random

function)

1

Proof of authority

2


1

Other

1

POI

1


1

BFT

3


1

Other

10

PoW DPoS PoS













32

PoW

DPoS

dBFT

PoW + PoS02468

101214161820

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019



93

310

0

0

3

3






33

71

11

4 0

21

1114




9 CONCLUSION






34

Consensusalgorithm

Yes

High

Low

No

Low

Low

HighMedium

Medium

High

Yes No

Medium

Incentivised

Energy

Scalable

Security

AISC Resistant

RBFTSBFTYACPoET

Burrow

Chained

PoW




DPoSTendermint

CTFG Ouroboros

Low

PoRPoSVPoCPoI

Medium

Medium

Low

Medium







35




REFERENCES

































36























































37






































































38




















































39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

12





















13




Block Time


30072015 388 10-20s







Block Time





Block Time





Block Time





Block Time



514 PoW Limitations


14




Block Time


01020304050607080

2017-02-10

hellip2017-03-27

hellip2017-05-11

hellip2017-06-25

hellip2017-08-09

hellip2017-09-23

hellip2017-11-07

hellip2017-12-22

hellip2018-02-05

hellip2018-03-22

hellip2018-05-06

hellip2018-06-21

hellip2018-08-05

hellip2018-09-19

hellip2018-11-03

hellip2018-12-18

hellip2019-02-01

hellip2019-03-18

hellip2019-05-02

hellip2019-06-16










15


Known Blocks

Relayed By count

BTCcom 74

Unknown 41

F2Pool 39

Poolin 38

AntPool 37

SlushPool 27

BTCTOP 26

ViaBTC 16







1 of 1 27072019 1008 pm








52 Proof of Stake



16






x High 2f + 1






















17




















18







522 BFT PoS










19

Propose


Propose Block

New Height

Wait for pre-

commits from +23


Wait for pre-vote

from +23

Valid block

No +23 pre-vote

for block



No +

23

pre-

com

mit

for b

lock

Invalid block

or not

received

in time














20











21
















22






05s 21















23



Chained(PeerCoin)



Chained(CFFG)



BFT(Tendermint)





BTFG(Ouroboros)

ClientsElectors amp

Stakeholders







Chained(PeerCoin)

X High 3f + 1

Chained(CFFG)

X High 3f + 1

BFT(Tendermint)


High 3f + 1


BFT(Ouroboros)

X High 2f + 1

DPoS X High 3f + 1

















24















25





















26




Minters







transactionpartners





PoR X High 3f + 1

PoB X High 3f + 1

PoSV X High 3f + 1

PoC High PoI X High




PoSV X X X X X X














NEM March 31st2015






27





















28


















75 Hyperledger Indy
















29




76 Analysis






(log log nlog n


nodes


8 DISCUSSION





30











Fabric Low 3f + 1

PoET Low Θ(

log log nlog n


YAC Low 3f + 1

RBFT Low 3f + 1









PoW 221 238 526 412DPoS 6 483 606 020PoS 6 287 224 485







31

PoW

58

DPoS

9

PoS

8

PoW+PoS

4


1


Tollerance (dBFT)

3


(PBFT)

2


1XRP Ledger

Protocol

1Stellar

Consens

us

Protocol

(SCP)

1

Tangle

1

VBFT

(verifiabl

e random

function)

1

Proof of authority

2


1

Other

1

POI

1


1

BFT

3


1

Other

10

PoW DPoS PoS













32

PoW

DPoS

dBFT

PoW + PoS02468

101214161820

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019



93

310

0

0

3

3






33

71

11

4 0

21

1114




9 CONCLUSION






34

Consensusalgorithm

Yes

High

Low

No

Low

Low

HighMedium

Medium

High

Yes No

Medium

Incentivised

Energy

Scalable

Security

AISC Resistant

RBFTSBFTYACPoET

Burrow

Chained

PoW




DPoSTendermint

CTFG Ouroboros

Low

PoRPoSVPoCPoI

Medium

Medium

Low

Medium







35




REFERENCES

































36























































37






































































38




















































39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

13




Block Time


30072015 388 10-20s







Block Time





Block Time





Block Time





Block Time



514 PoW Limitations


14




Block Time


01020304050607080

2017-02-10

hellip2017-03-27

hellip2017-05-11

hellip2017-06-25

hellip2017-08-09

hellip2017-09-23

hellip2017-11-07

hellip2017-12-22

hellip2018-02-05

hellip2018-03-22

hellip2018-05-06

hellip2018-06-21

hellip2018-08-05

hellip2018-09-19

hellip2018-11-03

hellip2018-12-18

hellip2019-02-01

hellip2019-03-18

hellip2019-05-02

hellip2019-06-16










15


Known Blocks

Relayed By count

BTCcom 74

Unknown 41

F2Pool 39

Poolin 38

AntPool 37

SlushPool 27

BTCTOP 26

ViaBTC 16







1 of 1 27072019 1008 pm








52 Proof of Stake



16






x High 2f + 1






















17




















18







522 BFT PoS










19

Propose


Propose Block

New Height

Wait for pre-

commits from +23


Wait for pre-vote

from +23

Valid block

No +23 pre-vote

for block



No +

23

pre-

com

mit

for b

lock

Invalid block

or not

received

in time














20











21
















22






05s 21















23



Chained(PeerCoin)



Chained(CFFG)



BFT(Tendermint)





BTFG(Ouroboros)

ClientsElectors amp

Stakeholders







Chained(PeerCoin)

X High 3f + 1

Chained(CFFG)

X High 3f + 1

BFT(Tendermint)


High 3f + 1


BFT(Ouroboros)

X High 2f + 1

DPoS X High 3f + 1

















24















25





















26




Minters







transactionpartners





PoR X High 3f + 1

PoB X High 3f + 1

PoSV X High 3f + 1

PoC High PoI X High




PoSV X X X X X X














NEM March 31st2015






27





















28


















75 Hyperledger Indy
















29




76 Analysis






(log log nlog n


nodes


8 DISCUSSION





30











Fabric Low 3f + 1

PoET Low Θ(

log log nlog n


YAC Low 3f + 1

RBFT Low 3f + 1









PoW 221 238 526 412DPoS 6 483 606 020PoS 6 287 224 485







31

PoW

58

DPoS

9

PoS

8

PoW+PoS

4


1


Tollerance (dBFT)

3


(PBFT)

2


1XRP Ledger

Protocol

1Stellar

Consens

us

Protocol

(SCP)

1

Tangle

1

VBFT

(verifiabl

e random

function)

1

Proof of authority

2


1

Other

1

POI

1


1

BFT

3


1

Other

10

PoW DPoS PoS













32

PoW

DPoS

dBFT

PoW + PoS02468

101214161820

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019



93

310

0

0

3

3






33

71

11

4 0

21

1114




9 CONCLUSION






34

Consensusalgorithm

Yes

High

Low

No

Low

Low

HighMedium

Medium

High

Yes No

Medium

Incentivised

Energy

Scalable

Security

AISC Resistant

RBFTSBFTYACPoET

Burrow

Chained

PoW




DPoSTendermint

CTFG Ouroboros

Low

PoRPoSVPoCPoI

Medium

Medium

Low

Medium







35




REFERENCES

































36























































37






































































38




















































39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

14




Block Time


01020304050607080

2017-02-10

hellip2017-03-27

hellip2017-05-11

hellip2017-06-25

hellip2017-08-09

hellip2017-09-23

hellip2017-11-07

hellip2017-12-22

hellip2018-02-05

hellip2018-03-22

hellip2018-05-06

hellip2018-06-21

hellip2018-08-05

hellip2018-09-19

hellip2018-11-03

hellip2018-12-18

hellip2019-02-01

hellip2019-03-18

hellip2019-05-02

hellip2019-06-16










15


Known Blocks

Relayed By count

BTCcom 74

Unknown 41

F2Pool 39

Poolin 38

AntPool 37

SlushPool 27

BTCTOP 26

ViaBTC 16







1 of 1 27072019 1008 pm








52 Proof of Stake



16






x High 2f + 1






















17




















18







522 BFT PoS










19

Propose


Propose Block

New Height

Wait for pre-

commits from +23


Wait for pre-vote

from +23

Valid block

No +23 pre-vote

for block



No +

23

pre-

com

mit

for b

lock

Invalid block

or not

received

in time














20











21
















22






05s 21















23



Chained(PeerCoin)



Chained(CFFG)



BFT(Tendermint)





BTFG(Ouroboros)

ClientsElectors amp

Stakeholders







Chained(PeerCoin)

X High 3f + 1

Chained(CFFG)

X High 3f + 1

BFT(Tendermint)


High 3f + 1


BFT(Ouroboros)

X High 2f + 1

DPoS X High 3f + 1

















24















25





















26




Minters







transactionpartners





PoR X High 3f + 1

PoB X High 3f + 1

PoSV X High 3f + 1

PoC High PoI X High




PoSV X X X X X X














NEM March 31st2015






27





















28


















75 Hyperledger Indy
















29




76 Analysis






(log log nlog n


nodes


8 DISCUSSION





30











Fabric Low 3f + 1

PoET Low Θ(

log log nlog n


YAC Low 3f + 1

RBFT Low 3f + 1









PoW 221 238 526 412DPoS 6 483 606 020PoS 6 287 224 485







31

PoW

58

DPoS

9

PoS

8

PoW+PoS

4


1


Tollerance (dBFT)

3


(PBFT)

2


1XRP Ledger

Protocol

1Stellar

Consens

us

Protocol

(SCP)

1

Tangle

1

VBFT

(verifiabl

e random

function)

1

Proof of authority

2


1

Other

1

POI

1


1

BFT

3


1

Other

10

PoW DPoS PoS













32

PoW

DPoS

dBFT

PoW + PoS02468

101214161820

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019



93

310

0

0

3

3






33

71

11

4 0

21

1114




9 CONCLUSION






34

Consensusalgorithm

Yes

High

Low

No

Low

Low

HighMedium

Medium

High

Yes No

Medium

Incentivised

Energy

Scalable

Security

AISC Resistant

RBFTSBFTYACPoET

Burrow

Chained

PoW




DPoSTendermint

CTFG Ouroboros

Low

PoRPoSVPoCPoI

Medium

Medium

Low

Medium







35




REFERENCES

































36























































37






































































38




















































39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

15


Known Blocks

Relayed By count

BTCcom 74

Unknown 41

F2Pool 39

Poolin 38

AntPool 37

SlushPool 27

BTCTOP 26

ViaBTC 16







1 of 1 27072019 1008 pm








52 Proof of Stake



16






x High 2f + 1






















17




















18







522 BFT PoS










19

Propose


Propose Block

New Height

Wait for pre-

commits from +23


Wait for pre-vote

from +23

Valid block

No +23 pre-vote

for block



No +

23

pre-

com

mit

for b

lock

Invalid block

or not

received

in time














20











21
















22






05s 21















23



Chained(PeerCoin)



Chained(CFFG)



BFT(Tendermint)





BTFG(Ouroboros)

ClientsElectors amp

Stakeholders







Chained(PeerCoin)

X High 3f + 1

Chained(CFFG)

X High 3f + 1

BFT(Tendermint)


High 3f + 1


BFT(Ouroboros)

X High 2f + 1

DPoS X High 3f + 1

















24















25





















26




Minters







transactionpartners





PoR X High 3f + 1

PoB X High 3f + 1

PoSV X High 3f + 1

PoC High PoI X High




PoSV X X X X X X














NEM March 31st2015






27





















28


















75 Hyperledger Indy
















29




76 Analysis






(log log nlog n


nodes


8 DISCUSSION





30











Fabric Low 3f + 1

PoET Low Θ(

log log nlog n


YAC Low 3f + 1

RBFT Low 3f + 1









PoW 221 238 526 412DPoS 6 483 606 020PoS 6 287 224 485







31

PoW

58

DPoS

9

PoS

8

PoW+PoS

4


1


Tollerance (dBFT)

3


(PBFT)

2


1XRP Ledger

Protocol

1Stellar

Consens

us

Protocol

(SCP)

1

Tangle

1

VBFT

(verifiabl

e random

function)

1

Proof of authority

2


1

Other

1

POI

1


1

BFT

3


1

Other

10

PoW DPoS PoS













32

PoW

DPoS

dBFT

PoW + PoS02468

101214161820

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019



93

310

0

0

3

3






33

71

11

4 0

21

1114




9 CONCLUSION






34

Consensusalgorithm

Yes

High

Low

No

Low

Low

HighMedium

Medium

High

Yes No

Medium

Incentivised

Energy

Scalable

Security

AISC Resistant

RBFTSBFTYACPoET

Burrow

Chained

PoW




DPoSTendermint

CTFG Ouroboros

Low

PoRPoSVPoCPoI

Medium

Medium

Low

Medium







35




REFERENCES

































36























































37






































































38




















































39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

16






x High 2f + 1






















17




















18







522 BFT PoS










19

Propose


Propose Block

New Height

Wait for pre-

commits from +23


Wait for pre-vote

from +23

Valid block

No +23 pre-vote

for block



No +

23

pre-

com

mit

for b

lock

Invalid block

or not

received

in time














20











21
















22






05s 21















23



Chained(PeerCoin)



Chained(CFFG)



BFT(Tendermint)





BTFG(Ouroboros)

ClientsElectors amp

Stakeholders







Chained(PeerCoin)

X High 3f + 1

Chained(CFFG)

X High 3f + 1

BFT(Tendermint)


High 3f + 1


BFT(Ouroboros)

X High 2f + 1

DPoS X High 3f + 1

















24















25





















26




Minters







transactionpartners





PoR X High 3f + 1

PoB X High 3f + 1

PoSV X High 3f + 1

PoC High PoI X High




PoSV X X X X X X














NEM March 31st2015






27





















28


















75 Hyperledger Indy
















29




76 Analysis






(log log nlog n


nodes


8 DISCUSSION





30











Fabric Low 3f + 1

PoET Low Θ(

log log nlog n


YAC Low 3f + 1

RBFT Low 3f + 1









PoW 221 238 526 412DPoS 6 483 606 020PoS 6 287 224 485







31

PoW

58

DPoS

9

PoS

8

PoW+PoS

4


1


Tollerance (dBFT)

3


(PBFT)

2


1XRP Ledger

Protocol

1Stellar

Consens

us

Protocol

(SCP)

1

Tangle

1

VBFT

(verifiabl

e random

function)

1

Proof of authority

2


1

Other

1

POI

1


1

BFT

3


1

Other

10

PoW DPoS PoS













32

PoW

DPoS

dBFT

PoW + PoS02468

101214161820

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019



93

310

0

0

3

3






33

71

11

4 0

21

1114




9 CONCLUSION






34

Consensusalgorithm

Yes

High

Low

No

Low

Low

HighMedium

Medium

High

Yes No

Medium

Incentivised

Energy

Scalable

Security

AISC Resistant

RBFTSBFTYACPoET

Burrow

Chained

PoW




DPoSTendermint

CTFG Ouroboros

Low

PoRPoSVPoCPoI

Medium

Medium

Low

Medium







35




REFERENCES

































36























































37






































































38




















































39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

17




















18







522 BFT PoS










19

Propose


Propose Block

New Height

Wait for pre-

commits from +23


Wait for pre-vote

from +23

Valid block

No +23 pre-vote

for block



No +

23

pre-

com

mit

for b

lock

Invalid block

or not

received

in time














20











21
















22






05s 21















23



Chained(PeerCoin)



Chained(CFFG)



BFT(Tendermint)





BTFG(Ouroboros)

ClientsElectors amp

Stakeholders







Chained(PeerCoin)

X High 3f + 1

Chained(CFFG)

X High 3f + 1

BFT(Tendermint)


High 3f + 1


BFT(Ouroboros)

X High 2f + 1

DPoS X High 3f + 1

















24















25





















26




Minters







transactionpartners





PoR X High 3f + 1

PoB X High 3f + 1

PoSV X High 3f + 1

PoC High PoI X High




PoSV X X X X X X














NEM March 31st2015






27





















28


















75 Hyperledger Indy
















29




76 Analysis






(log log nlog n


nodes


8 DISCUSSION





30











Fabric Low 3f + 1

PoET Low Θ(

log log nlog n


YAC Low 3f + 1

RBFT Low 3f + 1









PoW 221 238 526 412DPoS 6 483 606 020PoS 6 287 224 485







31

PoW

58

DPoS

9

PoS

8

PoW+PoS

4


1


Tollerance (dBFT)

3


(PBFT)

2


1XRP Ledger

Protocol

1Stellar

Consens

us

Protocol

(SCP)

1

Tangle

1

VBFT

(verifiabl

e random

function)

1

Proof of authority

2


1

Other

1

POI

1


1

BFT

3


1

Other

10

PoW DPoS PoS













32

PoW

DPoS

dBFT

PoW + PoS02468

101214161820

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019



93

310

0

0

3

3






33

71

11

4 0

21

1114




9 CONCLUSION






34

Consensusalgorithm

Yes

High

Low

No

Low

Low

HighMedium

Medium

High

Yes No

Medium

Incentivised

Energy

Scalable

Security

AISC Resistant

RBFTSBFTYACPoET

Burrow

Chained

PoW




DPoSTendermint

CTFG Ouroboros

Low

PoRPoSVPoCPoI

Medium

Medium

Low

Medium







35




REFERENCES

































36























































37






































































38




















































39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

18







522 BFT PoS










19

Propose


Propose Block

New Height

Wait for pre-

commits from +23


Wait for pre-vote

from +23

Valid block

No +23 pre-vote

for block



No +

23

pre-

com

mit

for b

lock

Invalid block

or not

received

in time














20











21
















22






05s 21















23



Chained(PeerCoin)



Chained(CFFG)



BFT(Tendermint)





BTFG(Ouroboros)

ClientsElectors amp

Stakeholders







Chained(PeerCoin)

X High 3f + 1

Chained(CFFG)

X High 3f + 1

BFT(Tendermint)


High 3f + 1


BFT(Ouroboros)

X High 2f + 1

DPoS X High 3f + 1

















24















25





















26




Minters







transactionpartners





PoR X High 3f + 1

PoB X High 3f + 1

PoSV X High 3f + 1

PoC High PoI X High




PoSV X X X X X X














NEM March 31st2015






27





















28


















75 Hyperledger Indy
















29




76 Analysis






(log log nlog n


nodes


8 DISCUSSION





30











Fabric Low 3f + 1

PoET Low Θ(

log log nlog n


YAC Low 3f + 1

RBFT Low 3f + 1









PoW 221 238 526 412DPoS 6 483 606 020PoS 6 287 224 485







31

PoW

58

DPoS

9

PoS

8

PoW+PoS

4


1


Tollerance (dBFT)

3


(PBFT)

2


1XRP Ledger

Protocol

1Stellar

Consens

us

Protocol

(SCP)

1

Tangle

1

VBFT

(verifiabl

e random

function)

1

Proof of authority

2


1

Other

1

POI

1


1

BFT

3


1

Other

10

PoW DPoS PoS













32

PoW

DPoS

dBFT

PoW + PoS02468

101214161820

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019



93

310

0

0

3

3






33

71

11

4 0

21

1114




9 CONCLUSION






34

Consensusalgorithm

Yes

High

Low

No

Low

Low

HighMedium

Medium

High

Yes No

Medium

Incentivised

Energy

Scalable

Security

AISC Resistant

RBFTSBFTYACPoET

Burrow

Chained

PoW




DPoSTendermint

CTFG Ouroboros

Low

PoRPoSVPoCPoI

Medium

Medium

Low

Medium







35




REFERENCES

































36























































37






































































38




















































39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

19

Propose


Propose Block

New Height

Wait for pre-

commits from +23


Wait for pre-vote

from +23

Valid block

No +23 pre-vote

for block



No +

23

pre-

com

mit

for b

lock

Invalid block

or not

received

in time














20











21
















22






05s 21















23



Chained(PeerCoin)



Chained(CFFG)



BFT(Tendermint)





BTFG(Ouroboros)

ClientsElectors amp

Stakeholders







Chained(PeerCoin)

X High 3f + 1

Chained(CFFG)

X High 3f + 1

BFT(Tendermint)


High 3f + 1


BFT(Ouroboros)

X High 2f + 1

DPoS X High 3f + 1

















24















25





















26




Minters







transactionpartners





PoR X High 3f + 1

PoB X High 3f + 1

PoSV X High 3f + 1

PoC High PoI X High




PoSV X X X X X X














NEM March 31st2015






27





















28


















75 Hyperledger Indy
















29




76 Analysis






(log log nlog n


nodes


8 DISCUSSION





30











Fabric Low 3f + 1

PoET Low Θ(

log log nlog n


YAC Low 3f + 1

RBFT Low 3f + 1









PoW 221 238 526 412DPoS 6 483 606 020PoS 6 287 224 485







31

PoW

58

DPoS

9

PoS

8

PoW+PoS

4


1


Tollerance (dBFT)

3


(PBFT)

2


1XRP Ledger

Protocol

1Stellar

Consens

us

Protocol

(SCP)

1

Tangle

1

VBFT

(verifiabl

e random

function)

1

Proof of authority

2


1

Other

1

POI

1


1

BFT

3


1

Other

10

PoW DPoS PoS













32

PoW

DPoS

dBFT

PoW + PoS02468

101214161820

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019



93

310

0

0

3

3






33

71

11

4 0

21

1114




9 CONCLUSION






34

Consensusalgorithm

Yes

High

Low

No

Low

Low

HighMedium

Medium

High

Yes No

Medium

Incentivised

Energy

Scalable

Security

AISC Resistant

RBFTSBFTYACPoET

Burrow

Chained

PoW




DPoSTendermint

CTFG Ouroboros

Low

PoRPoSVPoCPoI

Medium

Medium

Low

Medium







35




REFERENCES

































36























































37






































































38




















































39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

20











21
















22






05s 21















23



Chained(PeerCoin)



Chained(CFFG)



BFT(Tendermint)





BTFG(Ouroboros)

ClientsElectors amp

Stakeholders







Chained(PeerCoin)

X High 3f + 1

Chained(CFFG)

X High 3f + 1

BFT(Tendermint)


High 3f + 1


BFT(Ouroboros)

X High 2f + 1

DPoS X High 3f + 1

















24















25





















26




Minters







transactionpartners





PoR X High 3f + 1

PoB X High 3f + 1

PoSV X High 3f + 1

PoC High PoI X High




PoSV X X X X X X














NEM March 31st2015






27





















28


















75 Hyperledger Indy
















29




76 Analysis






(log log nlog n


nodes


8 DISCUSSION





30











Fabric Low 3f + 1

PoET Low Θ(

log log nlog n


YAC Low 3f + 1

RBFT Low 3f + 1









PoW 221 238 526 412DPoS 6 483 606 020PoS 6 287 224 485







31

PoW

58

DPoS

9

PoS

8

PoW+PoS

4


1


Tollerance (dBFT)

3


(PBFT)

2


1XRP Ledger

Protocol

1Stellar

Consens

us

Protocol

(SCP)

1

Tangle

1

VBFT

(verifiabl

e random

function)

1

Proof of authority

2


1

Other

1

POI

1


1

BFT

3


1

Other

10

PoW DPoS PoS













32

PoW

DPoS

dBFT

PoW + PoS02468

101214161820

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019



93

310

0

0

3

3






33

71

11

4 0

21

1114




9 CONCLUSION






34

Consensusalgorithm

Yes

High

Low

No

Low

Low

HighMedium

Medium

High

Yes No

Medium

Incentivised

Energy

Scalable

Security

AISC Resistant

RBFTSBFTYACPoET

Burrow

Chained

PoW




DPoSTendermint

CTFG Ouroboros

Low

PoRPoSVPoCPoI

Medium

Medium

Low

Medium







35




REFERENCES

































36























































37






































































38




















































39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

21
















22






05s 21















23



Chained(PeerCoin)



Chained(CFFG)



BFT(Tendermint)





BTFG(Ouroboros)

ClientsElectors amp

Stakeholders







Chained(PeerCoin)

X High 3f + 1

Chained(CFFG)

X High 3f + 1

BFT(Tendermint)


High 3f + 1


BFT(Ouroboros)

X High 2f + 1

DPoS X High 3f + 1

















24















25





















26




Minters







transactionpartners





PoR X High 3f + 1

PoB X High 3f + 1

PoSV X High 3f + 1

PoC High PoI X High




PoSV X X X X X X














NEM March 31st2015






27





















28


















75 Hyperledger Indy
















29




76 Analysis






(log log nlog n


nodes


8 DISCUSSION





30











Fabric Low 3f + 1

PoET Low Θ(

log log nlog n


YAC Low 3f + 1

RBFT Low 3f + 1









PoW 221 238 526 412DPoS 6 483 606 020PoS 6 287 224 485







31

PoW

58

DPoS

9

PoS

8

PoW+PoS

4


1


Tollerance (dBFT)

3


(PBFT)

2


1XRP Ledger

Protocol

1Stellar

Consens

us

Protocol

(SCP)

1

Tangle

1

VBFT

(verifiabl

e random

function)

1

Proof of authority

2


1

Other

1

POI

1


1

BFT

3


1

Other

10

PoW DPoS PoS













32

PoW

DPoS

dBFT

PoW + PoS02468

101214161820

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019



93

310

0

0

3

3






33

71

11

4 0

21

1114




9 CONCLUSION






34

Consensusalgorithm

Yes

High

Low

No

Low

Low

HighMedium

Medium

High

Yes No

Medium

Incentivised

Energy

Scalable

Security

AISC Resistant

RBFTSBFTYACPoET

Burrow

Chained

PoW




DPoSTendermint

CTFG Ouroboros

Low

PoRPoSVPoCPoI

Medium

Medium

Low

Medium







35




REFERENCES

































36























































37






































































38




















































39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

22






05s 21















23



Chained(PeerCoin)



Chained(CFFG)



BFT(Tendermint)





BTFG(Ouroboros)

ClientsElectors amp

Stakeholders







Chained(PeerCoin)

X High 3f + 1

Chained(CFFG)

X High 3f + 1

BFT(Tendermint)


High 3f + 1


BFT(Ouroboros)

X High 2f + 1

DPoS X High 3f + 1

















24















25





















26




Minters







transactionpartners





PoR X High 3f + 1

PoB X High 3f + 1

PoSV X High 3f + 1

PoC High PoI X High




PoSV X X X X X X














NEM March 31st2015






27





















28


















75 Hyperledger Indy
















29




76 Analysis






(log log nlog n


nodes


8 DISCUSSION





30











Fabric Low 3f + 1

PoET Low Θ(

log log nlog n


YAC Low 3f + 1

RBFT Low 3f + 1









PoW 221 238 526 412DPoS 6 483 606 020PoS 6 287 224 485







31

PoW

58

DPoS

9

PoS

8

PoW+PoS

4


1


Tollerance (dBFT)

3


(PBFT)

2


1XRP Ledger

Protocol

1Stellar

Consens

us

Protocol

(SCP)

1

Tangle

1

VBFT

(verifiabl

e random

function)

1

Proof of authority

2


1

Other

1

POI

1


1

BFT

3


1

Other

10

PoW DPoS PoS













32

PoW

DPoS

dBFT

PoW + PoS02468

101214161820

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019



93

310

0

0

3

3






33

71

11

4 0

21

1114




9 CONCLUSION






34

Consensusalgorithm

Yes

High

Low

No

Low

Low

HighMedium

Medium

High

Yes No

Medium

Incentivised

Energy

Scalable

Security

AISC Resistant

RBFTSBFTYACPoET

Burrow

Chained

PoW




DPoSTendermint

CTFG Ouroboros

Low

PoRPoSVPoCPoI

Medium

Medium

Low

Medium







35




REFERENCES

































36























































37






































































38




















































39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

23



Chained(PeerCoin)



Chained(CFFG)



BFT(Tendermint)





BTFG(Ouroboros)

ClientsElectors amp

Stakeholders







Chained(PeerCoin)

X High 3f + 1

Chained(CFFG)

X High 3f + 1

BFT(Tendermint)


High 3f + 1


BFT(Ouroboros)

X High 2f + 1

DPoS X High 3f + 1

















24















25





















26




Minters







transactionpartners





PoR X High 3f + 1

PoB X High 3f + 1

PoSV X High 3f + 1

PoC High PoI X High




PoSV X X X X X X














NEM March 31st2015






27





















28


















75 Hyperledger Indy
















29




76 Analysis






(log log nlog n


nodes


8 DISCUSSION





30











Fabric Low 3f + 1

PoET Low Θ(

log log nlog n


YAC Low 3f + 1

RBFT Low 3f + 1









PoW 221 238 526 412DPoS 6 483 606 020PoS 6 287 224 485







31

PoW

58

DPoS

9

PoS

8

PoW+PoS

4


1


Tollerance (dBFT)

3


(PBFT)

2


1XRP Ledger

Protocol

1Stellar

Consens

us

Protocol

(SCP)

1

Tangle

1

VBFT

(verifiabl

e random

function)

1

Proof of authority

2


1

Other

1

POI

1


1

BFT

3


1

Other

10

PoW DPoS PoS













32

PoW

DPoS

dBFT

PoW + PoS02468

101214161820

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019



93

310

0

0

3

3






33

71

11

4 0

21

1114




9 CONCLUSION






34

Consensusalgorithm

Yes

High

Low

No

Low

Low

HighMedium

Medium

High

Yes No

Medium

Incentivised

Energy

Scalable

Security

AISC Resistant

RBFTSBFTYACPoET

Burrow

Chained

PoW




DPoSTendermint

CTFG Ouroboros

Low

PoRPoSVPoCPoI

Medium

Medium

Low

Medium







35




REFERENCES

































36























































37






































































38




















































39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

24















25





















26




Minters







transactionpartners





PoR X High 3f + 1

PoB X High 3f + 1

PoSV X High 3f + 1

PoC High PoI X High




PoSV X X X X X X














NEM March 31st2015






27





















28


















75 Hyperledger Indy
















29




76 Analysis






(log log nlog n


nodes


8 DISCUSSION





30











Fabric Low 3f + 1

PoET Low Θ(

log log nlog n


YAC Low 3f + 1

RBFT Low 3f + 1









PoW 221 238 526 412DPoS 6 483 606 020PoS 6 287 224 485







31

PoW

58

DPoS

9

PoS

8

PoW+PoS

4


1


Tollerance (dBFT)

3


(PBFT)

2


1XRP Ledger

Protocol

1Stellar

Consens

us

Protocol

(SCP)

1

Tangle

1

VBFT

(verifiabl

e random

function)

1

Proof of authority

2


1

Other

1

POI

1


1

BFT

3


1

Other

10

PoW DPoS PoS













32

PoW

DPoS

dBFT

PoW + PoS02468

101214161820

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019



93

310

0

0

3

3






33

71

11

4 0

21

1114




9 CONCLUSION






34

Consensusalgorithm

Yes

High

Low

No

Low

Low

HighMedium

Medium

High

Yes No

Medium

Incentivised

Energy

Scalable

Security

AISC Resistant

RBFTSBFTYACPoET

Burrow

Chained

PoW




DPoSTendermint

CTFG Ouroboros

Low

PoRPoSVPoCPoI

Medium

Medium

Low

Medium







35




REFERENCES

































36























































37






































































38




















































39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

25





















26




Minters







transactionpartners





PoR X High 3f + 1

PoB X High 3f + 1

PoSV X High 3f + 1

PoC High PoI X High




PoSV X X X X X X














NEM March 31st2015






27





















28


















75 Hyperledger Indy
















29




76 Analysis






(log log nlog n


nodes


8 DISCUSSION





30











Fabric Low 3f + 1

PoET Low Θ(

log log nlog n


YAC Low 3f + 1

RBFT Low 3f + 1









PoW 221 238 526 412DPoS 6 483 606 020PoS 6 287 224 485







31

PoW

58

DPoS

9

PoS

8

PoW+PoS

4


1


Tollerance (dBFT)

3


(PBFT)

2


1XRP Ledger

Protocol

1Stellar

Consens

us

Protocol

(SCP)

1

Tangle

1

VBFT

(verifiabl

e random

function)

1

Proof of authority

2


1

Other

1

POI

1


1

BFT

3


1

Other

10

PoW DPoS PoS













32

PoW

DPoS

dBFT

PoW + PoS02468

101214161820

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019



93

310

0

0

3

3






33

71

11

4 0

21

1114




9 CONCLUSION






34

Consensusalgorithm

Yes

High

Low

No

Low

Low

HighMedium

Medium

High

Yes No

Medium

Incentivised

Energy

Scalable

Security

AISC Resistant

RBFTSBFTYACPoET

Burrow

Chained

PoW




DPoSTendermint

CTFG Ouroboros

Low

PoRPoSVPoCPoI

Medium

Medium

Low

Medium







35




REFERENCES

































36























































37






































































38




















































39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

26




Minters







transactionpartners





PoR X High 3f + 1

PoB X High 3f + 1

PoSV X High 3f + 1

PoC High PoI X High




PoSV X X X X X X














NEM March 31st2015






27





















28


















75 Hyperledger Indy
















29




76 Analysis






(log log nlog n


nodes


8 DISCUSSION





30











Fabric Low 3f + 1

PoET Low Θ(

log log nlog n


YAC Low 3f + 1

RBFT Low 3f + 1









PoW 221 238 526 412DPoS 6 483 606 020PoS 6 287 224 485







31

PoW

58

DPoS

9

PoS

8

PoW+PoS

4


1


Tollerance (dBFT)

3


(PBFT)

2


1XRP Ledger

Protocol

1Stellar

Consens

us

Protocol

(SCP)

1

Tangle

1

VBFT

(verifiabl

e random

function)

1

Proof of authority

2


1

Other

1

POI

1


1

BFT

3


1

Other

10

PoW DPoS PoS













32

PoW

DPoS

dBFT

PoW + PoS02468

101214161820

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019



93

310

0

0

3

3






33

71

11

4 0

21

1114




9 CONCLUSION






34

Consensusalgorithm

Yes

High

Low

No

Low

Low

HighMedium

Medium

High

Yes No

Medium

Incentivised

Energy

Scalable

Security

AISC Resistant

RBFTSBFTYACPoET

Burrow

Chained

PoW




DPoSTendermint

CTFG Ouroboros

Low

PoRPoSVPoCPoI

Medium

Medium

Low

Medium







35




REFERENCES

































36























































37






































































38




















































39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

27





















28


















75 Hyperledger Indy
















29




76 Analysis






(log log nlog n


nodes


8 DISCUSSION





30











Fabric Low 3f + 1

PoET Low Θ(

log log nlog n


YAC Low 3f + 1

RBFT Low 3f + 1









PoW 221 238 526 412DPoS 6 483 606 020PoS 6 287 224 485







31

PoW

58

DPoS

9

PoS

8

PoW+PoS

4


1


Tollerance (dBFT)

3


(PBFT)

2


1XRP Ledger

Protocol

1Stellar

Consens

us

Protocol

(SCP)

1

Tangle

1

VBFT

(verifiabl

e random

function)

1

Proof of authority

2


1

Other

1

POI

1


1

BFT

3


1

Other

10

PoW DPoS PoS













32

PoW

DPoS

dBFT

PoW + PoS02468

101214161820

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019



93

310

0

0

3

3






33

71

11

4 0

21

1114




9 CONCLUSION






34

Consensusalgorithm

Yes

High

Low

No

Low

Low

HighMedium

Medium

High

Yes No

Medium

Incentivised

Energy

Scalable

Security

AISC Resistant

RBFTSBFTYACPoET

Burrow

Chained

PoW




DPoSTendermint

CTFG Ouroboros

Low

PoRPoSVPoCPoI

Medium

Medium

Low

Medium







35




REFERENCES

































36























































37






































































38




















































39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

28


















75 Hyperledger Indy
















29




76 Analysis






(log log nlog n


nodes


8 DISCUSSION





30











Fabric Low 3f + 1

PoET Low Θ(

log log nlog n


YAC Low 3f + 1

RBFT Low 3f + 1









PoW 221 238 526 412DPoS 6 483 606 020PoS 6 287 224 485







31

PoW

58

DPoS

9

PoS

8

PoW+PoS

4


1


Tollerance (dBFT)

3


(PBFT)

2


1XRP Ledger

Protocol

1Stellar

Consens

us

Protocol

(SCP)

1

Tangle

1

VBFT

(verifiabl

e random

function)

1

Proof of authority

2


1

Other

1

POI

1


1

BFT

3


1

Other

10

PoW DPoS PoS













32

PoW

DPoS

dBFT

PoW + PoS02468

101214161820

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019



93

310

0

0

3

3






33

71

11

4 0

21

1114




9 CONCLUSION






34

Consensusalgorithm

Yes

High

Low

No

Low

Low

HighMedium

Medium

High

Yes No

Medium

Incentivised

Energy

Scalable

Security

AISC Resistant

RBFTSBFTYACPoET

Burrow

Chained

PoW




DPoSTendermint

CTFG Ouroboros

Low

PoRPoSVPoCPoI

Medium

Medium

Low

Medium







35




REFERENCES

































36























































37






































































38




















































39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

29




76 Analysis






(log log nlog n


nodes


8 DISCUSSION





30











Fabric Low 3f + 1

PoET Low Θ(

log log nlog n


YAC Low 3f + 1

RBFT Low 3f + 1









PoW 221 238 526 412DPoS 6 483 606 020PoS 6 287 224 485







31

PoW

58

DPoS

9

PoS

8

PoW+PoS

4


1


Tollerance (dBFT)

3


(PBFT)

2


1XRP Ledger

Protocol

1Stellar

Consens

us

Protocol

(SCP)

1

Tangle

1

VBFT

(verifiabl

e random

function)

1

Proof of authority

2


1

Other

1

POI

1


1

BFT

3


1

Other

10

PoW DPoS PoS













32

PoW

DPoS

dBFT

PoW + PoS02468

101214161820

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019



93

310

0

0

3

3






33

71

11

4 0

21

1114




9 CONCLUSION






34

Consensusalgorithm

Yes

High

Low

No

Low

Low

HighMedium

Medium

High

Yes No

Medium

Incentivised

Energy

Scalable

Security

AISC Resistant

RBFTSBFTYACPoET

Burrow

Chained

PoW




DPoSTendermint

CTFG Ouroboros

Low

PoRPoSVPoCPoI

Medium

Medium

Low

Medium







35




REFERENCES

































36























































37






































































38




















































39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

30











Fabric Low 3f + 1

PoET Low Θ(

log log nlog n


YAC Low 3f + 1

RBFT Low 3f + 1









PoW 221 238 526 412DPoS 6 483 606 020PoS 6 287 224 485







31

PoW

58

DPoS

9

PoS

8

PoW+PoS

4


1


Tollerance (dBFT)

3


(PBFT)

2


1XRP Ledger

Protocol

1Stellar

Consens

us

Protocol

(SCP)

1

Tangle

1

VBFT

(verifiabl

e random

function)

1

Proof of authority

2


1

Other

1

POI

1


1

BFT

3


1

Other

10

PoW DPoS PoS













32

PoW

DPoS

dBFT

PoW + PoS02468

101214161820

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019



93

310

0

0

3

3






33

71

11

4 0

21

1114




9 CONCLUSION






34

Consensusalgorithm

Yes

High

Low

No

Low

Low

HighMedium

Medium

High

Yes No

Medium

Incentivised

Energy

Scalable

Security

AISC Resistant

RBFTSBFTYACPoET

Burrow

Chained

PoW




DPoSTendermint

CTFG Ouroboros

Low

PoRPoSVPoCPoI

Medium

Medium

Low

Medium







35




REFERENCES

































36























































37






































































38




















































39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

31

PoW

58

DPoS

9

PoS

8

PoW+PoS

4


1


Tollerance (dBFT)

3


(PBFT)

2


1XRP Ledger

Protocol

1Stellar

Consens

us

Protocol

(SCP)

1

Tangle

1

VBFT

(verifiabl

e random

function)

1

Proof of authority

2


1

Other

1

POI

1


1

BFT

3


1

Other

10

PoW DPoS PoS













32

PoW

DPoS

dBFT

PoW + PoS02468

101214161820

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019



93

310

0

0

3

3






33

71

11

4 0

21

1114




9 CONCLUSION






34

Consensusalgorithm

Yes

High

Low

No

Low

Low

HighMedium

Medium

High

Yes No

Medium

Incentivised

Energy

Scalable

Security

AISC Resistant

RBFTSBFTYACPoET

Burrow

Chained

PoW




DPoSTendermint

CTFG Ouroboros

Low

PoRPoSVPoCPoI

Medium

Medium

Low

Medium







35




REFERENCES

































36























































37






































































38




















































39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

32

PoW

DPoS

dBFT

PoW + PoS02468

101214161820

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019



93

310

0

0

3

3






33

71

11

4 0

21

1114




9 CONCLUSION






34

Consensusalgorithm

Yes

High

Low

No

Low

Low

HighMedium

Medium

High

Yes No

Medium

Incentivised

Energy

Scalable

Security

AISC Resistant

RBFTSBFTYACPoET

Burrow

Chained

PoW




DPoSTendermint

CTFG Ouroboros

Low

PoRPoSVPoCPoI

Medium

Medium

Low

Medium







35




REFERENCES

































36























































37






































































38




















































39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

33

71

11

4 0

21

1114




9 CONCLUSION






34

Consensusalgorithm

Yes

High

Low

No

Low

Low

HighMedium

Medium

High

Yes No

Medium

Incentivised

Energy

Scalable

Security

AISC Resistant

RBFTSBFTYACPoET

Burrow

Chained

PoW




DPoSTendermint

CTFG Ouroboros

Low

PoRPoSVPoCPoI

Medium

Medium

Low

Medium







35




REFERENCES

































36























































37






































































38




















































39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

34

Consensusalgorithm

Yes

High

Low

No

Low

Low

HighMedium

Medium

High

Yes No

Medium

Incentivised

Energy

Scalable

Security

AISC Resistant

RBFTSBFTYACPoET

Burrow

Chained

PoW




DPoSTendermint

CTFG Ouroboros

Low

PoRPoSVPoCPoI

Medium

Medium

Low

Medium







35




REFERENCES

































36























































37






































































38




















































39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

35




REFERENCES

































36























































37






































































38




















































39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

36























































37






































































38




















































39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

37






































































38




















































39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

38




















































39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

39


























1 Introduction



31 Bitcoin


33 Blockchain type












513 Chained PoW

514 PoW Limitations

515 Analysis

52 Proof of Stake

521 Chained PoS

522 BFT PoS

523 DPoS


525 Analysis


61 Hybrid Consensus

62 N-POSPOW

63 Analysis






75 Hyperledger Indy

76 Analysis

8 Discussion

9 Conclusion

References

Blockchain Consensus Algorithms: A Survey1 Blockchain Consensus Algorithms: A Survey Md Sadek...

Documents

Transcript of Blockchain Consensus Algorithms: A Survey1 Blockchain Consensus Algorithms: A Survey Md Sadek...