Blockchain Transaction Processing

Suyash Gupta, Mohammad Sadoghi

Synonyms Overview

• Blockchain Data Management In 2008, Satoshi Nakamoto (Satoshi • Blockchain Consensus 2008) came up with the design of an • Cryptocurrency unanticipated technology that revolu- tionized the research in the distributed systems community. Nakamoto presented the design of a peer-to-peer Definitions money exchange process that was shared, yet distributed. Nakamoto A blockchain is a linked-list of im- named his transactional token as Bit- mutable tamper-proof blocks, which coin, and brought forth design of a new is stored at each participating node. paradigm Blockchain. Each block records a set of transac- The key element of any blockchain tions and the associated metadata. system is the existence of an immutable Blockchain transactions act on the tamper-proof block. In its simplest form identical ledger data stored at each a block is an encrypted aggregation of node. Blockchain was first perceived by a set of transactions. The existence of a Satoshi Nakamoto (Satoshi 2008), as a block acts as a guarantee that the trans- peer-to-peer money exchange system. actions have been executed, and verified. Nakamoto referred to the transactional A newly created block is appended tokens exchanged among clients in his to an existing chain of blocks. This system, as Bitcoins. chain of blocks is predominantly a linked list which associates one block with the other. The initial block of any

1 2 Suyash Gupta, Mohammad Sadoghi

the Merkle tree, as given the root, it is easy to verify the immutability. The preceding discussion allows us to summarize that a blockchain aims at Fig. 1: Basic Blockchain Representations securely storing a set of transactions. In the succeeding sections, we discuss in detail the transaction processing in a such list is a genesis block (Decker and blockchain system. We also study mech- Wattenhofer 2013). Genesis block is anisms to validate these transactions and a special block that is numbered zero, analyze some blockchain applications and is hard-coded in the blockchain that employ the same. application. Each other block links to some previously existing block. Hence, a blockchain grows by appending new blocks to the existing chain. Key Research Findings A transaction in a blockchain system is identical to any distributed or OLTP Transactions in a blockchain system are transaction (TPP Council 2010) that acts identical to their traditional database on some data. Traditional blockchain counterparts. These transactions are applications (such as Bitcoin) consist issued by the clients to the servers of the of transactions that represent an ex- blockchain system (Nawab 2018). These change of money between two entities transactions act on the data stored on all (or users). Each valid transaction is the participating servers. In its vanilla recorded in a block, which can can con- form, a blockchain transaction could tain multiple transactions, for efﬁciency. be visualized as a set of read / write Immutability is achieved by leveraging operations performed on each node strong cryptographic properties such of a replicated distributed database. as hashing (Katz and Lindell 2007). To determine an ordering for all the Figure 1 presents the structure of a incoming transactions each blockchain simple blockchain. application employs a consensus (Steen A blockchain is a linked-list in a and Tanenbaum 2017) protocol. true sense, as each block stores the A distributed consensus algo- hash of the previous block in its chain. rithm (Lamport 1998; Gray and Each block also digitally signs its Lamport 2006) allows a system to reach contents by storing the hash of its a common decision, respected by the contents inside the block. These hashes majority of nodes. Recent blockchain provide cryptographic integrity, as any technologies present several strategies adversary intending to modify a block for establishing consensus: Proof- needs to also modify all the previous of-Work (Jakobsson and Juels 1999; blocks in a chain, which makes the Satoshi 2008), Proof-of-Stake (King and attack cryptographically infeasible. A Nadal 2012), Proof-of-Authority (Par- key design strategy is to construct a ity Technologies 2018), Practical Merkle tree (Katz and Lindell 2007) to Byzantine Fault Tolerance (Castro and efﬁciently store and verify the hashes. Liskov 1999; Cachin 2016) and so on. Thus, each block only stores the root of 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 is created, and transmitted to each node, which also implies adding to global ledger. that can create a block (or participate Blockchain Topologies in the consensus process), it is also necessary to characterize the topologies A key parameter that renders the design for blockchain systems. of a blockchain application is the cat- egorization of nodes to be part of the application. Recent works (Pilkington Blockchain Execution 2015; Cachin and Vukolic 2017) categorize blockchain systems as either public, private or permissioned and Figure 2 illustrates the three main phases hybrid. Although, the characteristics required by any blockchain application of a public blockchain is clearly stated to create a new block. The client trans- in the community, but there is not a mits a transactional request to one of common consensus on the terminology the servers. This server multicasts the pertaining to the other terms. request to all other servers. We term this We categorize blockchain systems phase as Transaction Dissemination. under four heads: public, private, per- Once, all the servers have a copy of missioned and hybrid. Figure 3 presents client request, they initiate a consensus a pictorial representation of the different protocol. The choice of underlying categories. In these ﬁgures nodes that consensus protocol affects the time are not allowed to participate in the complexity and resource consumption. activities pertaining to the network, The winner of the consensus phase, lack connections to any node in the generates the next block, and transmits network. We use different circles to it to all other servers. This transmission demarcate different zones of operation; process is equivalent to adding an entry certain nodes are allowed to lead (or (block) to the global distributed ledger. create the block), and some are allowed to participate in the consensus protocol. Public Blockchain systems such as Bitcoin (Satoshi 2008) and 4 Suyash Gupta, Mohammad Sadoghi

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

