scispace - formally typeset
Search or ask a question
Proceedings ArticleDOI

A Taxonomy of Blockchain-Based Systems for Architecture Design

TL;DR: This taxonomy captures major architectural characteristics of blockchains and the impact of their principal design decisions and is intended to help with important architectural considerations about the performance and quality attributes of blockchain-based systems.
Abstract: Blockchain is an emerging technology for decentralised and transactional data sharing across a large network of untrusted participants. It enables new forms of distributed software architectures, where agreement on shared states can be established without trusting a central integration point. A major difficulty for architects designing applications based on blockchain is that thetechnology has many configurations and variants. Since blockchains are at an early stage, there is little product data or reliable technology evaluation available to compare different blockchains. In this paper, we propose how to classify and compare blockchains and blockchain-based systems to assist with the design and assessment of their impact on software architectures. Our taxonomy captures major architectural characteristics of blockchains and the impact of their principal design decisions. This taxonomy is intended to help with important architectural considerations about the performance and quality attributes of blockchain-based systems.

Content maybe subject to copyright    Report

A Taxonomy of Blockchain-Based Systems for
Architecture Design
Xiwei Xu
, Ingo Weber
, Mark Staples
, Liming Zhu
, Jan Bosch
, Len Bass
, Cesare Pautasso
§
, Paul Rimba
Data61, CSIRO, Sydney, Australia
{firstname.lastname}@data61.csiro.au
School of Computer Science and Engineering, UNSW, Sydney, Australia
Carnegie Mellon University, Pittsburgh, USA
lenbass@cmu.edu
§
USI Lugano, Switzerland
c.pautasso@ieee.org
Chalmers University of Technology, Gothenburg, Sweden
jan@janbosch.com
Abstract—Blockchain is an emerging technology for decent-
ralised and transactional data sharing across a large network
of untrusted participants. It enables new forms of distributed
software architectures, where agreement on shared states can
be established without trusting a central integration point. A
major difficulty for architects designing applications based on
blockchain is that the technology has many configurations and
variants. Since blockchains are at an early stage, there is
little product data or reliable technology evaluation available
to compare different blockchains. In this paper, we propose
how to classify and compare blockchains and blockchain-based
systems to assist with the design and assessment of their impact
on software architectures. Our taxonomy captures major archi-
tectural characteristics of blockchains and the impact of their
principal design decisions. This taxonomy is intended to help with
important architectural considerations about the performance
and quality attributes of blockchain-based systems.
Index Terms—Software architecture, Distributed databases
I. Introduction
Blockchain is the technology behind Bitcoin [
16
], which
is a digital currency based on a peer-to-peer network and
cryptographic tools. Bitcoin network provides a “trust-less
environment, where users can transfer money to each other
without relying on central trusted authorities, like bank systems
or payment services. A blockchain provides a kind of append-
only data store of transactions replicated between peers.
Many banks are involved in trials of blockchain technology,
including through the global R3 consortium1, which is apply-
ing blockchain to trade finance and cross-border payments.
Financial transactions are the first, but not the only use case
being investigated for blockchain technology. A blockchain
implements a distributed ledger, which can in general verify and
store any kind of transactions [
22
]. Many startups, enterprises,
and governments [
1
] are exploring its applications in areas
as diverse as supply chain, electronic health records, voting,
energy supply, ownership management, and protecting critical
civil infrastructure. The wide array of interest in blockchain
1http://www.r3cev.com/
technology is underlined by the fast evolution of its ecosystem,
including easier deployment through Blockchain-as-a-Service
from Microsoft Azure
2
and IBM
3
. Blockchain has become
a publicly-available infrastructure for building decentralised
applications and achieving interoperability.
From a software architecture perspective, blockchain en-
ables new forms of distributed software architectures, where
agreement on shared state for decentralised and transactional
data can be established across a large network of untrusted
participants. This circumvents the need to rely on a central,
trusted integration point which has the power to control
and manipulate the system, and is a single point of failure.
Applications built on blockchains can take advantage of
properties such as data immutability, integrity, fair access,
transparency, and non-repudiation of transactions.
However, blockchains have technical limitations. Privacy is
impacted because information on a blockchain is available to
all participants. For throughput scalability, mainstream public
blockchains can only handle on average 3-20 transactions per
second
4
, whereas mainstream payment services, like VISA,
can handle an average of 1,700 transactions per second
5
.
Blockchain, as a software connector, has a complex internal
structure and has many configurations and variants [
28
].
Since the advent of Bitcoin in 2008 [
16
], a diverse range
of blockchains has emerged.
Thus, blockchains cannot by themselves meet the require-
ments for all usage scenarios, e.g., those that require real-time
processing. When building applications based on blockchains,
we need to systematically consider the features and config-
urations of blockchains and assess their impact on quality
attributes for the overall systems. In practice, the lack of reliable
technology evaluation resources makes the comparison very
2https://azure.microsoft.com/en-us/solutions/blockchain/
3http://www.ibm.com/blockchain/
4https://blog.ethereum.org/2016/01/15/privacy-on-the-blockchain/
5https://usa.visa.com/run-your-business/small-business-tools/retail.html

