08246573

This article has been accepted for publication in a future issue of this journal, but has not been
fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TKDE.2017.2781227, IEEE
Transactions on Knowledge and Data Engineering
1
Untangling Blockchain: A Data Processing View

of Blockchain Systems
Tien Tuan Anh Dinh, Rui Liu, Meihui Zhang∗ , Member, IEEE, Gang Chen, Member, IEEE,
Beng Chin Ooi, Fellow, IEEE, and Ji Wang
Abstract—Blockchain technologies are gaining massive momentum in the last few years. Blockchains are distributed ledgers that
enable parties who do not fully trust each other to maintain a set of global states. The parties agree on the existence, values and
histories of the states. As the technology landscape is expanding rapidly, it is both important and challenging to have a firm grasp of
what the core technologies have to offer, especially with respect to their data processing capabilities. In this paper, we first survey the
state of the art, focusing on private blockchains (in which parties are authenticated). We analyze both in-production and research
systems in four dimensions: distributed ledger, cryptography, consensus protocol and smart contract. We then present BLOCKBENCH,
a benchmarking framework for understanding performance of private blockchains against data processing workloads. We conduct a
comprehensive evaluation of three major blockchain systems based on BLOCKBENCH, namely Ethereum, Parity and Hyperledger
Fabric. The results demonstrate several trade-offs in the design space, as well as big performance gaps between blockchain and
database systems. Drawing from design principles of database systems, we discuss several research directions for bringing blockchain
performance closer to the realm of databases.
Index Terms—Blockchain, Distributed Databases, Survey.
1 I NTRODUCTION replicated applications known as smart contracts. More im-

Blockchain technologies are taking the world by storm, portantly, interest from the industry has started to drive
largely due to the success of Bitcoin [1]. A blockchain, development of new blockchain platforms designed for
also called distributed ledger, is essentially an append-only private settings where participants are authenticated. Block-
data structure maintained by a set of nodes which do not chain systems in such environments are called private (or
fully trust each other. Nodes in the blockchain agree on an permissioned), as opposed to the early systems operating in
ordered set of blocks, each containing multiple transactions, public environments (or permissionless) where anyone can
thus the blockchain can be viewed as a log of ordered trans- join and leave. Applications such as security trading and
actions. In the database context, blockchain can be viewed settlement [6], asset and finance management [7], [8], bank-
as a solution to distributed transaction management: nodes ing and insurance [9] are being built and evaluated. These
keep replicas of the data and agree on an execution order applications are currently supported by enterprise-grade
of transactions. However, traditional databases assume a database systems like Oracle and MySQL, but blockchain
trusted environment and employ well known concurrency has the potential to disrupt this status quo because it incurs
control techniques [2], [3], [4] to order transactions. Block- lower infrastructure and human costs [9]. In particular,
chain’s key property is that it assumes nodes behave in arbi- blockchain’s immutability and transparency help reduce
trary (or Byzantine) manner. Being able to tolerate Byzantine human errors and the need for manual intervention due
failure by design, blockchain offers stronger security than to conflicting data. Blockchain can help streamline business
incumbent database systems. processes by removing duplicate efforts in data governance.
In the original design, Bitcoin’s blockchain stores coins Goldman Sachs estimated 6 billion USD saving in current
as the system states. For this application, Bitcoin nodes capital market [9], and J.P. Morgan forecast that blockchains
implement a simple replicated state machine model which will start to replace currently redundant infrastructure by
moves coins from one address to another. Since then, block- 2020 [8].
chain has grown beyond crypto-currencies to support user- Amid the growing commercial and academic interest, a
defined states and Turing complete state machine mod- large number of blockchain systems have sprung up, each
els. For example, Ethereum [5] enables any decentralized, claiming some unique capabilities. Both private and public
sector are clamoring to adopt blockchains, but they face
(∗ ) - Corresponding author. overwhelming choices. While challenging, it is important
• Tien Tuan Anh Dinh, Rui Liu, Ji Wang, Beng Chin Ooi are with the to have a firm grasp on what the technology can and cannot
Department of Computer Science, National University of Singapore, do. A quest for understanding blockchain must ultimately
Singapore. answer the following questions:
E-mail: {dinhtta, liur, wangji, ooibc}@comp.nus.edu.sg
• Meihui Zhang is with Beijing Institute of Technoloy.
E-mail: meihui zhang@bit.edu.cn 1) What is a blockchain? Specifically, what are its
• Gang Chen is with Zhejiang University. unique properties that benefit current and future
E-mail: cg@zju.edu.cn
applications?
1041-4347 (c) 2017 IEEE. Translations and content mining are permitted for academic research only. Personal use is also permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TKDE.2017.2781227, IEEE
2
2) How do current blockchains differ from each other,

both qualitatively in the design and quantitatively
in their performance?
3) What are the current challenges? And what do
future blockchains look like?
To answer these questions, in this paper, we start by
distinguishing two major classes of blockchain systems,
namely public and private blockchains. We then explain
four key technical concepts by which current systems can
be categorized: distributed ledger, cryptography, consensus
protocol and smart contract. Next, we describe BLOCK-
BENCH [10], our benchmarking framework for quantita-
Fig. 1: Blockchain data structure. Transactions are packed
tively evaluate and compare private blockchains. Using
into blocks which are linked to previous blocks.
BLOCKBENCH, we conduct comprehensive evaluation of
three major blockchains: Ethereum [5], Parity [11] and Hy-
perledger [12]. The results show that current blockchains’
data structure which stores historical states and transac-
performance is limited, far below what a state-of-the-art
tions. All nodes in the system agree on the transactions and
database system can offer. Finally, we draw from our experi-
their order. Figure 1 shows the blockchain data structure,
ence in building large-scale database systems several design
in which each block is linked to its predecessor via a
principles that can improve future blockchains.
cryptographic pointer, all the way back to the first (genesis)
Other in-depth surveys of blockchain systems [13], [14]
block. Because of this, blockchain is often referred to as a
focus on crypto-currencies, which is an important block-
distributed ledger.
chain application but it does not fully represent the potential
A transaction in a blockchain is the same as in traditional
of blockchain as a data processing platform. Our work
databases: a sequence of operations applied on some states.
presents a deeper, and broader view of the technology,
As such, the blockchain transaction requires the same ACID
with special emphasis on its performance. In summary, our
semantics. The key difference is the failure model under con-
contributions are:
sideration. Current transactional, distributed databases [15],
1) We provide an in-depth survey of blockchain sys- [16] employ classic concurrency control techniques such as
tems. We discuss state of the art, and categorize two-phase commit to ensure ACID. They can achieve high
current systems along four dimensions: distributed performance, because of the simple crash failure model. In
ledger, cryptography, consensus protocol and smart contrast, the original blockchain design considers a much
contract. hostile environment in which nodes exhibit Byzantine be-
2) We describe our benchmarking framework, havior. Under this model the overhead of concurrency con-
BLOCKBENCH, that is designed for understanding trol is much higher [17].
performance of private blockchains against data At a high level, a blockchain system can be categorized
processing workloads. as either public or private. In the former, any node can join
3) We present a comprehensive evaluation of Eth- and leave the system, thus the blockchain is fully decentral-
ereum, Parity and Hyperledger. The results show ized, resembling a peer-to-peer system [18]. In the latter, the
the limitation of blockchains as data processing blockchain enforces strict membership. More specifically,
platforms. They identify several performance bot- there is an access control mechanism to determine who can
tlenecks, and therefore can serve as a baseline for join the system. As the result, every node is authenticated
future blockchain research and development. and its identity is known to the other nodes.
In the next section, we provide an overview of block-

chain systems, separating them into public and private 2.1 Public Blockchain
settings. Section 3 explains the four building blocks which Bitcoin [1] is the most well known example of public
are used in Section 4 to categorize existing blockchains. blockchains. In Bitcoin the states are digital coins (crypto-
Section 5 describes BLOCKBENCH, followed by the evalu- currencies), and a transaction moves coins from one set of
ation of three blockchains in Section 6. Section 7 discusses a addresses to another. Each node broadcasts a set of transac-
number of lessons learned from the performance study, and tions it wants to perform. Special nodes called miners collect
how to bring design principles from databases to improve transactions into blocks, check for their validity, and start
blockchains. Section 8 concludes. a consensus protocol to append the blocks onto the block-
chain. Bitcoin uses proof-of-work (PoW) for consensus: only
a miner which has successfully solved a computationally
2 B LOCKCHAINS : P RIVATE VS . P UBLIC hard puzzle (finding the right nonce for the block header)
A typical blockchain system consists of multiple nodes can append to the blockchain. PoW is tolerant of Byzantine
which do not fully trust each other. Some nodes exhibit failure, but it is probabilistic in nature: it is possible that
Byzantine behavior, but the majority is honest. Together, the two blocks are appended at the same time, creating a fork
nodes maintain a set of shared, global states and perform in the blockchain. Bitcoin resolves this by only considering
transactions modifying the states. Blockchain is a special a block as confirmed after it is followed by a number of
3
blocks (typically six blocks). This probabilistic guarantee and the ledger records entire history of update operations
leads to security and performance issues: attacks have been made to the states.
demonstrated by an adversary controlling only 25% of the A system supporting distributed ledgers can be charac-
nodes [19], and Bitcoin transaction throughput remains very terized in three dimensions, as illustrated in Table 1. First,
low (7 transactions per second [20]). the application built on top of the ledger determines the
Most public blockchain systems employ variants of PoW data model of what being stored in the ledger. The data
for consensus. PoW works well in the public settings be- model captures key data abstractions, making it easy for
cause it guards against Sybil attacks [18]. However, being the application to express its logic. For example, a crypto-
non-deterministic and computationally expensive, it is un- currency application may adopt the user-account model
suitable for applications such as banking and finance which resembling traditional banking systems. On the other hand,
must handle large volumes of transactions in a deterministic a general-purpose blockchain may use low-level model such
manner. as table or key-value. Second, the system may have one
or more ledgers which may be connected to each other. A
2.2 Private Blockchain large enterprise, for example, may own multiple ledgers,
one for each of its departments: engineering, customer care,
Hyperledger [12] is among the most popular private supply chain, payroll, etc.. Third, ledger ownership may
blockchains. Since node identities are known in the pri- vary from completely open to public to strictly controlled
vate settings, most blockchains adopt one of the protocols by one party. Bitcoin, for example is completely open, and
from the vast literature on distributed consensus. Zab [21], as a consequence requires expensive consensus protocol to
Raft [22], Paxos [23], PBFT [17] are popular protocols that identify who can update the ledger. Parity [11], on the other
are in active use today. Hyperledger directly uses PBFT1 , hand, pre-determines a set of owners who can write to the
while others like Parity [11], Ripple [6] and ErisDB [24] ledger simply by singing the blocks.
develop their own variants. PBFT is a three-phase protocol.
In the pre-prepare phase, a leader broadcast a value to be
commit by other nodes. Next, in the prepare phase, the nodes 3.2 Consensus
broadcast the values they are about to commit. Finally, the
commit phase confirms the committed value when more The content of the ledger reflects historical and current
than two third of the nodes agree in the previous phase. states maintained by the blockchain. Being replicated, up-
PBFT is communication bound, but it achieves both safety dates to the ledger must be agreed on by all parties. In other
and liveness in partially synchronous networks. Besides words, multiple parties must come to a consensus. Note that
deterministic consensus, another key property of private this is not the case in many real-world applications such
blockchains is that they support smart contracts which can as fiat currency, in which one entity (e.g. the bank or the
express highly complex transaction logics. These properties government) decides the updates.
are particularly desirable in business and financial systems. One key property of a blockchain system is that the
Indeed, private blockchains evoke such interest from major nodes do not trust each other, meaning that some may
banking and financial institutions that some even claim that behave in Byzantine manners. The consensus protocol must
they have the potentials to disrupt current practices in data therefore tolerate Byzantine failures. The research litera-
management [8], [9]. ture on distributed consensus is vast, and there are many
variants of previously proposed protocols being developed
for blockchains [25]. They can be largely classified along
3 K EY C ONCEPTS a spectrum. One extreme consists of purely computation
Categorizing blockchains as public or private is useful based protocols that use proof of computation to randomly
for identifying major characteristics of many blockchains. select a node which single-handedly decides the next op-
However, understanding their subtle differences warrants a eration. Bitcoin’s proof-of-work (PoW) is an example. The
finer taxonomy. This section introduces four underpinning other extreme is purely communication based protocols in
concepts, based on which a more detailed classification of which nodes have equal votes and go through multiple
the systems can be obtained. rounds of communication to reach consensus. These proto-
cols, PBFT [17] being the prime example, are used in private
settings because they assume authenticated nodes.
3.1 Distributed Ledger
In between the two extremes are hybrid protocols which
A ledger is a data structure that consists of an ordered list aim to improve performance of PoW and PBFT. Some are
of transactions. For example, a ledger may record monetary used in public blockchains to address the inefficiency of
transactions between multiple banks, or goods exchanged PoW. One example is Proof-of-Elapsed-Time (PoET) which
among known parties. In blockchains, the ledger is repli- replaces PoW with another protocol based on trusted hard-
cated over all the nodes. Furthermore, transactions are ware such as Intel SGX. Other examples are Elastico [26] and
grouped into blocks which are then chained together. Thus, Algorand [27] which improve PoW by randomly sampling
the distributed ledger is essentially a replicated append-only a small set of nodes at each round. Other hybrid protocols,
data structure. A blockchain starts with some initial states, for example Proof-of-Authority (PoA) [28], Stellar [29] and
Ripple [6], are used in private blockchains where they
1. Hyperledger has two main releases: v0.6.0 and v1.0.0-rc1. The
former supports PBFT, but the latter adopts a no-Byzantine consensus improve PBFT by executing consensus in smaller networks
protocol based on Kafka. called federates.
4
TABLE 1: Examples of distributed ledgers.
Data Model Number of ledgers Owner Example

