Blockchain Transaction Processing - ExpoLabBlockchain Transaction Processing 5 Blockchain Consensus The common denominator for all the blockchain applications is the underlying distributed

Blockchain Transaction Processing

Suyash Gupta, Mohammad Sadoghi

Synonyms

• Blockchain Data Management• Blockchain Consensus• Cryptocurrency

Definitions

A blockchain is a linked-list of im-mutable tamper-proof blocks, whichis stored at each participating node.Each block records a set of transac-tions and the associated metadata.Blockchain transactions act on theidentical ledger data stored at eachnode. Blockchain was first perceived bySatoshi Nakamoto (Satoshi 2008), as apeer-to-peer money exchange system.Nakamoto referred to the transactionaltokens exchanged among clients in hissystem, as Bitcoins.

Overview

In 2008, Satoshi Nakamoto (Satoshi2008) came up with the design of anunanticipated technology that revolu-tionized the research in the distributedsystems community. Nakamoto pre-sented the design of a peer-to-peermoney exchange process that wasshared, yet distributed. Nakamotonamed his transactional token as Bit-coin, and brought forth design of a newparadigm Blockchain.

The key element of any blockchainsystem is the existence of an immutabletamper-proof block. In its simplest forma block is an encrypted aggregation ofa set of transactions. The existence of ablock acts as a guarantee that the trans-actions have been executed, and verified.

A newly created block is appendedto an existing chain of blocks. Thischain of blocks is predominantly alinked list which associates one blockwith the other. The initial block of any

1

2 Suyash Gupta, Mohammad Sadoghi

Fig. 1: Basic Blockchain Representations

such list is a genesis block (Decker andWattenhofer 2013). Genesis block isa special block that is numbered zero,and is hard-coded in the blockchainapplication. Each other block links tosome previously existing block. Hence,a blockchain grows by appending newblocks to the existing chain.

A transaction in a blockchain systemis identical to any distributed or OLTPtransaction (TPP Council 2010) that actson some data. Traditional blockchainapplications (such as Bitcoin) consistof transactions that represent an ex-change of money between two entities(or users). Each valid transaction isrecorded in a block, which can can con-tain multiple transactions, for efficiency.Immutability is achieved by leveragingstrong cryptographic properties suchas hashing (Katz and Lindell 2007).Figure 1 presents the structure of asimple blockchain.

A blockchain is a linked-list in atrue sense, as each block stores thehash of the previous block in its chain.Each block also digitally signs itscontents by storing the hash of itscontents inside the block. These hashesprovide cryptographic integrity, as anyadversary intending to modify a blockneeds to also modify all the previousblocks in a chain, which makes theattack cryptographically infeasible. Akey design strategy is to construct aMerkle tree (Katz and Lindell 2007) toefficiently store and verify the hashes.Thus, each block only stores the root of

the Merkle tree, as given the root, it iseasy to verify the immutability.

The preceding discussion allows usto summarize that a blockchain aims atsecurely storing a set of transactions.In the succeeding sections, we discussin detail the transaction processing in ablockchain system. We also study mech-anisms to validate these transactions andanalyze some blockchain applicationsthat employ the same.

Key Research Findings

Transactions in a blockchain system areidentical to their traditional databasecounterparts. These transactions areissued by the clients to the servers of theblockchain system (Nawab 2018). Thesetransactions act on the data stored on allthe participating servers. In its vanillaform, a blockchain transaction couldbe visualized as a set of read / writeoperations performed on each nodeof a replicated distributed database.To determine an ordering for all theincoming transactions each blockchainapplication employs a consensus (Steenand Tanenbaum 2017) protocol.

A distributed consensus algo-rithm (Lamport 1998; Gray andLamport 2006) allows a system to reacha common decision, respected by themajority of nodes. Recent blockchaintechnologies present several strategiesfor establishing consensus: Proof-of-Work (Jakobsson and Juels 1999;Satoshi 2008), Proof-of-Stake (King andNadal 2012), Proof-of-Authority (Par-ity Technologies 2018), PracticalByzantine Fault Tolerance (Castro andLiskov 1999; Cachin 2016) and so on.To quantify the allowed set of nodes

Blockchain Transaction Processing 3

Fig. 2: Blockchain Flow: Three main phases in any blockchain application are represented. (a)Client sends a transaction to one of the server, which it disseminates to all the other servers. (b)Servers run the underlying consensus protocol, to determine the block creator. (c) New block iscreated, and transmitted to each node, which also implies adding to global ledger.