difficult.
In this paper, we propose a taxonomy that captures major
architecturally-relevant characteristics of various blockchains,
and indicate their support for various quality attributes. This is
intended to be a basis for architecting blockchain-based systems.
During design, the taxonomy may highlight trade-offs arising
from design decisions related to blockchain platforms. The
taxonomy is informed by existing industrial products, technical
forums, academic literature and our own experience of using
blockchains and developing prototypes.
The paper first gives background on blockchains in Section II.
Section III describes the development and details of our
taxonomy. A conceptual model for the design of blockchain-
based systems is proposed in Section IV. Section V concludes.
II. Background on Blockchain
The term “blockchain is used to refer to a data structure
and occasionally to a network or system. As a data structure,
a blockchain is an ordered list of blocks, where each block
contains a small (possibly empty) list of transactions. Each
block in a blockchain is “chained” back to the previous block,
by containing a hash of the representation of the previous
block. Thus historical transactions in the blockchain may
not be deleted or altered without invalidating the chain of
hashes. Combined with computational constraints and incentive
schemes on the creation of blocks, this can in practice prevent
tampering and revision of information stored in the blockchain.
The first generation of blockchains, like Bitcoin, provided
a public ledger to store cryptographically-signed financial
transactions [
20
]. There was very limited capability to support
programmable transactions, and only very small pieces of
auxiliary data could be embedded in the transactions to
serve other purposes, such as representing digital assets (e.g.,
document notarisation) or physical assets (e.g., diamonds). The
second generation of blockchains provides a general-purpose
programmable infrastructure with a public ledger that records
the computational results. Programs can be deployed and
run on a blockchain, and are known as smart contracts [
18
].
Smart contracts can express triggers, conditions and business
logic [
25
] to enable more complex programmable transaction.
However, they are not necessarily smart, nor necessarily related
to legal contracts. A common simple example of a smart
contract-enabled service is escrow, which can hold funds until
the obligations defined in the smart contract have been fulfilled.
Ethereum
6
is the most widely-used blockchain that supports
general-purpose (Turing-complete) smart contracts.
Public key cryptography and digital signatures are normally
used to identify accounts and to ensure authorization of
transactions initiated on a blockchain. Transactions are data
packages that store parameters (such as monetary value in the
case of Bitcoin) and results of function calls (such as from
smart contracts). The integrity of a transaction is checked by
algorithmic rules and cryptographic techniques. A transaction
is signed by its initiator, to authorise the expenditure of their
6https://www.ethereum.org/
money, to authorise the data payload of a transaction, or the
creation and execution of a smart contract.
A signed transaction is sent to a node connected to the
blockchain network, which validates the transaction. If the
transaction is valid and previously unknown to the node, the
node propagates it to other nodes in the network, which also
validate the transaction and propagate it to their peers, until
the transaction reaches all nodes in the network. In a global
network, this can take seconds.
Mining is the process of appending new blocks to the
blockchain data structure. A blockchain network relies on
miners to aggregate valid transactions into blocks and append
them to the blockchain. New blocks broadcast across the whole
network, so that each node holds a replica of the whole data
structure. The whole network aims to reach a consensus about
the latest block to be included into the blockchain. There
are different consensus mechanisms, e.g., “proof-of-work” or
“proof-of-stake (see Section III). Depending on the consensus
mechanism and the required guarantees, there can be different
notions of when a transaction is taken to be committed or
confirmed and thus immutable.
A. Fundamental Properties
If data is contained in a committed transaction, it will
eventually become in practice immutable. The immutable chain
of cryptographically-signed historical transactions provides non-
repudiation of the stored data. Cryptographic tools also support
data integrity, the public access provides data transparency,
and equal rights allows every participant the same ability to
access and manipulate the blockchain. These rights can be
weighted by the compute power or stake owned by the miner.
A distributed consensus mechanism governs addition of new
items; it consists of the rules for validating and broadcasting
transactions and blocks, resolving conflicts, and the incentive
scheme. The consensus ensures all stored transactions are valid,
and that each valid transaction is added only once.
Trust in the blockchain is achieved from the interactions
between nodes within the network. The participants of block-
chain network rely on the blockchain network itself rather than
relying on trusted third-party organisations to facilitate trans-
actions. These five properties (immutability, non-repudiation,
integrity, transparency, and equal rights) are the main properties
supported in existing blockchains.
B. Other Non-Functional Properties
Data privacy and scalability are two points of criticism of
public blockchains. As discussed earlier, in this setting privacy
is limited: there are no privileged users, and every participant
can join the network to access all the information on blockchain
and validate new transactions. There are scalability limits on
(i) the size of the data on blockchain, (ii) the transaction
processing rate, and (iii) the latency of data transmission. The
number of transactions included in each block is also limited
by the bandwidth of nodes participating in leader election (for
Bitcoin the current bandwidth per block is 1MB) [
3
]. Latency
between submission and confirmation that a transaction has