Accounts One Administrator Traditional ledgers used in financial institutions.
Private ledger used within a financial institu-
Assets Many Group of users tion, or between small groups of financial orga-
nizations, e.g. global financial services.
Coins or accounts One Any user Crypto-currencies like Bitcoin or Ethereum.
3.3 Cryptography contract Doubler {

struct Partitipant {
Blockchain systems make heavy use of cryptographic tech- address etherAddress;
niques to ensure integrity of the ledgers. Integrity here uint amount;
}
refers to the ability to detect tampering of the blockchain Partitipant[] public participants;
data. This property is vital in public settings where there uint public balance = 0;
is no pre-established trust. For example, public confidence ...
in crypto-currencies like Bitcoin, which determines values of function enter() {
...
the currencies, is predicated upon the integrity of the ledger; balance+= msg.value;
that is the ledger must be able to detect double spending. ...
Even in private blockchains, integrity is equally essential if (balance >
2*participants[payoutIdx].amount) {
because the authenticated nodes can still act maliciously.
transactionAmount = ...
There are at least two levels of integrity protection. First, participants[payoutIdx].
the global states are protected by a hash (Merkle) tree whose etherAddress.send(transactionAmount);
root hash is stored in a block. Any state change results ...
}
in a new root hash. The tree’s leaves contain the states, }
the internal nodes contain the hashes of their children. For ...
instance, Hyperledger v0.6 uses a bucket hash tree, in which }
states are grouped (by hashing) into a pre-defined number
of buckets. Ethereum, on the other hand, employs a Patricia- Fig. 2: An example of Ethereum smart contract, written in
Merkle tree which resembles a trie and whose leaves are Solidity, which implements a pyramid scheme.
key-value states. Second, the block history is protected, that
is the blocks are immutable once they are appended to the
blockchain. The key technique is to link the blocks through All blockchains have built-in smart contracts that im-
a chain of cryptographic hash pointers: the content of block plement their transaction logics. In crypto-currencies, for
number n + 1 contains the hash of block number n. This example, the built-in smart contract first verifies transaction
way, any modification in block n immediately invalidates inputs by checking their signatures. Next, it verifies that
all the subsequent blocks. By combining Merkle tree and the balance of the output addresses matches that of the
hash pointers, blockchain offers a secure and efficient data inputs. Finally, it applies changes to the states. In the rest
model that tracks all historical changes made to the global of the paper we do not refer to such built-in logics as smart
states. contracts. Instead, we only consider smart contracts that can
Blockchain’s security model assumes the availability be defined by users.
of public key cryptography. Identities, including user and One way to characterize a smart contract system is by
transaction identities, are derived from public key certifi- its language. At one extreme, Bitcoin provides fewer than
cates. Secure key management, therefore, is essential to any 200 opcodes from which users can write stack-based scripts.
blockchains. As in other security systems, losing private For example, the following script verifies if 2 out of 3 valid
keys means losing access. But in blockchain applications signatures are available.
such as crypto-currencies, losing the keys has direct and
OP_2 <Pub1> <Pub2> <Pub3> OP_3 OP_CHECKMULTSIG
irrevocable financial impact. We discuss in Section 4.2 dif-
ferent schemes for key and identity management. At the other extreme, Ethereum smart contracts can specify
There exist many research systems that extend the orig- arbitrary computations, i.e. they are Turing complete code.
inal blockchain design with novel and complex crypto- Figure 2 shows a snippet of a real smart contract running
graphic protocols. They aim to improve security and per- on Ethereum. It implements a pyramid scheme: users send
formance with esoteric techniques such as zero-knowledge money to this contract which then pays interests to early
proofs, group signatures and trusted hardware. We discuss participants. The contract has its own states, namely the list
them in greater detail in Section 4.2. of participants, and exports a function called enter. A user
invokes the contract by sending his money through a trans-
3.4 Smart Contracts action. When executed, the contract can access the input
A smart contract refers to the computation executed when address (user account) via msg.sender and the transaction
a transaction is performed. It can be regarded as a stored value via msg.amount. It updates the accumulated balance,
procedure invoked upon a transaction. The inputs, outputs computes the interest for each participants. Finally, payment
and states affected by the smart contract execution are is made by invoking etherAddress.send.
agreed on by every node. In between the two extremes are smart contract sys-
5
tems that offer more expressiveness than Bitcoin’s op- Digital assets
codes, but they reject Turing-completeness. Kadena [30] Crypto-currency is one instance of digital assets — pieces
and BigchainDB [31] support contracts with complex, but of data with attached real-world values. Unlike crypto-
constrained semantics so that they can be formally checked currencies which are created on and derive their values
for safety. directly from the blockchains, digital assets are often issued
Another way to categorize smart contract systems is by by real world entities and blockchains are merely a medium
their runtime environments. Most systems execute smart to record their existence and exchanges. Multichain [36],
contracts in the same runtime as the rest of the blockchain BigchainDB and Corda offer ledgers for storing and tracking
stack. We refer to them as employing native runtimes. For asset history. Like Bitcoin, their data models are transaction-
example, Kadena parses contracts written in its Haskell-like based which are centered around assets. These systems
language and executes them directly as Haskell programs. target private settings, in which multiple organizations can
Ethereum, on the other hand, comes with its own virtual spin up a network to trade assets among each other. The
machine for executing Ethereum bytecodes. Hyperledger, organizations are the ledger owners, and it is common to
opting for portability, employs Docker containers to execute have more than one ledger among them. Stellar, Ripple and
its contracts. IOTA issue their own assets (tokens) and offer their ledgers
as a medium of exchange or a platform for micro-payment.
IOTA, in particular, allows for zero-fee micropayment via its
4 S TATE OF THE A RT tokens, which makes the ledger useful for exchanges among
IoT devices. The ledgers in these systems adopt account-
In this section we compare current blockchains using the based data models. One ledger exists per system and it is
four concepts discussed in Section 3. We explain their design open; that is anyone can buy tokens and take part in the
in more detail and highlight their subtle differences. We also exchanges.
discuss research problems that are being tackled.
A list of blockchains and their properties are shown General applications
in Table 2. Major systems are included, but we stress that Going beyond crypto-currency and asset management,
the list is not exhaustive, especially given the growing some ledgers support running general, user-defined com-
commercial and academic interest in blockchains. Systems putations (or smart contracts). Ethereum and its derivatives,
shown in italics are either no longer in active development, namely Hydrachain, Quorum, Monax, Parity and Dfinity let
or are still in initial phases of development. For examples, users write arbitrary business logics executed on top of the
Hydrachain [38] codebase was last updated about 8 months ledger. For example, Ethereum contracts range from simple
ago at the time of writing, and IOTA’s current codebase crowdfunding campaigns to complex investment funds like
consists of only a reference implementation2 . The table has the DAO [47]. Dfinity has a special type of contract — the
no column for cryptography, since all systems (except for governance contract — that enforces real-world regulations
ZCash) employ standard techniques described in Section 3. on Ethereum-like blockchains. Hyperledger and its close
Novel cryptographic protocols that are not yet integrated cousin Sawtooth Lake likewise support running Turing-
are discussed in Section 4.2. complete code. They offer key-value data model, with which
the applications can create and update key-value tuples on
the blockchain. Kadena and Tezos restrict how powerful the
4.1 Distributed Ledger applications can be by devising their own languages which
Recall that a system supporting distributed ledgers is are not Turing complete but can be formally verified. Tezos
characterized by its target applications, by the number of data model is account-based, whereas Kadena’s is based on
ledgers, and by the ledger ownership. In the following, table. In particular, Kadena applications operate on key-row
we group the systems listed in Table 2 by their target structures with schemas, versions and column history.
applications3 .
4.2 Cryptography
Crypto-currency Identity management
A user in a blockchain is uniquely identified by her public
The most successful adoption of blockchain technology is
key certificate. In public settings, the user first generates
crypto-currency. In the wake of Bitcoin’s success, multiple
a key pair (the default option being ECDSA based on the
competing currencies appear. Most of these alternative cur-
Secp256k1 elliptic curve), then derives the identity as the
rencies (or alt-coins) such as Litecoin or Dodgecoin, adopt
hash of the public key. This hash serves as a transaction
similar data models to Bitcoin’s. Ethereum, departs from
address or an account number in crypto-currencies systems.
Bitcoin’s transaction-based model and instead implements
To claim ownership of the transaction output or of the
an account-based model. The nature of currency applica-
account, the user signs transactions with the corresponding
tions requires that the ledger must be open and the system
private key. In private settings, there is an additional access
maintains only one ledger.
control layer. Hyperledger separates this layer from the
blockchain, in the form of a membership provider service
2. As many other blockchain projects do, IOTA is raising fund for
development via token sale.
and a certificate authority service. The administrator can
3. We note that each system can also support other applications, implement arbitrary policies with these services to control
limited only by the power of the supported smart contracts. who gets access to the blockchain. Signed requests sent to
6
TABLE 2: Comparison of blockchain systems. Ones in italics are deemed inactive or at early phases of development.
Smart contract
Application Smart contract language Data model Consensus
execution
Hyperledger General
Dockers Golang, Java Key-value PBFT
v0.6.0 [32] applications
Hyperledger General Ordering service
Dockers Golang, Java Key-value
v1.0.0 [33] applications (Kafka)
Transaction-
Bitcoin Crypto-currency Native Golang, C++ PoW
based
Transaction-
Litecoin [34] Crypto-currency Native Golang, C++ PoW (memory)
based
Transaction-
ZCash [35] Crypto-currency Native C++ PoW (memory)
based
General
Ethereum [5] EVM Solidity, Serpent, LLL Account-based PoW
applications
Multichain Transaction- Trusted validators
Digital assets Native C++
[36] based (round robin)
General
Quorum [37] EVM Golang Account-based Raft
applications
HydraChain General Trusted validators
Python, EVM Solidity, Serpent, LLL Account-based
[38] applications (majority)
OpenChain
Digital assets - - Transaction-based Single validator
[39]
IOTA’s Tangle
IOTA [40] Digital assets - - Account-based
Consensus
BigchainDB Transaction Trusted validators
Digital assets Native Python, crypto-conditions
[31] based (majority)
General
Monax [24] EVM Solidity Account-based Tendermint [41]
applications
Ripple [6] Digital assets - - Account-based Ripple consensus
Kadena [30] Pact applications Native Pact Table ScalableBFT [42]
Stellar [29] Digital assets - - Account-based Stellar consensus
General
Dfinity [43] EVM Solidity, Serpent, LLL Account-based Threshold relay
applications
General Trusted validators
Parity [11] EVM Solidity, Serpent, LLL Account-based
applications (round robin)
Michaleson
Tezos [44] Native Michaleson Account-based Proof of Stake
applications
Transaction-
Corda [45] Digital assets JVM Kotlin, Java Raft
based
Sawtooth General
Native Python Key-value Proof of elapsed time
Lake [46] applications
Hyperledger are first checked against these services before mance at a slight cost of security [49], [50]. Sawtooth Lake
processed by the next (consensus) component. Multichain proposes proof of elapsed time (PoET) as an efficient re-
offers a simpler model with a fixed number of global per- placement for proof-of-work. TownCrier [51] employs SGX
missions, while the remaining systems provide little detail to implement a trusted party for vetting external contents
of their protocols. and importing them to the blockchain. These systems are
The problem of managing user keys is the same in based on a trust model that is weaker than that of a
private blockchains as in typical enterprise systems, thus purely cryptographic system. In particular, their security
existing solutions can be readily integrated. In public is dependent upon a trusted computing base (TCB) that is
blockchains, however, the sheer scale and monetary impacts running inside the trusted hardware. Smaller TCBs mean
of losing private keys calls for more secure and more usable better security.
protocols. Bitcoin, in particular, embodies the challenges, as
All systems based on trusted hardware rely on remote
Bitcoin users themselves are tasked with managing large
attestation protocols. A key pair, called Endorsement Key
numbers of keys which are refreshed on new transac-
(EK), is burnt into each device during manufacturing. Such
tions. Eskandari et al. [48] evaluated six approaches for
a key pair serves as the root of trust, from which other short-
Bitcoin key management (or wallet): local storage, pass-
term keys are derived. Before a piece of code is loaded,
word protected storage, offline storage, air-gapped storage,
the hardware measures it by hashing the code content and
password-derived keys, and hosted storage. The authors
signing it with one of the keys. The signed measurement
found that none of these approaches is satisfactorily usable,
together with the key certificate attest to a remote party
due to misuse of metaphors to traditional currencies, and
what is being run in the local device. This protocol requires
also due to confusing abstractions.
a certificate authority that maintains and endorses a list of
known certificates and a list of revoked certificates. Highly
Trusted hardware complex attestation schemes, for example direct anonymous
Recent distributed systems are leveraging trusted hardware attestation [52], offer hardware anonymity without a certifi-
such as Intel SGX and ARM TrustZone to improve perfor- cate authority.
7
Transaction privacy involves four rounds of communication at the end of which