Fig. 3: Topologies for Blockchain Systems.

Ethereum (Wood 2015) allow any node Hybrid Blockchain systems attain to participate in the consensus process, a middle ground between the two and any node can generate the next extremes. These systems allow any node valid block. Hence, if all the nodes have to be part of the consensus process, but same resources, then each node has only some designated nodes are allowed equal probability of creating a block1. to form the next block. Cryptocurrency Private Blockchain systems are at the Ripple (Schwartz et al 2014) supports a other end of the spectrum, as they variant of the hybrid model, where some allow only some nodes to be part of the public institutions can act as transaction consensus process, and only a subset validators. Permissioned Blockchain of these nodes can generate the next systems are the restricted variant of pub- block. These systems could be utilized lic blockchain systems. These systems at a banking organization which only enlist few nodes as the members with allows its customers to participate in equal rights, that is each node part of the the consensus, while its employees are system can form a block. These systems only permitted to commit the results by allow us to represent internal working of creating a block. any organization, social media groups and an early stage startup.

1 We are assuming fair and ideal conditions, where each node works independently Blockchain Transaction Processing 5

Blockchain Consensus the network. This theoretical possibility has practical implications as a group of The common denominator for all miners can share resources to generate the blockchain applications is the blocks faster, skewing the decentralized underlying distributed consensus nature of the network. algorithm. Nakamoto suggested Proof- Proof-of-stake (King and Nadal of-work (Satoshi 2008) (henceforth 2012) (henceforth referred at PoS), aims referred as PoW) for achieving con- at preserving the decentralized nature sensus among the participating nodes. of the blockchain network. In PoS PoW requires each node to demonstrate algorithm a node with n% resources gets its ability to solve a non-trivial task. n% time opportunity to create a block. The participating nodes compete among Hence, the underlying principle in PoS themselves to solve a complex puzzle is that the node with higher stake lays (such as computation of a 256-bit SHA claim to generation of the next block. To value). The node which computes the determine a node’s stake, a combination solution gets the opportunity to generate of one or more factors such as wealth, the next block. It also disseminates the resources and so on, could be utilized. block to all the nodes, which marks PoS algorithm requires a set of nodes to as the proof that it performed some act as validators. Any node that wants non-trivial computation. Hence, all to act as a validator needs to lockout its other nodes respect the winner’s ability, resources, as a proof of its stake. and reach the consensus by continuing PoS only permits a validator to create to chain ahead of this block. new blocks. To create a new block, a set In PoW the accessibility to larger of validators participate in the consensus computational resources determines the algorithm. PoS consensus algorithm has winner node(s). However, it is possible two variants: (i) chain-based and (ii) that multiple nodes could lay claim for BFT-style. Chain-based PoS algorithm the next block to be added to the chain. uses a psuedo-random algorithm to se- Based on the dissemination of the new lect a validator, which then creates a new block, this could lead to branching out block and adds it to the existing chain of the single chain. Interestingly, these of blocks. The frequency of selecting branches are often short lived, as all the the validator is set to some pre-defined nodes tend to align themselves to the time interval. BFT-style algorithm runs longest chain, which in turn leads to a byzantine fault tolerance algorithm pruning of the branches. It is important to select the next valid block. Here, to understand that a node receives validators are given right to propose incentive when it is able to append a the next block, at random. Another key block to the longest chain. Hence, it is difference between these algorithms to their advantage to always align with is the synchrony requirement; chain- the longest chain, otherwise they would based PoS algorithms are inherently end up spending their computational synchronous, while BFT-style PoS is resources for zero gains. Note: PoW partially synchronous. algorithm can theoretically be compro- Early implementations of PoS such mised by an adversary controlling at as Peercoin (King and Nadal 2012) suf- least 51% of computational resources in fer from non-convergence, that is lack of 6 Suyash Gupta, Mohammad Sadoghi single chain (also referred as “nothing- of the graph, and then he queries prover at-stake” attack). Such a situation hap- for random locations in the committed pens when the longest chain branches graph. The key intuition behind this into multiple forks. Intuitively, the nodes approach is that unless the prover has should aim at converging the branches sufficient storage, he would not pass the into the single longest chain. However, verification. PoC based cryptocurrency if the participating nodes are incentive such as SpaceMint (Park et al 2015) driven then they could create blocks in claims PoC based approaches more both the chains, to maximize their gains. resource efficient to PoW as storage Such an attack is not possible on PoW as consumes less energy. it would require a node to have double A decade prior to the first blockchain the number of computational resources, application, distributed consensus but as PoS does not require solving a problem had excited the researchers. complex problem, nodes can easily cre- Paxos (Lamport 1998) and View- ate multiple blocks. stamped Replication (Oki and Liskov Proof-of-Authority (Parity Tech- 1988) presented key solutions to dis- nologies 2018) (henceforth referred as tributed consensus when the node PoA) is designed to be used alongside failures were restricted to fail-stop. non-public blockchain systems. The key Castro and Liskov (1999) presented idea is to designate a set of nodes as their novel Practical Byzantine Fault the authority. These nodes are entrusted Tolerance (henceforth referred as PBFT) with the task of creating new blocks and consensus algorithm to handle byzantine validating the transactions. PoA marks failures. Interestingly, all of previously a block as part of the blockchain if it discussed consensus algorithms provide is signed by majority of the authorized similar guarantees as PBFT. Garay nodes. The incentive model in PoA et al (2015) helped in establishing an highlights that it is in the interest of an equivalence between the PoW and authority node to maintain its reputation, general consensus algorithms. This to receive periodic incentives. Hence, equivalence motivated the community PoA does not select nodes based on to design efficient alternatives to PoW. their claimed stakes. PBFT runs a three phase protocol to Proof-of-Space (Ateniese et al reach a consensus among all the non- 2014; Dziembowski et al 2015) also byzantine nodes. PBFT requires a bound know as proof-of-capacity (henceforth on the number of byzantine nodes. If “n” referred as PoC) is an consensus algo- represents the total number of nodes in rithm orthogonal to PoW. It expects the system, then PBFT bounds the num- nodes to provide a proof that they ber of byzantine nodes “ f ” as follows: n+1 have sufficient “storage” to solve a f ≤ 3 , PBFT based algorithms have computational problem. PoC algorithm an advantage of reduced resource con- targets computational problems such as sumption, but suffer from large message hard-to-pebble graphs (Dziembowski complexity (order O(n2)). Hence, these et al 2015) that need large amount of algorithms are preferred for restricted or memory storage to solve the problem. small blockchain systems, in order to In the PoC algorithm, the verifier first have less message overhead. expects a prover to commit to a labeling Blockchain Transaction Processing 7

