Fine-Grained, Secure and Efficient Data Provenance on Blockchain Systems
Pingcheng Ruan†, Gang Chen§, Tien Tuan Anh Dinh†, Qian Lin†, Beng Chin Ooi†, Meihui Zhang‡ †National University of Singapore §Zhejiang University ‡Beijing Institute of Technology †{ruanpc, dinhtta, linqian, ooibc}@comp.nus.edu.sg §[email protected] ‡[email protected]
ABSTRACT the previous block via a hash pointer. It was firstly in- The success of Bitcoin and other cryptocurrencies bring troduced in Bitcoin [27], where Satoshi Nakamoto employs enormous interest to blockchains. A blockchain system im- it to batch cryptocurrency transactions. Often referred to plements a tamper-evident ledger for recording transactions as decentralized ledger, the chain ensures integrity of the that modify some global states. The system captures entire complete transaction history. It is replicated over a peer-to- evolution history of the states. The management of that peer (P2P) network, and a distributed consensus protocol, history, also known as data provenance or lineage, has been namely Proof-of-Work (PoW), is used to ensure that honest studied extensively in database systems. However, query- nodes in the network have the same ledger. More recent ing data history in existing blockchains can only be done blockchains, for instance Ethereum [1] and Hyperledger [2], by replaying all transactions. This approach is applicable extend the original design to support applications beyond to large-scale, offline analysis, but is not suitable for online cryptocurrencies. In particular, they add smart contracts transaction processing. which encode arbitrary, Turing-complete computation on We present LineageChain, a fine-grained, secure and effi- top of the blockchain. A smart contract has its states stored cient provenance system for blockchains. LineageChain ex- on the blockchain, and the states are modified via transac- poses provenance information to smart contracts via sim- tions that invoke the contract. ple and elegant interfaces, thereby enabling a new class of Blockchains are disrupting many industries, including fi- blockchain applications whose execution logics depend on nance [34, 29], supply chain [24, 35], and healthcare [4]. provenance information at runtime. LineageChain captures These industries are exploiting two distinct advantages provenance during contract execution, and efficiently stores of blockchains over traditional data management systems. it in a Merkle tree. LineageChain provides a novel skip First, a blockchain is decentralized, which allows mutually list index designed for supporting efficient provenance query distrusting parties to manage the data together instead of processing. We have implemented LineageChain on top trusting a single party. Second, the blockchain provides of Hyperledger and a blockchain-optimized storage system integrity protection (tamper evidence) to all transactions called ForkBase. Our extensive evaluation of LineageChain recorded in the ledger. In other words, the complete trans- demonstrates its benefits to the new class of blockchain ap- action history is secure. plications, its efficient query, and its small storage over- The management of data history, or data provenance, has head. been extensively studied in databases, and many systems have been designed to support provenance [13, 14, 8, 30, PVLDB Reference Format: 5, 36]. In the context of blockchain, there is explicit, but Pingcheng Ruan, Gang Chen, Tien Tuan Anh Dinh, Qian Lin, only coarse-grained support for data provenance. In par- Beng Chin Ooi, Meihui Zhang. Fine-Grained, Secure and Effi- ticular, the blockchain can be seen as having some states cient Data Provenance on Blockchain Systems. PVLDB, 12(9): (with known initial values), and every transaction moves 975-988, 2019. the system to new states. The evolution history of the DOI: https://doi.org/10.14778/3329772.3329775 states (or provenance) can be securely and completely re- constructed by replaying all transactions. This reconstruc- tion can be done during offline analysis. During contract 1. INTRODUCTION execution (or runtime), however, no provenance informa- Blockchains are capturing attention from both academia tion is safely available to smart contracts. In other words, and industry. A blockchain is a chain of blocks, in which smart contracts cannot access historical blockchain states in each block contains many transactions and is linked with a tamper-evident manner. The lack of secure, fine-grained, runtime access to provenance therefore restricts the expres- This work is licensed under the Creative Commons Attribution- siveness of the business logic the contract can encode. NonCommercial-NoDerivatives 4.0 International License. To view a copy Consider an example smart contract shown in Figure 1, of this license, visit http://creativecommons.org/licenses/by-nc-nd/4.0/. For which contains a method for transferring a number of tokens any use beyond those covered by this license, obtain permission by emailing from one user to another. Suppose user A wants to send [email protected]. Copyright is held by the owner/author(s). Publication rights tokens to B based on the latter’s historical balance in recent licensed to the VLDB Endowment. months. For example, A only sends token if B’s average Proceedings of the VLDB Endowment, Vol. 12, No. 9 ISSN 2150-8097. balance per day is more than t. It is not currently possible to DOI: https://doi.org/10.14778/3329772.3329775
975 contract Token { exposes simple access interface to smart contracts. method Transfer(sender, recipient, amount) { bal1 = gState[sender]; • We design a novel index optimized for querying bal2 = gState[recipient]; blockchain provenance. The index incurs small stor- if (amount < bal1) { age overhead, and its performance is independent of gState[sender] = bal1 - amount; the blockchain size. It is adapted from the skip list gState[recipient] = bal2 + amount; but we completely remove the randomness to fit for }}} deterministic blockchains. Figure 1: A smart contract that manages for token • We implement LineageChain for Hyperledger [2]. management. Our implementation builds on top of ForkBase, a blockchain-optimized storage [37]. We conduct exten- write a contract method for this operation. To work around sive evaluation of LineageChain. The results demon- this, A needs to first compute the historical balance of B strate its benefits to provenance-dependent applica- by querying and replaying all on-chain transactions, then tions, and its efficient query and small storage over- based on the result issues the Transfer transaction. Besides head. performance overhead incurred from multiple interactions LineageChain is a component of our Hyperledger++ sys- with the blockchain, this approach is not safe: it fails to tem [3], for which we improve Hyperledger’s execution and achieve transaction serializability. In particular, suppose A storage layer for the secure runtime provenance support. issues the Transfer transaction tx based on its computation Elsewhere, we have addressed the consensus bottleneck by of B’s historical balance. But before tx is received by the applying sharding efficiently and exploiting trusted hard- blockchain, another transaction is committed such that B’s ware to scale out system horizontally, to substantially im- average balance becomes t0 < t. Consequently, when tx prove the system throughput [15]. We have also improved is later committed, it will have been based on stale state, the storage efficiency by designing a tamper-evident stor- and therefore fails to meet the intended business logic. In age engine that supports efficient forking called Forkbase. blockchains with native currencies, serializability violation We are currently incorporating smart contract verification can be exploited for Transaction-Ordering attacks that cause to enhance the correctness of smart contracts. substantial financial loss to the users [25]. The remainder of the paper is organized as follows. Sec- In this paper, we design and implement a fine-grained, se- tion 2 provides background on blockchains. Section 3 de- cure and efficient provenance system for blockchains, called scribes our design for capturing provenance, and the inter- LineageChain. In particular, we aim to enable a new class face exposed to smart contracts. Section 4 discusses how of smart contracts that can access provenance information we store provenance, and Section 5 describes our new index. at runtime. Although our goal is similar to that of exist- Section 6 presents our implementation. Section 7 reports ing works in adding provenance to databases [5, 35, 31], we the performance of LineageChain. Section 8 discusses re- face three unique challenges due to the nature of blockchain. lated work, and Section 9 concludes this work. First, there is a lack of data operators whose semantics cap- ture provenance in the form of input-output dependency. More specifically, for general data management workloads 2. BACKGROUND AND OVERVIEW (i.e., non-cryptocurrency), current blockchains expose only In this section, we present relevant background on generic operators, for example, put and get of key-value blockchain systems [18, 7], and design choices that affect tuples. These operators do not have input-output depen- index structure requirements. Following which, we present dency. In contrast, relational databases operators such as an overview of LineageChain. map, join, union, are defined as relations between input and output, which clearly capture their dependencies. To over- come this lack of provenance-friendly operators, we instru- 2.1 Blockchain Systems ment blockchain runtime to record read-write dependency A blockchain system consists of multiple nodes that do not of all the states used in any contract invocation, which is trust each other. Current blockchains can be broadly clas- then passed to a user-defined method that specifies which sified as permissionless or permissioned. In the former, any dependency to be persisted. node can join or leave the network. In the latter, member- The second challenge is that blockchains assume an adver- ship is strictly controlled, and a node must be authenticated sarial environment, therefore any captured provenance must and granted permission to join the network. be made tamper evident. To address this, we store prove- Consensus. Except for a few permissioned blockchains nance in a Merkle tree data structure that also allows for with high auditability, most blockchains assume the Byzan- efficient verification. The final challenge is to ensure that tine failure model, in which faulty nodes behave arbitrarily. provenance queries are fast, because a large execution over- Under this hostile environment. They use a Byzantine Fault head is undesirable due to the Verifier’s Dilemma [26]. To Tolerance (BFT) consensus protocol to ensure that honest address this challenge, we design a novel skip list index that nodes agree on the same states. Examples of BFT protocols is optimized for provenance queries. The index incurs small include Proof-of-work (PoW) which is used in Bitcoin [27], storage overhead, and its performance is independent of the and PBFT [11] which is used in Hyperledger. Classic BFT number of blocks in the blockchain. protocols, such as PBFT, guarantee that honest nodes have In summary, we make the following contributions: the identical chain of blocks. PoW and its variants, on the • We introduce a system, called LineageChain that other hand, allow for inconsistency because the chain can efficiently captures fine-grained provenance for have forks. These protocols handle forks by deterministi- blockchains. It stores provenance securely, and cally selecting one branch over the other. For example, in PoW the longest branch is selected.
976 Data model. Different blockchains adopt different data Block verification. Algorithm 1 illustrates how a node models for their states. Bitcoin’ states are unspent coins uses the block header to verify if a block it receives from modeled as Unspent Transaction Outputs (UTXOs), which the network is valid. If the block is valid, it is appended to consists of outputs of transactions that have not been used the chain. When PoW is used for consensus, the node first as inputs to another transaction. The UTXO model lends checks if Nonce is the correct solution to the PoW puzzle. itself to simple transaction verification, because nodes only This step is skipped if a deterministic consensus protocol, need to check that the transaction output has not been used such as PBFT, is used. Next, it checks if the list of transac- in the past. More recent blockchains, namely Ethereum and tions has not been tampered with, by computing and veri- Hyperledger, support general states that can be modified ar- fying TransactionDigest from the list. It then tentatively bitrarily by smart contracts. They adopt an account-based re-executes the included transactions. During execution, the data model, in which each account has its own local states states are accessed via some index structures. After the ex- stored on the blockchain. A smart contract transaction can ecution, the node checks if the resulting states match with write arbitrary data to the storage. This flexible data model StateDigest. If they do, the block is considered valid and comes at the cost of integrity protection and verification of the new states are committed to the storage. Otherwise, the the account states. In this paper, we focus on the account- states are rolled back to those before execution. We note based data model. that Algorithm 1 takes as input an object gState that repre- Block structure. A block in the blockchain stores the sents the global states. If the blockchain does not have forks, transactions and the global states. The block header con- e.g., Hyperledger, this object is the latest states. However, tains the following fields. when there are forks, e.g., in Ethereum, this object may refer to the global states at a point in the past. • PreviousBlockHash: reference to the previous block in the chain. • Nonce: used for checking validity of the block. In PoW 2.2 State Organization consensus, Nonce is the solution to the PoW puzzle. The most important feature of blockchain is the guarantee • TransactionDigest: used for integrity protection of of data integrity, which implies that the global states must the list of transactions in the block. be tamper evident. The block verification algorithm above • StateDigest: used for integrity protection of the is crucial for the security of blockchain. We note that the al- global states after executing the block transactions. gorithm requires access to all history snapshots of the states, as well as the ability to update the states in batch. These Both TransactionDigest and StateDigest are Merkle-tree requirements present new challenges in designing an index roots. They allow for efficient block transfer, in which the structure for organizing blockchain states. In particular, tra- block headers and block content can be decoupled and trans- ditional database indices such as B+ tree cannot be used. ferred separately. In addition, they enable efficient verifica- We now elaborate on the requirements for a blockchain in- tion of transactions and states. dex, and explain how they are met in Ethereum and Hyper- ledger. LineageChain builds on existing blockchain indices Algorithm 1: Block verification in blockchain to ensure security for the captured provenance. Input: A block Blk received from the network. Tamper evidence. A user may want to read some states Input: The global state gState, which maps state without downloading and executing all the transactions. identifiers to their values. Thus, the index structure must be able to generate an in- Output: True if the block is valid, False otherwise. tegrity proof for any state. In addition, the index must // Step 1: Verify Nonce (PoW only). provide a unique digest for the global states, so that nodes 1 if checkNonce(Blk.Header.Nonce) then can quickly check if the post-execution states are identical 2 return False; across the network. // Step 2: Verify transactions. Incremental update. The size of global states in a typical 3 txnDigest = computeDigest(Blk.Transactions); blockchain application is large, but one block only updates 4 if txnDigest != Blk.Header.TransactionDigest then a small part of the states. For example, some states may 5 return False; be updated at every block, whereas other may be updated // Step 3: Tentatively execute transactions. much more infrequently. Because the index must be updated 6 oldState = gState; at every block, it must be efficient at handling incremental 7 allUpdates = []; updates. 8 for txn in Blk.Header.Transactions do // Buffer the changes Snapshot. A snapshot of the index, as well as of the global 9 updates = execute(txn); states, must be made at every block. This is crucial to realize 10 allUpdates.Append(update); the immutability property of blockchain which allows users 11 gState.apply(allUpdates); to read any historical states. It is also important for block // Step 4: Verify new state. verification. As explained earlier, when a new block is re- 12 stateDigest = computeDigest(state); ceived that creates a fork, an old snapshot of the state must 13 if stateDigest != Blk.Header.StateDigest then be used as input for verification. Even when the blockchain // Rollback allows no forks, snapshots enable roll-back when the received 14 gState = oldState; block is found to be invalid after execution (step 4 in Algo- 15 return False; rithm 1). 16 else Existing blockchains use indices that are based on Merkle 17 return True; tree. In particular, Ethereum implements Merkle Patricia Trie (MPT), and Hyperledger implements Merkle Bucket
977 contract Token { L-1 L M N method Transfer(...){...} // as above 1 Contract Txn1 Txn2 method prov_helper(name, reads, writes) { Block Deployment ...... if name == "Transfer" { for (id,value) in writes { if (reads[id] < value) { recipient = id; gState[Addr1]=100 gState[Addr1]=90 gState[Addr1]=70 } else {sender = id; } gState[Addr2]=100 gState[Addr2]=110 gState[Addr2]=130 } // dependency list with a Figure 2: The example ledger with the correspond- // single element. ing gState between the block interval dep = [sender]; return {recipient:dep}; Tree (MBT). In a Merkle tree, content of the parent node } is recursively defined by those of the child nodes. The root ... node uniquely identifies the content of all the leaf nodes. } } A proof of integrity can be efficiently constructed without reading the entire tree. Therefore, the Merkle tree meets Figure 3: The provenance helper method for Token the first requirement. This structure is also suitable for in- contract. It defines dependency between the sender cremental updates (second requirement), because only the identifier and recipient identifier. This method is nodes affected by the update need to be changed. To support invoke after every invocation of the Token contract. efficient snapshots, an update in the Merkle tree recursively creates new nodes in the path affected by the change. The do not capture any data association (input-output depen- new root then serves as index of the new snapshot, and is dency). In contrast, relational databases or big data sys- then included in the block header. tems have many provenance-friendly operators, such as map, reduce and join, whose semantics meaningfully capture the 2.3 LineageChain Overview association. For instance, the output of join is clearly de- Given a smart contract on an existing blockchain, Lin- rived from (or is dependent on) the input data. eageChain enriches it with fine-grained, secure and efficient In LineageChain, every contract method can be made provenance as follows. First, the contract can implement a provenance-friendly via a helper method. More specifi- helper method to define the exact provenance information cally, during transaction execution, LineageChain collects to be captured at every contract invocation. By default, the identifiers and values of the accessed states, i.e., ones all read-write dependencies of all the states are recorded. used in read and write operations. The results are a read Second, new methods can be added that make use of prove- set reads and write set writes. For Txn1, reads = {Addr1 : nance at runtime. As far as a contract developer is con- 100, Addr2 : 100}, and writes = {Addr1 : 90, Addr2 : 110}. cerned, these are the only two changes from the existing, After the execution finishes, these sets are passed to a user- non-provenance blockchain. The captured information is defined method prov_helper, together with the name of the then stored in an enhanced blockchain storage that ensures contract method. prov_helper has the following signature: efficient tracking and tamper evidence of provenance. On top of this storage, we build a skip list index to support method prov_helper(name: string, fast provenance queries. These changes to the blockchain reads: map(string, byte[]), storage are invisible to the contract developer. writes: map(string, byte[])) returns map(string, string[]);
3. FINE-GRAINED PROVENANCE It returns a set of dependencies based on the input read and write sets. Figure 3 shows implementation of the helper In this section, we describe our approach to capture prove- method for the Token contract. It first computes the iden- nance during smart contract execution. We present APIs tifier of the sender and recipient from the read and write that allow the contract to query provenance at runtime. sets. Specifically, the identifier whose value in writes is Running example. Throughout this section, we use as lower than that in reads is the sender, and the opposite is running example the token smart contract shown in Fig- true for the recipient. It then returns a dependency set of ure 1. Figure 2 depicts how the global states are modi- a single element: the recipient-sender dependency. In our fied by the contract. In particular, the contract is deployed example, for Txn1, this method returns {Addr2 : [Addr1]} at block Lth in the blockchain. Two addresses Addr1 and LineageChain ensures that prov_helper is invoked im- Addr2 are initialized with 100 tokens. Two transactions mediately after every successfully contract execution. If the Txn1 and Txn2 that transfer tokens between the two ad- method is left empty, LineageChain uses all identifiers in dresses are committed at block M and N respectively. The the read set as dependency of each identifier in the write value of Addr1 is 100 from block R to block M − 1, 90 from set. Interested readers may observe that the vanilla Hyper- block M to N − 1, and 70 from block N. The global state ledger already computes for the read/write set during the gState is essentially a map of addresses to their values. endorsement phase. Orthogonal to ours, they are internally used for the concurrency control to achieve one-copy serial- 3.1 Capturing Provenance izability. Instead, we allow contract developers to capture Blockchains support only a small set of data operators for their application-level provenance. for general workloads, namely read and write. These op- erators are not provenance friendly, in the sense that they 3.2 Smart Contract APIs
978 Current smart contracts can only safely access the latest contract Token { ... blockchain state. In Hyperledger, for example, the get(k) method Refund(addr) { operation returns the last value of k that is written or being blk := last block in the ledger batched. In Ethereum, on the other hand, when a smart first_blk := first block in this month contract reads a value of k at block b, the system considers sum = count = 0; the snapshot of states at block b − 1 as the latest states. Al- while (first_blk < blk) { though there may exist a block b0 > b on a different branch, val, startBlk, txnID = Hist(addr, blk); blk = startBlk - 1; the smart contract always treats what returned from the sum += val; storage layer as the latest state. count += 1; The main limitation of the current APIs is that the smart } contract cannot tamper-evidently read previous values of a avg = sum / count; state. Instead, the contract has to explicit track historical refund_amount := refund amount based on avg versions, for example by maintaining a list of versions for gState[addr] += refund_amount; } every state. This approach is costly both in terms of storage and computation. LineageChain addresses this limitation method Blacklist(addr) { with three additional smart contract APIs. blk := last block in the ledger • Hist(stateID, [blockNum]): returns the tuple (val, blacklisted = false; iterate 5 times { blkStart, txnID) where val is the value of stateID val, startBlk, txnID = Hist(addr, blk); at block blockNum. If blockNum is not specified, the for (depAddr, depBlk) latest block is used. txID is the transaction that sets in (Backward(addr, startBlk) stateID to val, and blkStart is the block number at or Forward(addr, startBlk)) { which txID is executed. if depAddr in gState["blacklist"] { • : returns a list of tu- gState["blacklist"].append(addr); Backward(stateID, blkNum) return; ples (depStateID, depBlkNum) where depStateID is } the dependency state of stateID at block blkNum. } depBlkNum is the block number at which the value of blk = startBlk - 1; depStateID is set. In our example, Backward(Addr2, } N) returns (Addr1, M). } } • Forward(stateID, blkNum): similar to the Backward API, but returns the states of which stateID is a de- Figure 4: Smart contract with provenance- pendency. For example, Forward(Addr1, L) returnss dependent methods. (Addr2, M). Figure 4 demonstrates how the above APIs are used to denote the value of the state with identifier k at version v. express smart contract logics that are currently impossible We drop the subscripts if the meaning of k and v are not 0 0 in the secure manner. (The vanilla Hyperledger optionally important. For any k 6= k and v 6= v , sk,v and sk0,v0 repre- provides a historyDB for the historical query. But imple- sent the values of two different states at different versions. b mented from the flat storage, it does not provide the tamper- sk represents the state value with identifier k at its latest evidence guarantee, which is our major contribution. ) We version before block b. In our example, for k = Addr1 and add two additional methods to the original contract, both of v = M, sk,v = 90. which use the new APIs. The Refund method examines an Definition 1. A transaction, identified by tid which is account’s average balance in the recent month and makes i strictly increasing, reads a set of input states Stid and up- the refund accordingly. The Blacklist method marks an o dates a set of output states Stid. A valid transaction satisfies address as blacklisted if one of its last 5 transactions is with the following properties: a blacklisted address. o ∀sk1,v1 , sk2,v2 ∈ Stid. k1 6= k2 ∧ v1 = v2 (1)
4. SECURE PROVENANCE STORAGE i o ∀sk1,v1 ∈ Stid, sk2,v2 ∈ Stid. v1 < v2 (2) In this section, we discuss how LineageChain enhances i i 0 0 existing blockchain storage layer to provide efficient track- ∀sk,v ∈ Stid, sk,v0 ∈ Stid0 . tid < tid ⇒ v ≤ v . (3) ing and tamper evidence for the captured provenance. Our 0 o o key insight is to reorganize the flat leaf nodes in the orig- tid 6= tid ⇒ Stid ∩ Stid0 = ∅ (4) inal Merkle tree into a Merkle DAG. We first describe the Property (1) means that the versions of all output states of Merkle DAG structure, then discuss its properties. Finally, a transaction are identical, because they are updated by the we explain how to exploit the blockchain execution model same transaction in the same block. Property (2) implies the to support forward provenance tracking. version of any input state is strictly lower than that of the output version. This makes sense because the blockchain es- 4.1 Merkle DAG tablishes a total order over the transactions, and because the Let k be the unique identifier of a blockchain state, whose input states can only be updated in previous transactions. evolution history is expected to be tracked. Let v be the Property (3) specifies that, for all the states with the same unique version number that identifies the state in its evo- identifier, the input of later transactions can never have an lution history. When the state at version v is updated, the earlier version. This ensures the input state of any trans- new version v0 is strictly greater than v. In LineageChain, action must be up-to-date during execution time. Finally, we directly use the block number as its version v. Let sk,v Property (4) means that every state update is unique.
979 Block b-1 Block b Root Hash Digest Digest s s …... k0,v2 k0,v4 tid1 tid3 tid2 tid4 Merkle s sk1,v1 k1,v3 Tree s tid1 s tid3 s k1,v1 k1,v2 k1,v3 sk2,v2 sk2,v4
tid4 Figure 6: Forward tracking support. After sk1,v1 is sk2,v1 sk2,v4 updated, there can only be sk0,v2 and sk2,v2 that are
dependent on sk1,v1 . Future states can only depend tid2 s tid4 s k3,v2 k3,v4 on sk1,v3. Forward pointers of sk1,v1 are stored in the entry of sk1,v3 . Figure 5: A Merkle DAG for storing provenance. Recall that the state entry hash captures the entire evolu- s and s updated by the same transaction k2,v4 k3,v4 tion history of the state. Since this hash is protected by the (tid ), but their dependencies are different. b con- 4 Merkle index for tamper evidence, so is the state history. tains two transactions, tid and tid . Its latest states 3 4 In other words, we add integrity protection for provenance include s , s , s , from which a Merkle tree k1,v3 k2,v4 k3,v4 without any extra cost to the index structure. For exam- is built. ple, suppose a client wants to read a specific version of a Definition 2. The dependency of state s is a subset of state, it first reads the state entry hash at the latest block. the input states of the transaction that outputs s. More This read operation can be verified against tampering, as specifically: in existing blockchains. Next, the client traverses the DAG from this hash to read the required version. Because the i o dep(s) ⊂ Stid where s ∈ Stid. DAG is tamper evident, the integrity of the read version is guaranteed. We note that dep, which is returned by prov_helper method, is only a subset of the read set. 4.3 Support for Forward Tracking One problem of the above DAG model is that it does not 3. The entry E of the state s is a tu- Definition sk,v k,v support forward tracking, because the hash pointers only ple containing the current version, the state value, and the reference backward dependencies. When a state is updated, hashes of the entries of its dependent state. More specifi- these backward dependencies are permanently established, cally: so that they belong to the immutable derivation history of 0 the state. However, the state can be read by future trans- Es = hv, sk,v, {hash(Es0 )|s ∈ dep(sk,v)}i k,v action, therefore its forward dependencies cannot be deter- An entry uniquely identifies a state. In LineageChain, we mined at the time of update. associate each entry with its corresponding hash. Our key insight here is that only forward dependencies of the latest state are mutable. Once the state is updated, Definition 4. The set of latest states at block b, denoted due to the execution model of blockchain smart contract, as Slatest,b is defined as: in which the latest state is always read, forward dependen- cies of the previous state version becomes permanent. As a [ b Slatest,b = {sk} result, they can be included into the derivation history. Fig- k ure 6 illustrates an example, in which forward dependencies
of sk1,v1 becomes fixed when the state is updated to sk1,v3 . Let Ub be the updated states in block b. We can compute This is because when the transaction that outputs sk0,v4 is Slatest,b by recursively combining Ub with Slatest,b−1 \ Ub. executed, it reads sk1,v3 instead of sk1,v1 . In LineageChain, for each state sk,v at its latest version, Definition 5. χb is the root of a Merkle tree built on the we buffer a list of forward pointers to the entries whose de- map Sb where pendencies include sk,v. We refer to this list as Fsk,v , which b is defined more precisely as follows: Sb = {k : hash(E b )|∀sk ∈ Slatest,b}. sk 0 0 Fsk,v = {hash(Es )|sk,v ∈ dep(s )} LineageChain stores χb as the state digest in the block 0 header. 0 When the state is updated to sk,v for v > v, we store Fsk,v at the entry of s 0 . 4.2 Discussion k,v Our new Merkle DAG can be easily integrated to existing blockchain index structures. In particular, existing Merkle 5. EFFICIENT PROVENANCE QUERIES index such as MPT stores state values directly at the leaves, The Merkle DAG structure supports efficient access to the whereas the Merkle DAG in LineageChain stores the entry latest state version, since the state index at block b contains hashes of the latest state versions at the leaves. By adding pointers to all the latest versions at this block. To read the one more level of indirection, we maintain the three proper- latest version of s, one simply reads χb, follows the index ties of the index (tamper evidence, incremental update and to the entry for s, and then reads the state value from the snapshot), while enhancing it with the ability to traverse the entry. However, querying an arbitrary version in the DAG DAG to extract fine-grained provenance information. is inefficient, because one has to start at the DAG head
980 struct Node { Version v; Algorithm 2: DASL Append Value val; Input: version v and last node last List
981 We now describe how a new node is appended to DASL. The challenge is to determine the lists that should include Application the new node. Algorithm 2 details the steps that find the Original Provenance Provenance Helper Handler Query Handler Method Specification lists, and subsequently the previous versions, of the new node. The key idea is to start from the last node in L0, then Consensus Layer (Unchanged) keep increasing the list level until the current node and the new node belong to the same interval (line 9 - 18). Figure Execution Layer Accessed States Provenane 8(b) shows the result of appending a node with version 12 Execution Engine Engine to the original DASL. The algorithm starts at node 10 and moves up to list L1 and L2. It stops at L3 because in this Provenance level node 10 and 12 belong to the same interval, i.e., [8, 16). Storage Layer Thus, the new node is appended to list L0 to L2. When the algorithm reaches the last level and is still able to append, it DAG Model with DASL Index creates a new level where node 0 is the first entry and repeats the process (line 21 - 24). In Figure 8(b), when appending ForkBase version 16, all existing lists can be used. The algorithm then creates L4 with node 1 and appends the node 16 to it. It also creates level L5, but then discards it because node 16 Figure 9: LineageChain’s software stack. The will not be appended since it belongs to same interval of original storage layer is replaced with the imple- [0, 32) with node 1. mentation that supports fine-grained provenance. The original execution layer is instrumented with a 5.2 Discussion provenance capture engine. The application layer Integrating to Merkle DAG The DASL is integrated to contains the new helper method and provenance the Merkle DAG as follows. The node structure (Figure 7) is query APIs. The consensus layer is unchanged. stored in the state entry (Definition 3). The node pointers are implemented entry hashes. The Merkle tree structure network has to execute the same transaction. Current public remains unchanged. blockchains prevent such denial-of-service attack by explic- itly charging a fee for each operation in the transaction. In Speed-storage tradeoff As a skip list variant, DASL Ethereum, the transaction owner pays for the resource con- shares the same lineage space complexity and logarithmic sumption in gas. A transaction that writes more data or ∗ query time complexity. Suppose there are v number of ver- consumes more CPUs has to pay more gas. Thus, rational sions and the base of DASL is b. The maximum number of users are deterred from running too complex transactions b(v∗−1) ∗ required pointers is b−1 . (There are at most dlogb v e on the blockchain. ∗ v As DASL consumes resources, its costs must be explicitly levels and the i-th level takes at most d bi e − 1 pointers.) Suppose the queried version is vq and the query distance accounted for in permissionless blockchains. More specifi- d = v∗ − vq, the maximum number of hops in such query cally, during deployment, the contract owner specifies which is capped at 2bdlogb de. (A query traversal from the end states require DASL support. Alternatively, DASL support will undergo two stages, one stage towards lower levels and can be automatically inferred from the contract’s source the other stage back towards upper levels. In each stage, code. The deployment fee should reflect this extra storage the traversal will take at most b hops on the same list before cost for DASL. If the fee is too high, the owner can lower it moving to the next level. And there are at most dlogb de lev- by increasing b. During contract execution, the execution els to traverse.) Hence, b controls the tradeoff between the engine must charge the cost of DASL queries to the trans- space overhead and query delay. One benefit of this prop- action fee. In particular, a query that requires more hops erty is that DASL queries favor more recent versions, i.e. d to find the requested version incurs a higher transaction fee. are small, which is useful for smart contracts that work use Users may empirically estimate the hops (as well as the cost) recent rather than old versions. Another benefit is that the based on the above-derived theoretical upper bound. performance of such recent-version queries does not change as the state history grows. 6. IMPLEMENTATION Extending to permissionless blockchains. We note In this section, we present our implementation of Lin- that DASL incurs storage overhead. The version query also eageChain based on Hyperledger. We implement Lin- incurs some computation cost, even though it is more effi- eageChain both on Hyperledger v0.6 and v1.3. Although cient with DASL than without it. These costs may be small the two blockchains follow different designs, they share the enough such that they do not affect the performance of a same four logical layers: storage, execution, consensus and permissioned blockchain, as we demonstrate in Section 7. application layer [19]. Figure 9 depicts these layers and high- However, they need to be carefully managed in a permi- lights the changes we make to the original Hyperledger’s sionless blockchain where any overhead directly translates stack. In particular, we completely replace Hyperledger’s to monetary cost to the miners. In particular, any addi- storage layer with our implementation of the Merkle DAG tional cost to the miner triggers the Verifier Dilemma [26] and DASL index. This new storage is built on top of Fork- and compromises the incentive mechanism of the blockchain. Base [37], a state-of-the-art blockchain storage system with A malicious user could issue a transaction that references support for version tracking. We instrument the original ex- a very old version. Reading earlier versions is more expen- ecution engine to record read and write sets during contract sive, because there are more hops involved. This overhead execution. At the application layer we add a new helper is born by all nodes in the network, since every node in the method and three provenance APIs. The execution engine
982 Algorithm 3: Provenance update and digest Computa- the dependent states (line 5-8). Next, we build the pointers tion for the DASL index, then retrieve the forward pointers of 1 fb.Map
983 contract for a supply chain application In this application, a Transaction latency phone is assembled from intermediary components which are made from other components or raw material. The supply with LineageChain w/o LineageChain chain creates a DAG representing the derivation history of a 10000
phone. The maximum depth of the DAG is 6. We generate ms synthetic data for this contract, and examine the latency of 5000 the operation that uses Backtrack to retrieve dependencies of a given phone. 1 10 20 30 40 50 In the third set of experiments, we evaluate the prove- # of fetched block nance impact on the overall performance of the blockchain (a) in the distributed setting. To this end, we run the Small- bank benchmark in BLOCKBENCH on multiple nodes. We Breadth first search measure the overall throughput, and analyze the cost break- 1.2 down to understand the overhead of provenance support. 1.0 LineageChain Hyperledger+ Our experiments are conducted on a local clusters of 16 0.8 nodes. Each node is equipped with E5-1650 3.5GHz CPU, 0.6 ms 32GB RAM, and 2TB hard disk. The nodes are connected 0.4 via 1Gbps Ethernet. The results reported are based on Hy- 0.2 perledger v0.6, unless stated otherwise. 0.0 1 2 3 4 5 6 Search level 7.2 Experimental Results (b) Figure 10: Performance of (a) a provenance- Provenance-dependent applications dependent blockchain application and (b) BFS Traversal latency We implement a simple provenance-dependent blockchain application by modifying the YCSB benchmark in BLOCK- is low when the block distance is small. When the block dis- BENCH such that the update operation depends on his- tance increases, the latency in LineageChain increases only torical values. With LineageChain, the contract has direct logarithmically, as opposed to linearly in LineageChain–. access to the provenance information, and the client remains We repeat the experiment above while fixing the block the same as in the original YCSB. Without LineageChain, distance to 64 and varying the total number of blocks. Fig- the client is modified such that it reads B latest blocks be- ure 11(b) shows the results for the version query when the fore issuing transactions. B represents how far behind the number of block increases. It can be seen that the query client is to the latest states. latency in both LineageChain and Hyperledger+ remains We run the experiments using the LineageChain imple- roughly the same. In other words, the performance of ver- mentation on Hyperledger v1.3, with 16 nodes and 1 client. sion queries in these systems are independent of the block Figure 10(a) shows transaction latency with varying B. It numbers, which is due to the DAG data model that tracks can be seen that with LineageChain, the latency remains state versions. LineageChain outperforms Hyperledger+ almost constant because the client does not have to fetch thanks to the index that reduces the number of hops needed any block for the provenance query. In contrast, without to be read. An interesting observation is that the latency LineageChain, the latency increases linearly with B. This of Hyperledger+ fluctuates significantly. We attribute this demonstrates the performance benefit of having access to fluctuation to RocksDB’s log-structure-merge tree index, in provenance information at runtime. which the requested version may reside at different levels of the tree when the total number of block increases. Provenance queries Next, we measure the latency for the operation that scan the entire version history of a given key. Figure 11(c) shows We first create 500 key-value tuples and then continuously the scan latency with increasing number of blocks. For Hy- issue update transactions until there are more 10k blocks perledger+, we first construct the key range and rely on in the ledger. Each block contains 500 transactions. We RocksDB iterator for the scanning. LineageChain– and Lin- then execute a query for the values of a key at different eageChain both use ForkBase iterator, therefore they have block numbers. Figure 11(a) illustrates the query latency the same performance. As the number of block increases, with increasing block distance from the last block. It can be the version history becomes longer which accounts for the seen that when the distance is small, LineageChain– has the linear increase in latency in both systems. However, Lin- lowest latency. LineageChain– does not have DASL index, eageChain outperforms Hyperledger+ by a constant factor. hence for this query it performs linear scan from the latest We attribute this difference to ForkBase’s optimizations for version. Therefore, it is fast when the requested version is version tracking. very recent because the number of read is small. However, Finally, we evaluate the query performance with multi- its performance degrades quickly as the distance increases. state dependency. We populate the blockchain states with In particular, when the block distance reaches 128, the query raw materials and issue transactions that create new phones. is 4× slower than LineageChain. We observe that the query We perform a breadth-first search to retrieve all the depen- latency in Hyperledger+ is independent of the block dis- dencies of a phone. For this experiment, we only compare tance. It is because the query uses RocksDB index directly. Hyperledger+ and LineageChain, because LineageChain– LineageChain outperforms both LineageChain– and Hyper- does not support multi-state dependencies. Figure 10(b) ledger+. Due to DASL, the query latency in LineageChain
984 Version query Version query (distance=64) Version scan 0.20 12.5 Hyperledger+ LineageChain 0.08 Hyperledger+ LineageChain Hyperledger+ LineageChain LineageChain- LineageChain- 0.15 10.0 0.06 7.5 0.10 ms ms ms 5.0 0.04 0.05 2.5
0.00 0.02 0.0 21 23 25 27 210 211 212 213 214 2 4 6 8 10 Block distance # of blocks # of blocks ( x1000) (a) (b) (c) Figure 11: Latency of the version query on YCSB with increasing block distance (a) and increasing number of blocks (b). Latency of the version scan with increasing block number (c).
Latency 150 Commit Execute Consensus 2000
1500 100 1000 ms ms
500 50
0 1 4 8 12 16 0 # of nodes H+ L- L H+ L- L H+ L- L Hyperledger+ LineageChain- LineageChain 8 nodes 12 nodes 16 nodes Throughput 150 Figure 13: Latency breakdown. H+, L-, L stands for Hyperledger+, LineageChain– and LineageChain 100 respectively. tps 50 accounts for a majority of the cost. There is no significant difference in block execution time of Hyperledger+ and Lin- 0 1 4 8 12 16 eageChain. Hence, the overhead of the provenance capture # of nodes engine is negligible. Figure 12: Performance under Smallbank workload. The block commit latency in LineageChain– and Lin- eageChain are 2× higher than that of Hyperledger+. It is shows the performance with varying search depths, in due to ForkBase’s computation to update its internal data which the latency of both Hyperledger+ and LineageChain structures during commit. However, the block commit phase grow exponentially with increasing depths. However, Lin- accounts for less than 20% of the total block latency. We eageChain outperforms the baseline. It is because the in- further note that the transaction latency is in order of sec- dex in LineageChain directly captures the dependencies, onds, whereas a block latency is in in order of hundreds of whereas each backtrack operation in Hyperledger+ requires milliseconds. Thus, any extra overhead incurred by prove- traversing on RocksDB index. As the number of queries nance support does not result in any visible differences in increases with the search level, their performance gap accu- the user-perceived performance of the blockchain. mulates. Next, we examine the breakdown in storage cost of Lin- eageChain. Figure 14 shows the storage breakdown with LineageChain overhead varying number of blocks. The block size is fixed at 500 transactions per block. Figure 14 shows the breakdown with We run the Smallbank benchmark with a single client and varying block sizes, while fixing the number of blocks at increasing number of nodes. The client uses 16 threads and 1000. It can be seen that the storage size grows linearly issues 16 transactions per second. We examine the over- with the number of blocks and block sizes. We observe head of provenance support on the overall performance of that the block content accounts for the majority the storage the blockchain. cost. In contrast, the extra provenance and DASL index Figure 12 shows the transaction latency and overall account for only 2 − 4% of the total space consumption. In throughput. We do not observe significant differences be- LineageChain, the DASL pointers are implemented as 20- tween LineageChain and the other baselines. In particular, byte vid strings. A new state will at most add D + log(N) the transaction latency is around 1.2s, and the throughput new pointers where N is the number of previous versions decreases from roughly 118tps to 108tps. and D is the number of dependent states. When compared We break down the block latency into three components: with kilobyte-sized blocks, the storage consumption of these consensus latency (the block proposal phase), execution la- pointers is not significant. As a result, the storage overhead tency (when transactions are executed), and commit latency of DASL is small. (when the states are committed to the storage). Figure 13 shows the detailed breakdown when the number of nodes Finally, we evaluate LineageChain overhead on Hyper- is 8, 12 and 16. It can be seen that the execution phase ledger v1.3. This version of Hyperledger uses a different
985 Storage cost 200 2.5 graphs are established based on the data flow from map-
2.0 pers to reducers [21]. Titian [22] instruments Spark’s orig- 150 inal RDDs to capture data transformation. Other works 1.5 100 exploit provenance in specific application domains, such as MB 1.0 networks [12], language processing [17] and interactive work- 50 0.5 flow applications [31]. They focus on improving provenance 0 0.0 Percentage(%) storage and query efficiency. 0 2 4 6 8 # of blocks ( x100) Our work shares the same spirit as the above. We add Block Dependency & Index provenance capabilities to blockchains, which enables a new Historical State Meta Field Ratio class of blockchain applications. We design a new data model and index that are optimized for blockchains. Our 200 5 system addresses the unique challenges raised by the decen- 150 tralization nature of blockchains. 0
MB 100 Blockchain Most research in blockchain systems focuses
50 on security of permissionless blockchains. One open chal- 5
Percentage(%) lenge is to improve incentive compatibility. A protocol is 0 0 1 2 3 4 5 6 incentive compatible if honest participants get rewards pro- # of transactions in a block portional to its contributions to the network. Bitcoin, for Figure 14: Storage cost breakdown. example, is not incentive compatible [20, 32, 28]. Another challenge is to improve smart contracts security. Recent Latency vulnerabilities in Ethereum that resulted in substantial fi- 4000 nancial loss has prompted many efforts in finding bugs and 3000 securing smart contracts with programming language tech- 2000 niques [6, 16, 25]. As a data management system, blockchain ms 1000 has poor performance. BLOCKBENCH [19] compares sev- 0 eral blockchains with in-memory databases and shows orders 270 300 330 360 390 420 450 of magnitude difference in transaction throughput. Client rate (tps) Our work aims to enrich blockchain capabilities by in- Hyperledger Hyperledger+ LineageChain- LineageChain troducing provenance. It is orthogonal to those above that Throughput aim to improve security and performance of the consensus 400 protocol. The most closely related work to ours is Fork- Base [37]. In fact, current LineageChain implementation tps 300 is built on top of ForkBase to leverage its version tracking capability. However, our novelties over ForkBase include 200 270 300 330 360 390 420 450 multi-state dependency tracking, efficient index, and rich Client rate (tps) APIs for accessing provenance at runtime. Another similar Figure 15: Performance on Hyperledger v1.3 recent work is VChain [38], where researchers achieve the in- tegrity of boolean range queries over the historical data on consensus protocol and more simplified data model than blockchain databases. But different from ours, they are op- v0.6. We use 16 nodes and vary the offer load by increasing timizing for the offline analytical query. Instead, we extend the client’s transaction rate. Figure 15 shows the perfor- the provenance support to blockchain online transactions. mance overhead. At saturation, LineageChain– and Lin- eageChain add less than 200ms in latency, compared to the original Hyperledger that has no provenance support. In 9. CONCLUSIONS contrast, Hyperledger+ adds more than 1s. LineageChain– In this paper, we presented LineageChain, a fine-grained, and LineageChain reach similar throughput as the original secure and efficient provenance system for blockchains. The Hyperledger, which is around 350tps. Hyperledger+ peaks system efficiently captures provenance information during at around 330tps. These results demonstrate that Lin- runtime and stores it in a secure storage. It exposes sim- eageChain’s overhead over the original Hyperledger is small. ple APIs to smart contracts, which enables a new class of provenance-dependent blockchain applications. Provenance 8. RELATED WORK queries are efficient in LineageChain, thanks to a novel skip Data Provenance Data provenance has been studied list index. We implemented LineageChain on top of Hyper- extensively in database systems. Support for provenance ledger and benchmarked it against several baselines. The re- has been added to a wide range of systems, from relational sults show the benefits of LineageChain in supporting rich, databases [13, 14, 8], collaborative data sharing systems [23, provenance-dependent applications. They demonstrate that 33], to big data platforms [30, 5, 36]. However, these sys- provenance queries are efficient, and that the system incurs tems have different requirements on provenance and there- small storage overhead. fore face different challenges. As a result, their provenance solutions are ad-hoc and do not generalize well. In relational databases, Peter Buneman et al. [9] propose an approach 10. ACKNOWLEDGMENTS for query provenance, in which they identify two types of This research is supported by Singapore Ministry of Edu- provenance for databases: "why" and "where" provenance. cation Academic Research Fund Tier 3 under MOE’s official In Hadoop and other MapReduce systems, data derivation grant number MOE2017-T3-1-007.
986 11. REFERENCES [19] T. T. A. Dinh, J. Wang, G. Chen, R. Liu, B. C. Ooi, [1] Ethereum. https://www.ethereum.org. and K.-L. Tan. Blockbench: A framework for [2] Hyperledger. https://www.hyperledger.org. analyzing private blockchains. In Proceedings of the 2017 ACM International Conference on Management [3] Hyperledger++. https://www.comp.nus.edu.sg/ of Data, pages 1085–1100. ACM, 2017. ~dbsystem/hyperledger++/index.html. [20] I. Eyal and E. G. Sirer. Majority is not enough: [4] Medilot. https://medilot.com. Bitcoin mining is vulnerable. Communications of the [5] S. Akoush, R. Sohan, and A. Hopper. Hadoopprov: ACM, 61(7):95–102, 2018. Towards provenance as a first class citizen in [21] R. Ikeda, H. Park, and J. Widom. Provenance for mapreduce. In TaPP, 2013. generalized map and reduce workflows. 2011. [6] N. Atzei, M. Bartoletti, and T. Cimoli. A survey of [22] M. Interlandi, K. Shah, S. D. Tetali, M. A. Gulzar, attacks on ethereum smart contracts (sok). In S. Yoo, M. Kim, T. Millstein, and T. Condie. Titian: Principles of Security and Trust, pages 164–186. Data provenance support in spark. PVLDB, Springer, 2017. 9(3):216–227, 2015. [7] S. Bano, A. Sonnino, M. Al-Bassam, S. Azouvi, [23] Z. G. Ives, T. J. Green, G. Karvounarakis, N. E. P. McCorry, S. Meiklejohn, and G. Danezis. Taylor, V. Tannen, P. P. Talukdar, M. Jacob, and Consensus in the age of blockchain. F. Pereira. The orchestra collaborative data sharing https://arxiv.org/abs/1711.03936, 2018. system. ACM Sigmod Record, 37(3):26–32, 2008. [8] P. Buneman, A. Chapman, and J. Cheney. Provenance [24] K. Korpela, J. Hallikas, and T. Dahlberg. Digital management in curated databases. In Proceedings of supply chain transformation toward blockchain the 2006 ACM SIGMOD international conference on integration. In proceedings of the 50th Hawaii Management of data, pages 539–550. ACM, 2006. international conference on system sciences, 2017. [9] P. Buneman, S. Khanna, and T. Wang-Chiew. Why [25] L. Luu, D.-H. Chu, H. Olickel, P. Saxena, and and where: A characterization of data provenance. In A. Hobor. Making smart contracts smarter. In International conference on database theory, pages Proceedings of the 2016 ACM SIGSAC Conference on 316–330. Springer, 2001. Computer and Communications Security, pages [10] C. Cachin, S. Schubert, and M. Vukolić. 254–269. ACM, 2016. Non-determinism in byzantine fault-tolerant [26] L. Luu, J. Teutsch, R. Kulkarni, and P. Saxena. replication. arXiv preprint arXiv:1603.07351, 2016. Demystifying incentives in the consensus computer. In [11] M. Castro, B. Liskov, et al. Practical byzantine fault CCS, 2015. tolerance. In OSDI, volume 99, pages 173–186, 1999. [27] S. Nakamoto. Bitcoin: A peer-to-peer electronic cash [12] C. Chen, H. T. Lehri, L. Kuan Loh, A. Alur, L. Jia, system. https://bitcoin.org/bitcoin.pdf, 2009. B. T. Loo, and W. Zhou. Distributed provenance [28] K. Nayak, S. Kumar, A. Miller, and E. Shi. Stubborn compression. In Proceedings of the 2017 ACM mining: Generalizing selfish mining and combining International Conference on Management of Data, with an eclipse attack. In Security and Privacy pages 203–218. ACM, 2017. (EuroS&P), 2016 IEEE European Symposium on, [13] J. Cheney, L. Chiticariu, W.-C. Tan, et al. Provenance pages 305–320. IEEE, 2016. in databases: Why, how, and where. Foundations and [29] Q. K. Nguyen. Blockchain-a financial technology for Trends R in Databases, 1(4):379–474, 2009. future sustainable development. In 2016 3rd [14] L. Chiticariu, W.-C. Tan, and G. Vijayvargiya. International Conference on Green Technology and Dbnotes: a post-it system for relational databases Sustainable Development (GTSD), pages 51–54. IEEE, based on provenance. In Proceedings of the 2005 ACM 2016. SIGMOD international conference on Management of [30] H. Park, R. Ikeda, and J. Widom. Ramp: A system data, pages 942–944. ACM, 2005. for capturing and tracing provenance in mapreduce [15] H. Dang, T. T. A. Dinh, D. Loghin, E.-C. Chang, workflows. 2011. Q. Lin, and B. C. Ooi. Towards scaling blockchain [31] F. Psallidas and E. Wu. Smoke: Fine-grained lineage systems via sharding. arXiv preprint at interactive speed. PVLDB, 11(6):719–732, 2018. arXiv:1804.00399, 2018. [32] A. Sapirshtein, Y. Sompolinsky, and A. Zohar. [16] K. Delmolino, M. Arnett, A. Kosba, A. Miller, and Optimal selfish mining strategies in bitcoin. In E. Shi. Step by step towards creating a safe smart International Conference on Financial Cryptography contract: Lessons and insights from a cryptocurrency and Data Security, pages 515–532. Springer, 2016. lab. In International Conference on Financial Cryptography and Data Security, pages 79–94. [33] Y. L. Simmhan, B. Plale, and D. Gannon. A survey of Springer, 2016. data provenance in e-science. ACM Sigmod Record, 34(3):31–36, 2005. [17] D. Deutch, N. Frost, and A. Gilad. Provenance for natural language queries. PVLDB, 10(5):577–588, [34] A. Tapscott and D. Tapscott. How blockchain is 2017. changing finance. Harvard Business Review, 1(9), 2017. [18] T. T. A. Dinh, R. Liu, M. Zhang, G. Chen, B. C. Ooi, and J. Wang. Untangling blockchain: A data [35] F. Tian. An agri-food supply chain traceability system processing view of blockchain systems. IEEE for china based on rfid & blockchain technology. In Transactions on Knowledge and Data Engineering, Service Systems and Service Management (ICSSSM), 30(7):1366–1385, 2018. 2016 13th International Conference on, pages 1–6. IEEE, 2016.
987 [36] J. Wang, D. Crawl, S. Purawat, M. Nguyen, and Q. Cai, G. Chen, B. C. Ooi, and P. Ruan. Forkbase: I. Altintas. Big data provenance: Challenges, state of An efficient storage engine for blockchain and forkable the art and opportunities. In Big Data (Big Data), applications. PVLDB, 11(10):1137–1150, 2018. 2015 IEEE International Conference on, pages [38] C. Xu, C. Zhang, and J. Xu. vchain: Enabling 2509–2516. IEEE, 2015. verifiable boolean range queries over blockchain [37] S. Wang, T. T. A. Dinh, Q. Lin, Z. Xie, M. Zhang, databases. arXiv preprint arXiv:1812.02386, 2018.
988