that can create a block (or participatein the consensus process), it is alsonecessary to characterize the topologiesfor blockchain systems.

Blockchain Execution

Figure 2 illustrates the three main phasesrequired by any blockchain applicationto create a new block. The client trans-mits a transactional request to one ofthe servers. This server multicasts therequest to all other servers. We term thisphase as Transaction Dissemination.Once, all the servers have a copy ofclient request, they initiate a consensusprotocol. The choice of underlyingconsensus protocol affects the timecomplexity and resource consumption.The winner of the consensus phase,generates the next block, and transmitsit to all other servers. This transmissionprocess is equivalent to adding an entry(block) to the global distributed ledger.

Blockchain Topologies

A key parameter that renders the designof a blockchain application is the cat-egorization of nodes to be part of theapplication. Recent works (Pilkington2015; Cachin and Vukolic 2017) cat-egorize blockchain systems as eitherpublic, private or permissioned andhybrid. Although, the characteristicsof a public blockchain is clearly statedin the community, but there is not acommon consensus on the terminologypertaining to the other terms.

We categorize blockchain systemsunder four heads: public, private, per-missioned and hybrid. Figure 3 presentsa pictorial representation of the differentcategories. In these figures nodes thatare not allowed to participate in theactivities pertaining to the network,lack connections to any node in thenetwork. We use different circles todemarcate different zones of operation;certain nodes are allowed to lead (orcreate the block), and some are al-lowed to participate in the consensusprotocol. Public Blockchain systemssuch as Bitcoin (Satoshi 2008) and

4 Suyash Gupta, Mohammad Sadoghi

(a) Public Blockchain. (b) Hybrid Blockchain.

(c) Permissioned Blockchain. (d) Private Blockchain.

Fig. 3: Topologies for Blockchain Systems.

Ethereum (Wood 2015) allow any nodeto participate in the consensus process,and any node can generate the nextvalid block. Hence, if all the nodes havesame resources, then each node hasequal probability of creating a block1.Private Blockchain systems are at theother end of the spectrum, as theyallow only some nodes to be part of theconsensus process, and only a subsetof these nodes can generate the nextblock. These systems could be utilizedat a banking organization which onlyallows its customers to participate inthe consensus, while its employees areonly permitted to commit the results bycreating a block.

1 We are assuming fair and ideal conditions,where each node works independently

Hybrid Blockchain systems attaina middle ground between the twoextremes. These systems allow any nodeto be part of the consensus process, butonly some designated nodes are allowedto form the next block. CryptocurrencyRipple (Schwartz et al 2014) supports avariant of the hybrid model, where somepublic institutions can act as transactionvalidators. Permissioned Blockchainsystems are the restricted variant of pub-lic blockchain systems. These systemsenlist few nodes as the members withequal rights, that is each node part of thesystem can form a block. These systemsallow us to represent internal working ofany organization, social media groupsand an early stage startup.

Blockchain Transaction Processing 5

Blockchain Consensus

The common denominator for allthe blockchain applications is theunderlying distributed consensusalgorithm. Nakamoto suggested Proof-of-work (Satoshi 2008) (henceforthreferred as PoW) for achieving con-sensus among the participating nodes.PoW requires each node to demonstrateits ability to solve a non-trivial task.The participating nodes compete amongthemselves to solve a complex puzzle(such as computation of a 256-bit SHAvalue). The node which computes thesolution gets the opportunity to generatethe next block. It also disseminates theblock to all the nodes, which marksas the proof that it performed somenon-trivial computation. Hence, allother nodes respect the winner’s ability,and reach the consensus by continuingto chain ahead of this block.

In PoW the accessibility to largercomputational resources determines thewinner node(s). However, it is possiblethat multiple nodes could lay claim forthe next block to be added to the chain.Based on the dissemination of the newblock, this could lead to branching outof the single chain. Interestingly, thesebranches are often short lived, as all thenodes tend to align themselves to thelongest chain, which in turn leads topruning of the branches. It is importantto understand that a node receivesincentive when it is able to append ablock to the longest chain. Hence, it isto their advantage to always align withthe longest chain, otherwise they wouldend up spending their computationalresources for zero gains. Note: PoWalgorithm can theoretically be compro-mised by an adversary controlling atleast 51% of computational resources in

the network. This theoretical possibilityhas practical implications as a group ofminers can share resources to generateblocks faster, skewing the decentralizednature of the network.