The algorithm starts with a client Zyzzyva, the replicas are relived from sending a request to the primary node. the task of ensuring a global order for The primary node verifies the request, the client requests. This task is delegated assigns a sequence number, and sends to the client, which in turn informs the a pre-prepare message to all the repli- replicas if they are not in sync. cas. Each pre-prepare message also The protocol initiates with a client contains the client’s request and the sending a request to the primary, which current view number. When a replica in turn sends a pre-prepare message receives a pre-prepare message, it first to all the replicas. The structure of the verifies the request, and then transmits prepare message is similar to its PBFT a prepare message to all the nodes. The counterpart except that it includes a prepare message contains the digest of digest summarizing the history. Each client request, sequence number and replica on receiving a request from view number. Once a node receives the primary, executes the request and 2 f prepare messages, matching to the transmits the response to the client. pre-prepare message, it multicasts a Each response, in addition to the fields commit message. The commit message in the pre-prepare message, contains also contains the digest of client request, the digest of history and a signed copy sequence number and view number. of message from primary. If the client Each replica waits for receiving iden- receives 3 f + 1 matching responses, tical 2 f + 1 commit messages, before then it assumes the response is stable executing the request, and then transmits and considers the request completed. In the solution to the client. case the number of matching responses The client needs f + 1 matching received by the client are in the range responses from different replicas, to 2 f + 1 and 3 f , then it creates a commit mark the request as complete. If the certificate and transmits this certificate client timeouts while waiting for f + 1 to all the nodes. The commit certificate responses, then it multicasts the request includes the history which proves to to all the replicas. Each replica on a receiving replica that it can safely receiving a request from the client, commit the history and start process- which it has not executed, starts a ing the next request. All the replicas timer, and queries the primary. If the acknowledge the client for the commit primary does not reply until timeout certificate. If the client receives less than then the replicas proceed to change the 2 f + 1 responses, then it starts a timer primary. Note: PBFT heavily relies on and informs all the replicas again about strong cryptographic guarantees, and the impending request. Now, either the each message is digitally signed by the request would be safely completed, or sender using his private key. new primary would be elected. Zyzzyva (Kotla et al 2007) is another Although Zyzzyva achieves higher interesting byzantine fault tolerance throughput than PBFT, its client-based protocol aimed at reducing the costs speculative execution is far from ideal. associated with BFT-style protocols. Zyzzyva places a lot of faith on the Zyzzyva (Kotla et al 2007) allows the correctness of the client, which is quite replicas to reach early consensus by discomforting, as a malicious client can permitting speculative execution. In prevent the replicas from maintaining 8 Suyash Gupta, Mohammad Sadoghi linearizability. Aardvark (Clement it transmits a message to elect a new et al 2009) studies the ill-effects of primary. Note: RBFT does not allow various fast, byzantine fault tolerant more than one primary on any node. protocols and presents the design of a Hence, each node can have at most one robust BFT protocol. In Aadvark, the primary instance. RBFT protocol has messages are signed by the client using an additional step in comparison to the both digital signatures and message three phases in PBFT and Aardvark. authentication codes (Katz and Lindell The client node initiates the protocol by 2007). This prevents malicious clients transmitting a request to all the nodes. from performing a denial-of-service Next, each node propagates this request attack, as it is costly for client to sign to all other nodes and then the three each message two times. Aadvark phase protocol begins. This extra round uses point-to-point communication, of redundancy ensures that the client instead of multicast communication. request reaches all the instances. The key intuition behind such a choice is to disallow a faulty client of replica from blocking the complete network. Aadvark also periodically changes the Blockchain Systems primary replica. Each replica tracks the throughput of the current primary and Bitcoin (Satoshi 2008) is regarded suggest replacing the primary, when as the first blockchain application. It there is a decrease in its throughput. The is a cryptographically secure digital authors use a simple timer to track the currency with the aim of disrupting the rate of primary response. traditional, institutionalized monetary RBFT (Aublin et al 2013) is a simple exchange. Bitcoin acts as the token of extension to Aardvark. RBFT aims at transfer between two parties undergoing detecting smartly malicious primary a monetary transaction. The underlying replica, which could avoid being de- blockchain system is a network of tected malicious by other replicas. The nodes (also known as miners) that key intuition behind RBFT is to prevent take a set of client transactions and primary from insinuating delays that are validate the same by demonstrating within the stated threshold. Hence, the a proof-of-work, that is generating a primary could reduce the throughput block. The process of generating the without being ever replaced. To tackle next block is non-trivial and requires this problem, RBFT insists running large computational resources. Hence, f + 1 independent instances of the the miners are given incentives (such as Aardvark protocol on each node. One of Bitcoins) for dedicating their resources the instance is designated as the “master and generating the block. Each miner instance”, and it executes the requests. maintains locally an updated copy of the Rest of the instances are labeled as the complete blockchain and the associated “backup instances”, and they order the ledgers for every Bitcoin user. requests and monitor the performance To ensure Bitcoin system remains of the master instance. If any backup fair towards all the machines, the instance observes a degradation of the difficulty of proof-of-work challenge performance of the master instance, then is periodically increased. We also Blockchain Transaction Processing 9 know that Bitcoin is vulnerable to create correct applications. One of the 51% attack, which can lead to double key advantage of Ethereum is that it spending (Rosenfeld 2014). The in- supports a Turing complete language tensity of such attacks increases when to generate new applications on top of multiple forks of the longest chain are EVM. Initially, Ethereum’s consensus created. To avoid these attacks, Bitcoin algorithm used the key elements of both developers suggest the clients to wait PoW and PoC algorithms. Ethereum for their block to be confirmed before made nodes solve challenges that were they mark the Bitcoins as transferred. not only computational intensive, but This wait ensures that the specific block also memory intensive. This design is a little deep (nearly six blocks) in the prevented existence of miners who longest chain (Rosenfeld 2014). Bitcoin utilized specially designed hardware for critics also argue that its proof-of-work compute intensive applications. consumes huge energy 2 and may not be Recently, Ethereum modified its con- a viable solution for future. sensus protocol to include some notions Bitcoin-NG (Eyal et al 2016) is a of PoS algorithm. The modified proto- scalable variant to Bitcoin’s protocol. col is referred as Casper (Buterin and Our preceding discussion highlights Griffith 2017). Casper introduces the no- that Bitcoin suffers from throughput tion of finality, that is it ensures that degradation. This can be reduced by one chain becomes permanent in time. either increasing the block size or It also introduces the notion of account- decreasing the block interval. However, ability that is penalize a validator, who increasing the former increases the performs the “nothing-at-stake” attack in propagation delays and latter can lead PoS based systems. The penalty lever- to incorrect consensus. Bitcoin-NG aged on such a validator is equivalent to solves this problem by dividing the negating all his stakes. time into a set of intervals and selecting Parity (Parity Technologies 2018) one leader for each time interval. The is an application designed on top of selected leader autonomously orders the Ethereum. It provides an interface for transactions. Bitcoin-NG also uses two its users to interact with the Ethereum different block structures: key-blocks blockchain. Parity can be regarded for facilitating leader election and as an interesting application for the microblocks for maintaining the ledger. blockchain community, as it provides Ethereum (Wood 2015) is support for both Proof-of-Work and blockchain framework that permits Proof-of-Authority consensus algo- users to create their own applications rithms. Hence, they allow mechanism on top of the Ethereum Virtual Machine for users of their application to setup (EVM). Ethereum utilizes the notion of “authority” nodes, and resort to non- smart contracts to facilitate development compute intensive, POA algorithm. of new operations. It also supports a Ripple (Schwartz et al 2014) is digital cryptocurrency, ether, which is considered as third largest cryptocur- used to incentivize the developers to rency after Bitcoin and Ethereum, in terms of market cap. It uses a consensus 2 As per some claims one Bitcoin transaction algorithm which is a simple variant consumes power equivalent to that required by of BFT algorithms. Ripple requires 1.5 American homes per day. 10 Suyash Gupta, Mohammad Sadoghi number of failures f to be bounded nologies. ExpoDB consists of a set of as follows: ≤ (n − 1)/5 + 1, where n five layers providing distinct functional- represents the total number of nodes. ities (refer Figure 4). Application Layer Ripple’s consensus algorithm introduces acts as the testbed for evaluating the the notion of a Unified Node List (UNL), underlying database protocols (Gupta which is a subset of the network. Each and Sadoghi 2018). It allows the system server communicates with the nodes to access OLTP benchmarks such as in its UNL for reaching a consensus. YCSB Cooper et al (2010), TPC- The servers exchange the set of trans- C TPP Council (2010) and PPS Harding actions they received from the clients et al (2017). Application layer acts and propose those transactions to their as an interface for the client-server respective UNL for vote. If a transaction interaction. Transport Layer allows receives 80% of the votes, it is marked communication of messages between permanent. It is important to understand the client and server nodes. that if the generated UNL groups are a Execution Layer facilitates seamless clique then forks of the longest chain execution of a transaction with help of could co-exist. Hence, UNLs are created a set of threads. These threads lie at the in a manner that they share some set of core of execution layer as they run the nodes. Another noteworthy observation transaction, abide by the rules of stated about Ripple protocol is that each client concurrency protocol and achieve agree- needs to select a set of validators or ment among different transactional par- unique nodes that they trust. These titions. ExpoDB provides implementa- validators next utilize ripple consensus tion for eight concurrency control and algorithm to verify the transactions. three commit protocols. ExpoDB also Hyperledger (Cachin 2016) is a characterizes a storage layer (Sadoghi suite of resources aimed at modeling et al 2018) for storing the transactional industry standard blockchain applica- data, messages and relevant metadata, tions. It provides a series of Application ExpoDB extends blockchain func- Programming Interfaces (APIs) for de- tionality to the traditional distributed velopers to create their own non-public systems through a secure layer. To blockchain applications. Hyperledger facilitate secure transactions ExpoDB provides implementations of blockchain provides a cryptographic variant to systems that uses RBFT and other vari- YCSB – Secure YCSB benchmark. ants of the PBFT consensus algorithm. ExpoDB also contains implementations It also facilitates use and development for a variety of consensus protocols such of smart contracts. It is important to as PoW, PBFT, RBFT and Bitcoin-NG. understand that the design philosophy of Hyperledger leans towards blockchain applications that require existence of non-public networks, and so, they do Future Directions for Research not need a compute intensive consensus. ExpoDB (Sadoghi 2017; Gupta Although blockchain technology is just and Sadoghi 2018) is an experimental a decade old, it gained majority of its research platform that facilitates design momentum in the last five years. This and testing of emerging database tech- allows us to render different elements Blockchain Transaction Processing 11