Most blockchains are designed to protect transaction in- a collective signature is generated and verified by all mem-
tegrity, but they do not consider transaction privacy. A bers of the group. The signature is structured as a tree
blockchain is said to have transaction privacy when (1) of Schnorr signatures. It significantly reduces the size of
transactions cannot be linked from one to another, and (2) messages broadcast in the network during the prepare and
the transaction content is known only to its participants. commit phase of PBFT, because each node no longer needs
In private settings, complete transparency of transaction individual signatures from all the other for verification.
history may not be a problem. Either transparency is desir-
able for the applications, such as financial auditing, or it is 4.3 Consensus
straightforward to add an access control layer to protect the
Recall that there is a spectrum of consensus protocols be-
blockchain data. In public settings, on the other hand, the
hind blockchain systems, starting from purely computation
need for transaction privacy is driven by two factors. First,
bound like PoW to purely communication bound like PBFT.
deanonymization attacks have successfully recovered the
Table 3 summarizes key properties of the major protocols
underlying structure of the Bitcoin network [53], and even
which we now explore in detail.
linked Bitcoin addresses to real-world identities [54]. Sec-
ond, transaction linkability can undermine the currency’s
fungibility, rendering some coins more valuable than others Proof of Work variants
due to their histories. All PoW protocols require miners to find solutions to crypto-
Zerocoin [55] is the first blockchain providing transac- graphic puzzles based on cryptographic hashes. Specifically,
tion unlinkability. It extends Bitcoin to allow for trading the solution is a random nonce n such that:
between bitcoins and special coins called zerocoins. Ze-
rocoin essentially implements a cryptographic mixer that H(nkH(b)) < t
hides linkability between zerocoins and the corresponding
for a cryptographic hash function H , a threshold t and
bitcoins. Each zerocoin is a cryptographic commitment to
the current block content b. The original protocol imple-
two random values (s, r). When redeeming a zerocoin, the
mented in Bitcoin uses SHA-256 as the hash function.
owner reveals s as the proof that the coin has not been spent,
The availability of custom hardware (ASIC) that speeds
and a zero-knowledge proof of r. Transaction unlinkability
up hash computation prompts other crypto-currencies to
is derived from the fact that the coin being redeemed can be
adopt memory-hard hash functions. Ethereum uses Dagger-
any of the many unspent zercoins.
Hashimoto function, Litecoin and Dodgecoin use scrypt,
Zerocash [35] extends Zerocoin by improving efficiency
and ZCash uses Equihash function. These functions are
of the latter’s cryptographic operations. It functions as a
resistant to ASIC, as they demand large investment in
stand-alone blockchain, as opposed to Zercoin being an ex-
memory, but are easy to verify.
tension of Bitcoin. Transactions in Zerocash, including split
How fast a block is created is dependent on how hard
and merge transactions, are fully private. They are based on
the puzzle is. Bitcoin sets t to a value equivalent of 10
complex zero-knowledge proofs which only reveal the fact
minutes per block. Litecoin, Dodgecoin and ZCash decrease
that there exists unredeemed coins whose sum is a specific
t to achieve lower average block time to several minutes.
value. Both Zerocoin and Zerocash are implemented using
t cannot be arbitrary small because it leads to unnecessary
zkSNARK [56] and carry large overheads due to the un-
forks in the blockchain. Forks not only lead to wastage of
derlying zero-knowledge protocols. Zerocash, for instance,
resources but have security implication since they make it
requires a trusted party to securely create and distribute
possible to double spend. Ethereum adopts GHOST [75]
some public parameters whose sizes are in hundreds of
protocol which helps bring down block generation time to
megabytes.
tens of seconds without compromising much security. In
Advanced signatures GHOST, the blockchain is allowed to have branches as long
Bitcoin supports multi-signatures, in which a transaction as the branches do not contain conflicting transactions.
can be redeemed when at least t out of n valid signatures
are available. Multi-signatures are resilient against corrupt Proof of Stake
individuals by virtue of spreading the decryption or singing PoW mining is hugely expensive. The process is partic-
capabilities to a group of users. Lightning Network [57], ularly energy intensive, and has been estimated to con-
an extension of Bitcoin with near-instant payment consume enough electricity to power a small country like
firmation, relies on multi-signatures to first deposit some Denmark [76]. PoS is proposed to substantially reduce the
mutual funds on the blockchain. Once confirmed, payments cost of mining. Unlike Ethereum’s GHOST, PoS maintains
from the funds can happen outside of the blockchain with a single branch but changes the puzzle’s difficulty to be
immediate confirmation. Finally, the funds can be closed inversely proportional to the miner’s stake in the network.
with corresponding transactions signed with all the required A stake is essentially a locked account with a certain balance
signatures. Extensions of Bitcoin multi-signature scheme can representing the miner’s commitment to keep the network
be built directly on top of ECDSA [58]. More advanced healthy. Let s be the function that returns the stake, then a
schemes, e.g. [59], [60], can be employed (albeit not without miner M can generate a new block by solving the puzzle of
major changes in the current design). the following form:
Byzcoin [61] uses a group signature scheme called
Cosi [62] to reduce communication overhead in PBFT. Cosi H(nkH(b)) < s(M ).t
8
TABLE 3: Comparison of consensus protocols.
Consensus Protocol Network Settings Description