been included on a blockchain is affected by the consensus
protocol. This is around 1 hour (10-minute block interval
with 6-block confirmation) on Bitcoin, and around 3 minutes
(14-second block interval with 12-block confirmation) on
Ethereum.
III. Design Taxonomy
Taxonomies have been used in the software architecture
community to understand existing technologies [
14
], [
11
].
Creating a taxonomy requires classifying the existing work into
a compact framework, which allows an architect to explore the
conceptual design space and enables rigorous comparison and
evaluation of different design options.
The design taxonomy we present here defines dimensions
and categories for classifying blockchains and ways of using
them in systems. It is intended to help software architects
evaluate and compare blockchains, and to enable research into
architectural decision-making frameworks for blockchains and
blockchain-based systems.
Our taxonomy is informed by the academic literature (e.g.,
[
3
], [
5
], [
19
], [
7
], [
13
], [
27
]), books (e.g., [
20
]), government
and technical reports (e.g., [
1
], [
2
]), documents of industrial
blockchain products (e.g., [
26
]), developer forums and wikis,
our investigation for the Australian government of the use of
blockchains in various use cases, and our experience from
implementing proof-of-concept blockchain-based systems [
28
].
Our discussion of architectural design issues for blockchain-
based systems is structured in four sections below: the level of
(de)centralisation, support for client storage and computation,
blockchain infrastructural configuration, and other issues.
A. Architectural Design Regarding Decentralisation
Decentralisation devolves responsibility and capability from
a central location or authority. In a centralised system, all
users rely on a central authority to mediate transactions. For
example in a bank, customers rely on the bank’s systems to
correctly adjust their account balances after a bank transfer. A
central authority can manipulate the whole system, including
by directly updating backend databases, or by upgrading
the software that implements the system. Thus, a central
authority is a single point of failure for a centralised system.
In contrast, a fully decentralised currency system like Bitcoin
allows people to reach agreement on who owns what without
having to trust each other or a separate third party. Such a
system is highly available since every full node in Bitcoin
network downloads every block and transaction, checks them
against Bitcoin’s core consensus rules and provides the required
functionality to process transactions. There are currently 5000+
nodes in the Bitcoin network
7
, although not all are full
nodes that form the backbone of Bitcoin. Table I represents a
spectrum of (de)centralisation, from full centralisation to full
decentralisation. In a system it is possible that some components
or functions are decentralised while others are centralised.
There are two types of centralised systems. In the first there
is a monopoly service provider, including governments and
7https://bitnodes.21.co/nodes/
courts within a jurisdiction, and business monopolies. In the
other type there are alternative providers, such as banks, on-
line payments, or cloud computing providers. Any centralised
system is a single point of failure for its users. However, where
there are alternative providers, the failure of a single service
provider only affects its users, and users may switch providers
or use multiple providers.
At the other end of the spectrum, fully decentralised systems
include permission-less public blockchains, such as the Bitcoin
and Ethereum blockchains. Permission-less public blockchains
are completely open: new users can at any time join the
network, validate transactions, and mine blocks. Decentralised
systems using anonymous validators need to protect against
Sybil attacks, where attackers create many hostile anonymous
nodes. Bitcoin partly guards against this using its proof-of-
work mechanism, so that it is not the total number of nodes
that is important for integrity, but rather the total amount
of computational power. While it is easy for an attacker to
create anonymous nodes, it is not easy for them to amass
large amounts of computational power. A decentralised system
can be defeated unless there is a majority of authority (nodes,
computational power, or stakeholding). Game-theoretic attacks
can change this threshold, requiring a higher (e.g. 66%) majority
to maintain integrity [9].
There is a spectrum of possibilities between centralisation
and decentralisation. Here we discuss two options for partial
decentralisation: permission and verification.
1) Permission: Instead of anonymous public participation, a
blockchain may be permissioned in requiring that one or more
authorities act as a gate for participation. This may include
permission to join the network (and thus read information
from the blockchain), permission to initiate transactions, or
permission to mine. Some permissioned blockchains, e.g.,
Multichain
8
, allow more fine-grained permissions, such as
the permission to create assets. Permissioned blockchain
networks include Ripple
9
or Eris
10
. However, the code for
public blockchains can also be deployed on private networks to
create a kind of permissioned blockchain using network access
controls. Permissioned blockchains may be more suitable in
regulated industries. For example banks are required to establish
the real-world identity of transacting parties to satisfy Know-
Your-Customer (KYC) regulation. Permission information can
be stored either on-chain or off-chain, and permissioned
blockchains may be able to better control access to off-chain
information about real-world assets [
21
]. However, a transaction
on a permission-less blockchain across jurisdictional boundaries
can circumvent this and undermine regulatory controls.
There are often trade-offs between permissioned and
permission-less blockchains including transaction processing
rate, cost, censorship-resistance, reversibility, finality [
21
] and
the flexibility in changing and optimising the network rules. The
suitability of a permissioned blockchain may also depend on the
8http://www.multichain.com/
9https://ripple.com/
10https://monax.io

