Yugala: Blockchain Based Encrypted Cloud Storage for IoT Data

Full text

Yugala: Blockchain based Encrypted Cloud Storage
for IoT Data
Sarada Prasad Gochhayat, Eranga Bandara, Sachin Shetty, Peter Foytik
Virginia Modeling Analysis and Simulation Center
Old Dominion University
Norfolk, VA, USA
{sgochhay, cmedawer, sshetty, pfoytik}@odu.edu
Abstract—Cloud storage enables users to upload, store and
download their data. However, with the rapid growth of the
Internet of Things (IoT) and edge devices, such as camera, the
cloud not only manages the user generate data but also devices
generated data. This increment in the volume of outsourced data
has raised two important issues in big data management for
cloud storage servers, namely, optimal data storage and data
security. In order to solve the former issue, cloud storage employs
a deduplication technique to avoids storing duplicate data; and
uses encryption to solve the later issue. However, both these
issues are orthogonal in nature. Thanks to convergent encryption
that addresses both the issues simultaneously. Nevertheless, the
existing approaches relies on proxy servers and put all the trust
on third party, which is vulnerable to single point failure.
In this paper, we propose a novel lightweight decentralized
encrypted cloud storage architecture called, Yugula, which main-
tains file confidentiality, removes the centralized data deduplica-
tion and increases file integrity by using blockchain. In particular,
we discuss two approaches for file confidentiality with data
deduplication: one uses double hashing and the other symmetric
encryption. In order to show the efficiency and usability, we
implemented the proposed architecture and showed its results in
terms of high transaction throughput requirement for IoT data
management in cloud storage.
Index Terms—Blockchain, Cloud computing, IoT, Security
I. INTRODUCTION
Cloud storage is one of the most popular cloud services
which enables users to store tremendous amount of data in
the cloud, which may exceed their own storage spaces. The
dependency on cloud storage even further increases because of
growth of Internet of Thing (IoT) and the data IoT generates.
IoT become an essential element for the evolution of connected
products and related services. Along with IoT, the era of Fog
computing, also produces a huge amound of data. Hence, the
adoption of IoT and fog computing going to create more and
more data in the cloud storage, in which most of the data will
be redundant.
In order to solve redundant data storage and improve the
utilization of storage, cloud storage employs data deduplica-
tion. Data deduplication is a process in which the cloud storage
eliminates storage of multiple copies of a file by storing only
a single copy of the file [1], [2]. Hence, it improves both
the storage and bandwidth utilization. It further enhances the
storing capacity by storing a single copy of a file in block level
[3], [4]. Particularly, at file level, the cloud storage avoids
storing multiple copies of already existing files, i.e., when
Fig. 1. Deduplication in cloud storage
client Cwants to upload a file F, to Cloud Server CS.CS
checks if it has F.IfCS finds that it has F, then it prohibits A
to upload the file. At block level, CS performs deduplication
check on different blocks of the file. Additionally, to save
the upload bandwidth, the user uploads a unique tag of the
file instead of the actual file to check the availability of the
file [5], [6]. Fig. 1 shows the deduplication process in detail.
Unfortunately, CS unable to perform deduplication when user
encrypts his/her files.
Normally, a security-concerned user encrypts his file before
outsourcing to CS. As encryption makes it difficult for anyone
to distinguish between encrypted text of a plain text and ran-
domly generated value, encryption conflicts with deduplication
mechanism [7]. For example, when users AE and BE encrypt
a plain text file PF using two different keys KB and KB, they
generate two indistinguishable cipher-text files, namely, AEF
and BEF. So, when CS uses deduplication process, it cannot
verify existence of the file. Hence, the cloud storage cant save
storage space by using deduplication. Thanks to Convergent
Encryption (CE) which allows deduplication over encrypted
files. In convergent encryption, a user first generates the hash
of the file, and then uses it to encrypt the file. In this way, the
files is encrypted, and can be protected. Nevertheless, the hash
of the file aka the tag, is used by the user to encrypt the data is
still used by the cloud to perform deduplication check. Hence,
CS and use the tag to decrypt the encrypted information. In
order to still use data deduplication along with convergence
encryption, the existing works in the literature need additional
servers [8]. Another issue an adverse CS can do is the denial of
uploading of the file by the user. For instance, a user initially
483
2019 IEEE International Conference on Blockchain (Blockchain)
978-1-7281-4693-5/19/$31.00 ©2019 IEEE
DOI 10.1109/Blockchain.2019.00073
Authorized licensed use limited to: Old Dominion University. Downloaded on November 11,2020 at 20:55:49 UTC from IEEE Xplore. Restrictions apply.