Fig. 4: Architecture of ExpoDB. of the blockchain systems and achieve learning techniques can play an impor- higher performance and throughput. tant role in eliminating the human bias Some of the plausible directions to and inexperience. To learn which nodes develop efficient blockchain systems can act as block creators, a feature set, are: (i) reducing the communication representative of the nodes, needs to be messages, (ii) defining efficient block defined. Some interesting features can structure, (iii) improving the consensus be: geographical distance, cost of com- algorithm, and (iv) designing secure munication, available computational light-weight cryptographic functions resources, available memory storage Statistical and machine learning and so on. These features would help in approaches have presented interesting generating the dataset that would help solutions to automate key processes to train and test the underlying machine such as Face Recognition (Zhao et al learning model. This model would be 2003), Image classification (Krizhevsky ran against new nodes that wish to join et al 2012), Speech Recognition (Graves the associated blockchain application. et al 2013) and so on. The tools can be The programming languages and leveraged to facilitate easy and efficient software engineering communities have consensus. The intuition behind this developed several works that provide approach is to allow learning algorithms semantic guarantees to a language or an to select nodes, which are fit to act as application (Wilcox et al 2015; Leroy a block creator and prune the rest from 2009; Kumar et al 2014). These works the list of possible creators. The key have tried to formally verify (Keller observation behind such a design is that 1976; Leroy 2009) the system using the the nodes selected by the algorithm are principles of programming languages predicted to be non-malicious. Machine and techniques such as finite state 12 Suyash Gupta, Mohammad Sadoghi automata, temporal logic and model vacy, IEEE Computer Society, Washington, checking (Grumberg and Long 1994; DC, USA, SP ’15, pp 104–121 Baier and Katoen 2008). We believe Buterin V, Griffith V (2017) Casper the Friendly Finality Gadget. CoRR abs/1710.09437, similar analysis can be performed in the URL http://arxiv.org/abs/ context of blockchain applications. The- 1710.09437, 1710.09437 orem provers (such as Z3 (De Moura Cachin C (2016) Architecture of the Hyper- and Bjørner 2008)) and proof assis- ledger blockchain fabric. In: Workshop on tants (such as COQ (Bertot 2006)) Distributed Cryptocurrencies and Consen- sus Ledgers, DCCL 2016 could prove useful to define a certified Cachin C, Vukolic M (2017) Blockchain blockchain application. A certified Consensus Protocols in the Wild. CoRR blockchain application can help in stat- abs/1707.01873 ing theoretical bounds on the resources Castro M, Liskov B (1999) Practical byzantine required to generate a block. Similarly, fault tolerance. In: Proceedings of the Third Symposium on Operating Systems Design some of the blockchain consensus has and Implementation, USENIX Association, been shown to suffer from Denial of Ser- Berkeley, CA, USA, OSDI ’99, pp 173–186 vice attacks (Bonneau et al 2015), and a Clement A, Wong E, Alvisi L, Dahlin M, formally verified blockchain application Marchetti M (2009) Making Byzantine can help realize such guarantees, if the Fault Tolerant Systems Tolerate Byzantine Faults. In: Proceedings of the 6th USENIX underlying application provides such a Symposium on Networked Systems Design claim. and Implementation, USENIX Association, Berkeley, CA, USA, NSDI’09, pp 153–168 Cooper BF, Silberstein A, Tam E, Ramakrish- nan R, Sears R (2010) Benchmarking Cloud References Serving Systems with YCSB. In: Proceed- ings of the 1st ACM Symposium on Cloud Computing, ACM, pp 143–154 Ateniese G, Bonacina I, Faonio A, Galesi N De Moura L, Bjørner N (2008) Z3: An Effi- (2014) Proofs of space: When space is of the cient SMT Solver, Springer Berlin Heidel- essence. In: Abdalla M, De Prisco R (eds) berg, Berlin, Heidelberg, pp 337–340 Security and Cryptography for Networks, Decker C, Wattenhofer R (2013) Information Springer International Publishing, pp 538– Propagation in the Bitcoin Network. In: 13th 557 IEEE International Conference on Peer-to- Aublin PL, Mokhtar SB, Quema´ V (2013) Peer Computing (P2P), Trento, Italy RBFT: Redundant Byzantine Fault Toler- Dziembowski S, Faust S, Kolmogorov V, ance. In: Proceedings of the 2013 IEEE 33rd Pietrzak K (2015) Proofs of space. In: International Conference on Distributed Gennaro R, Robshaw M (eds) Advances Computing Systems, IEEE Computer Soci- in Cryptology – CRYPTO 2015, Springer ety, ICDCS ’13, pp 297–306 Berlin Heidelberg, pp 585–605 Baier C, Katoen JP (2008) Principles of Model Eyal I, Gencer AE, Sirer EG, Van Renesse R Checking (Representation and Mind Series). (2016) Bitcoin-NG: A Scalable Blockchain The MIT Press Protocol. In: Proceedings of the 13th Usenix Bertot Y (2006) Coq in a Hurry. CoRR Conference on Networked Systems Design abs/cs/0603118, URL http://arxiv. and Implementation, USENIX Association, org/abs/cs/0603118, cs/0603118 Berkeley, CA, USA, NSDI’16, pp 45–59 Bonneau J, Miller A, Clark J, Narayanan A, Garay J, Kiayias A, Leonardos N (2015) The Kroll JA, Felten EW (2015) SoK: Research Bitcoin Backbone Protocol: Analysis and Perspectives and Challenges for Bitcoin and Applications, Springer Berlin Heidelberg, Cryptocurrencies. In: Proceedings of the Berlin, Heidelberg, pp 281–310 2015 IEEE Symposium on Security and Pri- Graves A, Mohamed A, Hinton GE (2013) Speech Recognition with Blockchain Transaction Processing 13