Proof-of-stake (King and Nadal2012) (henceforth referred at PoS), aimsat preserving the decentralized natureof the blockchain network. In PoSalgorithm a node with n% resources getsn% time opportunity to create a block.Hence, the underlying principle in PoSis that the node with higher stake laysclaim to generation of the next block. Todetermine a node’s stake, a combinationof one or more factors such as wealth,resources and so on, could be utilized.PoS algorithm requires a set of nodes toact as validators. Any node that wantsto act as a validator needs to lockout itsresources, as a proof of its stake.

PoS only permits a validator to createnew blocks. To create a new block, a setof validators participate in the consensusalgorithm. PoS consensus algorithm hastwo variants: (i) chain-based and (ii)BFT-style. Chain-based PoS algorithmuses a psuedo-random algorithm to se-lect a validator, which then creates a newblock and adds it to the existing chainof blocks. The frequency of selectingthe validator is set to some pre-definedtime interval. BFT-style algorithm runsa byzantine fault tolerance algorithmto select the next valid block. Here,validators are given right to proposethe next block, at random. Another keydifference between these algorithmsis the synchrony requirement; chain-based PoS algorithms are inherentlysynchronous, while BFT-style PoS ispartially synchronous.

Early implementations of PoS suchas Peercoin (King and Nadal 2012) suf-fer from non-convergence, that is lack of

6 Suyash Gupta, Mohammad Sadoghi

single chain (also referred as “nothing-at-stake” attack). Such a situation hap-pens when the longest chain branchesinto multiple forks. Intuitively, the nodesshould aim at converging the branchesinto the single longest chain. However,if the participating nodes are incentivedriven then they could create blocks inboth the chains, to maximize their gains.Such an attack is not possible on PoW asit would require a node to have doublethe number of computational resources,but as PoS does not require solving acomplex problem, nodes can easily cre-ate multiple blocks.

Proof-of-Authority (Parity Tech-nologies 2018) (henceforth referred asPoA) is designed to be used alongsidenon-public blockchain systems. The keyidea is to designate a set of nodes asthe authority. These nodes are entrustedwith the task of creating new blocks andvalidating the transactions. PoA marksa block as part of the blockchain if itis signed by majority of the authorizednodes. The incentive model in PoAhighlights that it is in the interest of anauthority node to maintain its reputation,to receive periodic incentives. Hence,PoA does not select nodes based ontheir claimed stakes.

Proof-of-Space (Ateniese et al2014; Dziembowski et al 2015) alsoknow as proof-of-capacity (henceforthreferred as PoC) is an consensus algo-rithm orthogonal to PoW. It expectsnodes to provide a proof that theyhave sufficient “storage” to solve acomputational problem. PoC algorithmtargets computational problems such ashard-to-pebble graphs (Dziembowskiet al 2015) that need large amount ofmemory storage to solve the problem.In the PoC algorithm, the verifier firstexpects a prover to commit to a labeling

of the graph, and then he queries proverfor random locations in the committedgraph. The key intuition behind thisapproach is that unless the prover hassufficient storage, he would not pass theverification. PoC based cryptocurrencysuch as SpaceMint (Park et al 2015)claims PoC based approaches moreresource efficient to PoW as storageconsumes less energy.

A decade prior to the first blockchainapplication, distributed consensusproblem had excited the researchers.Paxos (Lamport 1998) and View-stamped Replication (Oki and Liskov1988) presented key solutions to dis-tributed consensus when the nodefailures were restricted to fail-stop.Castro and Liskov (1999) presentedtheir novel Practical Byzantine FaultTolerance (henceforth referred as PBFT)consensus algorithm to handle byzantinefailures. Interestingly, all of previouslydiscussed consensus algorithms providesimilar guarantees as PBFT. Garayet al (2015) helped in establishing anequivalence between the PoW andgeneral consensus algorithms. Thisequivalence motivated the communityto design efficient alternatives to PoW.

PBFT runs a three phase protocol toreach a consensus among all the non-byzantine nodes. PBFT requires a boundon the number of byzantine nodes. If “n”represents the total number of nodes inthe system, then PBFT bounds the num-ber of byzantine nodes “ f ” as follows:f ≤

⌊ n+13

⌋, PBFT based algorithms have

an advantage of reduced resource con-sumption, but suffer from large messagecomplexity (order O(n2)). Hence, thesealgorithms are preferred for restricted orsmall blockchain systems, in order tohave less message overhead.

Blockchain Transaction Processing 7