uploads a file at CS. But at some later instance, the CS simply
discards the file from the storage to save space, and when
the user returns CS denies that the user had indeed uploaded
the file. This problem is known as proof of retrievability [9],
where a CS proves that it indeed has the file uploaded by the
user. Nevertheless, the solution to the above mentioned issues
have to be lightweight to support the high load generated on
the cloud storage, as the load on cloud storage also grows with
the number of nodes in IoT.
Motivated by above mentioned challenges, in this work
we propose a novel lightweight decentralized encrypted cloud
storage architecture called, yugula, which removes the central-
ized data deduplication, uses modified convergent encryption
for file confidentiality and provides file integrity by using
Blockchain [10]. In our first approach, the user encrypts the
data using convergent encryption to ensure file confidentiality;
and uses the output of the double-hash of the data as the tag
to check data deduplication. In the second approach, we use
symmetric encryption and a secure information, to generate
the tag, in this way, which enables different organizations to
use cloud storage while still protecting individual data.
In summary, the contributions of the paper are:
•We proposed a new decentralized encrypted cloud storage
architecture, called Yugula, which uses Blockchain and
modified convergence encryption. Yugala uses Mystiko
Blockchain [11] to provide high throughput while still
possessing data deduplication capability.
•Yugula decouples the relationship between the tag and the
encrypted file, by first, using hash of the data to encrypt
the file, i.e., by the help of convergence encryption,
and second, by storing the double-hash of the file at
the Blockchain to enable all the user to query and find
the availability of the encrypted data in the cloud. Data
deduplication is handling with Mystiko Blockchain based
smart contracts.
•We even suggested a modified version of the first ap-
proach, which uses symmetric encryption and secret
information to generate the tag that suits well when
different organizations try delineate their data and tags
on the same Blockchain based encrypted cloud storage.
•As a proof of concept, we implemented the architecture
and showed that the proposed system work fits quite well
in IoT environment in terms of transaction throughput.
The rest of the paper is organized as follows: Section II
discusses some of the related works and system and threat
model; Section III presents the Yugula architecture; Section
IV dicussses implementation process of Yugula in detail by
discussing each components; and Results and conclusion are
discussed in Section V and VI, respectively.
II. RELATED WORKS
In this section, we discuss the related works in encrypted
cloud storage, by focusing on the convergence encryption, and
Blockchain. Then, we discuss about the problem statement
by emphasizing the system model and threat model in an
adversarial cloud scenario.
Fig. 2. Convergence encryption
A. Convergence encryption
Convergence encryption is a method of encrypting a file by
using a key which is deterministically associated with the file.
In particular, a user first generates a hash of the file, and uses
the hash output as a key to encrypt the file. Fig 2 shows the
process of convergence encryption.
The formal definition of the convergence encryption consists
of three algorithms (KeyGen,encrypt, and Decrypt)as
follows:
•KeyGenCE (F)→(Key)–this algorithm takes a file F
as an input and outputs a secret key Key, thus mapping
the file to a convergent key.
•EncryptCE(F, Key)→(CT )–This is a symmetric
encryption algorithm, which takes the plain text file F
and the Key as inputs and outputs the cipher text CT.
•DecryptCE(CT, Key)→(F)–this is the decryption of
algorithm, which takes the the cipher text CT and the
secret key Key as the inputs, and returns the original
plain text file F.
B. Blockchain
Blockchain is a form of distributed storage system that
stores the chronological sequence of transactions in a tamper-
evident manner. In Blockchain, each node has the same order
of data which is immutable. Since Blockchain is a distributed
storage, it uses a consensus algorithm to maintain consistency
of data among the nodes. Due to its decentralized, immutabil-
ity nature, Blockchain becomes a promising technology for
untrusted peer to peer network. [12]. Currently, there are
various Blockchain platforms in the market. Bitcoin [13],
Ethereum [14], Bigchaindb [15], Hyperledger [16] are some
examples. Some of these Blockchains are mostly used for
electronic currencies such as Bitcoin. While Ethereum and
Hyperledger go beyond crypto-currency to support different
kind of transaction storage models that relate to other forms
of business or e-commerce activities. However, these platforms
lack high throughput and the immediate concerns the research
community has is to improve the throughput.
For Yugala implementation, we have incorporated Mystiko
Blockchain [11] platform which mainly targeted for big data
operations. It built with Apache Cassandra distributed stor-
age [17] and Apache Kafka [18]. The main reason to use
Mystiko Blockchain for Yugala work is it’s high transaction
throughput, and scalability features. Since Mystiko storage
model supports to keep large data payloads we were able to
484
Authorized licensed use limited to: Old Dominion University. Downloaded on November 11,2020 at 20:55:49 UTC from IEEE Xplore. Restrictions apply.

