ArticlePDF Available

Abstract and Figures

Blockchain is an innovative distributed ledger technology which has attracted a wide range of interests for building the next generation of applications to address lack-of-trust issues in business. Blockchain as a service (BaaS) is a promising solution to improve the productivity of blockchain application development. However, existing BaaS deployment solutions are mostly vendor-locked: they are either bound to a cloud provider or a blockchain platform. In addition to deployment, design and implementation of blockchain-based applications is a hard task requiring deep expertise. Therefore, this paper presents a unified blockchain as a service platform (uBaaS) to support both design and deployment of blockchain-based applications. The services in uBaaS include deployment as a service, design pattern as a service and auxiliary services. In uBaaS, deployment as a service is platform agnostic, which can avoid lock-in to specific cloud platforms, while design pattern as a service applies design patterns for data management and smart contract design to address the scalability and security issues of blockchain. The proposed solutions are evaluated using a real-world quality tracing use case in terms of feasibility and scalability.
Content may be subject to copyright.
uBaaS: A Unified Blockchain as a Service Platform
Qinghua Lua, Xiwei Xua,, Yue Liub, Ingo Webera, Liming Zhua, Weishan
Zhangb
aData61, CSIRO, Sydney, Australia
bCollege of Computer and Communication Engineering, China University of Petroleum
(East China), Qingdao, China
qinghua.lu@data61.csiro.au, xiwei.xu@data61.csiro.au
Abstract
Blockchain is an innovative distributed ledger technology which has attracted
a wide range of interests for building the next generation of applications to
address lack-of-trust issues in business. Blockchain as a service (BaaS) is a
promising solution to improve the productivity of blockchain application de-
velopment. However, existing BaaS deployment solutions are mostly vendor-
locked: they are either bound to a cloud provider or a blockchain platform.
In addition to deployment, design and implementation of blockchain-based
applications is a hard task requiring deep expertise. Therefore, this paper
presents a unified blockchain as a service platform (uBaaS) to support both
design and deployment of blockchain-based applications. The services in
uBaaS include deployment as a service,design pattern as a service and aux-
iliary services. In uBaaS, deployment as a service is platform agnostic, which
can avoid lock-in to specific cloud platforms, while design pattern as a ser-
vice applies design patterns for data management and smart contract design
to address the scalability and security issues of blockchain. The proposed
solutions are evaluated using a real-world quality tracing use case in terms
of feasibility and scalability.
Keywords: Blockchain, architecture, design patterns, deployment,
blockchain as a service
Xiwei Xu is the corresponding author.
Preprint submitted to Future Generation Computer Systems June 4, 2019
1. Introduction
Blockchain technology has attracted a wide range of interests as a dis-
tributed ledger technology for establishing digital trust in business. Many
start-ups, enterprises, and governments [1, 2] are currently exploring how
to leverage blockchain technology to achieve trust and decentralization in
the next generation of applications. Blockchain-based application areas are
diverse, including physical or digital asset ownership management, tokens,
currency, identity management, supply chain, electronic health records, vot-
ing, energy supply, and more.
Blockchain as a service (BaaS) is a promising solution to improve the
productivity of blockchain application development. Easier deployment is
the primary service offered by the existing BaaS platform providers, e.g. Mi-
crosoft Azure1, IBM2, and Amazon3. However, the existing BaaS deployment
solutions are usually vendor locked, which are bound to either a cloud vendor
(e.g. Microsoft Azure1) or a blockchain platform (e.g. IBM Hyperledger2).
In addition to deployment, the design and implementation of blockchain-
based applications are challenging to developers. First, blockchain is a new
technology with limited tooling and documentation, so there can be a steep
learning curve for developers. According to a survey by Gartner [3], “23 per-
cent of [relevant surveyed] CIOs said that blockchain requires the most new
skills to implement any technology area, while 18 percent said that blockchain
skills are the most difficult to find.” Second, blockchain is by design an im-
mutable data store, so updating deployed blockchain smart contracts can be
hard. This makes it difficult to fix bugs by releasing new versions of smart
contracts. Mistakes in smart contracts have led to massive economic loss
such as the DAO exploit on the Ethereum blockchain [4].
A software design pattern is defined as a solution to a problem that
commonly occurs within a given context during software design [5]. Design
patterns for blockchain-based applications are best practices from industry
and can be encapsulated services to ease the burden of developers and im-
prove the quality of blockchain-based applications. One motivating example
is the on-chain and off-chain design pattern, which provides a solution for
storing data of blockchain-based applications. The purpose of separately
1https://azure.microsoft.com/en-gb/solutions/blockchain/
2https://www.ibm.com/blockchain/platform/
3https://aws.amazon.com/blockchain/
2
storing data on-chain and off-chain is to ensure the integrity of on-chain data
and privacy of the off-chain data. This pattern can be implemented as a
service to generate an on-chain data registry smart contract and an off-chain
data table in the conventional database based on the data model built by the
developers. For example, in a quality tracing system, the on-chain attributes
could be the traceability identifier and traceability result, while the off-chain
attributes could be product price, buyer name, etc.
This paper presents a unified blockchain as a service platform named
uBaaS, which facilitates the design and deployment of blockchain-based ap-
plications. The contributions of this paper are as follows.
A set of design patterns for data management and smart contract design
of blockchain-based applications to better take advantage of blockchain
technology in practice. The design patterns include on-chain and off-
chain,hash integrity,data encryption,multiple authorities,dynamic
binding, and embedded permission.
The uBaaS platform approach:
Deployment as a service which includes a blockchain deployment
service and a smart contract deployment service. Deployment as
a service can ease blockchain network deployment and smart con-
tract deployment. The proposed blockchain deployment service is
platform agnostic, which can avoid lock-in to specific cloud plat-
forms.
Design pattern as a service which consists of data management
services and smart contract design services. Each service is de-
signed based on a design pattern to better leverage the unique
properties of blockchain (i.e. immutability and data integrity,
transparency) and address the limitations (i.e. privacy and scala-
bility).
Feasibility and scalability of the proposed solutions are evaluated using
a real-world quality tracing use case. The evaluation results show that
our solutions are feasible and have good scalability.
The remainder of this paper is organized as follows. Section 2 discusses
the background and related work. Section 3 summarizes the design patterns
for data management and smart contract design. Section 4 presents the
overall architecture of uBaaS platform and design of each service provided
by uBaaS. Section 5 introduces the implementation details. Section 6 evalu-
ates the proposed solutions in terms of feasibility and scalability. Section 6
concludes the paper and outlines the future work.
3
2. Related Work
This section introduces the related work of our research. Blockchain
technology and its classification are presented first, as it is the basis of this
research. Further, how to apply blockchain technology to software systems
is demonstrated, after which there is a brief introduction of the current ob-
stacles to develop blockchain-based applications. Lastly design patterns and
blockchain as a service are discussed.
2.1. Blockchain Technology
Blockchain is the technology behind Bitcoin [6], which is a decentralized
data store that maintains all historical transactions of the Bitcoin network.
The concepts of blockchain have been generalized to distributed ledger sys-
tems that verify and store transactions without coins or tokens [7], without
relying on any central trusted authority, e.g. traditional banking systems.
Instead, all participants in the blockchain network can reach agreement on
the states of transactional data to achieve trust.
The data structure of blockchain is an ordered list of identifiable blocks,
each of which is connected to the previous block in the chain. Blocks are
containers aggregating transactions while transactions are identifiable data
packages that store parameters (such as monetary value) and function calls
to smart contracts. A smart contract is a user-defined program that is de-
ployed and executed on the blockchain network [8], which can express trig-
gers, conditions and business logic [9] to enable more complex programmable
transactions. Smart contracts can be implemented as part of transactions,
and are executed across the blockchain network by all connected nodes. The
blockchain platform Ethereum provides a built-in Turing-complete scripting
language for writing smart contracts, called Solidity. The Ethereum Virtual
Machine (EVM) is the execution environment for Ethereum, which comprises
all full nodes on the network and executes bytecode compiled from Solidity
scripts.
2.2. Types of Blockchain
As shown in Table 1, there are three types of blockchain in terms of de-
ployment, including public blockchain, consortium blockchain, and private
blockchain. Public blockchains, which are used by most digital currencies,
can be accessed by anyone on the Internet. Using a public blockchain achieves
better data transparency and auditability, but sacrifices performance and has
4
Table 1: Types of Blockchain (: Less favourable, ⊕⊕: Neutral, ⊕⊕⊕: More favourable)
Type
Impact
Fundamental
properties
Cost
efficiency Performance Flexibility
Public blockchain ⊕⊕⊕ ⊕
Consortium blockchain ⊕⊕ ⊕⊕ ⊕⊕ ⊕⊕
Private blockchain ⊕⊕⊕ ⊕⊕⊕ ⊕⊕⊕
a different cost model. A consortium blockchain is typically used across mul-
tiple organizations and has pre-authorized nodes to control the consensus
process. In a private blockchain network, write permissions are often kept
within one organization, although this may include multiple divisions of a
single organization. The right to read the consortium or private blockchain
may be public or may be restricted to a specific group of participants. When
using a consortium or private blockchain, a permission management com-
ponent is required to authorize participants within the blockchain network.
Private blockchains are the most flexible for configuration because the net-
work is governed and hosted by a single organization. Our work is mainly
focused on consortium blockchains and private blockchains.
2.3. Blockchain as a Component of Software Application Systems
Researchers in academia and developers in industry are investigating and
exploring how to build next generation applications using blockchain tech-
nology [1, 2]. Application areas in industry include but are not limited to
digital currency, international payments, registries, government identity and
taxation management, Internet of Things (IoT) identify and security man-
agement, and supply chain [10, 11, 12, 13]. Furthermore, there is various
academic work that exploits blockchain to address issues in different do-
mains. Qu et al. [14] propose spatio-temporal blockchain technology that
supports fast query processing, which is proved to be applicable and effective.
Zyskind et al. use blockchain to build a personal data management system
that ensures users own and control their data in a decentralized way[15]. Bu-
lat Nasrulin et al. proposed a mobility analytics application that is built on
top of blockchain[16] and renovated blockchain with distributed database[17].
5
Key
management
Smart contracts
Decentralised
data ledger Conventional databases
Components
On-chain
Data layer
Logic layer
Presentation layer
User interface
Permission
management
Validation
Incentive
mechanism
Cryptography Oracles
Platform layer
Off-chain
Figure 1: Blockchain as a component of software application systems.
Namecoin [18] and PKI [19] are two public key platforms built on blockchain.
ProvChain enables data Provenance for cloud-based data analytics[20].
Software components are the fundamental building blocks for software
architecture, and blockchain can be a software component offering computa-
tional capabilities. Blockchains are complex, network-based software compo-
nents, which can provide data storage, computation services, and communi-
cation services.
Fig. 1 illustrates the architecture of a blockchain-based application sys-
tem, which consists of four horizontal layers and two vertical layers. The
horizontal layers include a presentation layer, a logic layer, a data layer, and
a platform layer, while the vertical layers are on-chain and off-chain.
The users interact with blockchain smart contracts and off-chain compo-
nents (including the key management component) via the user interface. The
blockchain-based application system can implement business logic through
different off-chain components and on-chain smart contracts. Key manage-
ment is an essential off-chain component in such blockchain-based system.
Every participant in a blockchain network has one or more private keys, which
are used to digitally sign the transactions. The security of these private keys
6
is important: if the private key is stolen, assets held by the respective account
can be accessed and protected functions of smart contracts can be invoked.
At the data layer, blockchain acts as a decentralized data ledger to store
data which requires integrity and/or transparency. Off-chain conventional
databases are often needed to store private or large-size data due to the
scalability and privacy.
At the platform layer, the fundamental blockchain features can include
permission management, incentive mechanisms, transaction validation, and
cryptographically-secure payment. The oracles supply information about the
external world to the blockchain, usually by adding that information to the
blockchain as data in a transaction.
2.4. Challenges of Blockchain Application Development
Blockchain is an emerging distributed ledger technology which requires
developers to learn new skills and have a deep understanding of the tech-
nology in order to build blockchain-based applications. We summarize the
challenges of blockchain application development as follows.
Deployment. The current blockchain deployment solutions (e.g. Mi-
crosoft Azure1, IBM Hyperledger2, Amazon3) lock customers in to
specific cloud and/or blockchain platforms. However, many enter-
prises or governments require building blockchain-based applications
on their own on-premise private cloud, which are not met by the exist-
ing blockchain solutions. Besides, the deployment process of blockchain
is error-prone, time-consuming, and requires frequent updating.
Scalability. Blockchain has limited storage capability since it con-
tains a full history of all the transactions across all participants of the
blockchain network. Thus, the size of blockchain continues to grow.
The ever-growing size of blockchain is a challenge for storing data on
blockchain. Also, storing large amounts of data or deploying large
smart contracts within a transaction may be impossible due to the lim-
ited size of the blocks of the blockchain, which is under control of the
network [21].
Data privacy. Blockchain-based applications might have sensitive data
which should be only available to some certain blockchain participants.
However, the information on blockchain is designed to be accessible to
all the participants. There is no privileged user within the blockchain
network, whether the blockchain is public, consortium or private.
7
Key management. Authentication on blockchain is achieved by digi-
tal signatures. However, blockchain does not offer any mechanism to
recover a lost or a compromised private key. Losing a key results in per-
manent loss of control over an account, and potentially smart contracts
that refer to it.
Permission control. All the smart contracts deployed on blockchain
can be accessed and called by all the blockchain participants by de-
fault. A permission-less function might be triggered by unauthorized
users accidentally, which becomes a vulnerability of blockchain-based
application.
2.5. Design Patterns and Blockchain as a Service
A design pattern is a reusable solution to a problem that commonly oc-
curs within a given context during software design [22]. There are a few
works on design patterns for blockchain-based applications. J. Eberhardt
and S. Tai present a group of patterns which mainly focus on on-chain and
off-chain data and computation [23]. Zhang et al. applies four existing
object-oriented software patterns to smart contract design in the context of
a blockchain-based health care application [24]. Liu et al. summarized eight
smart contract design patterns and classified them into four categories[25].
Bartoletti and Pompianu conduct an empirical analysis of smart contracts,
in which they collected hundreds of smart contracts and divided them into
several categories: token, authorization, oracle, randomness, poll, time con-
straint, termination, math and fork check [26]. In recent work, some of the
authors of this paper proposed an extensive pattern collection [27]. However,
the summarized design patterns for blockchain-based applications are mostly
at conceptual level, requiring users to implement the solutions.
Blockchain as a service (BaaS) provides an offering that allows develop-
ers to develop blockchain-based applications efficiently. Most of the current
BaaS platforms are designed to help developers create, deploy, and manage
blockchain network, e.g. Microsoft Azure1, IBM2, and Amazon3. However,
the existing BaaS deployment solutions are usually locked into a specific
public cloud or blockchain network provider (e.g. Microsoft Azure1, IBM
Hyperledger2). Many governments or enterprises deploy their applications
in private clouds and may have different blockchain network preferences.
Besides, in addition to deployment services, development services are also
required for BaaS platforms. Architecture design of blockchain application
8
is a challenge to developers since they need to learn blockchain programming
languages and have a deep understanding of blockchain technology.
3. Design Patterns for Blockchain-based Applications
In software engineering, a design pattern is a reusable solution to a prob-
lem that commonly occurs within a given context during software design [5].
In this section, we summarize and categorize six design patterns which can
be applied to the architecture design of a blockchain-based application sys-
tem. Those patterns are divided into data management design patterns and
smart contract design patterns according to their characteristics and effects.
3.1. Data Management Design Patterns
As discussed in Section 2.3, in a blockchain-based application system,
blockchain can act as a decentralized data ledger and work with conventional
databases to store data. Data management of blockchain-based application is
challenging due to the fundamental properties (e.g. data transparency) and
limitations of blockchain (e.g. blockchain scalability). Here we summarize
three design patterns for data management: on-Chain and off-Chain,hash
integrity and data encryption.
3.1.1. On-Chain and Off-Chain
Summary: The on-chain and off-chain pattern separately stores data on
blockchain and off blockchain to ensure the data integrity while addressing
the storage capability issue of blockchain.
Context: Some applications consider leveraging blockchain to ensure data
integrity since all the data on blockchain are transparent and immutable.
Problem: It may be impossible to store sensitive and large amounts of
data on blockchain since all the information on blockchain is accessible to all
participants and blockchain has limited storage capacity.
Solution: Rather than placing all the data on-chain, only the sensitive and
small data is stored on-chain. For example, a food quality tracing system
can store traceability information that is required by the traceability regu-
lation (e.g. traceability number and results) on-chain, while places the fac-
tory production process photos off-chain. The benefits of separately storing
data on blockchain and off blockchain is to better leverage the properties of
9
blockchain and avoid the limitations of blockchain. Blockchain can guarantee
the integrity and immutability of the critical data on-chain. The non-tiny
files are stored off-chain so that the size of the blockchain would not grow so
fast. Storing the hashes of off-chain files can further ensure the integrity of
the off-chain files.
3.1.2. Hash Integrity
Summary: The hash integrity pattern uses hashing to ensure the integrity
of arbitrarily large datasets which may not fit directly on the blockchain.
Context: Some blockchain-based applications consider using blockchain to
ensure the integrity of large amounts of data.
Problem: It may be impossible to store large amounts of data within a
transaction since the blocks of blockchain has limited size (e.g., Ethereum
has a block gas limit to control the data size, computational complexity
and number of transactions included in a block). There is a problem about
how to store arbitrary size data on blockchain to guarantee data integrity.
Solution: For data of large size (essentially data that is bigger than its
hash value), rather than storing the raw data directly on blockchain, a hash
value of the raw data is stored on blockchain. The hash value is produced
by a hash function which maps data of arbitrary size to data of fixed size
and is non-invertible. Any change to the data will lead to a change in its
corresponding hash value.
3.1.3. Data Encryption
Summary: The data encryption pattern ensures confidentiality of the data
stored on blockchain by encrypting it.
Context: For some blockchain-based applications, commercially sensitive
data should be only accessed by specific participants. An example would be
a special discount price offered by a service provider to a subset of its users.
Such information might not be supposed to be accessible to the other users
who do not get the discount.
Problem: The lack of data privacy is one of the main limitations of blockchain.
All the information on blockchain is publicly available to the participants
of the blockchain. There is no privileged user within the blockchain net-
work, no matter the blockchain is public, consortium or private. On a public
10
blockchain, new participants can join the blockchain network freely and ac-
cess all the information recorded on blockchain. Any confidential data on
public blockchain is exposed to the public.
Solution: Asymmetric(or symmetric) encryption can be used to encrypt
data before storing the data on blockchain. One of the involved participants
generate a key pair and distribute the decryption key to other involved par-
ticipants. The involved participants can encrypt the data before placing it
on blockchain using the encryption key. Only the involved participants who
have the decryption key can decrypt the data.
3.2. Smart Contract Design Patterns
Developers can define smart contracts (i.e. software programs on blockchain)
to implement business logic and enable more complex programmable trans-
actions. However, developing smart contracts usually require developers to
have a deep understanding of blockchain and rich smart contract develop-
ment experience. Thus, we summarize three design patterns as solutions to
address the common problems (e.g. security) in the design of smart contracts.
3.2.1. Multiple Authorities
Summary: A set of blockchain account addresses which can authorize a
transaction is pre-defined. Only a subset of the pre-defined account addresses
is required to authorize transactions.
Context: Some activities in blockchain-based applications might need to
be authorized by multiple parties (i.e. blockchain account addresses). For
example, a monetary transaction may require authorization from multiple
blockchain account addresses.
Problem: The actual addresses that authorize an activity might not be able
to be determined due to the availability of the authorities.
Solution: To enable more flexible binding, an M-of-N mechanism can be
used to define that M out of N private keys are required to authorize the
transaction. M is the threshold of authorization.
3.2.2. Dynamic Binding
Summary: The dynamic binding pattern uses a hash created off-chain to
dynamically bind authority for a transaction.
11
Context: In blockchain-based applications, some activities need to be autho-
rized by one or more participants that are unknown when the corresponding
smart contract is deployed or the transaction is submitted to blockchain.
Problem: Blockchain does not support dynamic binding with a blockchain
account address which is not defined in the transaction or smart contract.
All accounts that can authorize a second transaction have to be defined in
the first transaction before that transaction is added to the blockchain.
Solution: An off-chain secret can be used to enable a dynamic binding
when the participant authorizing a transaction is unknown beforehand. In
the context of payment, when the sender deposits money to an escrow smart
contract, a hash of a secret is submitted with the money as well. The partic-
ipant who receives the secret off-chain can claim the money from the escrow
smart contract by revealing the secret. Thus, the receiver of the money does
not need to be defined beforehand in the escrow contract.
3.2.3. Embedded Permission
Summary: Smart contracts use an embedded permission control to restrict
access to the invocation of the functions defined in the smart contracts.
Context: A smart contract by default has no owner, since the smart con-
tracts running on blockchain can be accessed and called by all the blockchain
participants and other smart contracts by default.
Problem: Once the smart contract is deployed, the author of the smart con-
tract has no special privilege to invoke on the smart contract. A permission-
less function can be triggered by unauthorized users accidentally, which
becomes a vulnerability of blockchain-based application. For example, a
permission-less function is discovered in a smart contract library used by
the Parity multi-sig wallet, caused the freezing of about 500K Ether4. In
2016, 7% smart contract on public Ethereum could be terminated without
authority [28].
Solution: Permission control can be added to every smart contract func-
tion to check permissions for every function caller based on the blockchain
address of the caller before executing the logic of the function. Calls from
unauthorized blockchain addresses are rejected.
4https://paritytech.io/a-postmortem-on-the-parity-multi- sig-library-self-destruct/
12
Blockchain networ k
Deployment services
Auxiliary services
Blockchain
deployment
Smart contract
deployment
Key generation
File comparison
Data management services Smart contract design
services
Developer
Blockchain
node
Data encryption
Hash integrity
Multiple authorities
Dynamic binding
Embedded
permission
Deployment
parameters
Smart
contract
Smart
contract
code
Off-chain
database
File hash
Data
schema
Off-chain
data
schema
On-chain data/file
registry sma rt contract
Operator
User
File
Data
Key
request
Key
pair
Encryptio n key
Off-chain
data/file
On-chain & off-chain
On-chain data including
encrypted data and
hashed file
Smart
contract
Figure 2: Architecture of uBaaS.
4. Architecture of uBaaS
In uBaaS, we propose deployment as a service for vendor-independent
deployment and design pattern as a service to address the scalability and
security issues of blockchain-based applications. Fig. 2 illustrates the over-
all architecture of uBaaS. The services proposed in uBaaS are classified into
three categories, deployment as a service,design pattern as a service and
auxiliary services. Users can build up blockchain environment and design
blockchain-based applications via uBaaS front-end user interface, which in-
teracts with the back-end services through an API gateway. The API gate-
way forwards API calls from the front-end user interface to the corresponding
services.
The remainder of this section introduces deployment as a service,design
pattern as a service and auxiliary services respectively. Deployment as a
13
Service consists of 2 kinds of deployment services, design pattern as a ser-
vice includes 6 design pattern services to help developers take advantage of
blockchain’s properties and address blockchain’s limitations, while auxiliary
services can act as assistance to better leverage design pattern as a service.
4.1. Deployment as a Service
Deployment as a service includes blockchain deployment service and smart
contract deployment service. Users can configure the blockchain settings
(such as difficulty and participant node IP) and deploy their customized
blockchain network using uBaaS. Infrastructure-as-code is applied to the
blockchain deployment service which enables the automation of deployment,
configuration, and task management by the developed script. Once the
blockchain is set up, users can monitor the status of blockchain at real-time
and deploy the developed smart contracts on the blockchain. We assume we
can access the participant nodes since we focus on consortium blockchain and
private blockchain. Currently, both Ethereum blockchain and Hyperledger
Fabric blockchain are supported. We plan to add more blockchain platforms
as deployment options in uBaaS.
The smart contract deployment service enables users to select the devel-
oped smart contract (i.e. program) file and deploy the smart contract code
on the blockchain. Besides, the smart contract address and Application Bi-
nary Interface (ABI) are stored in the off-chain database for invoking the
deployed smart contract.
4.2. Design Pattern as a Service
Design pattern as a service consists of data management services and
smart contract design services.Data management services include on-chain
and off-chain service,data encryption service, and hash integrity service,
while smart contract design services comprises multiple authorities service,
dynamic binding service,embedded permission service. Each type of services
is designed based on a design pattern to improve scalability, adaptability,
and security of blockchain-based applications. The data management services
enable users to manage data directly via uBaaS front-end user interface while
the smart contract design services integrate smart contract design patterns
into the original smart contract.
14
4.2.1. Data Management Services
To address the issues of blockchain storage capability limitation and data
privacy, an on-chain and off-chain service is proposed to store the critical
data which is required to be immutable on-chain while keep all the data off-
chain to enhance the data reading efficiency. Users can define the data schema
and determine which attributes are stored on-chain and off-chain. Based
on the data model built by users, the service builds up a data registry on
blockchain by deploying the generated on-chain data registry smart contract
and sets up an off-chain data table in the conventional database. The on-
chain data registry and off-chain data table share the same name. The user
can write/read data to/from the selected data store regardless to being stored
on-chain or off-chain.
To preserve the privacy of the involved participants, uBaaS provides a
data encryption service that encrypts on-chain data to ensure confidentiality
of the data stored on blockchain. The uBaaS user first encrypts the data item
using the private key (generated by the key generation service in auxiliary
services) and then stores it on blockchain. The blockchain participants who
have the public key are allowed to access the transaction and decrypt the
information. By using the on-chain data encryption service, the sensitive
data stored on blockchain are not accessible to blockchain participants who
do not hold the public key.
To store the large size data (i.e. file) on blockchain, the hash integrity
service generates the hash value of the file and stores the hash in the on-
chain file registry which is associated with the on-chain data registry using
the pre-defined foreign key.
4.2.2. Smart Contract Design Services
The smart contract design services focus on the permission control for invoca-
tion of the smart contract functions. The input of each of those services is the
smart contract code written by the user while the output is updated smart
contract code by adding the template code implementing the corresponding
smart contract design pattern.
The multiple authorities service focuses on the smart contact functions
that can be invoked only when the authorized blockchain addresses approve.
Users can predefine a group of blockchain addresses which can authorize a
transaction (i.e. calling a function in the smart contract) and set the minimal
15
number of authorizations for transaction approval. The users need to select
a smart contract they write and the function which needs the mechanism of
multiple authorities. Then uBaaS modifies the code of the selected function
and generate an updated smart contract with code for multiple authorities.
The dynamic binding service uses an off-chain secret to enable a dynamic
authorization when the participant approving a transaction (i.e. calling a
function in the smart contract) is unknown beforehand. Users need to provide
an secret (e.g. a random number) and select the corresponding function in
the smart contract. The service modifies the function code by adding the
hash of the secret and generate the updated smart contract. There is no
need for a special protocol to exchange the secret as it can be exchanged in
any ways off-chain. Only the user who has the secret can invoke the selected
function in the smart contract.
The purpose of embedded permission service is to restrict access to the
invocation of the functions defined in the smart contracts. Users can identify
the authorities for the selected function in the smart contract by providing
the authority addresses. The service adds permission control code to the
smart contract function to check permissions for every caller based on the
blockchain addresses of the caller, which is done before executing the function
logic.
4.3. Auxiliary Services
The current version of uBaaS supports two auxiliary services, key man-
agement service and file comparison service.
The key management service is used to generate key pairs for data en-
cryption. The developers can encrypt the data using the data encryption
service and share the decryption key with other platform users (e.g. devel-
opers or application users) before store the encrypted data in the on-chain
data registry. The channel for sharing the decryption key is out of the scope
in this paper.
The purpose of file comparison service is to validate the authenticity of
a file (e.g. higher education certificates). Users can select the file from local
node and check the authenticity of the file by comparing its hash value with
the hash value of the associated original file stored in the on-chain file registry.
16
DesignedContractDesignedContract
initialCode: String
(user-de fined sma rt contract)
selectedFunction: St ri ng
updatedCode: String
(update d smart c ontract)
setCode(initialCode): void
selectFunction(initialCode): String
applyEm beddedPerm ission(initialCode, selectedFunction): String
applyDynamicBinding(initialCode, s electedFunction): String
applyMultipleAuthorities(initialCode, selec tedFunction): String
OnChainDataRegistryOnChainDataRegistry
record: Record
addRecor d(): void
getRecor d(): Record
SmartContractSmartContract
abi: String
address: address
deploy(sour ceCode, abi ): address
BlockchainBlockchain
id: String
ip: String
blockchainType: String
difficulty: St ring
deployFabric(ip): bool
deployEthereum(ip, diffic ulty): bool
1
0..*
OffChainDataRegistryOffChainDataRegistry
record: Record
addRecor d(): void
getRecor d(): Record
1 1
FileFile
id: String
path: String
name: Stri ng
fileContext:String
fileHash: String
getFile(): void
SHA256(fileContext): String
KeyPairKeyPair
publicKey: P ublicKey
privateKey: PrivateKey
generateKeyPair(): void
getPublicKe y(): PublicKey
getPrivateKey(): PrivateKey
OnChainFileRegistryOnChainFileRegistry
fileId: String
fileHash: String
setFileHash(fileId, file Hash): void
getFileHash(file Id): String
1
RecordRecord
attributeName: String
attribute: Type
(user-defined attribute s)
encryptAt tributeVal(publickkey, attribute): String
decryptAt tributeVal(privatekey, a ttribute): T ype
setAttributeVal(attributeName, attr ibute): void
getAttributeVal(attributeName): Type
checkIntegrity(attribute, onC hainAttribute): bool
OffChainFileRegistryOffChainFileRegistry
fileId: String
fileHash: String
setFileHash(fileId, file Hash): void
getFileHash(fileId): String
checkInteg rit y(fileHash,
onChainFileH ash): bool
OffChainSmartContractRegistryOffChainSmartContractRegistry
sourceCode: String
abi: String
address: addr ess
setContrac tInfo(address,
sourceCode, abi): void
getContractInfo(): Str ing[]
BlockchainRegistryBlockchainRegistry
id: String
ip: String
blockchainType: String
setBlockchainI nfo(id, ip,
blockchainPlatform): void
getBlockchai nInfo(): String[]
1
*
1
1
*
Figure 3: The main class diagram of uBaaS implementation.
17
Figure 4: Blockchain deployment time.
5. Implementation
Fig. 3 illustrates the implementation design of uBaaS using the class
diagram. BlockchainRegistry maintains each deployed Blockchain network,
while OffChainSmartContractRegistry stores the source code and information
of SmartContract. There are three classes that inherit from SmartContract:
OnChainDataRegistry,OnChainFileRegistry and DesignedContract. Each
OnChainDataRegistry is associated with an OffChainDataRegistry for data
storage. User-defined data record attributes are contained in Record, and
OnChainDataRegistry and OffChainDataRegistry are composed of Record.
Note that the attribute values stored in Record must be encrypted using
KeyPair before storing in OnChainDataRegistry.File is stored in both Of-
fChainFileRegistry and its hash value is stored in OnChainFileRegistry.De-
signedContract applies smart contract design patterns to the smart contract
code written by users.
The platform is developed in Java 1.8 using Eclipse Java IDE 4.6.0 and
released using Tomcat v7.0 server. To achieve blockchain deployment as a
18
0
10
20
30
40
50
60
70
010 20 30 40 50 60 70 80 90 100
Exectuion time (s)
Number of attributes
off-chain table
on-chain contract
Figure 5: Execution time of generating an off-chain data table and an on-chain data
registry smart contract.
service, we used SSH to transfer the deployment files, including the client
file (e.g. Geth for Ethereum) and genesis block file (e.g. genesis.json for
Ethereum), to the participant nodes. To implement data management ser-
vices, we selected MySQL 5.7.17 as the supported database to store off-chain
data. Regarding smart contract design services, the smart contract design
pattern templates are pre-developed and stored in the database. The plat-
form users can select the smart contract design pattern that they want to
apply. For both data management services and smart contract design ser-
vices, the smart contracts are written in Solidity, compiled with Solidity
compiler version 0.4.24. After compilation, a smart contract is deployed on
blockchain via web3 API, returning smart contract address as result if the
deployment succeeds.
19
0
20
40
60
80
100
120
140
010 20 30 40 50 60 70 80 90 100
Ececution time (s)
Number of attributes
off-chain table
on-chain contr ac t
Figure 6: Execution time of writing data to the off-chain data table and the on-chain data
registry smart contract.
6. Evaluation
In this section, we evaluate the feasibility and scalability of uBaaS. We
first introduce the experiment environment. Then we evaluate the feasibility
and scalability of the blockchain deployment service and data management
services in uBaaS. Finally, we evaluate the feasibility of smart contract design
services in uBaaS using a real-world quality tracing use case.
6.1. Experiment environment
The uBaaS platform was deployed on an Alibaba Cloud5virtual machine
(2 vCPUs, 8G RAM, 20GB disk). The adopted blockchain is Ethereum
1.5.9-stable, in which the consensus algorithm is Proof-of-Work (PoW). The
selected database for off-chain data storage is MySQL 5.7.17. We set up
5https://www.aliyun.com/
20
0
200
400
600
800
1000
1200
1400
1600
1800
2000
010 20 30 40 50 60 70 80 90 100
Execution time (ms)
Number of attributes
off-chain table
on-chain contr ac t
Figure 7: Execution time of reading data from the off-chain table and the on-chain smart
contract.
100 Alibaba Cloud virtual machines (1 vCPUs, 1G RAM) as the blockchain
nodes (the number of nodes varies based on the experiment requirements).
6.2. Evaluation of Blockchain Deployment Service
We evaluated the scalability of blockchain deployment service by measur-
ing the deployment time of blockchain with different number of nodes. We
set the blockchain type as Ethereum and the difficulty as 0x4000, and filled
in the IP addresses of the nodes for deployment. According to the settings,
uBaaS automatically deployed the Ethereum blockchain on the target nodes.
Fig. 4 shows the measurement results for deployment time of Ethereum
blockchain using uBaaS with increased number of nodes. The deployment
time increased almost linearly, showing good scalability. The experiment
results also show that the blockchain deployment service in uBaaS is feasible.
6.3. Evaluation of Data Management Services
The main functionality provided by the data management services in-
clude: 1) generating an on-chain data registry and an off-chain data table in
21
Submit
application
Process
application
Inspect
factory
Check
products Supervise
loading Seal
containers
Test
sample
Receive
certificate
Issue
certificate
Supplier
Quality tracing agency
Factory
inspector
Freight
yard
inspector Admin
Lab
Figure 8: Quality tracing process.
the conventional database based on the data model built by the developers;
2) writing/reading data to/from the on-chain data registry and off-chain data
table. Therefore, we evaluated the data management services in a two-fold
way: First, we measured the execution time of creating a data table off-
chain in a remote conventional database and generating the corresponding
data registry smart contract on-chain; Then, we tested the execution time of
writing/reading data to/from the off-chain table and on-chain smart contract
respectively. Note that the current version of uBaaS encrypts all the data
before storing them on-chain. Thus, the time of writing data and reading
data to/from on-chain data registry include data encryption and decryption.
Fig. 5 illustrates the execution time of creating an off-chain data table and
generating the associated on-chain data registry with the increased number of
data record attributes. The execution time of generating a smart contract on
blockchain is much higher than creating a table in the conventional database,
due to the Proof of Work (POW) mechanism in Ethereum. In addition,
96.7% of the on-chain data registry smart contracts are generated within
50 seconds. The on-chain data registry smart contract generation time is
22
fluctuating because block generation time varies around an average value
according to the difficulty setting of Ethereum.
Fig. 6 demonstrates the execution time of writing data to an off-chain
data table and to the associated on-chain data registry smart contract with
increased number of attributes. The execution time increased linear, which
shows good scalability. Compared to writing data to the off-chain data table
in the conventional database, storing data to the on-chain data registry smart
contract is much slower since it is time-consuming to generate a new block
and include the transactions in the block. The fluctuation of writing data
to the deployed smart contract is also because the block generation time is
unstable as mentioned above.
Fig. 7 shows the execution time of reading data from the on-chain data
registry smart contract, which is much shorter than generating an on-chain
data registry smart contract and writing data to the deployed smart con-
tract, as reading is from the local node of blockchain. It is still higher than
reading data from traditional database, as the data stored on-chain needs to
be decrypted before being presented to the user in uBaaS.
The experiment results in Fig.5-7 also show the feasibility of the data
management services in uBaaS.
6.4. Evaluation of Smart Contract Design Services
We evaluated the feasibility of the smart contract design services using
a real world quality tracing process. Fig. 8 illustrates the quality tracing
process for import commodities in China [29]. The quality tracing agency
accredited by the Chinese government provides quality tracing services and
issues traceability certificates of commodity if all requirements are fulfilled.
The process starts when a product supplier submits a quality tracing ap-
plication to the agency. The administrator processes the application paper
work (e.g. invoices) and payment. Once the application is validated, the
agency assigns a factory inspector to check the factory location, production
capability, quality control process, etc. After inspecting the factory, a freight
yard inspector is sent to examine the products placed in the freight yard and
to inspect the on-site loading process. The inspector seals the containers if
the process of on-site loading complies with regulations. In the meantime,
a product sample is sent to the lab for sample testing. Once the applica-
tion passes the inspections and testing, the quality tracing agency issues the
supplier a traceability certificate of commodity. In the quality tracing sys-
tem, the quality tracing agency manages the quality tracing process and data
23
while the lab submits testing reports through the quality tracing system. The
quality inspection bureau mainly monitors the quality tracing process and
does not provide any input to this system.
contract MultipleAuthorities{
uint total;
address[] authority;
bool agreeing;
uint agreeThreshold;
mapping(address => bool) agreeState;
bool agreePermission;
address agreeRequester;
...
function agreeSignature(){
agreeState[msg.sender] = true;
if(agreeResult())
agreePermission = true;
}
function agreeResult() internal returns (bool signatureResult){
uint k = 0;
for(uint i = 0; i <total; i++)
if(agreeState[authority[i]] == true)
k++;
if(k >= agreeThreshold)
return true;
else
return false;
}
function initialAgree() internal{
...
}
modifier isEnoughAgreement(){
if(agreeing == true && agreePermission == true && msg.sender == agreeRequester){
;
initialAgree(); }
}
...
}
co n t r a ct S a m p l e Test i n g is MultipleAuthorities{
st r in g s a mp l eI D ;
bo o l p as se d ;
fu n c t io n sa m pl e T e st ( s tr i n g ID ) {
sa m p l eI D = I D ;
pa s se d = f al s e ;
}
fu n ct i on p a ss ( ) isEnoughAgreement(){
pa s se d = t r ue ;
}
.. .
}
Listing 1: Updated SampleTesting code after using the multiple auhtorities service.
According to the design of the quality tracing system, we deployed an
Ethereum blockchain on three nodes, which represent a node in the quality
24
tracing agency, a node in the lab, and a node in the quality inspection bureau.
We configured the difficulty as as 0x4000 and provided the IP addresses of
three nodes in uBaaS. Then uBaaS automatically deployed an Ethereum
blockchain on the three target nodes.
contract DynamicBinding{
bytes32 hashKey;
bool init;
address owner;
function initial(bytes32 key){
if(init != true){
hashKey = key;
init = true;
owner = msg.sender;
}
}
function changeKey(string oldKey , bytes32 newKey){
if(init == true)
if(hashKey == sha256(oldKey))
if(owner == msg.sender)
hashKey = newKey;
}
modifier verify(string inputKey){
if(hashKey == sha256(inputKey)){;}
}
}
contract ServiceAgreement is DynamicBinding{
st r in g f i rs t Pa rt y ;
st r in g s e co n dP ar t y ;
by t es 3 2 c on t ra c tH as h ;
.. .
fu n ct i on qu e ry A gr e em en t (string key )
verify(key) co ns ta nt r et ur ns ( str ing , st ring , b yt es 32 ) {
re t ur n f ir s tP ar t y , s ec on d Pa rt y , c o nt ra c tH a sh ;
}
.. .
}
Listing 2: Updated ServiceAgreement code after using the dynamic binding service.
As discussed in Section 4, uBaaS uses the smart contract design services
to restrict access to the invocation of the functions in the smart contracts.
Thus we selected three different functionalities (i.e. sample testing result
approval, service agreement query and freight yard picture storage) to apply
each of the proposed smart contract design services: multiple authorities ser-
vice,dynamic binding service, and embedded permission service. We wrote
three smart contracts implementing the business logic in those three scenar-
ios and select a function in each of the three smart contract to apply each
smart contract design service. Thus, the output of uBaaS is the updated
smart contract code with permission control for the smart contract function
25
invocation. List 1-3 show the generated code by uBaaS. The code in black
colour represents the input smart contract code (i.e. the smart contract code
written by the developers), while the code highlighted in red colour is the
code generated by the corresponding smart contract design services in uBaaS.
contract EmbeddedPermission{
address [] authority;
address owner;
function EmbeddedPermission(address [] temAuthority){
owner = msg.sender;
authority = temAuthority;
}
function changeAuthority(address [] temAuthority){
if(msg.sender == owner){
authority = temAuthority;
}
}
modifier permission(){
for(uint i = 0; i < authority.length; i++){
if(msg.sender == authority[i]){
;
break;}}
}
}
co n t r a ct F r e i g h tYar d P i c is EmbeddedPermission{
by t es 3 2 [ ] f re i gh t Ya r dP i c ;
address [] freightYardExaminer;
function FreightYardPic() embeddedPermission(addr){
address [] addr;
addr.push(/authority address/);
}
fu n ct i on se t F re i gh t Ya r dP i c ( by t es 3 2 pi c , a dd r es s u p lo a de r ) permission() {
f re i g ht Y ar d P ic . p us h ( p ic ) ;
f re i gh t Y ar d E xa m i ne r . p us h ( u pl o ad e r ) ;
}
fu n ct i on ge t F re i gh t Ya r dP i c ( ui n t i ) c on s ta n t r et u rn s ( b yt e s3 2 , a dd r es s ) {
re t u rn ( fr e i g ht Y a r dP i c [ i ] , f r ei g h t Ya r d E x am i n e r [ i ]) ;
}
}
Listing 3: Updated FreightYardPic code after using the embedded permission service.
The SampleTesting smart contract implements the logic in the sample
testing activity. According to the process design, the product passes the
sample test (i.e. the pass() function in the SampleTesting smart contract
is invoked) only when enough number of labs agree that the product passes
the sample test. Thus, SampleTesting smart contract code and the required
lab addresses are provided as the input for uBaaS and the pass() function is
selected to apply multiple authorities design pattern using the correspond-
ing service. MutlipleAuthorities smart contract including the modifer isE-
26
noughAgreement() attached to pass() are added after using the uBaaS mul-
tiple authorities service. Listing 1 presents the updated smart contract code
generated by the multiple authorities service in uBaaS.
The quality tracing service agreement signed between the product sup-
plier and the quality tracing service agency is implemented in the smart
contract ServiceAgreement. In order to ensure the data privacy in the ser-
vice agreement, uBaaS adds the modifier verfy() to the queryAgreement()
function in ServiceAgreement using uBaaS. Only the party who can provide
the secret key can successfully read the service agreement information stored
on-chain. The smart contract code generated by the uBaaS dynamic binding
service is presented in Listing 2. Note that the secret key can be changed on
demand by invoking function changeKey().
The smart contract FreightYardPic maintains the pictures taken at the
freight yard. According to the process design, only the freight yard inspectors
can upload the hash value of the pictures taken at the freight yard. Thus,
we use the EmbeddedPermission service in uBaaS to add the access control
for the function setFreightYardPic() which only allows the specific agency
employee addresses to store the hash value of the freight yard pictures on
blockchain. The smart contract code generated by the embedded permission
service is presented in Listing 3.
7. Conclusion and Future Work
In this paper, we present a unified blockchain as a service platform named
uBaaS which provides deployment as a service, design pattern as a service
and auxiliary services. Deployment as a service in uBaaS is not vendor locked
and provides one-click deployment service by hiding deployment script from
users. Design pattern as a service leverage design patterns to facilitate data
management and smart contract design of blockchain-based applications. We
evaluate the feasibility and scalability of uBaaS using a real-world quality
tracing use case, which demonstrates it is feasible and scalable to design and
deploy blockchain-based applications using uBaaS. The future work includes
adding more blockchain platforms as deployment platform options, and de-
signing self-sovereign identity as a service in uBaaS.
References
[1] Distributed Ledger Technology: beyond blockchain, Technical Report,
2016. UK Government Chief Scientific Adviser.
27
[2] M. Staples, S. Chen, S. Falamaki, A. Ponomarev, P. Rimba, A. B.
T. I. Weber, X. Xu, J. Zhu, Risks and opportunities for systems us-
ing blockchain and smart contracts, Technical Report, Sydney, 2017.
Data61(CSIRO).
[3] G. P. Release, Gartner survey reveals the scarcity of current blockchain
deployments, 2018. , accessed: 4 May 2018.
[4] D. Siegel, Understanding the dao attack, 2016.
[5] K. Beck, W. Cunningham, Using pattern languages for object oriented
programs, in: Conference on Object-Oriented Programming, Systems,
Languages, and Applications (OOPSLA), ACM, Orlando, FL, USA,
1987.
[6] S. Nakamoto, Bitcoin: A Peer-to-Peer electronic cash system, 2008.
[7] F. Tschorsch, B. Scheuermann, Bitcoin and beyond: A technical survey
on decentralized digital currencies, IEEE Communications Surveys &
Tutorials 18 (2016) 464.
[8] S. Omohundro, Cryptocurrencies, smart contracts, and artificial intelli-
gence, AI Matters 1 (2014) 19–21.
[9] I. Weber, X. Xu, R. Riveret, G. Governatori, A. Ponomarev,
J. Mendling, Untrusted business process monitoring and execution us-
ing blockchain, in: BPM, Springer, Rio de Janeiro, Brazil, 2016, pp.
329–347.
[10] X. Li, P. Jiang, T. Chen, X. Luo, Q. Wen, A survey on the security of
blockchain systems, Future Generation Computer Systems (2017).
[11] A. Reyna, C. Martn, J. Chen, E. Soler, M. Daz, On blockchain and its
integration with iot. challenges and opportunities, Future Generation
Computer Systems 88 (2018) 173 – 190.
[12] Q. Lu, X. Xu, Adaptable blockchain-based systems: A case study for
product traceability, IEEE Software 34 (2017) 21–27.
[13] X. Xu, Q. Lu, Y. Liu, L. Zhu, H. Yao, A. V. Vasilakos, Designing
blockchain-based applications a case study for imported product trace-
ability, Future Generation Computer Systems 92 (2019) 399 – 406.
28
[14] Q. Qu, I. Nurgaliev, M. Muzammal, C. S. Jensen, J. Fan, On spatio-
temporal blockchain query processing, Future Generation Computer
Systems 98 (2019) 208 – 218.
[15] G. Zyskind, O. Nathan, A. Pentland, Decentralizing privacy: Using
blockchain to protect personal data, in: SPW.
[16] B. Nasrulin, M. Muzammal, Q. Qu, Chainmob: Mobility analytics on
blockchain, in: 19th IEEE International Conference on Mobile Data
Management, MDM 2018, Aalborg, Denmark, June 25-28, 2018, pp.
292–293.
[17] M. Muzammal, Q. Qu, B. Nasrulin, Renovating blockchain with dis-
tributed databases: An open source system, Future Generation Com-
puter Systems (2018).
[18] M. Ali, J. Nelson, R. Shea, M. J. Freedman, Blockstack: A global
naming and storage system secured by blockchains, in: USENIX ATC,
Santa Clara, CA.
[19] S. Matsumoto, R. M. Reischuk, Ikp: Turning a pki around with decen-
tralized automated incentives, in: IEEE SSP, San Jose, CA, US.
[20] X. Liang, S. Shetty, D. T. et al., Provchain: A blockchain-based data
provenance architecture in cloud enviornment with enhanced privacy
and availability, in: CCGrid.
[21] I. Weber, V. Gramoli, M. Staples, A. Ponomarev, R. Holz, A. Tran,
P. Rimba, On availability for blockchain-based systems, in: SRDS’17:
IEEE International Symposium on Reliable Distributed Systems, IEEE,
Hong Kong, China, 2017, pp. 64–73.
[22] E. Gamma, R. Helm, R. Johnson, J. Vlissides, Design patterns: Ele-
ments of Reusable Object-oriented Software, Pearson Education, UK,
1995.
[23] J. Eberhardt, S. Tai, On or off the blockchain? insights on off-chaining
computation and data, in: ESOCC 2017(6th European Conference on
Service-Oriented and Cloud Computing), Springer International Pub-
lishing, Oslo, Norway, 2017, pp. 3–15.
29
[24] P. Zhang, J. White, D. C. Schmidt, G. Lenz, Applying Software Patterns
to Address Interoperability in Blockchain-based Healthcare Apps, 2017.
[25] Y. Liu, Q. Lu, X. Xu, L. Zhu, H. Yao, Applying design patterns in
smart contracts, in: International Conference on Blockchain, Springer,
pp. 92–106.
[26] M. Bartoletti, L. Pompianu, An empirical analysis of smart contracts:
platforms, applications, and design patterns, ArXiv e-prints (2017).
[27] X. Xu, C. Pautasso, L. Zhu, Q. Lu, I. Weber, A pattern language for
blockchain-based applications, in: EuroPLoP’18: European Conference
on Pattern Languages of Programs, Kloster Irsee, Germany.
[28] L. Anderson, R. Holz, A. Ponomarev, P. Rimba, I. Weber, New kids
on the block: an analysis of modern blockchains, CoRR abs/1606.06530
(2016).
[29] I. General Administration of Quality Supervision, Q. of the People’s
Republic of China, Rules for quality tracing of import commodities,
Technical Report, Beijing, 2017.
30
... The above discussions highlight that deployment and evaluation are time-consuming, errorprone, and knowledge-intensive processes [19,20] that are tightly coupled to blockchain network architectures. Thus, practitioners and researchers would benefit from an automation approach that works directly with context-rich architectural specifications of blockchain networks. ...
... to-automate activities (designing architecture) and mitigating implementation errors. In addition to the generic IT automation tools (Ansible 4 , Terraform 5 ), some blockchain-specific frameworks (e.g., PlaTIBART [22], Hyperledger Bevel, Hyperledger Composer, MixBytes Tank, Puppeth) and cloud services [19,13] have been proposed to automate blockchain network deployment. The generic IT automation tools fail to enable an architecture-driven automation approach. ...
... Automated blockchain network deployment has been investigated by both academia [22,20,19,13] and industry [33,34,35,36] to abstract the timeconsuming [20], and error-prone deployment process [19], allowing practitioners to focus on application development instead of learning networks and protocols [13]. Automation has also been sought to make blockchain network deployment repeatable to support regression tests [22]. ...
Preprint
Full-text available
Blockchain network deployment and evaluation have become prevalent due to the demand for private blockchains by enterprises, governments, and edge computing systems. Whilst a blockchain network's deployment and evaluation are driven by its architecture, practitioners still need to learn and carry out many repetitive and error-prone activities to transform architecture into an operational blockchain network and evaluate it. Greater efficiency could be gained if practitioners focus solely on the architecture design, a valuable and hard-to-automate activity, and leave the implementation steps to an automation framework. This paper proposes an automation framework called NVAL (Network Deployment and Evaluation Framework), which can deploy and evaluate blockchain networks based on their architecture specifications. The key idea of NVAL is reusing and combining the existing automation scripts and utilities of various blockchain types to deploy and evaluate incoming blockchain network architectures. We propose a novel meta-model to capture blockchain network architectures as computer-readable artefacts and employ a state-space search approach to plan and conduct their deployment and evaluation. An evaluative case study shows that NVAL successfully combines seven deployment and evaluation procedures to deploy 65 networks with 12 different architectures and generate 295 evaluation datasets whilst incurring a negligible processing time overhead.
... In recent years, along with the continuous development of Fintech applications, various innovative scenarios have become more feasible in the financial field. However, due to the complexity of integrating new platforms, banks need to gauge their maintenance capability to deal with intensive communications and troubleshooting issues between their legacy and newly developed systems [50][51][52]. Though banks may outsource their platform to a third party, its internal technicians still need to handle the system's maintenance, given the sensitive information involved in an SCF platform. ...
Article
Full-text available
Many banks are eager to adopt technology solutions to enhance operational efficiency in managing supply chain finance, which involves various participants and complex financial activities. Previous research either focuses on the technology aspect or the optimization of a supply chain; there is little specific guidance on how banks can form a holistic model to evaluate their Fintech strategy for supply chain finance. By using an integrated approach, this study adopted the decision-making trial and evaluation laboratory (DEMATEL) and several analytical methods to construct a hybrid decision model for banks. We concluded four plausible Fintech strategies from previous research and highlighted the advantages of the blockchain-based strategy. We used a domestic bank in Taiwan as a case study during the evaluation phase and implemented crisp and confidence-based fuzzy assessments. The result indicates that the blockchain-based leading strategy would be ideal for this bank. The hybrid decision model also unveils the complicated relationships among those evaluation factors, which sheds light on banks pursuing their innovation in financial services. The findings contribute to banks developing their Fintech-based supply chain financing business, and the supply chain participants may also benefit from securing efficient loans to expedite their operations.
... Recently, Blockchain-as-a-Service (BaaS) platforms have been developed as a promising solution to increase productivity. The BaaS framework provides blockchain service over cloud computing [90,91]. A BaaS can also take advantage of smart contract to receive data from IoT nodes [92]. ...
Article
Full-text available
The Internet of Things (IoT) is increasingly becoming widespread in different areas such as healthcare, transportation, and manufacturing. IoT networks comprise many diverse entities, including smart small devices for capturing sensitive information, which may be attainable targets for malicious parties. Thus security and privacy are of utmost importance. To protect the confidentiality of data handled by IoT devices, conventional cryptographic primitives have generally been used in various IoT security solutions. While these primitives provide just an acceptable level of security, they typically neither preserve privacy nor support advanced functionalities. Also, they overly count on trusted third parties because of some limitations by design. This multidisciplinary survey paper connects the dots and explains how some advanced cryptosystems can achieve ambitious goals. We begin by describing a multi-tiered heterogeneous IoT architecture that supports the cloud, edge, fog, and blockchain technologies and assumptions and capabilities for each layer. We then elucidate advanced encryption primitives, namely wildcarded, break-glass, proxy re-encryption, and registration-based encryption schemes, as well as IoT-friendly cryptographic accumulators. Our paper illustrates how they can augment the features mentioned above while simultaneously satisfying the architectural IoT requirements. We provide comparison tables and diverse IoT-based use cases for each advanced cryptosystem as well as a guideline for selecting the best one in different scenarios and depict how they can be integrated.
... The authors of literature [28] propose a concept of microservice, which analyzes the performance of virtual resources in different environments. The authors of literature [29] and [30] have done research on the platform architecture based on blockchain. In literature [30], the authors propose an extensible platform architecture for the system based on multi tenant blockchain to ensure data integrity, while maintaining data privacy and performance isolation. ...
Preprint
With the advent of the Internet of things (IoT) era, more and more devices are connected to the IoT. Under the traditional cloud-thing centralized management mode, the transmission of massive data is facing many difficulties, and the reliability of data is difficult to be guaranteed. As emerging technologies, blockchain technology and edge computing (EC) technology have attracted the attention of academia in improving the reliability, privacy and invariability of IoT technology. In this paper, we combine the characteristics of the EC and blockchain to ensure the reliability of data transmission in the IoT. First of all, we propose a data transmission mechanism based on blockchain, which uses the distributed architecture of blockchain to ensure that the data is not tampered with; secondly, we introduce the three-tier structure in the architecture in turn; finally, we introduce the four working steps of the mechanism, which are similar to the working mechanism of blockchain. In the end, the simulation results show that the proposed scheme can ensure the reliability of data transmission in the Internet of things to a great extent.
Preprint
Full-text available
Edge computing has become a popular paradigm where services and applications are deployed at the network edge closer to the data sources. It provides applications with outstanding benefits, including reduced response latency and enhanced privacy protection. For emerging advanced applications, such as autonomous vehicles, industrial IoT, and metaverse, further research is needed. This is because such applications demand ultra-low latency, hyper-connectivity, and dynamic and reliable service provision, while existing approaches are inadequate to address the new challenges. Hence, we envision that the future edge computing is moving towards distributed intelligence, where heterogeneous edge nodes collaborate to provide services in large-scale and geo-distributed edge infrastructure. We thereby propose Edge-as-a-Service (EaaS) to enable distributed intelligence. EaaS jointly manages large-scale cross-node edge resources and facilitates edge autonomy, edge-to-edge collaboration, and resource elasticity. These features enable flexible deployment of services and ubiquitous computation and intelligence. We first give an overview of existing edge computing studies and discuss their limitations to articulate the motivation for proposing EaaS. Then, we describe the details of EaaS, including the physical architecture, proposed software framework, and benefits of EaaS. Various application scenarios, such as real-time video surveillance, smart building, and metaverse, are presented to illustrate the significance and potential of EaaS. Finally, we discuss several challenging issues of EaaS to inspire more research towards this new edge computing framework.
Chapter
Full-text available
There has been a growing focus on cryptocurrencies in the finance and banking sector. In this research paper, we will try to explore the role of crypto currencies in the contemporary world of finance. The results indicate that cryptocurrencies offer businesses and individuals lower transaction costs, higher efficiencies, increased security and privacy, meaningful diversification benefits, alternative financing solutions, and financial inclusion. Challenges exist related to the integration of cryptocurrencies in modern finance. These include the lack of regulatory standards, the risk of criminal activity, high energy and environmental costs, regulatory bans and usage restrictions, security and privacy concerns, and the high volatility of cryptocurrencies. The current review is useful for scholars and managers, including those seeking to have a more balanced understanding of these emerging financial instruments
Article
A blockchain network is a distributed system established by mutually distrusting participants to operate a blockchain, enabling them to manage critical information such as account balances or asset ownership without a centralised third party. Blockchain network deployment and evaluation have become prevalent due to the emerging blockchain use cases by enterprises, governments, and Internet of Things (IoT) applications, which demand private blockchains rather than participating in public ones. A blockchain network architecture drives deployment and evaluation activities. Nevertheless, practitioners must learn and perform error-prone activities to transform architecture into a blockchain network and evaluate it. Therefore, it is beneficial to automate these activities so that practitioners can focus on the architecture design, a valuable and hard-to-automate activity. The key challenges of such an automation framework are keeping up with the advances in blockchain technologies and the increasing complexity of blockchain network architecture. This paper proposes NVAL, a software framework that implements a novel architecture-driven, community-supported approach to automate blockchain network deployment and evaluation. NVAL accepts blockchain network architecture as input. It supports complex multi-channel blockchain networks, an increasingly prevalent architecture for private blockchain. The framework keeps up with blockchain technologies by leveraging platform-specific automation programs developed by a practitioner community via runtime composition to handle new networks. We evaluated NVAL with a case study and showed that the framework requires only seven automation programs to deploy 65 blockchain networks with 12 diverse architectures and generate 295 evaluation datasets. Furthermore, it consumes only 95.5 ms to plan and orchestrate the deployment and evaluation, which is minuscule compared to the total time required for deploying and benchmarking a blockchain network.
Article
As a temporary facility, scaffolding has an essential role in providing a work environment at height in the construction industry. According to the Occupational Safety and Health Administration (OSHA), approximately 65% of laborers work on scaffolding. Scaffolding work information needs to be effectively managed with reliability to provide a safe environment. However, managing information of the scaffolding work process remains challenging in forgery risk and manual verification. Blockchain has been widely introduced as an accountable and efficient information management solution. This study presents a blockchain-based system for scaffolding work to grant reliability and efficiency of information management. The system is developed to secure applicability by considering three aspects: (1) optimal blockchain platform regarding characteristics of scaffolding work; (2) storage method to address the hindrance of blockchain; (3) information needed to be compared for verifying adequacy. The detailed configuration and process model for the system is categorically presented, and validated via a case study. The case study confirmed that the system was able to store the information in the block smoothly, verify the information using the smart contract successfully, and remain the block size constant by using off-chain. The proposed system has the potential of practical applicability and could contribute to mitigate potential safety risks associated with inadequate scaffolding work management. Furthermore, the proposed system development flow can be leveraged as a guideline to extend blockchain applications to diverse areas in the construction domain.
Article
As a decentralized distributed ledger, blockchain is endowed with immutability, traceability, anonymity, and transparency, which has got rapid development in cryptocurrency and production as a new trend. In the meantime, the occurrence of Blockchain-as-a-Service (BaaS) helps in mitigation of the complexity and difficulty in deployment and management of blockchain systems and makes it easier to concentrate on business logic implementation for developers. However, most existing BaaS systems are hosted in the environment of cloud vendors, which has also incurred vendor lock-in risk and impairs the inherent trustless characteristic of blockchain. Though present BaaS systems own a level of availability by using cloud computing or edge computing as infrastructure, the availability is limited, considering the availability of network connections and the data center itself. In this article, a novel cloud-edge collaborative BaaS paradigm is proposed. With the assistance of redundant blockchain node candidates, leader election, and edge network self-healing components, the proposed BaaS system is equipped to extend BaaS to the on-premises edge or private cloud, and realize high availability of blockchain systems in edge-autonomy and cross-data-center scenarios. Through testing a simplified system in a simulated environment in cloud servers, this proposed BaaS system has an acceptable throughput under specific transaction sending rates without much performance degradation due to containerization and data synchronization compared with the original blockchain on-premises deployment method.
Conference Paper
Full-text available
[This is a pre-publication version of the paper; the content is likely to change for the final publication version.] Blockchain is an emerging technology that enables new forms of decentralized software architectures, where distributed components can reach agreements on shared system states without trusting a central integration point. Blockchain provides a shared infrastructure to execute programs, called smart contracts, and to store data. Since blockchains are at an early stage, there is a lack of a systematic and holistic view on designing software systems that use blockchain. We view blockchain as part of a bigger system, which requires patterns of using blockchain in the design of the bigger systems. In this paper, we collect a list of patterns for blockchain-based applications. The pattern collection is categorized into four types, including interaction with external world patterns, data management patterns, security patterns and contract structural patterns. Some patterns are designed specifically based on real-world blockchain-based applications considering the nature of blockchain.Others are variants of existing design patterns applied in the context of blockchain-based applications and smart contracts.
Article
Full-text available
In the Internet of Things (IoT) vision, conventional devices become smart and autonomous. This vision is turning into a reality thanks to advances in technology, but there are still challenges to address, particularly in the security domain e.g., data reliability. Taking into account the predicted evolution of the IoT in the coming years, it is necessary to provide confidence in this huge incoming information source. Blockchain has emerged as a key technology that will transform the way in which we share information. Building trust in distributed environments without the need for authorities is a technological advance that has the potential to change many industries, the IoT among them. Disruptive technologies such as big data and cloud computing have been leveraged by IoT to overcome its limitations since its conception, and we think blockchain will be one of the next ones. This paper focuses on this relationship, investigates challenges in blockchain IoT applications, and surveys the most relevant work in order to analyze how blockchain could potentially improve the IoT.
Technical Report
Full-text available
Blockchain technologies originally emerged to support new forms of digital currency, but now hold promise as a new foundation for transactions in society. A blockchain is both a database recording transactions between parties, and also a computational platform to execute small programs (called ‘smart contracts’) as transactions. A blockchain is a distributed database, replicated across many locations and operated jointly by a collective. Blockchains transactions can support services for payments, escrow, notarisation, voting, registration, and process coordination. These are key in the operation of government and industry. Conventionally, these services are provided by speci c trusted third-parties such as banks, legal rms, accountancy rms, government agencies, and service providers in speci c industries. With a blockchain-based system, rather than relying on third-party organisations, we could instead choose to rely on the blockchain software and on a majority of the collective that jointly operates the blockchain system. The report describes some of the technical risks and opportunities in the application of blockchain technologies within government and industry, and how to assess whether blockchain-based systems will meet critical requirements. The project explores this primarily through the description and analysis of high-level design alternatives for illustrative ‘use cases’. Three use cases have been selected after a number of initial workshops and preliminary research: remittance payments, open data registries, and agricultural supply chain. These provide reasonable coverage of various kinds of requirements and regulatory concerns, against which we can evaluate design alternatives, and in turn learn more general lessons about blockchain technologies. In addition to this design-based analysis, we also report on some empirical results from testing prototype implementations. Compared to conventional centralised databases and computational platforms (on-premises or cloud), blockchains can reduce some counter-party and operational risks by providing neutral ground between organisations. Blockchain technologies may provide advantages for integrity and non-repudiation. However, they also currently have limitations for con dentiality, privacy, and scalability. For latency and availability, reading is improved but writing is worsened. Blockchains are also subject to a di erent cost model. Digital currency transfer and long-term storage of transactional data may be less expensive. However, program execution and storage of big data may be more expensive. Public blockchains provide very low barriers to entry for new participants, which can facilitate competition, innovation, and productivity. However, they do not mandate authentication of those participants, which creates challenges for regulation of money laundering, terrorism nancing, and tax avoidance. Private blockchains can impose more controls on authentication and access, which can partly address those regulatory concerns. Still, for competitors within an industry consortium, private blockchains may not be private enough to provide normal levels of commercial con dentiality for business operations, competitive position, and customer relationships. When assessing business risk, regulatory acceptance, and assurance arguments for a blockchain-based system, we need to consider not just the blockchain, but also all of the other components that are integrated in the design of the whole system. Other components will provide user interfaces, cryptographic key management, and o -chain databases, communications, and processing. Judicious use of these other components may mitigate blockchain’s risks while still leveraging blockchain’s opportunities. Finally, blockchains are still a rapidly evolving technology, with ongoing developments especially to improve scalability and con dentiality. Globally, governments, enterprises, and startups are exploring the technology/ market t in a wide variety of use cases and for a wide variety of requirements and regulatory demands. There is still much that is unknown about the development of trustworthy blockchain-based systems. Further research is required to improve our knowledge about how to create blockchain-based systems that work, and how to create evidence that blockchain-based systems will work as required.
Conference Paper
Full-text available
The potential for blockchains to fundamentally transform how organizations produce and capture value is huge and very real. Practical applications dealing with nearly any type of digital asset demonstrate this capacity. Blockchain-based application architectures benefit from a set of unique properties including immutability and transparency of cryptographically-secured and peer-recorded transactions, which have been agreed upon by network consensus. Blockchain-based applications, however, may also suffer from high computational and storage expenses, negatively impacting overall performance and scalability. In this paper, we report on lessons learned and insights gained from a set of experimental blockchain projects, focusing on off-chaining: How to move computation and data off-the-chain, without compromising the properties introduced and benefits gained by using blockchains in the first place.
Article
Full-text available
Since its inception, the blockchain technology has shown promising application prospects. From the initial cryptocurrency to the current smart contract, blockchain has been applied to many fields. Although there are some studies on the security and privacy issues of blockchain, there lacks a systematic examination on the security of blockchain systems. In this paper, we conduct a systematic study on the security threats to blockchain and survey the corresponding real attacks by examining popular blockchain systems. We also review the security enhancement solutions for blockchain, which could be used in the development of various blockchain systems, and suggest some future directions to stir research efforts into this area.
Article
Blockchain technology enables decentralization as new forms of distributed software architectures, where components can reach agreements on the shared system states without trusting on a central integration point. Since blockchain is an emerging technology which is still at an early stage of development, there is limited experience on applying blockchain to real-world software applications. We applied blockchain application design approaches proposed in software architecture community in a real-world project called originChain, which is a blockchain-based traceability system that restructures the current system by replacing the central database with blockchain. In this paper, we share our experience of building originChain. By using blockchain and designing towards security, originChain provides transparent tamper-proof traceability data with high availability and enables automated regulatory-compliance checking and adaptation in product traceability scenarios. We also demonstrate both qualitative and quantitative analysis of the software architecture of originChain. Based on our experience and analysis, we found that the structural design of smart contracts has large impact on the quality of the system.
Article
A blockchain is a decentralised linked data structure that is characterised by its inherent resistance to data modification, but it is deficient in search queries primarily due to its inferior data formatting. A distributed database is also a decentralised data structure which features quick query processing and well-designed data formatting but suffers from data reliability. In this work, we showcase CHAINSQL, an open-source system developed by integrating the blockchain with the database, i.e. we present a blockchain database application platform that has the decentralised, distributed and audibility features of the blockchain and quick query processing and well-designed data structure of the distributed databases. CHAINSQL features a tamper-resistant and consistent multi-active database, a reliable and cost effective data-level disaster recovery backup and an auditable transaction log mechanism. The system is presented as an operational multi-active database along with the data-level disaster recovery backup and audibility features. A comprehensive experimental evaluation is performed to demonstrate the effectiveness of the system.
Article
Traceability allows tracking products through all stages of a supply chain, which is crucial for product quality control. To provide accountability and forensic information, traceability information must be secured. This is challenging because traceability systems often must adapt to changes in regulations and to customized traceability inspection processes. OriginChain is a real-world traceability system using a blockchain. Blockchains are an emerging data storage technology that enables new forms of decentralized architectures. Components can agree on their shared states without trusting a central integration point. OriginChain’s architecture provides transparent tamper-proof traceability information, automates regulatory compliance checking, and enables system adaptability.