The algorithm starts with a clientsending a request to the primary node.The primary node verifies the request,assigns a sequence number, and sendsa pre-prepare message to all the repli-cas. Each pre-prepare message alsocontains the client’s request and thecurrent view number. When a replicareceives a pre-prepare message, it firstverifies the request, and then transmitsa prepare message to all the nodes. Theprepare message contains the digest ofclient request, sequence number andview number. Once a node receives2 f prepare messages, matching to thepre-prepare message, it multicasts acommit message. The commit messagealso contains the digest of client request,sequence number and view number.Each replica waits for receiving iden-tical 2 f + 1 commit messages, beforeexecuting the request, and then transmitsthe solution to the client.

The client needs f + 1 matchingresponses from different replicas, tomark the request as complete. If theclient timeouts while waiting for f + 1responses, then it multicasts the requestto all the replicas. Each replica onreceiving a request from the client,which it has not executed, starts atimer, and queries the primary. If theprimary does not reply until timeoutthen the replicas proceed to change theprimary. Note: PBFT heavily relies onstrong cryptographic guarantees, andeach message is digitally signed by thesender using his private key.

Zyzzyva (Kotla et al 2007) is anotherinteresting byzantine fault toleranceprotocol aimed at reducing the costsassociated with BFT-style protocols.Zyzzyva (Kotla et al 2007) allows thereplicas to reach early consensus bypermitting speculative execution. In

Zyzzyva, the replicas are relived fromthe task of ensuring a global order forthe client requests. This task is delegatedto the client, which in turn informs thereplicas if they are not in sync.

The protocol initiates with a clientsending a request to the primary, whichin turn sends a pre-prepare messageto all the replicas. The structure of theprepare message is similar to its PBFTcounterpart except that it includes adigest summarizing the history. Eachreplica on receiving a request fromthe primary, executes the request andtransmits the response to the client.Each response, in addition to the fieldsin the pre-prepare message, containsthe digest of history and a signed copyof message from primary. If the clientreceives 3 f + 1 matching responses,then it assumes the response is stableand considers the request completed. Incase the number of matching responsesreceived by the client are in the range2 f + 1 and 3 f , then it creates a commitcertificate and transmits this certificateto all the nodes. The commit certificateincludes the history which proves toa receiving replica that it can safelycommit the history and start process-ing the next request. All the replicasacknowledge the client for the commitcertificate. If the client receives less than2 f + 1 responses, then it starts a timerand informs all the replicas again aboutthe impending request. Now, either therequest would be safely completed, ornew primary would be elected.

Although Zyzzyva achieves higherthroughput than PBFT, its client-basedspeculative execution is far from ideal.Zyzzyva places a lot of faith on thecorrectness of the client, which is quitediscomforting, as a malicious client canprevent the replicas from maintaining

8 Suyash Gupta, Mohammad Sadoghi

linearizability. Aardvark (Clementet al 2009) studies the ill-effects ofvarious fast, byzantine fault tolerantprotocols and presents the design of arobust BFT protocol. In Aadvark, themessages are signed by the client usingboth digital signatures and messageauthentication codes (Katz and Lindell2007). This prevents malicious clientsfrom performing a denial-of-serviceattack, as it is costly for client to signeach message two times. Aadvarkuses point-to-point communication,instead of multicast communication.The key intuition behind such a choiceis to disallow a faulty client of replicafrom blocking the complete network.Aadvark also periodically changes theprimary replica. Each replica tracks thethroughput of the current primary andsuggest replacing the primary, whenthere is a decrease in its throughput. Theauthors use a simple timer to track therate of primary response.

RBFT (Aublin et al 2013) is a simpleextension to Aardvark. RBFT aims atdetecting smartly malicious primaryreplica, which could avoid being de-tected malicious by other replicas. Thekey intuition behind RBFT is to preventprimary from insinuating delays that arewithin the stated threshold. Hence, theprimary could reduce the throughputwithout being ever replaced. To tacklethis problem, RBFT insists runningf + 1 independent instances of theAardvark protocol on each node. One ofthe instance is designated as the “masterinstance”, and it executes the requests.Rest of the instances are labeled as the“backup instances”, and they order therequests and monitor the performanceof the master instance. If any backupinstance observes a degradation of theperformance of the master instance, then

it transmits a message to elect a newprimary. Note: RBFT does not allowmore than one primary on any node.Hence, each node can have at most oneprimary instance. RBFT protocol hasan additional step in comparison to thethree phases in PBFT and Aardvark.The client node initiates the protocol bytransmitting a request to all the nodes.Next, each node propagates this requestto all other nodes and then the threephase protocol begins. This extra roundof redundancy ensures that the clientrequest reaches all the instances.

Blockchain Systems