Fig. 3. Yugala architecture overview
store encrypted file payloads on the Blockchain. To support
concurrent transaction executions Mytiko uses Scala functional
programming [19] and Akka Actor [20] based Aplos smart
contract service. All smart contracts on Yugala platform writ-
ten with Aplos service of Mystiko Blockchain.
C. System Model and Threat Model
System Model: In the proposed setting, the cloud storage
system is deployed under multi-user model, which consists of
Cloud storage server, and a group of users (as shown in fig. 1).
Here, the Cloud storage offers storage of the encrypted files.
The users encrypt the files in such a way that only users having
the same files can verify the existence of the files, while the
cloud storage system can’t.
Threat Model: We assume that the cloud storage is semi-honest
and doesn’t collude with the users. CS may detect the the ex-
istence of the encrypted files which the user is inquiring about,
but wouldn’t know the content of the encrypt file. Additionally,
CS can simply remove the file which a user has uploaded into
the cloud. So, the two security goals the proposed architecture
provides with respect to the threat model are file confidentiality
and file integrity. First, it achieves file confidentiality as all
the users encrypt their files during uploading, hence, CS can’t
read the content of the file. Second, as the existence of the
file is now available in Blockchain, CS can’t remove the file
by itself (because the information in Blockchain is distributed
in multiple servers and the information is redundant,) hence
providing system integrity and reliability. The novelty of the
proposed approach is that the encryption is simplified by an
intelligent combination of convergence encryption and the
random puzzle methods.
III. YUGALA ARCHITECTURE
In this section, we first discuss the Yugula architecture
by mentioning all the important actors. Then, we explain
the proposed two approaches for file confidentiality with
data deduplication: one using double hash and another using
symmetric encryption.
Fig. 4. Double hash approach
User 1 User 2 Cloud storage
1.a :t2=H(t1)
t1=H(data)
1.b :Negative
1.c:DES t1(Data)
2.a:t2=H(t1)
t1=H(data)
2.b :Positive
2.c :No data transmission
Fig. 5. Deduplication using double hash
Architecture Overview: There are basically three actors
in the architecute: clients, Blockchain and cloud storage.
Consider a scenario where two clients (client1 and client2)
have a same file, Figure 3. First, client1 uploads the tag to
the Blockchain. The Blockchain checks whether a file already
existing with the given tag. If file not exists, its a new file.
This file will be saved at the storage. Later client2 uploads
same file to Yugala cloud with tag Blockchain checks the file
already exists with given tag and it wont save the new file
content. All the duplication checking functions handles with
smart contract on Mystiko Blockchain. So, we next discuss
the two proposed file confidentiality with data deduplication
approaches.
A. Double-hash approach
The steps of double hash approach is shown in Fig. 4.
In order to demonstrate the multi-user scenario, we have
considered two users here, which also holds true for more
485
Authorized licensed use limited to: Old Dominion University. Downloaded on November 11,2020 at 20:55:49 UTC from IEEE Xplore. Restrictions apply.