Table I: Blockchain-related design decisions regarding (de)centralisation, with an indication of their relative impact on quality
properties (: Less favourable, : Neutral, : More favourable)
Design
Decision
Option
Impact
Fundamental
properties
Cost
efficiency
Performance
#Failure
points
Fully
Centralised
Services with a single provider (e.g., governments, courts)
1
Services with alternative providers (e.g., banking, online payments,
cloud services)
Partially
Centralised &
Partially
Decentralised
Permissioned blockchain with permissions for fine-grained operations
on the transaction level (e.g., permission to create assets)
*
Permissioned blockchain with permissioned miners (write), but
permission-less normal nodes (read)
Fully
Decentralised
Permission-less blockchain
Majority
(nodes, power,
stake)
Fundamental
properties
Cost
efficiency
Performance
#Failure
points
Verifier
Single verifier trusted by the network (external verifier signs valid
transactions; internal verifier uses previously-injected external state)
1
M-of-N verifier trusted by the network M
Ad hoc verifier trusted by the participants involved
1 (per ad hoc
choice)
size of the network. Nonetheless, the permission management
mechanism may itself become a potential single point of failure,
not just from an operational perspective but also from a business
perspective.
2) Verification: The execution environment of a blockchain
is self-contained. It can only access information present in
a transaction or in the transaction history of the blockchain,
and the states of external systems are not directly accessible.
To address this limitation, a verifier role can be introduced to
evaluate conditions that cannot be expressed in a smart contract
running within the blockchain network. A verifier is a third
party that is trusted to provide some types of information about
the external world. When validation of a transaction depends
on external state, the verifier is requested to check the external
state and to provide the result to the validator (miner), which
then validates the condition. A verifier can be implemented as
a server outside the blockchain, and has the permission to sign
transactions using its own key pair on-demand. The concept
of an oracle in Bitcoin is an instance of a verifier
11
. The
verifier can be also implemented inside a blockchain network
as a smart contract with external state being injected into the
verifier periodically.
A centralised verifier becomes a potential single point
of failure for the transactions relying on the verifier. To
decentralise the verifier, a distributed verifier can be introduced.
A distributed verifier is comprised of several verifiers that
provide the same functionality to check the external state. All
the verifiers are trusted by the whole network. In this case, a
transaction that relies on external state can use a multi-signature
(M-of-N) schema that requires keys from M out of N verifiers
11https://en.bitcoin.it/wiki/Contract#Example_4:_Using_external_state
to authorise a transaction. For example, Orisi
12
on Bitcoin runs
a set of independent verifiers. Orisi allows the participants
involved in a smart contract to select a set of verifiers and
define the value of M before initiating a conditional transaction.
In addition, participants who wish to transact with each other
on a blockchain could rely on an ad hoc trusted arbitrator to
resolve disputes or check external status. An arbitrator may
be a human with a blockchain account that is able to sign the
transaction after some validation. Alternatively an arbitrator
may be automated and validate the transaction based on status
taken from the blockchain and the external world. For example,
Gnosis
13
is a decentralised prediction market that allows users
to choose any verifier they trust, such as another user or a web
service, e.g., for weather forecasts.
B. Architectural Design Regarding Storage and Computation
While blockchains provide some unique properties, the
amount of computational power and data storage space available
on a blockchain network remains limited. In addition, using
public blockchains costs real money, with a different kind of
cost model than conventional software systems. In regards
to cost efficiency, performance, and flexibility, major design
decisions in using a blockchain include choosing what data
and computation should be placed on-chain and what should
be kept off-chain [
28
]. Table II captures some of these options,
which are described in more detail below.
1) Item data: A common practice for data management in
blockchain-based systems is to store raw data off-chain, and to
store on-chain just meta-data, small critical data, and hashes of
12http://orisi.org/
13https://groupgnosis.com/