Hyperledger uses the original PBFT [17]. Tendermint [41] en-
hances it by assigning unequal weights to votes. Other variants
PBFT-based Private
include Scalable BFT [63], Parallel BFT [64], Optimistic BFT [65],
etc.
Stellar network [66] proposes its own consensus protocol where
Stellar Federated the nodes form intersecting groups (federates). Consensus is
agreed in each group, then propagated to the rest of the network.
Ripple payment system [6] proposes a variant of PBFT where the
Ripple Federated nodes belong to intersecting groups, and in each group there is a
large majority of non-Byzantine nodes.
Bitcoin uses pure proof-of-work, which leads to scalability issues.
Proof-of-Work (PoW) Public Bitcoin-NG [67], Byzcoin [61] separate leader election from trans-
action validation in PoW, thus increase the overall performance.
Tendermint [41] uses PoS, in which a node’s ability to create new
block is determined by its stake in the blockchain, e.g. the amount
Proof-of-Stake (PoS) Public of currencies it owns [68]. A set of high-stake owners uses another
consensus mechanism, which is usually faster than PoW, to reach
agreement on a new block.
Dfinity [43] proposes threshold relay in which nodes form random
group based on a public verifiable random function (Byzcoin [61]
Threshold Relay Public
and Elastico [26] adopt similar approaches). The nodes in the
group create a new block by signing it using threshold signature.
Parity [11] uses PoA, in which some pre-defined nodes are consid-
ered trusted authorities and they can propose the next blocks. It
Proof-of-Authority (PoA) Private
then uses round-robin scheduling to assign every authority node
a time window during which it can propose blocks.
Slimcoin [69] uses PoB, in which a node destroys some base
currencies it owns in another blockchain in order to get a chance
Proof-of-Burn (PoB) Public
of proposing a new block. Slimcoin supports PoB based on
Peercoin [70].
Sawtooth [46] uses PoET, in which each node runs a trusted
hardware, for example Intel SGX [71], that generates random
Proof-of-Elapsed Time (PoET) Private
timers. The first node whose timer has expired can propose the
next block.
Other protocols based on PoW are of the form proof-of-X, for
Others Public examples: Proof-of-Activity [72], Proof-of-Space [73], Proof-of-
Luck [74], etc.
It can be seen that the greater the stake s(M ), the easier it is loses its deposit. This mechanism avoids the nothing-at-stake
to find n. problem in which validators can propose blocks in different
Peercoin, forked from Bitcoin, is among the first systems branches. Tezos implements a simplified version of Casper
with PoS. It bootstraps by running PoW to generate coins. in which the nodes buy in to become authorities which can
The function s(.) in Peercoin takes a coin C as input and then approve changes to the underlying blockchain. Tezos
returns C.age(C) where age(C) is the coin’s age. Nxt [77], aims to provide an amendable blockchain in which soft
another PoS system, bootstraps by selling its tokens. The forks and hard forks are inherent features of the blockchain.
function s(.) in Nxt considers both the miner’s balance and
the elapsed time from the last block. The longer it is since PBFT variants
the last block, the easy it is to solve the puzzle. In particular: PoW suffers from non-finality, that is a block appended
to a blockchain is not confirmed until it is extended by
s(M, bh ) = bal(M ).age(bh−1 ) many other blocks. Even then, its existence in the block-
chain is only probabilistic. For example, eclipse attacks on
where bh is the current block at height h, bal(M ) returns Bitcoin [78] exploit this probabilistic guarantee to allow
how many coins in M ’s account, and age returns how much double spending. In contrast, the original PBFT protocol [17]
time has passed since the creation of a block at a certain is deterministic. Implemented in the earlier version of Hy-
height. perledger (v0.6), the protocol ensures that once a block is
Ethereum’s upcoming PoS protocol is implemented as appended, it is final and cannot be replaced or modified. It
a smart contract. Referred to as Casper, it allows miners incurs O(N 2 ) network messages for each round of agree-
to become validators by depositing Ethers to the Casper ment where N is the number of nodes in the network. In
account. The contract then picks a validator to propose practice, however, the original protocol scales poorly and
the next block according to the deposit amount. Its unique collapses even before reaching the network limit [79]. We
feature, however, is to force validators to behave correctly observe the same scalability issues in our evaluation of
or else risk losing the entire deposit. In particular, each Hyperledger with BLOCKBENCH.
validator places a bet on whether a certain block will be Tendermint proposes a small modification on top of
confirmed in the future. If the block is confirmed, the PBFT. Instead of each node having an equal vote, in Ten-
validator gets a small reward. But if it is not, the validator dermint each node may have different voting power, pro-
9
portional to their stake in the network. To reach agreement there is a large majority of honest nodes in every federate,
in Tendermint it is necessary to only gather over 2/3 of the and that the intersection of any two federates contain at least
total voting power. This may be cheaper than waiting for one honest node.
2/3 of the network to response when there is a small number Both Stellar and Ripple assume federates are pre-defined
of nodes with high stakes. and their safety conditions can be enforced by a network
Recent works on improving PBFT have mainly focused administrator. In a decentralized environment where node
on its performance. Zyzzyva [80] optimizes for normal identities are unknown, such assumptions do not hold.
cases (when there are no failures) via speculative execution. Byzcoin [61] and Elastico [26] propose novel, two-phase
XFT [81], assumes a network less hostile than purely Byzan- protocols that combine PoW and PBFT. In the first phase,
tine, and demonstrates better performance by reducing the PoW is used to form a consensus group. Byzcoin imple-
number of network messages. HoneyBadger [82], on the ments this by having a sliding window over the blockchain
other hand, focuses on improving security under asyn- and selecting the miners of the blocks within the window.
chronous networks. It employs a randomized agreement pro- Elastico [26] groups nodes by their identities that change
tocol which achieves safety with overwhelming probability every epoch. In particular, a node identity is its solution to
even under network asynchrony. By optimizing the network a cryptographic puzzle. In the second phase, the selected
layer, it is shown to outperform PBFT even when the net- nodes perform PBFT to determine the next block. The end
work is synchronous. Both Zyzzyva, XFT and HoneyBadger result is faster block confirmation time at a scale much
hold great promise, but they have not been integrated into greater than traditional PBFT (over 1000 nodes).
any blockchains. Similar to Byzcoin and Elastico, Dfinity [43] and Algo-
rand [27] select at each round a random set of nodes that
Trusted hardware can propose blocks. Unlike the former, they dispense with
Most overheads of PoW and PBFT can be attributed to PoW and instead use verifiable random functions (VRFs) to
the assumption that nodes behave in Byzantine manners. select the consensus group. In Dfinity, the VRF is based on
The availability of Intel SGX [83] or ARM TrustZone [84], the threshold signature of the previous block. In Algorand,
however, makes it possible to relax the trust model in the it is based on a random seed published in the previous block
Byzantine settings. In particular, a node equipped with and the node’s secret key.
trusted hardware can be reliably checked for certain proper-
ties, for example, that it is running a specific software. Non-Byzantine
Sawtooth Lake leverages SGX to replace PoW with a The systems described so far in this section tolerate Byzan-
more efficient protocol called PoET. Specifically, PoET runs tine failures, rendering them attractive for public settings
inside an enclave protected by SGX. It starts by taking a and for private settings where the cost of engaging trusted
block number as input and generating a timer of a random parties (for example, for escrowing assets) is high. Some
duration t. Afterward, it can produce certificates indicating blockchains, however, assume trusted parties in order to
how much time has passed since the timer starts. A node simplify their designs. These blockchains have no safety
whose PoET generates the smallest t can append the block guarantees when any of such parties behaves maliciously.
when the timer expires. In particular, the node attaches its Openchain [39] relies on a single trusted party (called
PoET certificate to the block, and as long as t is smaller than validator) that determines the next block. Consequently, it is
what generated by any other node the block is accepted. most vulnerable to attacks as the validator is the single point
A2M [85] and Hybster [86] both exploit trusted hardware of failure. Multichain and Parity have more than one trusted
to reduce the number of replicas needed to tolerate f failures party which is referred to as authority in their systems. Each
from 3f + 1 to 2f + 1. This means an N -node network authority is given a time slice, via round-robin scheduling,
can now tolerate up to N/2 adversarial nodes, as opposed during which it can append new blocks to the chain. This
to N/3 adversarial nodes in the original PBFT. A2M’s and simple proof-of-authority (PoA) protocol avoids single point
Hybster’s safety are dependent on the trusted code bases of failure while ensuring balanced workloads among the
(TCBs) that implement simple functions: a log data structure authorities. HydraChain and BigChainDb also have multi-
in the former and a monotonic counter in the latter. ple authorities, but one authority cannot unilaterally decide
the next blocks. Instead, the block is decided via majority
Federated voting. Quorum [37] employs Raft [22] as the consensus pro-
Despite numerous improvements to the original protocol, tocol among its authorities. Raft implements crash tolerant
PBFT-based consensus remains communication bound, thus state machine replication, which is an important building
it ultimately fails to scale beyond a certain number of nodes. block of modern distributed database systems. Using Raft,
To overcome this hard limit without scarifying safety, Stellar Quorum is able to make safe progress even when some
and Ripple adopt an approach that partitions the network authority nodes crash.
into smaller groups called federates. Each federate runs a lo- Corda’s consensus protocol is executed by a set of
cal consensus protocol among its members, which does not trusted parties called notaries which check if a given transac-
run into scalability problems because of the small network tion has been executed before. By delegating this check to an
size. Local agreements are then propagated to the entire entity outside of the blockchain, Corda can justify using Raft
network via nodes lying in the intersections of the federates. for consensus. Transactions in Corda are sent to the notaries
Global consensus can be achieved under certain conditions. before being confirmed in the blockchain. The notaries then
For Stellar, the condition is that every two federates intersect use Raft to ensure that the transactions are replicated among
at non-Byzantine nodes. Ripple’s safety conditions are that themselves and remain highly available despite crashes.
10
The latest release of Hyperledger (v1.0) outsources the either Solidity, Serpent or LLC language, which then get
consensus component to Kafka — another building block of- compiled to EVM bytecodes. EVM executes normal crypto-
ten found in distributed database systems. More specifically, currency transactions, and it treats smart contract bytecodes
transactions are sent to a centralized Kafka service which as a special transaction. Specifically, each smart contract is
orders them into a stream of events. Every node subscribes given its own memory to store local states. The memory is
to the same Kafka stream and therefore is notified of new exposed as a key-value storage, though Solidity provides
transactions in the same order as they are published. Since high-level data types such as map, array and composite
there is only one Kafka service, the observed transaction structures. Resources consumed during execution of the
sequence is the same at every node. contract, both in terms of CPU and memory, are tracked by
EVM and charged to the transaction sender’s account. EVM
Others also keeps track of intermediate state changes and reverse
IOTA [40] uses its own consensus protocol called Tangle them if there are insufficient funds to pay for the execution.
in which the blocks form a direct acyclic graph (DAG) as Hyperledger does not have its own bytecotes. Instead,
opposed to a chain. In addition, a block in Tangle consists it runs its language-agnostic smart contracts inside Docker
of only one transaction. When appended, the block must containers. Specifically, a contract can be written in any
approve two other blocks creating links to them in the DAG. language, which is then compiled into native code and
The block is confirmed when it is approved by many other packed into a Docker image. When the contract is uploaded,
blocks. Targeting IoT environments, Tangle’s main goal is each node starts a new container with that image. Invoking
efficiency and low-cost payment. Although its security has the contract is done via Docker APIs. The contract can access
not been rigorously analyzed, the low values of transactions the blockchain states via two methods getState and putState
(micropayments) in Tangle could in practice discourage exposed by a shim layer. One benefit of Hyperledger is that
Byzantine behavior. it supports multiple high-level programming languages like
Kadena [30] proposes an extension to Raft that handles Go and Java. However, its key-value interfaces with the
Byzantine failures. It introduces various techniques on top blockchain necessitates extra application logics for mapping
of Raft, such as message signatures, client verification and high-level data structures into key-value tuples.
incremental hashing. However, like Tangle, it is unclear Sawtooth Lake supports smart contracts in the form of
whether the protocol guarantees safety and liveness. transaction families. Each family is a user-defined Python
class loaded into the ledger during start up. The contract
is executed in the native runtime environment as a normal
4.4 Smart Contracts
Python program.
Recall that a smart contract system can be characterized by One consequence of supporting Turing complete con-
its language expressiveness or by its execution environment. tracts is that software bugs are all but inevitable. While
Except for Openchain, IOTA, Ripple and Stellar, all systems empowering, the Ethereum smart contract model receives
listed in Table 2 let users customize transaction logics to suit strong criticism because it directly exposes Ethers against
their applications. In the following, we group them by the programming bugs. The security concerns indeed material-
contract language expressiveness. ized in the DAO attack [47] in which the attacker stole $50M
worth of asset. The attack exploits a concurrency bug in the
Scripts DAO smart contract which allows one to repeatedly draw
Bitcoin provides approximately 200 opcodes, but many of more money than what is specified in the transaction. Such
them are disabled in the latest implementation. Users can bugs are inherent in a language like EVM which has weak
write stack-based programs with the opcodes. The most or no formal specifications of its semantics. OYENTE [88]
popular contracts in Bitcoin are related to multi-signatures. presents three major causes of security bugs: transaction
One example is the escrow contract that requires 2 out of 3 order dependencies, timestamp dependencies and mishan-
signatures before a coin can be released. The language can dled exceptions. It formalizes Ethereum semantics and pro-
also implement bounty-hunting style contracts, for example, poses a tool for checking bugs directly on EVM bytecodes.
one that releases the reward coins when the pre-image of a The tool discovered over 8000 Ethereum contracts (worth
hash value is found. over $60M ) with potential security bugs.
BigchainDB [31] adopts a more expressive language Like any other transactions on the blockchain, smart
called crypto-condition. Developed as part of the Interledger contract executions are transparent. It means the inputs,
Protocol project [87], crypto-condition allows specifying outputs and the states of the contract are visible to the
complex boolean expressions over many types of signatures. network. Hawk [89] extends Zerocash to provide transaction
A crypto-condition script contains conditions and fulfillments privacy for smart contracts. The main challenge compared
which are treated as inputs and output of the script. The to Zerocash lies in the arbitrary transaction logics, whereas
available conditions include timeout which enables time- in Zerocash the logics are constrained by a small set of oper-
release contracts. Crypto-condition’s encoding is higher ations. Another challenge is to protect local states, which is
level than Bitcoin opcodes, making it easy to express com- not applicable in Zerocash. Given a contract, Hawk compiles
plex logics. it with zkSNARK to make it privacy preserving. Transaction
inputs and outputs are pre- and post-processed via Hawk to
Turing complete hide the complex cryptographic details. Although the pro-
Ethereum is among the first blockchains offering Turing- tocols incur large overhead both in time and space, Hawk
complete smart contracts. Users write their contracts in represents a practical cryptographic system that achieves
11
Fig. 4: Blockchain software layers and corresponding bench-

mark workloads.
includes details of the runtime environment for execut-