Fig. 6. Symmetric encryption based approach
number of users. The process is described in detail below. The
Fig. 5 shows the data flow diagram of double-hash approach
secured data deduplication.
1) In the beginning, when a user tries to upload a file, he
first calculates the hash of the file which he wants to
send. Then, he uses the hash output as an input to again
generate a hash output, which he considers as the tag.
Subsequently, he sends the tag to the cloud sever (See
1.a and 2.a in fig 5).
2) The cloud storage sends Negative (orpositive)tothe
user, if it doesn’t have the file (or otherwise). (See 1.b
and 2.b in fig 5)
3) If, the use receives a positive response from the cloud,
i.e., the encrypted file associated with the tag is available
at the cloud, the user doesn’t do anything. (See 2.c in
fig 5).
4) Otherwise, the user encrypts the file using the hash
output as the key. (See 1.c in fig 5)
B. Symmetric encryption approach
The steps of symmetric encryption based approach is shown
in Fig. 6. Here also, in order to demonstrate the multi-user
scenario, we have considered two users here, which also holds
true for more number of users. The process is described in
detail below. The Fig. 7 shows the data flow diagram of the
modified secured data deduplication.
1) In the beginning, when a user tries to upload a file, he
first calculates the hash of the file which he wants to
send. Then, uses this hash output to encrypt a numeric
value , for example, ’1’ and generates the tag. Subse-
quently, he sends the tag to the cloud sever (See 1.a and
2.a in fig 7).
2) The cloud storage sends Negative (or positive) to the
user, if it doesn’t have the file (or has the file). (See 1.b
and 2.b in fig 7)
3) If, the user receives a positive response from the cloud,
i.e., the encrypted file associated with the tag is available
User 1 User 2 Cloud storage
1.a :t2=DESt1(1)
t1=H(data)
1.b :Negative
1.c:DES t1(Data)
2.a:t2=DESt1(1)
t1=H(data)
2.b :Positive
2.c :No data transmission
Fig. 7. Deduplication using symmetric encryption
at the cloud, the user doesn’t do anything. (See 2.c in
fig 7).
4) Otherwise, the user encrypts the file using the hash
output as the key. (See 1.c in fig 7)
IV. IMPLEMENTATION
As a proof of concept we have implemented “Yugala”. The
Yugala cloud service is built on the top of Mystiko Blockchain
which is highly scaleble. Since Mystiko blockchian mainly tar-
get for bigdata, we were able to support IoT requirements with
Yugala cloud service. Here, first, we discuss the underlying
Blockchain Mystico and then move on to different components
of Yugula and their interact with Mystico.
A. Mystiko
Mystiko is a highly scalable Blockchain system which
targeted for big data. It utilizes Apache Cassandra [17] dis-
tributed database (with Paxos consensus [21] as the under-
lying consensus platform). Mystiko uses Apache Kafka and
Akka streams [22] to handle back pressure operations on big
data. To facilitate the full text search on Blockchain data,
Mystiko utilized the Apache Lucene [23] based Elasticsearch
API [24]. Mytiko Blockchain built as a Microservices [25]
based distributed system (See Fig 8). These Microservices
can be deployed with Docker and Kubernetes in highly scal-
able environment. Mystiko addressed three main performance
bottlenecks on existing Blockchain platforms, namely, Order-
Execute architecture, Full node data replication and Imperative
style smart contracts.
To address the issues on traditional Order-Execute
Blockchain architecture [16] Mystiko provides Redis cache
based Validate-Execute-Group architecture. This architecture
allows to validates and executes the transactions when a client
submits a transaction to the network. The client does not
need to wait until a block has been created to commit the
486
Authorized licensed use limited to: Old Dominion University. Downloaded on November 11,2020 at 20:55:49 UTC from IEEE Xplore. Restrictions apply.