Table II: Blockchain-related design decisions regarding storage and computation, with an indication of their relative impact on
quality properties (: Least favourable, : Less favourable, : More favourable, : Most favourable)
Design Decision Option
Impact
Fundamental
properties
Cost efficiency Performance Flexibility
Item data
On-chain
Embedded in transaction (Bitcoin)
Embedded in transaction (Public Ethereum)
Smart contract variable (Public Ethereum)
Smart contract log event (Public Ethereum)
Off-chain
Private / Third party cloud
~KB Negligible
Peer-to-Peer system
Item collection On-chain
Smart contract
(public)
Separate chain (public)
Computation
On-chain
Transaction constraints
Smart contract
Off-chain Private / Third party cloud
the raw data. However, the applications of storing item data on
blockchain are not just for integration with external data. There
are various uses for wholly on-chain auxiliary data, including
e.g. “coloured coins which are a class of overlays on Bitcoin
to represent and manage real world assets.
In the Bitcoin blockchain, before
OP_RETURN14
was made
a valid
opcode
(i.e., function of Bitcoin Script language) to store
arbitrary bytes in an unspendable transaction, users were able to
include limited information into transactions on-chain using one
of four methods. These were: writing in a coinbase transaction
which is only editable by miners
15
, using the
nSequence
field,
using a fake account address, or using unreachable script code
defined through
if
and
else
conditions. All four methods are
deprecated now that
OP_RETURN
has been introduced as an
official way to embed arbitrary data in a Bitcoin transaction.
Table II compares the
OP_RETURN
mechanism with other
options provided by public Ethereum to store arbitrary data.
There are trade-offs in cost efficiency, performance and flexibil-
ity. The
OP_RETURN
instruction returns immediately with
an error so that the included data is not interpreted as a
script. The default Bitcoin client only relayed
OP_RETURN
transactions up to 80 bytes, which was reduced to 40 bytes
in February 2014
16
. Storing 80 bytes of arbitrary data on the
Bitcoin blockchain costs roughly US$0.036
17
. It is debatable
whether Bitcoin should be used to record arbitrary data.
Ethereum, on the other hand, theoretically allows storing
arbitrary structured data of any size. According to the cost
model given in the Ethereum yellow paper [
26
], every transac-
tion has a fixed cost of
21,000
gas (gas is the internal pricing
for executing a transaction or storing data), and every non-zero
14https://bitcoinfoundation.org/core-development-update-5/
15https://en.bitcoin.it/wiki/Genesis_block
16https://github.com/bitcoin/bitcoin/pull/3737
17
Assuming a typical Bitcoin transaction with one input and one output,
which has about 220 bytes, the default transaction fee rate of 2
×
10
4
BTC/KB
(see https://en.bitcoin.it/wiki/Transaction_fees), and with an exchange rate of
US$600/BTC (see https://poloniex.com/exchange#usdt_btc),
byte of data costs additional 68 gas. Thus, the total cost of
storing 80 bytes of data on Ethereum blockchain by submitting
a transaction is
26,440
gas (assuming all bytes are non-zero),
which is roughly US$0.00718.
Ethereum provides two other ways to store arbitrary data in
smart contracts. For 32 bytes of data, the first option is to store
the data as a variable in a smart contract (all simple types in
Solidity, the script language on Ethereum, are 32 bytes). The
cost of storing data in the contract storage is based on the
number of
SSTORE
operation on the contract variable. In the
case of storing 32 bytes, there is one
SSTORE
operation that
changes the data from zero to non-zero, which costs
20,000
gas. As aforementioned, the transaction as the carrier costs
21,000
gas. The data payload of the transaction including the
function signature and the actual data costs extra gas. Other
than these two costs, there is a cost for creating the smart
contract depending on its complexity. In total, the cost is larger
than US$0.010 (20,000 + 21,000 + 32 × 68 gas).
The second option is to store arbitrary data as a log event.
This follows different rules for calculating cost. Logged data is
stored in log topics which cost 375 gas, and where every byte
of data in a log topic costs an extra 8 gas. Including the fixed
cost of the carrier transaction with data payload, the rough
cost of using a log event to store 32 bytes of data is US$0.005
(
21,000
+ 375 + 32
×
8 gas). Storing data as a variable in a
smart contract is more efficient to manipulate, but less flexible
due to the constraints of the Solidity language on the value
types and length. The flexibility and performance of using
smart contract log events is intermediate because log events
allow up to three parameters to be queried.
Finally, we note that data storage on blockchain has a
different cost model than conventional data storage. Although
it may seem more expensive, storing data on blockchain is
18
Assuming from here on a gas price of 2
.
5
×
10
8
Ether (see https://
etherscan.io/chart/gasprice) and given an exchange rate of US$10/Ether (see
https://poloniex.com/exchange#usdt_eth).

Citations
More filters
Journal ArticleDOI
TL;DR: This paper provides a systematic vision of the organization of the blockchain networks, a comprehensive survey of the emerging applications of blockchain networks in a broad area of telecommunication, and discusses several open issues in the protocol design for blockchain consensus.
Abstract: The past decade has witnessed the rapid evolution in blockchain technologies, which has attracted tremendous interests from both the research communities and industries. The blockchain network was originated from the Internet financial sector as a decentralized, immutable ledger system for transactional data ordering. Nowadays, it is envisioned as a powerful backbone/framework for decentralized data processing and data-driven self-organization in flat, open-access networks. In particular, the plausible characteristics of decentralization, immutability, and self-organization are primarily owing to the unique decentralized consensus mechanisms introduced by blockchain networks. This survey is motivated by the lack of a comprehensive literature review on the development of decentralized consensus mechanisms in blockchain networks. In this paper, we provide a systematic vision of the organization of blockchain networks. By emphasizing the unique characteristics of decentralized consensus in blockchain networks, our in-depth review of the state-of-the-art consensus protocols is focused on both the perspective of distributed consensus system design and the perspective of incentive mechanism design. From a game-theoretic point of view, we also provide a thorough review of the strategy adopted for self-organization by the individual nodes in the blockchain backbone networks. Consequently, we provide a comprehensive survey of the emerging applications of blockchain networks in a broad area of telecommunication. We highlight our special interest in how the consensus mechanisms impact these applications. Finally, we discuss several open issues in the protocol design for blockchain consensus and the related potential research directions.

680 citations

Journal ArticleDOI
TL;DR: An in-depth survey of BCoT is presented and the insights of this new paradigm are discussed and the open research directions in this promising area are outlined.
Abstract: Internet of Things (IoT) is reshaping the incumbent industry to smart industry featured with data-driven decision-making. However, intrinsic features of IoT result in a number of challenges, such as decentralization, poor interoperability, privacy, and security vulnerabilities. Blockchain technology brings the opportunities in addressing the challenges of IoT. In this paper, we investigate the integration of blockchain technology with IoT. We name such synthesis of blockchain and IoT as blockchain of things (BCoT). This paper presents an in-depth survey of BCoT and discusses the insights of this new paradigm. In particular, we first briefly introduce IoT and discuss the challenges of IoT. Then, we give an overview of blockchain technology. We next concentrate on introducing the convergence of blockchain and IoT and presenting the proposal of BCoT architecture. We further discuss the issues about using blockchain for fifth generation beyond in IoT as well as industrial applications of BCoT. Finally, we outline the open research directions in this promising area.

654 citations


Cites methods from "A Taxonomy of Blockchain-Based Syst..."

  • ...We classify blockchain systems into three types: 1) public blockchains; 2) private blockchains; and 3) consortium (or community) blockchains [38]....

    [...]