ing smart contracts. Finally, the application layer includes
Fig. 3: Blockchain software stack on a fully validating node. classes of blockchain applications. Croman et. al. [20] pro-
posed to divide blockchain into several planes: network,
consensus, storage, view and side plane. While similar to
both transaction privacy and fairness. BLOCKBENCH’s four layers, the plane abstraction was
geared towards crypto-currency applications and did not
Verifiable take into account the execution of smart contracts.
Even before the DAO attack, some blockchains have rejected
the models that allow for unconstrained computations. The 5.2 Implementation
languages of Kadena, Tezos and Corda are more powerful BLOCKBENCH stack consists of a frontend interface for
than Bitcoin scripts, but they trade Turing completeness for integrating new benchmark workloads, a backend inter-
safety. Kadena’s language is a Lisp-like functional language face for integrating new blockchains, and a driver for
called Pact [30]. A Pact contract is stored in the ledger in driving the workloads. A new blockchain can be inte-
human readable form, which is then parsed and executed in grated into the framework’s backend by implementing the
Ocaml. It is strongly typed and can be formally verified. IBlockchainConnector interface. The interface contains
Similarly, Tezos’s stack-based language called Michelson operations for deploying the smart contract application,
comes with a strong type system and fully specified seman- invoking it by sending a transaction, and for querying the
tics. As a result, Tezos contracts can be statically checked for blockchain states. Ethereum, Parity and Hyperledger are the
safety. In Corda, a contract is a sequence of pure functions current backends, while ErisDB (or Monax), Quorum and
that do not modify the states. Because the functions are Sawtooth Lake integration are under development. A new
merely constraints, the contract’s safety can be formalized benchmarking workload can be added by implementing
and verified. IWorkloadConnector interface4 . The Driver takes as
input a workload and sends transactions to the blockchain
5 BLOCKBENCH according to user-defined configurations (number of oper-
The previous section has presented a thorough qualitative ations, number of clients, threads, etc.). It collects runtime
analysis of existing blockchains. In this section, we describe statistics which are used to compute five important metrics.
our benchmarking framework called BLOCKBENCH [10]. • Throughput: the number of successful transactions
Designed for quantitative analysis of blockchains as per second. A workload can be configured with
data processing platforms, the framework targets private multiple clients and threads per clients to saturate
blockchains with Turing-complete smart contracts. BLOCK- the blockchain throughput.
BENCH is open source [90] and contains data processing • Latency: the response time per transaction. Driver
workloads commonly found in database benchmarks. implements blocking transactions, i.e. it waits for one
transaction to finish before starting another.
5.1 Layers • Scalability: the changes in throughput and latency
when increasing the number of nodes and number
BLOCKBENCH targets blockchains that function as data
of concurrent workloads.
processing platforms. Such a blockchain must have no re-
• Fault tolerance: the changes in throughput and la-
strictions on the application logics, thus it must support
tency during node failure. We simulate crashes, net-
Turing complete smart contracts. Figure 3 shows the logical
work delays and random message corruptions.
components of the blockchain software stack, from which
• Security metrics: the ratio between the total number
we refine the taxonomy described in Section 4 into four
of blocks included in the main branch and the total
concrete layers shown in Figure 4. For each layer there
number of confirmed blocks. The lower the ratio, the
are multiple BLOCKBENCH workloads for evaluating it
less vulnerable the system is from double spending
individually.
or selfish mining.
The consensus layer implements the consensus protocol.
The data model layer contains the structure, content and 4. We assume that the smart contract implementing the workload’s
operations on the blockchain data. The execution layer logic is already implemented and deployed on the blockchain.
12
5.3 Workloads type account_t struct {

Balance int
BLOCKBENCH comes with macro benchmark workloads CommitBlock int
for evaluating the application layer, and micro benchmark }
type transaction_t {
workloads for analyzing the lower layers. Smart contract From string
implementations of the workloads shown in Figure 4 are To string
available and can be readily deployed on Ethereum, Parity Val int
and Hyperledger. }
func Invoke_SendValue(from_account string,
to_account string, value int) {
Macro benchmark workloads var pending_list []transaction_t
pending_list = decode(GetState("pending_list"))
We port two popular database benchmark workloads into var new_txn transaction_t
BLOCKBENCH, namely YCSB and Smallbank. YCSB is new_txn = transaction_t {
widely used for evaluating NoSQL databases, for which from_account, to_account, value
}
we implement a simple smart contract which functions as pending_list = append(pending_list, new_txn)
a key-value storage. The WorkloadClient is based on PutState(’pending_list’, encode(pending_list))
the YCSB driver [91] which preloads each storage with a }
number of records, and supports requests with different func Query_BlockTransactionList(block_number int)
[]transaction_t {
ratios of read and write operations. For Smallbank [92], a return decode(GetState("block:"+block_number))
popular benchmark for OLTP workload, we implement a }
smart contract that transfers money from one account to func Query_AccountBlockRange(account string,
start_block int, end_block int)
another.
[]account_t {
Besides database workloads, BLOCKBENCH also pro- version := decode(GetState(account+":latest"))
vides three other workloads based on real Ethereum con- var ret []account_t
tracts. The first is EtherId, a popular contract implementing while true {
var acc account_t
a domain name registrar. The second is Doubler, the pyramid acc = decode(GetState(account+":"+version))
scheme contract shown earlier in Figure 2. The third is if acc.CommitBlock >= start_block &&
WavesPresale that implements a crowdfunding campaign via acc.CommitBlock < end_block {
digital token sales. ret = append(ret, acc)
} else if acc.CommitBlock < start_block {
break;
Micro benchmark workloads }
version -= 1
For the consensus layer, BLOCKBENCH provides DoNoth- }
ing workload in which the smart contract accepts a trans- return ret
action as input and simply returns. Since the contract }
execution involves minimal number of operations at the
execution and data model layer, the overall performance Fig. 5: Code snippet from the VersionKVStore smart contract
will be determined by the consensus layer. for Analytics workload (Q1 and Q2).
For the data model layer, BLOCKBENCH provides Ana-
lytics workload that is similar to an OLAP workload. In par-
ticular, it performs scan-like and aggregate queries whose account and returns the corresponding balance when the
performance is determined by the system’s data model. version’s CommitBlock value is in the specified range.
Specifically, there are two queries: Another workload for the data model layer stresses
the persistent storage. In particular, the IOHeavy workload
Q1: Compute the total transaction values committed between evaluates the blockchain’s IO performance by invoking a
block i and block j. contract that performs a large number of random writes and
Q2: Compute the largest transaction value involving a given random reads to the local states.
state (account) between block i and block j. Finally, for the execution layer BLOCKBENCHprovides
For Ethereum and Parity, both queries can be implemented the CPUHeavy workload. It measures the efficiency of the
via JSON-RPC APIs that return transaction details and ac- execution layer for computationally heavy tasks by invoking
count balances at a specific block. For Hyperledger, how- a contract that executes quick sort algorithm over a large
ever, the second query must be implemented via a smart array.
contract (VersionKVStore), because Hyperledger has no
APIs for querying historical states. Figure 5 shows the con-
tract implementation in Hyperledger. To support historical
6 E VALUATION
data lookup, the contract appends a counter to the key of We selected Ethereum, Parity and Hyperledger for a com-
each account. To fetch a specific version of an account, the parative study using BLOCKBENCH. They occupy different
key account:version is used. The latest version is stored positions in the design space, and are considered the most
at the key account:latest. The contract also keeps keep mature in terms of the codebase and user base. We used
a CommitBlock value in the data field for every version the popular Go implementation of Ethereum, geth v1.4.18,
to point to the block number in which the current version the Parity release v1.6.0. Unless otherwise specified, the
is committed. To fetch the balances of a given account in Hyperledger version is v0.6.0-preview. We set up a private
a given block range, the contract scans all versions of this testnet for Ethereum and Parity by defining a genesis block
13
Throughput Latency Throughput vs. HStore

Ethereum Ethereum Ethereum 142702
Parity 103 Parity 105 Parity
4
10 Hyperledger Hyperledger Hyperledger 21596
114 H-Store
2 92 104
10
1273 1122 38
51
#tx/s
second
103
#tx/s
1273 1122
103
284 255 101
284 255
3 4
102 102
45 46 100 45 46
101
YCSB Smallbank
101 10−1
YCSB Smallbank YCSB Smallbank
Fig. 7: Performance of the three blockchain systems versus

Fig. 6: Blockchain peak performance with 8 clients and H-Store.
8 servers. The benchmark workload is YCSB. The perfor-
mance against Smallbank workload is similar.
and directly adding peers to the miner network. For Eth- other two in both benchmarks. The gap between Hyper-
ereum, we manually tuned the difficulty variable in the ledger and Ethereum is due to the difference in the con-
genesis block to ensure that miners do not diverge in large sensus protocols: one is based on PBFT while the other is
networks. For Parity, we set the stepDuration variable to based on PoW. With 8 servers, the communication cost from
1. In both Ethereum and Parity, confirmationLength is broadcasting messages is cheaper than block mining whose
set to 5 seconds. The default batch size in Hyperledger is difficulty is set at roughly 2.5s per block. The gap between
500. Parity and Hyperledger is not due to consensus protocols,
The experiments were run on a 48-node commodity clus- as Parity’s PoA protocol is expected to be simpler and more
ter. Each node has an E5-1650 3.5GHz CPU, 32GB RAM, 2TB efficient than both PoW and PBFT. Instead, we observe that
hard drive, running Ubuntu 14.04 Trusty, and connected to Parity processes transactions at a constant rate, and that it
the other nodes via 1GB switch. For Ethereum, we reserved enforces a maximum client request rate at around 80 tx/s.
8 cores out of the available 12 cores per machine, so that
the periodic polls from the client’s driver process do not To put their performance in context, we compare the
interfere with the mining process. Our main findings are as three blockchains against a popular in-memory database
follows: system, namely H-Store, using the YCSB and Smallbank
workload. Blockchains and databases do not necessarily
• Hyperledger performs consistently better than Eth- share the same design goal: the former are not designed
ereum and Parity across the benchmarks. But it fails for general data processing, nor do the latter protect data
to scale up to more than 16 nodes. integrity against Byzantine failures. Nonetheless, we argue
• Ethereum and Parity are more resilient to node fail- that the comparison offers useful insights into the design
ures, but they are vulnerable to security attacks that trade-offs and relative performance of the two systems. We
forks the blockchain. ran H-Store’s own benchmark driver and set the transaction
• The main bottlenecks in Hyperledger and Ethereum rate at 100,000 tx/s. Figure 7 shows at least an order of mag-
are the consensus protocols, but for Parity the bottle- nitude gap in throughput and two order of magnitude in la-
neck is caused by transaction signing. tency. Specifically, H-Store achieves over 140K tx/s through-
• Ethereum and Parity incur large overheads in terms put while maintaining sub-millisecond latency. The gap in
of memory and disk usage. Their execution engine is performance is due to the cost of consensus protocols. For
also less efficient than that of Hyperledger. YCSB, for example, H-Store requires almost no coordination
• Hyperledger’s data model is low level, but its flexi- among peers, whereas Ethereum and Hyperledger suffer the
bility enables customized optimization for analytical overhead of PoW and PBFT. An interesting observation is
queries. the overhead of Smallbank. Recall that compared to YCSB,
Smallbank consists of more complex transactions in which
multiple keys are updated in a single transaction. Smallbank
6.1 Macro benchmarks is simple but is representative of the large class of transac-
This section discusses the performance of the blockchains tional workloads such as TPC-C. We observe that in H-Store,
at the application layer, using YCSB and Smallbank bench- Smallbank achieves 6.6x lower throughput and 4x higher
marks. latency than YCSB, which reflects the cost of distributed
transaction management. In contrast, the blockchains suffer
modest degradation in performance: 10% in throughput and
Throughput and latency 20% in latency. This is because each node in the blockchains
Figure 6 shows the peak performance with 8 servers and 8 maintains the complete states, therefore it pays no overhead
concurrent clients over the period of 5 minutes. We observe in coordinating distributed transactions since the states are
that in terms of throughput, Hyperledger outperforms the not partitioned.
14
Throughput Latency
and the default behavior is to drop messages when the
104
Ethereum Ethereum queue is full. In the current design, both client requests
Parity 103 Parity (transactions) and consensus messages (pre-prepare, pre-
Hyperledger Hyperledger
pare, commit, view changes) are sent on the same channel,
103 102 that is they share the same queue. For large numbers of
second
#tx/s
concurrent clients and servers, the channels are dominated

101
by client requests, increasing the probability of consensus
102
messages being dropped. Without a sufficient number of
100
consensus messages, either a batch timer or a view-change
101 10−1
timer will expire. In the first case, the PBFT leader resends
12 4 8 12 16 20 24 28 32 12 4 8 12 16 20 24 28 32
#nodes #nodes
messages of the current consensus round. In the second,
the servers start the view change phase which broadcasts
multiple rounds of consensus messages. As client requests
Fig. 8: Performance scalability (with the same number of
are still occupying the network channels, both consensus or
clients and servers). The benchmark workload is YCSB.
view change messages are dropped with high probability.
The scalability against Smallbank is similar, except that
Consequently, the network gets stuck in perpetual attempts
Hyperledger fails beyond 8 nodes instead of 16.
to establish a stable view. The fact that PBFT is sensitive to
network conditions has been observed in the past [79].
1400 Throughput 180 Latency We note that in its latest release (v1.0) Hyperledger has
160
Ethereum replaced PBFT with a global ordering service. Implemented
1200 Parity
140 Hyperledger using Kafka, this new consensus engine may offer higher
1000
120
throughput than PBFT, but it offers no protection against
800 Ethereum 100
Byzantine failures.
second
#tx/s
Parity The results so far indicate that scaling both the number of
600 Hyperledger 80
clients and number of servers degrades the performance and
60
400 even causes Hyperledger to fail. We next examined the costs
40
200
of increasing the number of servers alone while fixing the
20
number of clients to 8. Figure 9 shows that the performance
0 0
8 12 16 20
#nodes
24 28 32 8 12 16 20
#nodes
24 28 32 becomes worse as there are more servers, meaning that the
systems incur some network overheads. For Hyperledger,
Fig. 9: Performance scalability (with 8 clients). having more servers means more messages being exchanged
and higher overheads. In particular, to a confirm a batch of
transaction in a larger network, the leader in Hyperledger
Scalability needs to wait for larger sets of messages, therefore lowering
overall throughputs. We note that with a fixed number of
We fixed the client request rate (320 requests per second clients Hyperledger can scale up to 32 nodes, as oppose
for Hyperledger, 160 requests per second for Ethereum and to failing after 16 nodes as in Figure 8. This is because
Parity) and increased both the number of clients and the with fewer clients, the message queues at each node are
number of servers. Figure 8 illustrates how well the three not saturated with client requests and therefore consensus
systems scale to handle larger YCSB workloads. Parity’s messages are less likely to get dropped.
performance remains constant as the network size and For Ethereum, even though it is computation bound,
offered load increase, due to the constant transaction pro- it still consumes a modest amount of network resources
cessing rate at the servers. Interestingly, while Ethereum’s for propagating transactions and blocks to other nodes.
throughput and latency degrade almost linearly beyond 8 Furthermore, with larger network, the difficulty is increased
servers, Hyperledger stops working beyond 16 servers. to account for the longer propagation delays. We observe
To understand why Hyperledger failed to scale beyond that to prevent the network from diverging, the difficulty
16 servers and 16 clients, we examined the system logs and level increases at a higher rate than the number of nodes.
find that the nodes never reached consensus on any batch of Thus, one reason for Ethereum’s throughput degradation is
transactions. We observe a large number of messages being due to network sizes. Another reason is that in our settings,
dropped even when there are fewer than 16 servers and 8 clients send requests to only 8 servers, but these servers
clients. Furthermore, the servers repeatedly triggered view do not always broadcast transactions to each other (they
changes but never succeeded. At the client side, requests keep mining on their own transaction pool). As a result, the
took longer to return as time passed, suggesting that the network mining capability is not fully utilized.
server or the network were saturated. Since the original
PBFT protocol guarantees both liveness and safety, we can 6.1.1 Fault tolerance and security
attribute this failure to scale to Hyperledger’s implementa- To evaluate how resilient the systems are to crash failures,
tion. Further investigation reveals that it is indeed the case. we ran the systems with 12 and 16 servers, with 8 clients for
Hyperledger uses gRPC for communication between over 5 minutes, during which we killed off 4 servers at 250th
servers. Each server keeps a separate message queue for second. Due to space constraints, we only highlight key
every other servers in the network. The queue size is defined findings here and refer readers to [10] for more details. First,
during initial setup (the default size being 1000 messages) Ethereum is unaffected by the change, suggesting that the
15
500 #Blocks generated 104 Execution time Peak memory usage