Bitcoin (Satoshi 2008) is regardedas the first blockchain application. Itis a cryptographically secure digitalcurrency with the aim of disrupting thetraditional, institutionalized monetaryexchange. Bitcoin acts as the token oftransfer between two parties undergoinga monetary transaction. The underlyingblockchain system is a network ofnodes (also known as miners) thattake a set of client transactions andvalidate the same by demonstratinga proof-of-work, that is generating ablock. The process of generating thenext block is non-trivial and requireslarge computational resources. Hence,the miners are given incentives (such asBitcoins) for dedicating their resourcesand generating the block. Each minermaintains locally an updated copy of thecomplete blockchain and the associatedledgers for every Bitcoin user.

To ensure Bitcoin system remainsfair towards all the machines, thedifficulty of proof-of-work challengeis periodically increased. We also

Blockchain Transaction Processing 9

know that Bitcoin is vulnerable to51% attack, which can lead to doublespending (Rosenfeld 2014). The in-tensity of such attacks increases whenmultiple forks of the longest chain arecreated. To avoid these attacks, Bitcoindevelopers suggest the clients to waitfor their block to be confirmed beforethey mark the Bitcoins as transferred.This wait ensures that the specific blockis a little deep (nearly six blocks) in thelongest chain (Rosenfeld 2014). Bitcoincritics also argue that its proof-of-workconsumes huge energy 2 and may not bea viable solution for future.

Bitcoin-NG (Eyal et al 2016) is ascalable variant to Bitcoin’s protocol.Our preceding discussion highlightsthat Bitcoin suffers from throughputdegradation. This can be reduced byeither increasing the block size ordecreasing the block interval. However,increasing the former increases thepropagation delays and latter can leadto incorrect consensus. Bitcoin-NGsolves this problem by dividing thetime into a set of intervals and selectingone leader for each time interval. Theselected leader autonomously orders thetransactions. Bitcoin-NG also uses twodifferent block structures: key-blocksfor facilitating leader election andmicroblocks for maintaining the ledger.

Ethereum (Wood 2015) isblockchain framework that permitsusers to create their own applicationson top of the Ethereum Virtual Machine(EVM). Ethereum utilizes the notion ofsmart contracts to facilitate developmentof new operations. It also supports adigital cryptocurrency, ether, which isused to incentivize the developers to

2 As per some claims one Bitcoin transactionconsumes power equivalent to that required by1.5 American homes per day.

create correct applications. One of thekey advantage of Ethereum is that itsupports a Turing complete languageto generate new applications on top ofEVM. Initially, Ethereum’s consensusalgorithm used the key elements of bothPoW and PoC algorithms. Ethereummade nodes solve challenges that werenot only computational intensive, butalso memory intensive. This designprevented existence of miners whoutilized specially designed hardware forcompute intensive applications.

Recently, Ethereum modified its con-sensus protocol to include some notionsof PoS algorithm. The modified proto-col is referred as Casper (Buterin andGriffith 2017). Casper introduces the no-tion of finality, that is it ensures thatone chain becomes permanent in time.It also introduces the notion of account-ability that is penalize a validator, whoperforms the “nothing-at-stake” attack inPoS based systems. The penalty lever-aged on such a validator is equivalent tonegating all his stakes.

Parity (Parity Technologies 2018)is an application designed on top ofEthereum. It provides an interface forits users to interact with the Ethereumblockchain. Parity can be regardedas an interesting application for theblockchain community, as it providessupport for both Proof-of-Work andProof-of-Authority consensus algo-rithms. Hence, they allow mechanismfor users of their application to setup“authority” nodes, and resort to non-compute intensive, POA algorithm.

Ripple (Schwartz et al 2014) isconsidered as third largest cryptocur-rency after Bitcoin and Ethereum, interms of market cap. It uses a consensusalgorithm which is a simple variantof BFT algorithms. Ripple requires

10 Suyash Gupta, Mohammad Sadoghi

number of failures f to be boundedas follows: ≤ (n − 1)/5 + 1, where nrepresents the total number of nodes.Ripple’s consensus algorithm introducesthe notion of a Unified Node List (UNL),which is a subset of the network. Eachserver communicates with the nodesin its UNL for reaching a consensus.The servers exchange the set of trans-actions they received from the clientsand propose those transactions to theirrespective UNL for vote. If a transactionreceives 80% of the votes, it is markedpermanent. It is important to understandthat if the generated UNL groups are aclique then forks of the longest chaincould co-exist. Hence, UNLs are createdin a manner that they share some set ofnodes. Another noteworthy observationabout Ripple protocol is that each clientneeds to select a set of validators orunique nodes that they trust. Thesevalidators next utilize ripple consensusalgorithm to verify the transactions.