Journal ArticleDOI
TL;DR: The operating mechanism and mainstream platforms of blockchain-enabled smart contracts are introduced, and a research framework for smart contracts based on a novel six-layer architecture is proposed.
Abstract: In recent years, the rapid development of cryptocurrencies and their underlying blockchain technology has revived Szabo’s original idea of smart contracts, i.e., computer protocols that are designed to automatically facilitate, verify, and enforce the negotiation and implementation of digital contracts without central authorities. Smart contracts can find a wide spectrum of potential application scenarios in the digital economy and intelligent industries, including financial services, management, healthcare, and Internet of Things, among others, and also have been integrated into the mainstream blockchain-based development platforms, such as Ethereum and Hyperledger. However, smart contracts are still far from mature, and major technical challenges such as security and privacy issues are still awaiting further research efforts. For instance, the most notorious case might be “The DAO Attack” in June 2016, which led to more than $50 million Ether transferred into an adversary’s account. In this paper, we strive to present a systematic and comprehensive overview of blockchain-enabled smart contracts, aiming at stimulating further research toward this emerging research area. We first introduced the operating mechanism and mainstream platforms of blockchain-enabled smart contracts, and proposed a research framework for smart contracts based on a novel six-layer architecture. Second, both the technical and legal challenges, as well as the recent research progresses, are listed. Third, we presented several typical application scenarios. Toward the end, we discussed the future development trends of smart contracts. This paper is aimed at providing helpful guidance and reference for future research efforts.

589 citations


Additional excerpts

  • ...blockchain-based systems [10]....

    [...]

  • ...[10] proposed a...

    [...]

Journal ArticleDOI
01 Jan 2017
TL;DR: An established research framework is adapted to structure the insights of the current body of research on blockchain technology, the present research scope as well as disregarded topics are outlined, and multidisciplinary research approaches are sketched out.
Abstract: While blockchain technology is commonly considered potentially disruptive in various regards, there is a lack of understanding where and how blockchain technology is effectively applicable and where it has mentionable practical effects. This issue has given rise to critical voices that judge the technology as over-hyped. Against this backdrop, this study adapts an established research framework to structure the insights of the current body of research on blockchain technology, outline the present research scope as well as disregarded topics, and sketch out multidisciplinary research approaches. The framework differentiates three groups of activities (design and features, measurement and value, management and organization) at four levels of analysis (users and society, intermediaries, platforms, firms and industry). The review shows that research has predominantly focused on technological questions of design and features, while neglecting application, value creation, and governance. In order to foster substantial blockchain research that addresses meaningful questions, this study identifies several avenues for future studies. Given the breadth of open questions, it shows where research can benefit from multidisciplinary collaborations and presents data sources as starting points for empirical investigations.