Ethereum-bc Parity-bc Hyperledger-bc Ethereum Ethereum
Ethereum-total Parity-total Hyperledger-total Parity Parity
400 103
Hyperledger 108 Hyperledger
232.78
102 79.61
300 22,819
#blocks
24.04
second
13,090
10.52 7
MB
10 1 10
200 3.01 4,150
1.94
2,078
100 1,353
100 0.33
0.19 106 718
473
10 −1 376
0
0 50 100 150 200 250 300 350 400 x x
time (second) 10−2 105
1M 10M 100M 1M 10M 100M
input size input size
Fig. 10: Blockchain forks caused by attacks that partitions

Fig. 11: CPUHeavy workload, ‘X’ indicates Out-of-Memory
the network in half at 100th second and lasts for 150 sec-
error.
onds. X-total means the total number of blocks generated in
blockchain X, X-bc means the total number of blocks that
reach consensus in blockchain X.
6.2 Micro benchmarks
This section discusses the performance of the blockchains at
the execution, data model and consensus layer. For the first
failed servers do not contribute significantly to the mining two layers, the workloads were run with one client and one
process. Second, Parity’s throughput is also unaffected. It is server. For the consensus layer, 8 clients and 8 servers were
because each node is given equal time slice during which it used.
can generate block, thus failing 4 nodes in Parity means
that the remaining 8 nodes are given bigger time slices. Execution layer
Third , Hyperledger stops generating blocks after the failure
We deployed the CPUHeavy smart contract that is initial-
in the 12-server network, which is as expected because
ized with an integer array of a given size. The array is
the PBFT can only tolerate fewer than 4 failures in a 12-
initialized in descending order. We invoked the contract to
server network. In the 16-server network, Hyperledger still
sort the array using quicksort algorithm, and measured the
generates blocks but at a lower rate, which were caused by
execution time and server’s peak memory usage. The results
the remaining servers having to stabilize the network after
for varying input sizes are shown in Figure 11. Although
the failures by synchronizing their views.
Ethereum and Parity use the same execution engine, i.e.
We next simulated the attack that could make the EVM, Parity’s implementation is more optimized, therefore
blockchains vulnerable to double spending. The attack es- it is more computation and memory efficient. An interesting
sentially creates network partition at 100th second that lasts finding is that Ethereum incurs large memory overhead. In
for 150 seconds. We set the partition size to be half of sorting 10M elements, it uses 22GB of memory, as compared
the original5 . Figure 10 compares the vulnerability of the to 473MB used by Hyperledger. Ethereum runs out of mem-
three blockchains with 8 clients and 8 servers. Recall that ory when sorting more than 10M elements. In Hyperledger,
vulnerability is measured as the differences in the number the smart contract is compiled and runs directly on the
of total blocks and the number of blocks on the main branch. native machine within Docker environment, thus it does
We refer to this as ∆. Both Ethereum and Parity fork at not have the overheads associated with executing high-level
100th seconds, and ∆ increases as time passes. For the EVM byte code. As the result, Hyperledger is much more
attack duration, upto 30% of the blocks are generated in the efficient in term of speed and memory usage. Finally, we
forked branch, meaning that the systems are highly exposed note that all three systems fail to make use of the multi-core
to double spending or selfish mining attacks. When the architecture, i.e. they execute the contracts using only one
partition heals, the nodes come to consensus on the main core.
branch and discard the forked blocks. As a consequence, ∆
stops increasing shortly after 250th second. Hyperledger, in Data model - IOHeavy
stark contrast, has no fork which is as expected because its We deployed the IOHeavy smart contract that performs a
consensus protocol is proven to guaranteed safety. We note, number of read and write operations of key-value tuples.
however, that Hyperledger takes longer than the other two We used 20-byte keys and 100-byte values. Figure 12 re-
systems to recover from the attacks (about 50 seconds more). ports the throughput and disk usage for these operations.
This is because of the synchronization protocol performed Ethereum and Parity use the same data model and internal
after the partitioned nodes reconnect. In particular, when index structure, therefore they incur similar space over-
the nodes reconnect they enter the view change phase and heads. Both use an order of magnitude more storage space
exchange checkpointed states with each other in order to than Hyperledger which employs a simple key-value data
establish a new, stable view. model. Parity holds all the state information in memory, so
it has better I/O performance but fails to handle large data
(capped by over 3M states under our hardware settings).
5. We note that partitioning a N -node network in half does not mean
there are N/2 Byzantine nodes. In fact, Byzantine tolerance protocols On the contrary, Ethereum only caches only parts of the
do not count network adversary as Byzantine failure state in memory (using LRU for eviction policy), therefore it
16
Average throughput (write) Average throughput (read) Disk usage

Ethereum Parity Hyperledger Ethereum Parity Hyperledger 105 Ethereum Parity Hyperledger
104
5618 5411 5123 4852 4527 30,221
104 9329 8785 9234 8758 8974 8700 8670 8605
12,804 12,104
1329 1181 104
1087
second
second
103 5,459 5,045
MB
4,865
377 359 2019 2,337 2,477

337 1631 2,086
1282 1,283
103
103 675
102 69 360
512
x x x x x x
0.8M 1.6M 3.2M 6.4M 12.8M 0.8M 1.6M 3.2M 6.4M 12.8M 0.8M 1.6M 3.2M 6.4M 12.8M
# tuples # tuples # tuples
(a) Write (b) Read (c) Disk usage
Fig. 12: IOHeavy workload, ‘X’ indicates Out-of-Memory error.
Latency 13.314 101 Latency 104 Transaction througput

101 Ethreum 8.901 8.465
Ethereum 4.907 SmallBank
3.472
Parity Parity YCSB
Hyperledger Hyperledger DoNothing 1122 1273 1285
1.374
100 103
100 0.915 0.984
0.595
0.533
second
second
0.427
328
#tx/s
256 284
0.168
0.129 0.135 0.107
10−1 0.091
10 −1 0.076
10 2
0.038 0.033 0.031 45 45 46

0.032 0.034
0.025 0.024 0.023
0.020 0.020 0.019 0.019 0.020
10−2 1 10 100 1,000 10,000

10−2 1 10 100 1,000 10,000
101
# blocks scanned # blocks scanned Ethereum Parity Hyperledger
(a) Analytics workload (Q1) (b) Analytics workload (Q2) (c) DoNothing workload
Fig. 13: Analytics and DoNothing workloads.
can handle more data than Parity at the cost of throughput. using only 1024 accounts. We then executed the two queries
Hyperledger leverages RocksDB to manage its states, which described in Section 5.3 and measured their latencies. Fig-
makes it more efficient at scale. ure 13 shows that the performance for Q1 is similar, whereas
Hyperledger v1.0. We used the same IOHeavy smart con- Q2 sees a significant gap between Hyperledger and the rest.
tract to compare I/O performance of Hyperledger version We note that the main bottleneck for both Q1 and Q2 is the
v1.0 with the older version v0.6. As Figure 14 illustrates, number of network (RPC) requests sent by the client. For Q1,
throughputs of v1.0 is an order of magnitude worse than the client sends the same number of requests to all systems,
that of v0.6. Furthermore, v1.0 crashes with more than 0.8M therefore their performance are similar. On the other hand,
operations, reporting exceptions about message oversizes. for Q2 the client sends one RPC per block to Ethereum and
The significant gap can be attributed to the changes in the Parity, but only one RPC to Hyperledger because of our
system architecture from v0.6 to v1.0. In the former, the customized smart contract implementation. This saving in
nodes take part in PBFT to confirm a block. In this case, network roundtrip time translates to over 10x improvement
transactions in the IOHeavy workload incur no consensus in Q2 latency.
overhead because there is only one node. In the latter, a
new service, the orderer, is introduced into the network to 6.2.1 Consensus
order transactions and provide the consensus. With this new We deployed the DoNothing smart contract that accepts
service, transactions in the IOHeavy workload now need a transaction and returns immediately. We measured the
to communicate with the orderer for them to be confirmed. throughput of this workload and compare against that of
More specifically, the nodes in v1.0 perform three more steps YCSB and Smallbank. The differences compared to other
to finish a transaction compared to v0.6. As communication workloads, shown in Figure 13[c] is indicative of the cost
overhead increases, the throughputs decrease. This result of consensus protocol versus the rest of the software stack.
suggests that replacing PBFT with a centralized service In particular, for Ethereum we observe 10% increases in
not only fails to protect the blockchain against Byzantine throughput as compared to YCSB, which means that execu-
failures, but it may also impair the overall performance. tion of the YCSB transaction accounts for the 10% overhead.
We observe no differences among these workloads in Parity,
Data model - Analytics because the bottleneck in Parity is due to transaction signing
We implemented the analytics workload by initializing the (even empty transactions still need to be signed), not due to
three systems with over 120, 000 accounts with a fixed consensus or transaction execution.
balance. We then pre-loaded them with 100, 000 blocks, each
contains 3 transactions on average. The transaction trans-
fers a value from one random account to another random
7 D ISCUSSION
account. Due to Parity’s overheads in signing transactions In this section, we first distill the lessons learned during the
when there are many accounts, we considered transactions comparative studies of Ethereum, Parity and Hyperledger.
17
Average throughput (write) Average throughput (read) 104 Disk usage

Hyperledger v0.6 Hyperledger v1.0 Hyperledger v0.6 Hyperledger v1.0 Hyperledger v0.6 Hyperledger v1.0
104 104 8559 8690 8785 8758

6122 5815 5618 5411 103 675
506
360
ops/s
ops/s
280
MB
197
103 141
625 625 623 625 107
102
63
103
102 627 628 639 630
0.2M 0.4M 0.8M 1.6M 0.2M 0.4M 0.8M 1.6M

101 0.2M 0.4M 0.8M 1.6M
# tuples # tuples # tuples
(a) Write (b) Read (c) Read
Fig. 14: Hyperledger v0.6.0 vs. v1.0.0 against IOHeavy workload.
We then discuss how design principles from database sys-

tems could help improve blockchain performance.
7.1 Lessons Learned From the Performance Study

Understanding blockchain systems. BLOCKBENCH aims
to facilitate better understanding of the design and per- Fig. 15: The life of a blockchain transaction.
formance of different private blockchains. As more and
more blockchain systems are being proposed, each offering big for blockchains to be disruptive to incumbent database
different sets of feature, BLOCKBENCH’s main value is that systems. There are much for blockchains to learn from
it narrows down the design space into four distinct ab- databases in terms of high-performance data processing,
straction layers. The layers are derived from our taxonomy which we discuss next. Nevertheless, there are useful
presented in Section 4 which sufficiently captures the key lessons that databases can take from the popularity and
and subtle characteristics of blockchain systems. By bench- success of blockchains. Perhaps the most interesting lesson
marking these layers, one can gain insights into the design is that there is a clear need for Byzantine tolerant data pro-
trade-offs and performance bottlenecks. For example, us- cessing systems which can accommodate a large number of
ing the IOHeavy workload we identify that Parity trades users. Distributed databases have diverged from P2P system
performance for scalability by keeping states in memory. designs by assuming non-Byzantine failures [18], but with
In addition, the workload reveals potential performance the increasing availability of faster and more trustworthy
issues with the latest version of Hyperledger. Another ex- hardware, this may be the right time for the community
ample is the Analytics workload that demonstrates trade- to revise interest in high-performance, decentralized, P2P
offs in the data models. In particular, Hyperledger’s simple database systems.
key-value model means some analytical queries cannot be
directly supported. However, it enables optimization that
7.2 Bringing Database Designs into Blockchains
helps answering analytical queries more efficiently. Finally,
we identify that the bottleneck in Parity is not due to The challenges in scaling blockchain by optimizing the
the consensus protocol, but due to the server’s transaction consensus protocols are being addressed in many recent
signing. We argue it is not easy to arrive at such insights works [26], [61]. Nevertheless, we demonstrated in our com-
without a systematic analysis framework. parative study that there are other performance bottlenecks
Usability of blockchain. Our experience in working with beside consensus. Figure 15 illustrates different stages that a
the three blockchain systems confirms that in their cur- transaction goes through before it is considered committed
rent states, the blockchains are not yet ready for mass to the blockchain. Each stage could be a potential bottleneck
usage. Their designs and codebases are still being refined and be subject to future optimizations. First, transactions
constantly, and there are no other established applications are batch into a block. Next, the block becomes input to the
beside crypto-currency. Of the three systems, Ethereum is consensus protocol, and if selected by the protocol it is sent
more mature both in terms of its codebase, user base and de- to the execution engine. Finally, the engine executes the en-
veloper community. Another usability issue we encountered tire batch of transaction, creates new states and appends the
is in porting smart contracts from one system to another, block to the chain6 . We note the striking resemblance with
due of their different programming models. This is likely the flow of a transaction in a distributed database. In fact,
to be exacerbated as more blockchain platforms are being the only difference being the consensus protocol: databases
proposed [6], [30], [44], [93]. use two-phase commit or Paxos, whereas blockchains use
Comparison to database systems. The comparison against Byzantine tolerant protocols or variants thereof. Given the
H-Store presented in the previous section demonstrates similarity, we propose four approaches inspired by design
that blockchains perform poorly at data processing tasks principles in databases to improve blockchain performance.
currently being handled by database systems. Although
6. Note that the execution phase can be considered the last part
databases are designed without security and tolerance to of the consensus phase, because during execution a node may detect
Byzantine failures, we remark that the gap remains too conflicting transactions and abort the current consensus round.
18
Decoupling the layers and optimize them individually. 8 C ONCLUSION