Fig. 8. Mystiko blockchian architecture
transaction. This new architecture provides high scalability and
high transaction throughput of Mystiko Blockchain.
All blocks, transactions and asset information are stored in
Cassandra database tables in Mystiko. Since using cassandra
as the assert storage, Mystiko can stores larger data payloads
with the asserts. In mystiko every Blockchain peer comes with
a Cassandra node; these nodes are connected with one another
in a ring cluster architecture. After executing a transaction,
state update in a peer is distributed and replicated using
sharding with Cassandras Paxos consensus algorithm. With
this approach mystiko avoids full node replication issue in
traditional Blockchains.
As an alternative to the imperative style smart contract
on existing Blockchains, Mystiko introduces the Aplos smart
contract platform. This platform is built using the Scala
Functional Programming [19] language and used Akka ac-
tors [20], which comes with built-in concurrency control. With
Akka actors and Functional Programming-based concurrency
control, the Aplos platform enables concurrent transaction
execution. All transactions in Mystiko are executed using
actors. Clients submit transactions to Mystiko aplos service
via apache kafka [18]. Mystiko transaction comes with actor
name and the message. Actors consumes messages; then based
on the message, it perform write/update/query on the ledger
and return the response to the client.
B. Components in yugala
The Yugala cloud storage intends to support for big data
operations. Fig. 9 illustrates the Yugala cloud implementation
architecture with Mystiko Blockchain.
1) Mystiko storage service: Storage service is Apache
Cassandra based storage service in Mystiko Blockchain. In
Yugula, all file payloads and respective tags saved in Mystiko
Storage service as the blockchian assets. Mystiko Blockchain
uses sharding based data replication instead of full node
replication. When files saved on Mystiko storage those files
will be replicated with other Blockchain nodes based on
sharding.
Fig. 9. Yugala architecture
2) Mystiko aplos service : As mentioned previously, Mys-
tiko Blockchain comes with Scala functional programming
based smart contract platform which introduced as Aplos.
These smart contracts written with Akka actors, so it intro-
duced as Aplos smart actor platform. All the business logics
of the Blockchain applications written on Aplos service as
smart actors. In Yugala, data deduplication, and encryption
logics are written on Aplos service as smart actor.
3) Mystiko kafka: Mystiko Blockchain mainly targeted
for big data, it use akka streams and kafka to handle the
backpressure operations on big data. In Yugala, we used
mystiko Blockchain to handle back pressure operations. All
the file upload transactions receives to kafka. When transaction
receives to kafka it consumes by aplos service. Then it
executes corresponding smart actor and take necessary action.
4) Yugala API: Yugala API is the front end REST API to
Mystiko Blockchain in Yugala platform. It expose HTTP API
which takes encrypted file payloads and tags. When it receives
request with tag and file payload it publish these information
to apache kafka. Then, kafka delivers it Aplos service and
handle further actions.
5) Yugala client: Clients upload encrypted files with re-
spective tags to Yugala cloud. Clients need to generate
keys/tags and encrypt the files based on these keys. We
provide Yugala-SDK to handle these key/tag generations and
encryptions. Client invoke yugala SDK function with file
payload. SDK function returns the key, tag and encrypted
payload. All the key/tag generations and file encryption handle
by SDK. Finally client uploads encrypted file with tag to
Yugala cloud via Yugala API.
V. R ESULTS
We have done a performance evaluation of Yugala cloud ser-
vice. We deployed multiple-node Mystiko Blockchain cluster
and Yugala services in AWS 2xlarge instances (16GB RAM
and 8 CPUs) and obtained the results. The evaluation is per-
formed with Yugala double hashing based system that we have
built on top of Mystiko Blockchain. The results are obtained
in the following five areas: Transaction throughput,Transaction
scalability, Search performance, Double hashing performance,
and Encryption performance in Yugla client.
487
Authorized licensed use limited to: Old Dominion University. Downloaded on November 11,2020 at 20:55:49 UTC from IEEE Xplore. Restrictions apply.