Hyperledger (Cachin 2016) is asuite of resources aimed at modelingindustry standard blockchain applica-tions. It provides a series of ApplicationProgramming Interfaces (APIs) for de-velopers to create their own non-publicblockchain applications. Hyperledgerprovides implementations of blockchainsystems that uses RBFT and other vari-ants of the PBFT consensus algorithm.It also facilitates use and developmentof smart contracts. It is important tounderstand that the design philosophy ofHyperledger leans towards blockchainapplications that require existence ofnon-public networks, and so, they donot need a compute intensive consensus.

ExpoDB (Sadoghi 2017; Guptaand Sadoghi 2018) is an experimentalresearch platform that facilitates designand testing of emerging database tech-

nologies. ExpoDB consists of a set offive layers providing distinct functional-ities (refer Figure 4). Application Layeracts as the testbed for evaluating theunderlying database protocols (Guptaand Sadoghi 2018). It allows the systemto access OLTP benchmarks such asYCSB Cooper et al (2010), TPC-C TPP Council (2010) and PPS Hardinget al (2017). Application layer actsas an interface for the client-serverinteraction. Transport Layer allowscommunication of messages betweenthe client and server nodes.

Execution Layer facilitates seamlessexecution of a transaction with help ofa set of threads. These threads lie at thecore of execution layer as they run thetransaction, abide by the rules of statedconcurrency protocol and achieve agree-ment among different transactional par-titions. ExpoDB provides implementa-tion for eight concurrency control andthree commit protocols. ExpoDB alsocharacterizes a storage layer (Sadoghiet al 2018) for storing the transactionaldata, messages and relevant metadata,

ExpoDB extends blockchain func-tionality to the traditional distributedsystems through a secure layer. Tofacilitate secure transactions ExpoDBprovides a cryptographic variant toYCSB – Secure YCSB benchmark.ExpoDB also contains implementationsfor a variety of consensus protocols suchas PoW, PBFT, RBFT and Bitcoin-NG.

Future Directions for Research

Although blockchain technology is justa decade old, it gained majority of itsmomentum in the last five years. Thisallows us to render different elements

Blockchain Transaction Processing 11

Fig. 4: Architecture of ExpoDB.

of the blockchain systems and achievehigher performance and throughput.Some of the plausible directions todevelop efficient blockchain systemsare: (i) reducing the communicationmessages, (ii) defining efficient blockstructure, (iii) improving the consensusalgorithm, and (iv) designing securelight-weight cryptographic functions

Statistical and machine learningapproaches have presented interestingsolutions to automate key processessuch as Face Recognition (Zhao et al2003), Image classification (Krizhevskyet al 2012), Speech Recognition (Graveset al 2013) and so on. The tools can beleveraged to facilitate easy and efficientconsensus. The intuition behind thisapproach is to allow learning algorithmsto select nodes, which are fit to act asa block creator and prune the rest fromthe list of possible creators. The keyobservation behind such a design is thatthe nodes selected by the algorithm arepredicted to be non-malicious. Machine

learning techniques can play an impor-tant role in eliminating the human biasand inexperience. To learn which nodescan act as block creators, a feature set,representative of the nodes, needs to bedefined. Some interesting features canbe: geographical distance, cost of com-munication, available computationalresources, available memory storageand so on. These features would help ingenerating the dataset that would helpto train and test the underlying machinelearning model. This model would beran against new nodes that wish to jointhe associated blockchain application.

The programming languages andsoftware engineering communities havedeveloped several works that providesemantic guarantees to a language or anapplication (Wilcox et al 2015; Leroy2009; Kumar et al 2014). These workshave tried to formally verify (Keller1976; Leroy 2009) the system using theprinciples of programming languagesand techniques such as finite state

12 Suyash Gupta, Mohammad Sadoghi

automata, temporal logic and modelchecking (Grumberg and Long 1994;Baier and Katoen 2008). We believesimilar analysis can be performed in thecontext of blockchain applications. The-orem provers (such as Z3 (De Mouraand Bjørner 2008)) and proof assis-tants (such as COQ (Bertot 2006))could prove useful to define a certifiedblockchain application. A certifiedblockchain application can help in stat-ing theoretical bounds on the resourcesrequired to generate a block. Similarly,some of the blockchain consensus hasbeen shown to suffer from Denial of Ser-vice attacks (Bonneau et al 2015), and aformally verified blockchain applicationcan help realize such guarantees, if theunderlying application provides such aclaim.