Deep Recurrent Neural Networks. Lamport L (1998) The Part-time Parliament. CoRR abs/1303.5778, URL http: ACM Trans Comput Syst 16(2):133–169 //arxiv.org/abs/1303.5778, Leroy X (2009) A Formally Verified Compiler 1303.5778 Back-end. J Autom Reason 43(4):363–446 Gray J, Lamport L (2006) Consensus on Trans- Nawab F (2018) Geo-Scale Transaction Pro- action Commit. ACM TODS 31(1):133–160 cessing, Springer International Publishing, Grumberg O, Long DE (1994) Model Checking pp 1–7. DOI 10.1007/978-3-319-63962-8 and Modular Verification. ACM Trans Pro- 180-1, URL https://doi.org/10. gram Lang Syst 16(3):843–871 1007/978-3-319-63962-8_180-1 Gupta S, Sadoghi M (2018) EasyCommit: A Oki BM, Liskov BH (1988) Viewstamped Non-blocking Two-phase Commit Protocol. Replication: A New Primary Copy Method In: Proceedings of the 21st International to Support Highly-Available Distributed Conference on Extending Database Tech- Systems. In: Proceedings of the Seventh An- nology, Open Proceedings, EDBT nual ACM Symposium on Principles of Dis- Harding R, Van Aken D, Pavlo A, Stone- tributed Computing, ACM, New York, NY, braker M (2017) An Evaluation of Dis- USA, PODC ’88, pp 8–17 tributed Concurrency Control. Proc VLDB Parity Technologies (2018) Parity Endow 10(5):553–564 Ethereum Blockchain. URL https: Jakobsson M, Juels A (1999) Proofs of Work //www.parity.io/ and Bread Pudding Protocols. In: Proceed- Park S, Kwon A, Fuchsbauer G, Gai P, Alwen J, ings of the IFIP TC6/TC11 Joint Work- Pietrzak K (2015) SpaceMint: A Cryptocur- ing Conference on Secure Information Net- rency Based on Proofs of Space. https: works: Communications and Multimedia //eprint.iacr.org/2015/528 Security, Kluwer, B.V., CMS ’99, pp 258– Pilkington M (2015) Blockchain Technol- 272 ogy: Principles and Applications. In: Re- Katz J, Lindell Y (2007) Introduction to Mod- search Handbook on Digital Transforma- ern Cryptography. Chapman & Hall/CRC tions, SSRN Keller RM (1976) Formal verification of par- Rosenfeld M (2014) Analysis of hashrate-based allel programs. Commun ACM 19(7):371– double spending. CoRR abs/1402.2009, 384 URL http://arxiv.org/abs/ King S, Nadal S (2012) PPCoin: Peer-to-Peer 1402.2009, 1402.2009 Crypto-Currency with Proof-of-Stake Sadoghi M (2017) Expodb: An exploratory data Kotla R, Alvisi L, Dahlin M, Clement A, Wong science platform. In: Proceedings of the E (2007) Zyzzyva: Speculative Byzantine Eighth Biennial Conference on Innovative Fault Tolerance. In: Proceedings of Twenty- Data Systems Research, CIDR first ACM SIGOPS Symposium on Operat- Sadoghi M, Bhattacherjee S, Bhattacharjee B, ing Systems Principles, ACM, New York, Canim M (2018) L-Store: A Real-time NY, USA, SOSP ’07, pp 45–58, DOI 10. OLTP and OLAP System. OpenProceed- 1145/1294261.1294267 ing.org, EDBT Krizhevsky A, Sutskever I, Hinton GE (2012) Satoshi N (2008) Bitcoin: A peer-to-peer Imagenet classification with deep convolu- electronic cash system. URL http:// tional neural networks. In: Proceedings of bitcoin.org/bitcoin.pdf the 25th International Conference on Neural Schwartz D, Youngs N, Britto A (2014) The Information Processing Systems - Volume1, Ripple Protocol Consensus Algorithm. URL Curran Associates Inc., NIPS’12, pp 1097– https://www.ripple.com/ 1105 Steen Mv, Tanenbaum AS (2017) Distributed Kumar R, Myreen MO, Norrish M, Owens S Systems (2014) CakeML: A Verified Implementation TPP Council (2010) TPC Benchmark C (Revi- of ML. In: Proceedings of the 41st ACM sion 5.11) SIGPLAN-SIGACT Symposium on Prin- Wilcox JR, Woos D, Panchekha P, Tatlock Z, ciples of Programming Languages, ACM, Wang X, Ernst MD, Anderson T (2015) New York, NY, USA, POPL ’14, pp 179– Verdi: A Framework for Implementing and 191 Formally 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. URL http://gavwood.com/paper.pdf Zhao W, Chellappa R, Phillips PJ, Rosenfeld A (2003) Face Recognition: A Literature Survey. ACM Comput Surv 35(4):399–458, DOI 10.1145/954339.954342