One possible direction is to decouple storage, execution en- In this paper, we have conducted a comprehensive survey
gine and consensus layer from each other, then optimize and on blockchain technologies. We laid out four underpinning
scale them independently. Tezos and Corda, for examples, concepts behind blockchains and analyzed the state of the
have decoupled the consensus layer by outsourcing it to art using these concepts. We presented our benchmarking
separate parties. The data model layer could also be de- framework, BLOCKBENCH which is designed to evaluate
coupled. For instance, current systems employ generic key- performance of blockchains as data processing platforms.
value storage, which may not be best suited to the unique Finally, we discussed four potential research directions,
data structure and operations in blockchain. UStore [94] inspired by database design principles, for improving block-
demonstrates that a storage designed around the blockchain hchain performance. We hope that the survey and bench-
data structure is able to achieve better performance than ex- marking framework would serve to guide the design and
isting implementations. Most importantly, we observe that implementation of future blockchain systems that are not
current data models in Ethereum and Hypereldger are not only secure, but scalable and usable in the real world.
ideal for answering analytics queries. In particular, both do
not support fine-grained versioning at the transaction level:
it is not possible to immediately query previous versions of ACKNOWLEDGMENTS
a state except for querying at block level and processing the This work is funded by the National Research Foundation,
state of each block. Implementing a new data model is less Prime Ministers Office, Singapore, under its Competitive
complex when the storage layer is decoupled from the rest Research Programme (CRP Award No. NRF-CRP8-2011-08).
of the blockchain stack. We would like to thank colleagues and the anonymous
reviewers who have provided valuable feedback to help
Embracing new hardware primitives. Many data process- improve the paper.
ing systems are taking advantage of new hardware to boost
their performance [95], [96], [97]. For blockchain, using
trusted hardware, the underlying Byzantine fault tolerance R EFERENCES
protocols can be modified to incur fewer network mes- [1] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,”
sages [85]. With trusted hardware, the blockchain can tol- 2008.
[2] Q. Lin, P. Chang, G. Chen, B. C. Ooi, K. Tan, and Z. Wang, “To-
erate more failures, and because of fewer network messages wards a non-2pc transaction management in distributed database
it can scale better. Systems like Parity and Ethereum can systems,” in Proceedings of ACM International Conference on Manage-
take advantage of multi-core CPUs and large memory to ment of Data (SIGMOD), San Francisco, CA, USA, 2016, pp. 1659–
1674.
improve contract execution and I/O performance. [3] A. Thomson, T. Diamond, S. Weng, K. Ren, P. Shao, and
D. J. Abadi, “Calvin: fast distributed transactions for partitioned
Sharding. Blockchain is essentially a replicated state ma- database systems,” in Proceedings of ACM International Conference
chine system, in which each node maintains the same on Management of Data (SIGMOD), Scottsdale, AZ, USA, 2012, pp.
1–12.
data. As such, blockchains are fundamentally different to [4] P. Bailis, A. Fekete, M. J. Franklin, A. Ghodsi, J. M. Hellerstein, and
database systems such as H-Store in which the data is I. Stoica, “Coordination avoidance in database systems,” PVLDB,
partitioned (or sharded) across the nodes. Sharding helps vol. 8, no. 3, pp. 185–196, 2014.
[5] “Ethereum blockchain app platform,” https://www.ethereum.
reduce the computation cost and can make transaction org/.
processing faster. The main challenge with sharding is to [6] Ripple, “Ripple,” https://ripple.com.
ensure consistency among multiple shards. However, exist- [7] Melonport, “Blockchain software for asset management,” http://
ing consistency protocols used in database systems do not melonport.com.
[8] J. Morgan and O. Wyman, “Unlocking economic advantage with
work under Byzantine failure. Nevertheless, their designs blockchain. a guide for asset managers.” 2016.
can offer insights into realizing a more scalable sharding [9] G. S. Group, “Blockchain: putting theory into practice,” 2016.
protocol for blockchain. Corda partitions the ledger into [10] T. T. A. Dinh, J. Wang, G. Chen, L. Rui, K.-L. Tan, and B. C. Ooi,
“Blockbench: a benchmarking framework for analyzing private
sub-ledgers belonging to smaller group, thus avoiding the blockchains,” in SIGMOD, 2017.
need to broadcast transactions to the entire network. How- [11] Ethcore, “Parity: next generation ethereum browser,” https://
ever, it still depends on an external, centralized compo- ethcore.io/parity.html.
nent for consensus between sub-ledgers. Recent work [26] [12] Hyperledger, “Blockchain technologies for business,” https://
www.hyperledger.org.
has demonstrated the feasibility of sharding the consensus [13] F. Tschorsch and B. Scheuermann, “Bitcoin and beyond: A techni-
protocol, making important steps towards partitioning the cal survey on decentralized digital currencies,” IEEE Communica-
entire blockchain. tions Survey & Tutorials, vol. 18, no. 3, pp. 2084–2123, 2016.
[14] J. Bonneau, A. Miller, J. Clark, A. Narayanan, J. A. Kroll, and E. W.
Felten, “Sok: Research perspectives and challenges for bitcoin
Supporting declarative language. Having a set of high-level and crypto-currencies,” in 2015 IEEE Symposium on Security and
operations that can be composed in a declarative manner Privacy. IEEE, 2015, pp. 104–121.
makes it easy to define complex smart contracts. It also [15] M. Stonebraker, S. Madden, D. J. Abadi, S. Harizopoulos,
N. Hachem, and P. Helland, “The end of an architectural era (it’s
opens up opportunities for low-level optimizations that time for a complete rewrite),” in Proceedings of the 33rd International
speed up contract execution. Hawk [89] is a recent exam- Conference on Very Large Data Bases (VLDB), Vienna, Austria, 2007,
ple that applies compiler techniques to hide complexity of pp. 1150–1160.
implementing privacy preserving smart contracts. However, [16] J. C. Corbett, J. Dean, and et al., “Spanner: Google’s globally-
distributed database,” in Proceedings of 10th USENIX Symposium
it aims to strengthen security of the smart contracts rather on Operating Systems Design and Implementation (OSDI), Hollywood,
than improve their performance. CA, USA, 2012, pp. 261–264.
19
[17] M. Castro and B. Liskov, “Practical byzantine fault tolerance,” in [50] W. Zheng, A. Dave, J. Beekman, R. A. Popa, J. Gonzalez, and
Proceedings of the 3rd USENIX Symposium on Operating Systems I. Stoica, “Oqaque: an oblivious and encrypted distributed ana-
Design and Implementation (OSDI), New Orleans, Louisiana, USA, lytics platform,” in NSDI, 2017.
1999, pp. 173–186. [51] F. Zhang, E. Cecchetti, K. Croman, and E. Shi, “Town crier: an
[18] Q. H. Vu, M. Lupu, and B. C. Ooi, Peer-to-Peer Computing Principles authenticated data feed for smart contracts,” in IEEE Security &
and Applications. Springer-Verlag, 2009. Privacy, 2016.
[19] I. Eyal and E. G. Sirer, “Majority is not enough: Bitcoin mining is [52] B. Smyth, M. Ryan, and L. Chen, “Direct anonymous attestation:
vulnerable,” in Proceedings of 18th International Conference on Finan- ensuring privacy with corrupt administrator,” in European Work-
cial Cryptography and Data Security (FC), Christ Church, Barbados, shop on Security and Privacy in Ad hoc and Sensor networks, 2007.
2014, pp. 436–454. [53] S. Meiklejohn, M. Pomarole, G. Jordan, K. Levchenko, D. McCoy,
[20] K. Croman, C. Decker, I. Eyal, A. E. Gencer, A. Juels, A. Kosba, G. M. Voelker, and S. Savage, “A fistful of bitcoins: characterizing
A. Miller, P. Saxena, E. Shi, and E. Gün, “On scaling decentralized payments among men with no names,” in IMC, 2013.
blockchains,” in Proceedings of 3rd Workshop on Bitcoin and Block- [54] “Chainalysis - blockchain analysis,” https://www.chainalysis.
chain Research, 2016. com.
[21] F. P. Junqueira, B. C. Reed, and M. Serafini, “Zab: High- [55] I. Miers, C. Garman, M. Green, and A. D. Rubin, “Zerocoins:
performance broadcast for primary-backup systems,” in Proceed- anonymous distributed e-cash from bitcoin,” in IEEE Security &
ings of the IEEE/IFIP International Conference on Dependable Systems Privacy, 2013.
and Networks (DSN), Hong Kong, China, 2011, pp. 245–256. [56] SCIPR Lab, “libsnark: a c++ library for zkSNARK proofs,” https:
[22] D. Ongaro and J. K. Ousterhout, “In search of an understandable //github.com/scipr-lab/libsnark.
consensus algorithm,” in Proceedings of the USENIX Annual Tech- [57] “Lightning network: scalable, instance bitcoin/blockchain trans-
nical Conference (USENIX ATC), Philadelphia, PA, USA, 2014, pp. actions,” https://lightning.network/.
305–319. [58] S. Goldfeder, J. Bonneau, E. W. Felten, J. A. Kroll, and
[23] L. Lamport, “Paxos made simple, fast, and byzantine,” in Proced- A. Narayanan, “Securing bitcoin wallets via threshold signatures,”
ings of the 6th International Conference on Principles of Distributed in ACNS, 2016.
Systems (OPODIS). Reims, France, 2002, pp. 7–9. [59] V. Shoup, “Practical threshold signatures,” in EUROCRYPT, 2000.
[24] “Monax: The ecosystem application platform,” https://monax.io. [60] D. Boneh, B. Lynn, and H. Shacham, “Short signatures from the
[25] M. Vukolic, “The quest for scalable blockchain fabric: proof-of- weil pairing,” Journal of cryptology, 2004.
work vs. bft replication,” in Open Problems in Network Security - [61] E. Kokoris-Kogias, P. Jovanovic, N. Gailly, I. Khoffi, L. Gasser, and
iNetSec, 2015. B. Ford, “Enhancing bitcoin security and performance with strong
[26] L. Luu, V. Narayanan, C. Zhang, K. Baweija, S. Gilbert, and consistency via collective signing,” in Proceedings of 25th USENIX
P. Saxena, “A secure sharding protocol for open blockchains,” in Security Symposium (USENIX Security), Austin, TX, USA, 2016, pp.
CCS, 2016. 279–296.
[27] Y. Gilad, R. Hemo, S. Micali, G. Vlachos, and N. Zeldovich, [62] E. Syta, I. Tamas, D. Visher, D. I. Wolinsky, P. Jovanovic, L. Gasser,
“Algorand: Scaling byzantine agreements for cryptocurrencies,” N. Gailly, I. Khoffi, and B. Ford, “Keeping authorities honest or
in SOSP, 2017. bust with decentralized witess cosigning,” in IEEE Security &
[28] “Proof of authority chains,” https://github.com/paritytech/ Privacy, 2016.
parity/wiki/Proof-of-Authority-Chains. [63] J. Behl, T. Distler, and R. Kapitza, “Scalable BFT for multi-cores:
[29] “Stellar,” https://www.stellar.org/. Actor-based decomposition and consensus-oriented paralleliza-
[30] “kadena,” http://kadena.io/. tion,” in 10th Workshop on Hot Topics in System Dependability,
[31] “Bigchaindb: a scalable blockchain database,” https://github. HotDep ’14, Broomfield, CO, USA., 2014.
com/bigchaindb/bigchaindb. [64] M. Zbierski, “Parallel byzantine fault tolerance,” in Soft Computing
[32] “Hyperledger fabric v0.6.0,” https://github.com/hyperledger/ in Computer and Information Science. Springer, 2015, pp. 321–333.
fabric/releases/tag/v0.6.0-preview. [65] W. Zhao, “Optimistic byzantine fault tolerance,” International Jour-
[33] “Hyperledger fabric v1.0.0-rc1,” https://github.com/ nal of Parallel, Emergent and Distributed Systems, vol. 31, no. 3, pp.
hyperledger/fabric/releases/tag/v1.0.0-rc1. 254–267, May 2016.
[34] “Global decentralized currency,” https://litecoin.org/. [66] D. Mazieres, “The stellar consensus protocol: A federated model
[35] E. B. Sasson, A. Chiesa, C. Garman, M. Green, I. Miers, E. Tromer, for internet-level consensus,” Stellar Development Foundation, 2015.
and M. Virza, “Zerocash: decentralized anonymous payments [67] I. Eyal, A. E. Gencer, E. G. Sirer, and R. van Renesse, “Bitcoin-ng:
from bitcoin,” in IEEE Security & Privacy, 2014. A scalable blockchain protocol,” in NSDI, 2016.
[36] “Multichain:open platform for blockchain applications,” https:// [68] “Proof of stake,” https://github.com/ethereum/wiki/wiki/
www.multichain.com/. Proof-of-Stake-FAQ.
[37] JPMorgan, “Enterprise-ready distributed ledger and smart con- [69] “Slimcoin a peer-to-peer crypto-currency with proof-of-burn,”
tract platforms,” https://github.com/jpmorganchase/quorum. www.slimcoin.club/whitepaper.pdf.
[38] “Hydrachain: Permissioned distributed ledger based on eth- [70] “Peercoin - secure & sustainable cryptocoin,” https://peercoin.
ereum,” https://github.com/HydraChain/hydrachain. net.
[39] “Openchain: Enterprise-ready blockchain,” https://github.com/ [71] “Proof of elapsed time (poet),” https://intelledger.github.io/
openchain. introduction.html#proof-of-elapsed-time-poet.
[40] “Openchain: Next generation blockchain,” https://iota.org/. [72] I. Bentov, C. Lee, A. Mizrahi, and M. Rosenfeld, “Proof of activity:
[41] “Tendermint: Blockchain app development simplified,” http:// Extending bitcoin’s proof of work via proof of stake,” IACR
tendermint.com/. Cryptology ePrint Archive, vol. 2014, p. 452, 2014.
[42] C. Copeland and H. Zhong, “Tangaroa: a byzantine fault tolerant [73] S. Park, K. Pietrzak, A. Kwon, J. Alwen, G. Fuchsbauer, and
raft,” https://github.com/chrisnc/tangaroa. P. Gazi, “Spacemint: A cryptocurrency based on proofs of space,”
[43] “Dfinity,” https://dfinity.network/. IACR Cryptology ePrint Archive, vol. 2015, p. 528, 2015.
[44] L. Goodman, “Tezos: A self-amending crypto-ledger position pa- [74] M. Milutinovic, W. He, H. Wu, and M. Kanwal, “Proof of luck: an
per,” 2014. efficient blockchain consensus protocol,” IACR Cryptology ePrint
[45] R. Brown, “Introducing r3 cordatm: A distributed ledger designed Archive, vol. 2017, p. 249, 2017.
for financial services,” R3CEV blog, 2016. [75] Y. Sompolinsky and A. Zohar, “Accelerating bitcoin’s transaction
[46] “Sawtooth lake,” https://github.com/hyperledger/ processing: fast money grows on trees, not chains,” Cryptology
sawtooth-core. ePrint Archive, Report 2013/881, 2013, https://eprint.iacr.org/
[47] “Decentralized autonomous organization,” https://www. 2013/881.pdf.
ethereum.org/dao. [76] S. Deetman, “Bitcoin could consume as much electricity as den-
[48] S. Eskandari, D. Barrera, E. Stobert, and J. Clark, “A first look at mark by 2020,” https://tinyurl.com/yd8hq6n2, 2016.
the usability of bitcoin key management,” in Workshop on Usable [77] “Nxt: own your data, control your vote,” https://nxt.org/.
Security, 2015. [78] E. Heilman, A. Kendler, A. Zohar, and S. Goldberg, “Eclipse
[49] T. T. A. Dinh, P. Saxena, E. chien Chang, B. C. Ooi, and C. Zhang, attacks on bitcoin’s peer-to-peer network,” in Proceedings of 24th
“M2r: enabling stronger privacy in mapreduce computation,” in USENIX Security Symposium (USENIX Security), Washington, D.C.,
USENIX Security, 2015. USA, 2015, pp. 129–144.
20
[79] A. Clement, E. Wong, L. Alvisi, M. Dahlin, and M. Marchetti, Rui Liu received the BEng degree from North-
“Making byzantine fault tolerant systems tolerate byzantine fail- eastern University of China in 2012, and MPhil
ure,” in NSDI, 2009. degree from the Hong Kong Polytechnic Univer-
[80] R. Kotla, L. Alvisi, M. Dahlin, A. Clement, and E. Wong, “Zyzzyva: sity in 2015. He was a research assistant at
speculative byzantine fault tolerance,” in SOSP, 2007. the Department of Computer Science, National
[81] S. Liu, P. Viotti, C. Cachin, V. Quema, and M. Vukolic, “Xft: University of Singapore. His research interests
Practical fault tolerance beyond crashes,” in OSDI, 2016. include distributed systems, data management,
[82] A. Miller, Y. Xia, K. Croman, E. Shi, and D. Song, “The honeybad- mobile computing and ubiquitous computing.
ger of bft protocols,” in CCS, 2016.
[83] Intel, “Intel software guard extensions,” https://software.intel.
com/en-us/sgx.
[84] T. Alves and D. Felton, “Trustzone: Integrated hardware and soft-
ware security, enabling trusted computing in embedded systems,”
White paper.
[85] B. Chun, P. Maniatis, S. Shenker, and J. Kubiatowicz, “Attested
Meihui Zhang received the BEng degree in
append-only memory: making adversaries stick to their word,”
computer science from the Harbin Institute of
in Proceedings of the 21st ACM Symposium on Operating Systems
Technology, China, in 2008 and the PhD degree
Principles (SOSP), Stevenson, Washington, USA, 2007, pp. 189–204.
in computer science from the National University
[86] J. Behl, T. Distler, and R. Kapitza, “Hybrids on steroids: Sgx-based
of Singapore in 2013. She is currently an asso-
high performance bft,” in Eurosys, 2017.
ciate professor at the Beijing Institute of Tech-
[87] “Interledger: the protocol for connecting blockchains.” https://
nology, and was an assistant professor at the
interledger.org/.
Singapore University of Technology and Design
[88] L. Luu, D.-H. Chu, H. Olickel, P. Saxena, and A. Hobor, “Making
(SUTD) from 2014 to 2017. Her research inter-
smart contracts smarter,” in CCS, 2016.
est includes crowdsourcing-powered data ana-
[89] A. Kosba, A. Miller, E. Shi, Z. Wen, and C. Papamanthou, “Hawk:
lytics, massive data integration, spatio-temporal
the blockchain model of cryptography and privacy preserving
databases, blockchain and AI. She is a member of the IEEE.
smart contracts,” in CCS, 2016.
[90] “BlockBench: private blockchains benchmarking,” https://github.
com/ooibc88/blockbench.
[91] B. F. Cooper, A. Silberstein, E. Tam, R. Ramakrishnan, and R. Sears,
“Benchmarking cloud serving systems with YCSB,” in Proceedings
of the 1st ACM Symposium on Cloud Computing (SoCC), Indianapolis, Gang Chen received the BSc, MSc and PhD de-
Indiana, USA, 2010, pp. 143–154. grees in computer science and engineering from
[92] M. J. Cahill, U. Röhm, and A. D. Fekete, “Serializable isolation for Zhejiang University in 1993, 1995, and 1998,
snapshot databases,” in Proceedings of the ACM SIGMOD Interna- respectively. He is currently a professor in the
tional Conference on Management of Data (SIGMOD), Vancouver, BC, College of Computer Science, Zhejiang Univer-
Canada, 2008, pp. 729–738. sity. His research interests include databases,
[93] Crypti, “A decentralized application platform,” https://crypti.me. information retrieval, information security, and
[94] A. Dinh, J. Wang, S. Wang, W.-N. Chin, Q. Lin, B. C. Ooi, P. Ruan, computer-supported cooperative work. He is
K.-L. Tan, Z. Xie, H. Zhang, and M. Zhang, “UStore: a distributed also the executive director of Zhejiang University
storage with rich semantics,” https://arxiv.org/pdf/1702.02799. Netease Joint Lab on Internet Technology. He is
pdf. a member of the IEEE.
[95] K. Tan, Q. Cai, B. C. Ooi, W. Wong, C. Yao, and H. Zhang, “In-
memory databases: Challenges and opportunities from software
and hardware perspectives,” SIGMOD Record, vol. 44, no. 2, pp.
35–40, 2015.
[96] H. Zhang, G. Chen, B. C. Ooi, K. Tan, and M. Zhang, “In-memory Beng Chin Ooi is currently a distinguished
big data management and processing: A survey,” IEEE Transactions professor of computer science at the National
on Knowledge and Data Engineering, vol. 27, no. 7, pp. 1920–1948, University of Singapore. His research interests
2015. include database system architectures, perfor-
[97] A. Dragojevic, D. Narayanan, E. B. Nightingale, M. Renzelmann, mance issues, indexing techniques and query
A. Shamis, A. Badam, and M. Castro, “No compromises: dis- processing, in the context of multimedia, spa-
tributed transactions with consistency, availability, and perfor- tiotemporal, distributed, parallel, peer-to-peer, in
mance,” in Proceedings of the 25th Symposium on Operating Systems memory, and cloud database systems. He has
Principles SOSP, Monterey, CA, USA, 2015, pp. 54–70. served as a PC member for a number of inter-
national conferences (including SIGMOD, VLDB,
ICDE, WWW, EDBT, DASFAA, GIS, KDD, CIKM,
and SSD). He was an editor of the VLDB Journal and the IEEE Trans-
actions on Knowledge and Data Engineering, editor-in-chief of the IEEE
Transactions on Knowledge and Data Engineering (20092012), and a
co-chair of the ACM SIGMOD Jim Gray Best Thesis Award committee.
He is serving as a trustee board member and the president of the VLDB
Endowment. He is a fellow of the IEEE and ACM.
Tien Tuan Anh Dinh received the BEng and
PhD from the University of Birmingham, United
Kingdom in 2006 and 2010 respectively. He is
currently a senior research fellow at the De-
partment of Computer Science, National Univer- Ji Wang received his BSc from Harbin Institute
sity of Singapore. His research interests include of Technology, China in 2015 and his MSc from
applied cryptography, trusted computing, dis- National University of Singapore in 2017. He
tributed systems, big data analytics, databases was a research assistant at the Department of
and machine learning. Computer Science, National University of Singa-
pore. His research interests include distributed
systems and data management.