References

Ateniese G, Bonacina I, Faonio A, Galesi N(2014) Proofs of space: When space is of theessence. In: Abdalla M, De Prisco R (eds)Security and Cryptography for Networks,Springer International Publishing, pp 538–557

Aublin PL, Mokhtar SB, Quema V (2013)RBFT: Redundant Byzantine Fault Toler-ance. In: Proceedings of the 2013 IEEE 33rdInternational Conference on DistributedComputing Systems, IEEE Computer Soci-ety, ICDCS ’13, pp 297–306

Baier C, Katoen JP (2008) Principles of ModelChecking (Representation and Mind Series).The MIT Press

Bertot Y (2006) Coq in a Hurry. CoRRabs/cs/0603118, URL http://arxiv.org/abs/cs/0603118, cs/0603118

Bonneau J, Miller A, Clark J, Narayanan A,Kroll JA, Felten EW (2015) SoK: ResearchPerspectives and Challenges for Bitcoin andCryptocurrencies. In: Proceedings of the2015 IEEE Symposium on Security and Pri-

vacy, IEEE Computer Society, Washington,DC, USA, SP ’15, pp 104–121

Buterin V, Griffith V (2017) Casper the FriendlyFinality Gadget. CoRR abs/1710.09437,URL http://arxiv.org/abs/1710.09437, 1710.09437

Cachin C (2016) Architecture of the Hyper-ledger blockchain fabric. In: Workshop onDistributed Cryptocurrencies and Consen-sus Ledgers, DCCL 2016

Cachin C, Vukolic M (2017) BlockchainConsensus Protocols in the Wild. CoRRabs/1707.01873

Castro M, Liskov B (1999) Practical byzantinefault tolerance. In: Proceedings of the ThirdSymposium on Operating Systems Designand Implementation, USENIX Association,Berkeley, CA, USA, OSDI ’99, pp 173–186

Clement A, Wong E, Alvisi L, Dahlin M,Marchetti M (2009) Making ByzantineFault Tolerant Systems Tolerate ByzantineFaults. In: Proceedings of the 6th USENIXSymposium on Networked Systems Designand Implementation, USENIX Association,Berkeley, CA, USA, NSDI’09, pp 153–168

Cooper BF, Silberstein A, Tam E, Ramakrish-nan R, Sears R (2010) Benchmarking CloudServing Systems with YCSB. In: Proceed-ings of the 1st ACM Symposium on CloudComputing, ACM, pp 143–154

De Moura L, Bjørner N (2008) Z3: An Effi-cient SMT Solver, Springer Berlin Heidel-berg, Berlin, Heidelberg, pp 337–340

Decker C, Wattenhofer R (2013) InformationPropagation in the Bitcoin Network. In: 13thIEEE International Conference on Peer-to-Peer Computing (P2P), Trento, Italy

Dziembowski S, Faust S, Kolmogorov V,Pietrzak K (2015) Proofs of space. In:Gennaro R, Robshaw M (eds) Advancesin Cryptology – CRYPTO 2015, SpringerBerlin Heidelberg, pp 585–605

Eyal I, Gencer AE, Sirer EG, Van Renesse R(2016) Bitcoin-NG: A Scalable BlockchainProtocol. In: Proceedings of the 13th UsenixConference on Networked Systems Designand Implementation, USENIX Association,Berkeley, CA, USA, NSDI’16, pp 45–59

Garay J, Kiayias A, Leonardos N (2015) TheBitcoin Backbone Protocol: Analysis andApplications, Springer Berlin Heidelberg,Berlin, Heidelberg, pp 281–310

Graves A, Mohamed A, Hinton GE(2013) Speech Recognition with

Blockchain Transaction Processing 13

Deep Recurrent Neural Networks.CoRR abs/1303.5778, URL http://arxiv.org/abs/1303.5778,1303.5778

Gray J, Lamport L (2006) Consensus on Trans-action Commit. ACM TODS 31(1):133–160

Grumberg O, Long DE (1994) Model Checkingand Modular Verification. ACM Trans Pro-gram Lang Syst 16(3):843–871

Gupta S, Sadoghi M (2018) EasyCommit: ANon-blocking Two-phase Commit Protocol.In: Proceedings of the 21st InternationalConference on Extending Database Tech-nology, Open Proceedings, EDBT

Harding R, Van Aken D, Pavlo A, Stone-braker M (2017) An Evaluation of Dis-tributed Concurrency Control. Proc VLDBEndow 10(5):553–564