Fig. 10. Number of concurrent transactions executed in mystiko Blockchain
A. Transaction throughput of Yugala cloud
For the Transaction throughput, we recorded the number of
transactions that can be executed in each Mystiko Blockchain
peer in Yugala cloud. We flooded transactions for each
Blockchain peer and recorded the number of executed transac-
tions. As shown in Figure 10, each peer in the Blockchain has
consistent transaction throughput. There are three main rea-
sons for high transaction throughput: The Underlying Apache
Cassandra database in Mystiko, the Validate-Execute-Group
architecture of Mystiko and Functional programming based
smart contracts.
B. Transaction scalability of Yugala cloud
In order to observe the transaction scalability, we recorded
the number of executed transactions (per second) over the
number of Blockchain peers in the Yugala network. We
flooded concurrent transaction in each Blockchain peer and
recorded the number of executed transactions. As shown in
Figure 11 when we increase the number of Blockchain peers,
the transaction throughput linearly increased. The main reason
for this liner scalability is Cassandra storage on which Mys-
tiko Blockchains is based. Cassandra follows master-less ring
architecture, so all nodes in the cluster have write capability.
When adding a node to the cluster, it linearly increases the
transaction throughput.
C. Search performance of Yugala
Next, we evaluated the search performance of Mystiko
Blockchain based Yugala cloud service. For this test we
bootstrap Mystiko Blockchain with different transaction sets
and obtained the time taken to search a record. As shown
in Figure 12 we were able to search a record from two
million transactions set within 4 milliseconds time. Mystiko
Blockchain uses Cassandra as it’s the storage platform and
Apache Lucene index-based Elasticsearch as it’s indexing tool.
This Elastisearch and Cassandra based storage yielding super
fast search in Yugala cloud storage.
Fig. 11. The scalability of mystiko blockchian
Fig. 12. Time taken to search the data from Mystiko Blockchain
D. Double hashing performance
Yugla platform uses double hashing based key generation.
For this evaluation we recorded number of double hashes that
can be performed (per second) in Golang [26] based Yugala
client SDK. We run SHA1, SHA2, MD5 hashing against the
50kb, 100kb, 200kb, 500kb, 1000kb, 2000kb size image file set.
Figure 13 shows how double hashing performance varying
with different file sizes and different hashing algorithms.
E. Encryption performance
Finally, we evaluated the encryption performance of Yugla
client SDK. For this evaluation, we used Golang based Yugla
client SDK. It uses AES asymmetric encryption with GCM
mode. This SDKs encryption function run against different
file sizes and recorded the number of encrypt ions that can be
performed within a second. Figure 14 shows how encryption
throughput varying with different file sizes.
488
Authorized licensed use limited to: Old Dominion University. Downloaded on November 11,2020 at 20:55:49 UTC from IEEE Xplore. Restrictions apply.