08246573

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

08246573

Hochgeladen von

Copyright:

Verfügbare Formate

This article has been accepted for publication in a future issue of this journal, but has not been

Untangling Blockchain: A Data Processing View

Index Terms—Blockchain, Distributed Databases, Survey.

1 I NTRODUCTION replicated applications known as smart contracts. More im-

2) How do current blockchains differ from each other,

In the next section, we provide an overview of block-

TABLE 1: Examples of distributed ledgers.

Data Model Number of ledgers Owner Example

3.3 Cryptography contract Doubler {

Transaction privacy involves four rounds of communication at the end of which

TABLE 3: Comparison of consensus protocols.

Consensus Protocol Network Settings Description

Fig. 4: Blockchain software layers and corresponding bench-

includes details of the runtime environment for execut-

5.3 Workloads type account_t struct {

Throughput Latency Throughput vs. HStore

Fig. 7: Performance of the three blockchain systems versus

concurrent clients and servers, the channels are dominated

500 #Blocks generated 104 Execution time Peak memory usage

Fig. 10: Blockchain forks caused by attacks that partitions

Average throughput (write) Average throughput (read) Disk usage

377 359 2019 2,337 2,477

(a) Write (b) Read (c) Disk usage

Fig. 12: IOHeavy workload, ‘X’ indicates Out-of-Memory error.

Latency 13.314 101 Latency 104 Transaction througput

0.038 0.033 0.031 45 45 46

10−2 1 10 100 1,000 10,000

Fig. 13: Analytics and DoNothing workloads.

Average throughput (write) Average throughput (read) 104 Disk usage

104 104 8559 8690 8785 8758

0.2M 0.4M 0.8M 1.6M 0.2M 0.4M 0.8M 1.6M

(a) Write (b) Read (c) Read

Fig. 14: Hyperledger v0.6.0 vs. v1.0.0 against IOHeavy workload.

We then discuss how design principles from database sys-

7.1 Lessons Learned From the Performance Study

Decoupling the layers and optimize them individually. 8 C ONCLUSION

Das könnte Ihnen auch gefallen