Jakobsson M, Juels A (1999) Proofs of Workand Bread Pudding Protocols. In: Proceed-ings of the IFIP TC6/TC11 Joint Work-ing Conference on Secure Information Net-works: Communications and MultimediaSecurity, Kluwer, B.V., CMS ’99, pp 258–272

Katz J, Lindell Y (2007) Introduction to Mod-ern Cryptography. Chapman & Hall/CRC

Keller RM (1976) Formal verification of par-allel programs. Commun ACM 19(7):371–384

King S, Nadal S (2012) PPCoin: Peer-to-PeerCrypto-Currency with Proof-of-Stake

Kotla R, Alvisi L, Dahlin M, Clement A, WongE (2007) Zyzzyva: Speculative ByzantineFault Tolerance. In: Proceedings of Twenty-first ACM SIGOPS Symposium on Operat-ing Systems Principles, ACM, New York,NY, USA, SOSP ’07, pp 45–58, DOI 10.1145/1294261.1294267

Krizhevsky A, Sutskever I, Hinton GE (2012)Imagenet classification with deep convolu-tional neural networks. In: Proceedings ofthe 25th International Conference on NeuralInformation Processing Systems - Volume 1,Curran Associates Inc., NIPS’12, pp 1097–1105

Kumar R, Myreen MO, Norrish M, Owens S(2014) CakeML: A Verified Implementationof ML. In: Proceedings of the 41st ACMSIGPLAN-SIGACT Symposium on Prin-ciples of Programming Languages, ACM,New York, NY, USA, POPL ’14, pp 179–191

Lamport L (1998) The Part-time Parliament.ACM Trans Comput Syst 16(2):133–169

Leroy X (2009) A Formally Verified CompilerBack-end. J Autom Reason 43(4):363–446

Nawab F (2018) Geo-Scale Transaction Pro-cessing, Springer International Publishing,pp 1–7. DOI 10.1007/978-3-319-63962-8180-1, URL https://doi.org/10.1007/978-3-319-63962-8_180-1

Oki BM, Liskov BH (1988) ViewstampedReplication: A New Primary Copy Methodto Support Highly-Available DistributedSystems. In: Proceedings of the Seventh An-nual ACM Symposium on Principles of Dis-tributed Computing, ACM, New York, NY,USA, PODC ’88, pp 8–17

Parity Technologies (2018) ParityEthereum Blockchain. URL https://www.parity.io/

Park S, Kwon A, Fuchsbauer G, Gai P, Alwen J,Pietrzak K (2015) SpaceMint: A Cryptocur-rency Based on Proofs of Space. https://eprint.iacr.org/2015/528

Pilkington M (2015) Blockchain Technol-ogy: Principles and Applications. In: Re-search Handbook on Digital Transforma-tions, SSRN

Rosenfeld M (2014) Analysis of hashrate-baseddouble spending. CoRR abs/1402.2009,URL http://arxiv.org/abs/1402.2009, 1402.2009

Sadoghi M (2017) Expodb: An exploratory datascience platform. In: Proceedings of theEighth Biennial Conference on InnovativeData Systems Research, CIDR

Sadoghi M, Bhattacherjee S, Bhattacharjee B,Canim M (2018) L-Store: A Real-timeOLTP and OLAP System. OpenProceed-ing.org, EDBT

Satoshi N (2008) Bitcoin: A peer-to-peerelectronic cash system. URL http://bitcoin.org/bitcoin.pdf

Schwartz D, Youngs N, Britto A (2014) TheRipple Protocol Consensus Algorithm. URLhttps://www.ripple.com/

Steen Mv, Tanenbaum AS (2017) DistributedSystems

TPP Council (2010) TPC Benchmark C (Revi-sion 5.11)

Wilcox JR, Woos D, Panchekha P, Tatlock Z,Wang X, Ernst MD, Anderson T (2015)Verdi: A Framework for Implementing andFormally Verifying Distributed Systems. In:Proceedings of the 36th ACM SIGPLAN

14 Suyash Gupta, Mohammad Sadoghi

Conference on Programming Language De-sign and Implementation, ACM, New York,NY, USA, PLDI ’15, pp 357–368

Wood G (2015) Ethereum: A secure decen-tralised generalised transaction ledger. URLhttp://gavwood.com/paper.pdf

Zhao W, Chellappa R, Phillips PJ, RosenfeldA (2003) Face Recognition: A LiteratureSurvey. ACM Comput Surv 35(4):399–458,DOI 10.1145/954339.954342