Fig. 13. Double hash performance of Yugala client SDK
Fig. 14. Encryption performance of Yugala client SDK
‘
VI. CONCLUSION
In this paper, we discuss a new encrypted cloud storage
architecture called, Yugula, which provides file confidentiality
and integrity by using modified convergent encryption and
Blockchain. In particular, we discuss two approaches for
data confidentiality: one uses double hashing and the other,
symmetric encryption.
As a proof of concept, we implemented Yugala. The Yugala
cloud service built on top of Mystiko Blockchain which is
highly scalable Blockcain. Since Mystiko blockchian mainly
target for bigdata, we can support IoT requirements with
Yugala cloud service. The result section demonstrates the per-
formance of the architecture highlighting the high transaction
throughput requirements, with respect to the size of the upload
files and the load of Blockchain, in IoT setting.
REFERENCES
[1] C.-M. Yu, S. P. Gochhayat, M. Conti, and C.-S. Lu, “Privacy aware data
deduplication for side channel in cloud storage,” IEEE Transactions on
Cloud Computing, 2018.
[2] D. Geer, “Reducing the storage burden via data deduplication,” Com-
puter, vol. 41, no. 12, pp. 15–17, 2008.
[3] H. Shin, D. Koo, Y. Shin, and J. Hur, “Privacy-preserving and updatable
block-level data deduplication in cloud storage services,” in 2018 IEEE
11th International Conference on Cloud Computing (CLOUD). IEEE,
2018, pp. 392–400.
[4] H. Jannati, E. Ardeshir-Larijani, and B. Bahrak, “Privacy in cross-user
data deduplication,” Mobile Networks and Applications, pp. 1–13, 2018.
[5] Y. Zhou, D. Feng, W. Xia, M. Fu, and Y. Xiao, “Darm: A deduplication-
aware redundancy management approach for reliable-enhanced storage
systems,” in International Conference on Algorithms and Architectures
for Parallel Processing. Springer, 2018, pp. 445–461.
[6] Z. Pooranian, K.-C. Chen, C.-M. Yu, and M. Conti, “Rare: Defeating
side channels based on data-deduplication in cloud storage,” in IEEE
INFOCOM 2018-IEEE Conference on Computer Communications Work-
shops (INFOCOM WKSHPS). IEEE, 2018, pp. 444–449.
[7] M. Liu, C. Yang, Q. Jiang, X. Chen, J. Ma, and J. Ren, “Updatable block-
level deduplication with dynamic ownership management on encrypted
data,” in 2018 IEEE International Conference on Communications
(ICC). IEEE, 2018, pp. 1–7.
[8] J. Fan, C. Guan, K. Ren, and C. Qiao, “Middlebox-based packet-
level redundancy elimination over encrypted network traffic,” IEEE/ACM
Transactions on Networking (TON), vol. 26, no. 4, pp. 1742–1753, 2018.
[9] K. D. Bowers, A. Juels, and A. Oprea, “Proofs of retrievability: Theory
and implementation,” in Proceedings of the 2009 ACM workshop on
Cloud computing security. ACM, 2009, pp. 43–54.
[10] F. Casino, T. K. Dasaklis, and C. Patsakis, “A systematic literature review
of blockchain-based applications: current status, classification and open
issues,” Telematics and Informatics, 2018.
[11] E. Bandara, W. K. NG, K. DE Zoysa, N. Fernando, S. Tharaka,
P. Maurakirinathan, and N. Jayasuriya, “Mystikoblockchain meets big
data,” in 2018 IEEE International Conference on Big Data (Big Data).
IEEE, 2018, pp. 3024–3032.
[12] D. Tosh, S. Shetty, P. Foytik, C. Kamhoua, and L. Njilla, “Cloudpos:
A proof-of-stake consensus design for blockchain integrated cloud,”
in 2018 IEEE 11th International Conference on Cloud Computing
(CLOUD). IEEE, 2018, pp. 302–309.
[13] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2008.
[14] V. Buterin et al., “A next-generation smart contract and decentralized
application platform,” white paper, 2014.
[15] T. McConaghy, R. Marques, A. M¨
uller, D. De Jonghe, T. Mc-
Conaghy, G. McMullen, R. Henderson, S. Bellemare, and A. Granzotto,
“Bigchaindb: a scalable blockchain database,” white paper, BigChainDB,
2016.
[16] E. Androulaki, A. Barger, V. Bortnikov, C. Cachin, K. Christidis,
A. De Caro, D. Enyeart, C. Ferris, G. Laventman, Y. Manevich et al.,
“Hyperledger fabric: a distributed operating system for permissioned
blockchains,” in Proceedings of the Thirteenth EuroSys Conference.
ACM, 2018, p. 30.
[17] A. Lakshman and P. Malik, “Cassandra: a decentralized structured
storage system,” ACM SIGOPS Operating Systems Review, vol. 44, no. 2,
pp. 35–40, 2010.
[18] J. Kreps, N. Narkhede, J. Rao et al., “Kafka: A distributed messaging
system for log processing,” in Proceedings of the NetDB, 2011, pp. 1–7.
[19] “The scala programming language.” [Online]. Available:
https://www.scala-lang.org/
[20] “Akka documentation.” [Online]. Available:
https://doc.akka.io/docs/akka/2.5/actors.html
[21] L. Lamport, “The part-time parliament,” ACM Transactions on Computer
Systems (TOCS), vol. 16, no. 2, pp. 133–169, 1998.
[22] “Akka documentation.” [Online]. Available:
https://doc.akka.io/docs/akka/2.5/stream/
[23] “Welcome to apache lucene.” [Online]. Available:
http://lucene.apache.org/
[24] “Elastic stack and product documentation — elastic.” [Online].
Available: https://www.elastic.co/guide/index.html
[25] “Microservices pattern: Microservice architecture pattern.” [Online].
Available: http://microservices.io/patterns/microservices.html
[26] “The go programming language.” [Online]. Available: https://golang.org/
489
Authorized licensed use limited to: Old Dominion University. Downloaded on November 11,2020 at 20:55:49 UTC from IEEE Xplore. Restrictions apply.