529 citations


Cites background or methods from "A Taxonomy of Blockchain-Based Syst..."

  • ...First approaches introduced blockchain technology to research by providing overviews over (de)centralized consensus systems in the context of cryptocurrencies (Glaser and Bezzenberger 2015; Tschorsch and Scheuermann 2016), blockchain typologies (Walsh et al. 2016; Xu et al. 2017) or digital payment providers in general (Kazan et al....

    [...]

  • ...…et al. (2016) Glaser and Bezzenberger (2015) Kazan et al. (2014) Tschorsch and Scheuermann (2016) Walsh et al. (2016) Watanabe et al. (2016) Xu et al. (2017) Zhu et al. (2016) Hayes (2016) Lindman et al. (2017) Sanda and Inaba (2016) Xu et al. (2016) Cocco and Marchesi (2016) Decker and…...

    [...]

  • ...…to research by providing overviews over (de)centralized consensus systems in the context of cryptocurrencies (Glaser and Bezzenberger 2015; Tschorsch and Scheuermann 2016), blockchain typologies (Walsh et al. 2016; Xu et al. 2017) or digital payment providers in general (Kazan et al. 2014)....

    [...]

Journal ArticleDOI
TL;DR: A comprehensive survey on the literature involving blockchain technology applied to smart cities, from the perspectives of smart citizen, smart healthcare, smart grid, smart transportation, supply chain management, and others is provided.
Abstract: In recent years, the rapid urbanization of world’s population causes many economic, social, and environmental problems, which affect people’s living conditions and quality of life significantly. The concept of “smart city” brings opportunities to solve these urban problems. The objectives of smart cities are to make the best use of public resources, provide high-quality services to the citizens, and improve the people’s quality of life. Information and communication technology plays an important role in the implementation of smart cities. Blockchain as an emerging technology has many good features, such as trust-free, transparency, pseudonymity, democracy, automation, decentralization, and security. These features of blockchain are helpful to improve smart city services and promote the development of smart cities. In this paper, we provide a comprehensive survey on the literature involving blockchain technology applied to smart cities. First, the related works and background knowledge are introduced. Then, we review how blockchain technology is applied in the realm of smart cities, from the perspectives of smart citizen, smart healthcare, smart grid, smart transportation, supply chain management, and others. Finally, some challenges and broader perspectives are discussed.

472 citations


Cites background from "A Taxonomy of Blockchain-Based Syst..."

  • ...its previous block, resulting an ordered list of blocks [67]....

    [...]

References
More filters
Book
24 Jan 2015
TL;DR: Mastering Bitcoin: Unlocking Digital Crypto-Currencies introduces Bitcoin and describes the technology behind Bitcoin and the blockchain, and Blockchain: Blueprint for a New Economy considers theoretical, philosophical, and societal impact of cryptocurrencies and blockchain technologies.
Abstract: Bitcoin is starting to come into its own as a digital currency, but the blockchain technology behind it could prove to be much more significant. This book takes you beyond the currency ("Blockchain 1.0") and smart contracts ("Blockchain 2.0") to demonstrate how the blockchain is in position to become the fifth disruptive computing paradigm after mainframes, PCs, the Internet, and mobile/social networking. Author Melanie Swan, Founder of the Institute for Blockchain Studies, explains that the blockchain is essentially a public ledger with potential as a worldwide, decentralized record for the registration, inventory, and transfer of all assetsnot just finances, but property and intangible assets such as votes, software, health data, and ideas. Topics include:Concepts, features, and functionality of Bitcoin and the blockchain Using the blockchain for automated tracking of all digital endeavors Enabling censorship? resistant organizational modelsCreating a decentralized digital repository to verify identity Possibility of cheaper, more efficient services traditionally provided by nations Blockchain for science: making better use of the data-mining network Personal health record storage, including access to ones own genomic dataOpen access academic publishing on the blockchain This book is part of an ongoing OReilly series. Mastering Bitcoin: Unlocking Digital Crypto-Currencies introduces Bitcoin and describes the technology behind Bitcoin and the blockchain. Blockchain: Blueprint for a New Economy considers theoretical, philosophical, and societal impact of cryptocurrencies and blockchain technologies.

2,277 citations


"A Taxonomy of Blockchain-Based Syst..." refers background in this paper

  • ..., [20]), government and technical reports (e....

    [...]

  • ...The first generation of blockchains, like Bitcoin, provided a public ledger to store cryptographically-signed financial transactions [20]....

    [...]

Proceedings ArticleDOI
24 Oct 2016
TL;DR: This paper introduces a novel quantitative framework to analyse the security and performance implications of various consensus and network parameters of PoW blockchains and devise optimal adversarial strategies for double-spending and selfish mining while taking into account real world constraints.
Abstract: Proof of Work (PoW) powered blockchains currently account for more than 90% of the total market capitalization of existing digital cryptocurrencies. Although the security provisions of Bitcoin have been thoroughly analysed, the security guarantees of variant (forked) PoW blockchains (which were instantiated with different parameters) have not received much attention in the literature. This opens the question whether existing security analysis of Bitcoin's PoW applies to other implementations which have been instantiated with different consensus and/or network parameters. In this paper, we introduce a novel quantitative framework to analyse the security and performance implications of various consensus and network parameters of PoW blockchains. Based on our framework, we devise optimal adversarial strategies for double-spending and selfish mining while taking into account real world constraints such as network propagation, different block sizes, block generation intervals, information propagation mechanism, and the impact of eclipse attacks. Our framework therefore allows us to capture existing PoW-based deployments as well as PoW blockchain variants that are instantiated with different parameters, and to objectively compare the tradeoffs between their performance and security provisions.

1,258 citations


"A Taxonomy of Blockchain-Based Syst..." refers background in this paper

  • ...Compared with proof-of-work, proof-ofstake is more cost-efficient because much less computational power is used in mining, while latency is shorter [10]....

    [...]

Journal ArticleDOI
TL;DR: This survey unroll and structure the manyfold results and research directions of Bitcoin, and deduce the fundamental structures and insights at the core of the Bitcoin protocol and its applications.
Abstract: Besides attracting a billion dollar economy, Bitcoin revolutionized the field of digital currencies and influenced many adjacent areas. This also induced significant scientific interest. In this survey, we unroll and structure the manyfold results and research directions. We start by introducing the Bitcoin protocol and its building blocks. From there we continue to explore the design space by discussing existing contributions and results. In the process, we deduce the fundamental structures and insights at the core of the Bitcoin protocol and its applications. As we show and discuss, many key ideas are likewise applicable in various other fields, so that their impact reaches far beyond Bitcoin itself.

1,193 citations


"A Taxonomy of Blockchain-Based Syst..." refers background in this paper

  • ...A blockchain implements a distributed ledger, which can in general verify and store any kind of transactions [22]....

    [...]

Proceedings ArticleDOI
19 Dec 2013
TL;DR: This paper analyzes how Bitcoin uses a multi-hop broadcast to propagate transactions and blocks through the network to update the ledger replicas, and verifies the conjecture that the propagation delay in the network is the primary cause for blockchain forks.
Abstract: Bitcoin is a digital currency that unlike traditional currencies does not rely on a centralized authority. Instead Bitcoin relies on a network of volunteers that collectively implement a replicated ledger and verify transactions. In this paper we analyze how Bitcoin uses a multi-hop broadcast to propagate transactions and blocks through the network to update the ledger replicas. We then use the gathered information to verify the conjecture that the propagation delay in the network is the primary cause for blockchain forks. Blockchain forks should be avoided as they are symptomatic for inconsistencies among the replicas in the network. We then show what can be achieved by pushing the current protocol to its limit with unilateral changes to the client's behavior.

1,116 citations


"A Taxonomy of Blockchain-Based Syst..." refers background in this paper

  • ..., [3], [5], [19], [7], [13], [27]), books (e....

    [...]

  • ...Users would respond by waiting for more confirmation blocks [7]....

    [...]

Book ChapterDOI
Marko Vukolic1
29 Oct 2015
TL;DR: In the early days of Bitcoin, the performance of its probabilistic proof-of-work (PoW) based consensus fabric, also known as blockchain, was not a major issue, and Bitcoin became a success story, despite its consensus latencies on the order of an hour and the theoretical peak throughput of only up to 7 transactions per second.
Abstract: Bitcoin cryptocurrency demonstrated the utility of global consensus across thousands of nodes, changing the world of digital transactions forever. In the early days of Bitcoin, the performance of its probabilistic proof-of-work (PoW) based consensus fabric, also known as blockchain, was not a major issue. Bitcoin became a success story, despite its consensus latencies on the order of an hour and the theoretical peak throughput of only up to 7 transactions per second.

956 citations


"A Taxonomy of Blockchain-Based Syst..." refers background in this paper

  • ...This approach can been modified to improve scalability [24]....

    [...]

  • ...Roughly speaking, BFT-based blockchains offers a much stronger consistency guarantee and lower latency, but for a smaller number of participants [24]....

    [...]