Conference PaperPDF Available

Proof of Stake Blockchain: Performance and Scalability for Groupware Communications

Authors:

Abstract and Figures

A blockchain is a distributed transaction ledger, a disruptive technology that creates new possibilities for digital ecosystems. The blockchain ecosystem maintains an immutable transaction record to support many types of digital services. This paper compares the performance and scalability of a web-based groupware communication application using both non-blockchain and blockchain technologies. Scalabil-ity is measured where message load is synthesized over two typical communication topologies. The first is 1 to n network – a typical client-server or star-topology with a central vertex (server) receiving all messages from the remaining n − 1 vertices (clients). The second is a more naturally occurring scale-free network topology, where multiple communication hubs are distributed throughout the network. System performance is tested with both blockchain and non-blockchain solutions using multiple cloud computing configurations. We analyze the empirical results from each configuration to identify the costs and overhead of blockchain technology.
Content may be subject to copyright.
Proof of Stake Blockchain: Performance and Scalability for
Groupware Communications
Jason Spasovski and Peter Eklund
IT University of Copenhagen
Rued Langgaards Vej 7
2300 Copenhagen, Denmark
jspa@itu.dk, petw@itu.dk
ABSTRACT
A blockchain is a distributed transaction ledger, a disruptive
technology that creates new possibilities for digital ecosys-
tems. The blockchain ecosystem maintains an immutable
transaction record to support many types of digital ser-
vices. This paper compares the performance and scalability
of a web-based groupware communication application using
both non-blockchain and blockchain technologies. Scalabil-
ity is measured where message load is synthesized over two
typical communication topologies. The first is 1 to nnet-
work – a typical client-server or star-topology with a central
vertex (server) receiving all messages from the remaining
n1 vertices (clients). The second is a more naturally
occurring scale-free network topology, where multiple com-
munication hubs are distributed throughout the network.
System performance is tested with both blockchain and non-
blockchain solutions using multiple cloud computing config-
urations. We analyze the empirical results from each con-
figuration to identify the costs and overhead of blockchain
technology.
General Terms
Groupware communication, distributed ledger ecosystems,
blockchain, scale-free networks, distributed & cloud com-
puting.
1. INTRODUCTION
Security and scalability are chief concerns when provid-
ing data storage and communication solutions in a transac-
tional digital ecosystem. Recent security vulnerabilities ex-
posed in well-established companies, e.g. ebay 1and Sony 2
1
“eBay faces investigations over data breach”, BBC
News, May, 2014, see http://www.bbc.com/news/
technology-27539799
2“Sony PlayStation suffers massive data breach”,
Reuters, April, 2011, see http://www.reuters.com/
article/us-sony-stoldendata-idUSTRE73P6WB20110426
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
MEDES 2017
Copyright 2017 ACM X-XXXXX-XX-X/XX/XX ...$5.00.
demonstrate the consequences of security failures in com-
mercial communication software. The blockchain, or dis-
tributed ledger, is a way of decentralizing database control.
Likewise, the importance of scalability is particularly visible
in web-based applications, system performance is critical to
the growth of a user base [14].
Collaboration tools are on-line services used by large audi-
ences and are characterized by countless database changes,
with the addition of other special requirements, such as the
need for low response times and confidential data storage.
These requirements prove to be a challenge to both security
and scalability.
One such collaboration tool is the web application dallr 3.
The first author Spasovski (with Andreassen and Lyck) de-
veloped dallr to create a simple intuitive platform with a
flat learning curve to target small to medium sized compa-
nies. dallr is a groupware communication application that
provides the platform for our empirical comparison.
A major threat to any database are tampering attacks. In
such attacks the database is partly or completely controlled
by an unauthorized third party. Database tampering can be
performed in many ways, each reflecting the possible severity
of the attack, depending on the level of privileges held by
the adversary. As a concrete example, if an adversary were
to use SQL injection, they would most likely only be able to
tamper with the database with minimal privileges, whereas
if an adversary gains access to an administrator account, the
entire database could be deleted.
A common approach to deal with database tampering is
auditing [12], a collection of methods to verify the integrity
of the database by simple procedures such as inserted check-
sums. The main concern with auditing is that it does not
protect against an adversary gaining access to the adminis-
trator privileges. An alternative to deal with database tam-
pering is to use an immutable database, such as Datomic4.
Immutable databases lift the modify and delete functional-
ity, thus making them immutable by design and allow for
extreme scalability and performance.
The current trending method to deal with data tamper-
ing is by using a decentralized blockchain [15] – a distributed
cryptographic ledger. Blockchain is a distributed database
consisting of linked blocks that contain timestamped and
valid transactions. These blocks are linked using the hash
3J. Spasovski, A. Lyck, J. Andreassen. Collaboration with-
out a learning curve [Software], see http://www.dallr.com.
4Pavlou, Kyriacos E., and Richard T. Snodgrass The fully
transactional, cloud-ready, distributed database. [Software],
see http://www.datomic.com/.
of the previous block, creating a chain of blocks where each
block reinforces the integrity of its predecessor. Chaining
blocks in this cryptological manner prevents data stored in
the blocks – the blockchain – to be easily tampered. Decen-
tralization of the blockchain adds an extra layer of security
by distributing the blockchain over multiple decentralized
participating network nodes, each containing a copy of the
blockchain. In this way, the blockchain cannot be controlled
or exploited through a single point of attack on any single
node.
Blockchain has few benefits over traditional databases while
having multiple trade offs, therefore it is important that the
motivation for using a blockchain is worth the trade offs.
Our motivation for using a blockchain is primarily to pro-
tect against database tampering while other use cases could
be motivated by the decentralized blockchain’s ability to re-
move the need for a middle man to authorize transactions.
A large body of work [15, 10, 7] demonstrates that decen-
tralized blockchain allows for strong irrefutability and au-
ditable data storage. In most cases, when using a blockchain
to increase the security of a web application, the scalabil-
ity and performance of the application is significantly de-
creased [6]. This is due to the overhead of the different
consensus algorithms that secure the blockchain.
This paper is structured as follows. Section 2 presents a
survey of the basic theory behind blockchain, as well as de-
scribing some of the mechanisms used in implementations.
Section 3 presents the technologies and architecture used
and give details of the implementation of both blockchain
and non-blockchain versions of dallr. In Section 4, we
present the test scenarios and cloud environments used through-
out the tests. In Section 5 experimental results are presented
focusing particularly on response time and throughput. In
Section 6 we confront expectations with the experimental
findings, thereafter we analyze each of the results attained.
Lastly, in Section 7 we conclude with a brief summary of the
experimental results and analysis.
2. BLOCKCHAIN
Consensus algorithms are used within blockchains to en-
sure that the participating nodes in the distributed system
agree with the current state of the blockchain before each
new block is added [5]. Blockchain consensus algorithms are
Byzantine Fault Tolerant meaning no single machine can
succeed in being malicious against the distributed system
[9].
Bitcoin is the prime example of a cryptocurrency powered
blockchain that allows users to submit transactions without
the need for a central trusted organization; this is achieved
using a consensus algorithm called Proof of Work [10]. This
algorithm uses mining to prove consensus, which requires a
large amount of energy and therefore enforces slow transac-
tion times.
Proof of Stake is a more efficient alternative to Proof of
work where no mining is required to achieve consensus but
instead the next node to create a block is selected pro-
portional to its stake in the blockchain. The stake can
vary depending on how the blockchain has implemented its
proof. In cryptocurrency blockchains, the stake is normally
the number of coins a node holds. In non-cryptocurrency
blockchains alternative approaches such as voting are re-
quired as no stake exists by default.
Merkle trees are a common data structure for storing
blockchain data and implemented using an AVL tree, also
refereed to as a self balancing binary search tree. Merkle
trees have one main difference from normal tree-based data
structures: a value in the tree can always be verified by re-
hashing all the way from the selected node upwards to the
root of the tree, which will take O(log n) time. On every in-
sert the the trail of the inserted node is rehashed from where
the node is inserted all the way to the root node.
All blockchains fall into one of two categories, namely
Public or Private. Public-blockchains are those that allow
all users on the network to view the data you store, while
private blockchains hide all data stored on the blockchain be-
tween its permissioned participants. Private blockchains can
be either fully private or consortium blockchains. Read and
write permissions of a fully private blockchain are controlled
by a single organization, which can be viewed as a central-
ized database with added cryptographic security. Consor-
tium blockchains are where the read and write permissions
are distributed across a permissioned consortium which adds
the extra security of decentralization.
3. IMPLEMENTATION
Figs. 1 and 2 show User 1 sending a message to User 2.
Fig. 1 does not use a blockchain while in Fig. 2 a blockchain
is used.
Figure 1: Flow diagram of User 1 sending a message
to User 2 without a blockchain.
Figure 2: Flow diagram of User 1 sending a message
to User 2 with a blockchain.
The blockchain used in our implementation is the private
consortium blockchain named Tendermint5. Tendermint is
5http://tendermint.com version 0.9.
a relatively lightweight blockchain solution since its consen-
sus method is proof of stake using a voting mechanism [2]
as opposed to the more computational expensive proof of
work [8].
Two different types of nodes exist in the tendermint
blockchain, namely validator nodes and non-validator nodes.
Validator nodes are part of the consortium which vote to
agree upon consensus while non-validator nodes are restricted
to reading and proposing transactions on the blockchain. All
nodes in the tendermint blockchain communicate over a per-
sistent encrypted TCP p2p gossip protocol.
From a design perspective, a straight-forward method of
using a blockchain is to store all data in the blockchain.
Storing all data in a blockchain has one large drawback;
namely if all data stored on the blockchain is immutable,
consequently no data can ever be removed. This in turn
causes the blockchain to grow so large that it can become
impractical to store.
Growth of the blockchain is inevitable but the rate of
growth can easily be managed. All data in our implementa-
tion is stored in the document database MongoDB database6,
while only a hash of the data entries are saved in the blockchain.
The hashes saved in the blockchain are used as a checksum to
confirm the validity of the data stored in the database. This
method of maintaining all data in the database has some
vulnerabilities which are not addressed in this paper. For
each individual document retrieved from the database, the
blockchain is queried with the according hashes, thus con-
firming the validity the data retrieved from the database.
The blockchain validity of data is always sent to the user
alongside the data retrieved from the database.
In order for the application to communicate with the
blockchain validator nodes each application server runs a lo-
cal version of the blockchain. This local version is in a non-
validator node which is synchronized with the blockchain
and pushes new transactions to validator nodes, but is not
involved in consensus. We chose this design to allow the
validator nodes to focus on adding transactions with con-
sensus rather than responding to blockchain queries, which
would otherwise slow the consensus process. We adopted
an asynchronous approach when pushing new transactions
to the blockchain which allows users the ability to view
transactions before consensus is agreed upon by the val-
idators. When adding a new transaction a constant time
function is run on the local blockchain returning true if the
local blockchain verifies the transaction as valid. The local
blockchain node gossips with the blockchain validators and
– normally after a second – consensus will be agreed and the
new transaction will be added to the blockchain, hereafter
the user will receive confirmation that the transaction has
been validated [3].
4. TESTING
4.1 Testing Scenarios
The two testing scenarios have the primary goal of sim-
ulating a large number of users simultaneously communi-
cating via the application. The difference between the two
scenarios lies in the form in which communication between
the users is initiated. The first test uses a realistic messaging
pattern based on a scale-free network graph. Network theory
6https://www.mongodb.com
and its application have shown that communication in com-
munities in the real-world follow a scale-free communication
pattern [1]. The second test simulates a pathological client-
server scenario where a single node (server or authority) re-
ceives messages from the entire client-network. We run each
test scenario for a total of 60 seconds including a 10 second
ramp-up period in which all threads are started and here-
after run concurrently. The timeout limit for all requests is
20 seconds throughout all tests. Response time and through-
put are the chosen metrics, when testing both SendMes-
sage and RetrieveAllMessages functions. Both the non-
blockchain and blockchain implementations are tested for
each of the two testing scenarios.
Scale-Free Network Topology
We create the first testing scenario by applying network the-
ory, more specifically scale-free network theory to produce
scale-free networks. A graph is scale-free if the degree dis-
tribution of the neighbor list of its vertices is roughly power-
law. As a concrete example, the French instant messaging
community nioki [1] proved to be scale-free.
We use the Barabasi-Albert model to build our produce
power-law graphs. The Barabasi-Albert Model is described
by the formula:
pi=ki
Pjkj
This formula states that the probability of a newly created
vertex being connected to vertex [i] is the degree of vertex [i]
divided by the sum of the degree of every individual remain-
ing vertex. 7.
Each user is represented as a vertex and a message sent
from one user to another is represented as an (undirected)
edge. A node with relatively high degree is denoted as a hub.
Illustration of hubs (marked by a black dot) can be seen in
in Fig. 3. A hub in scale-free network can be thought of as
role in an organization: hubs may represent the CEO of a
company, the vice-chancellor of a University or the faculties
manager of a building.
Figure 3: Random network vs Scale-free network
The test runs for 60 seconds in which it receives the num-
ber of users as input and creates that many threads (users)
that run in parallel. The Scale-Free Network graph is di-
vided over multiple files which are concurrently read by each
user, these files contain a single edge on each line. For each
line in the graph file, the user sends a message to the ac-
cording user using the SendMessage function. Thereafter
7We produce the scale-free network graphs using a Java im-
plementation of the Barabasi-Albert Model named graph-
stream http://graphstream-project.org/
the user has a 10% chance to retrieve all messages using the
RetrieveAllMessage function, followed by a 300ms second
delay. If the graph file reaches the end it will wait for (users
×2)ms before returning to the start of the file, this is done
to reduce the throughput of users with fewer edges.
1 to n Topology
We now describe the second testing scenario, namely 1 to n
(or star graph). By forcing all users to send their messages
to a single user (User 1), we replicate a very heavy load being
put onto a single user – as may occur in DoS or DDoS attack.
By comparing the load on the heavily loaded user with the
remaining users on both implementations, we emphasize the
blockchain’s ability to handle centralized stress.
Similarly to the previous case, the test runs for 60 sec-
onds. In that timeframe, the test takes the number of users
as input and creates that many threads (users) that run in
parallel. Each user concurrently sends a message to User 1
using the SendMessage function, followed by 300ms delay.
Hereafter the user has a 10% chance to retrieve all mes-
sages using the RetrieveAllMessage function, followed by
a 300ms second delay.
4.2 Testing Environment
As seen in Figure 4 all requests are sent using 10 slave
testing machines controlled by the Master testing machine.
Each slave testing machine concurrently sends requests to
the Application Load balancer which distributes the requests
across all the application servers. The blockchain imple-
mentation will run a local blockchain that is used to com-
municate and keep in sync with the validator blockchains.
A single database server is shared between all application
servers.
Testing Machines
The tests8run up to 800 concurrent users for over a minute,
thus testing on a single machine will break the tests as the
JVM garbage collector (GC) is likely to run mid test and
pollute the test results 9. All tests are distributed over 10
slave test machines. All test machines are hosted on the
Azure cloud within the same subnet and the master machine
is controlled via remote desktop.
Each slave test machine is an Azure D13 instance running
with 8 Intel Xeon E5-2660 2.2 GHz Cores and 56GB RAM
running Debian version 8.7. The master test machine runs
on a smaller D3 instance, as less resources are required to
control the slaves. The resources of the testing machines are
monitored throughout all tests to ensure they do not cause
inconsistent test results.
Blockchain Validator Nodes
Throughout our tests the 10 blockchain validator nodes are
spread over three different geographic regions (Amsterdam,
London and Frankfurt) on the Digital Ocean cloud. By do-
ing so we attempt to replicate a real-world scenario where
8We ran the tests using Apache JMeter, see http://jmeter.
apache.org
9The min and max heap of the JVM is set to be 52GB and
the young generation (Eden) of the heap to be as large as
possible to ensure the GC does not pollute the results. A
major GC won’t trigger until Eden starts to get full. The
verbose gc setting was used throughout all tests to output
all garbage collection information.
Figure 4: Overview of testing environment.
the blockchain nodes would be distributed between a con-
sortium of organizations. The validator nodes are hosted on
dual core virtual machines with 2GB of RAM, SSD storage
and running Ubuntu version 14.04. In addition, we moni-
tored the CPU and RAM usage to ensure that the servers
hosting the blockchains are appropriately provisioned.
Buchman [3] ran detailed tests on tendermint which showed
that adding more validators both lowers the throughput and
increases the latency. Buchman first ran 64 validators and
reached a throughput of 4,000 transactions per second with
latencies of 2 seconds, and then 8 validators with 9,000 trans-
actions per second and latencies of 1.5 seconds. The reason
for the high latencies in his tests is due to the high spread of
locations of the testing validators. Due to the asynchronous
architecture of our application, our tests are not affected by
validator latencies. It follows that changing the number of
validators does not directly affect our test results but could
affect the overall user experience.
Cloud Computing Configurations
The Microsoft Azure cloud computing service is used for all
tests to host both the application, test and database servers
instances. The number of instances that run the application
and local blockchain are the only factors that change within
the testing environment. Throughout all tests we use a sin-
gle Azure G4 instance to run our database which has a 16
core Intel Xeon E5 v3 2.0 GHz processor,224GB of RAM
and SSD storage.
The Azure scale set is used to scale the application servers
using replica instances which run the dallr application,
alongside a local version of the blockchain (only if the blockchain
implementation is being tested) 10.
The Azure scale set uses D3 instances that have 4 In-
tel Xeon E5-2660 2.2 GHz cores and 13GB of ram and use
SSD hard drives. The D3 instance was chosen because the
application and local blockchain would not run adequately
on the smaller D1 or D2 instances due to lack of hardware
provision.
The tests are started initially with one instance and a
gradually increasing load until the test results show aver-
age response times of over a second. After these average
response times of over a second appear the number of in-
stances is doubled and the tests are restarted and run until
an average response time of over a second appears again.
This process is be repeated until an average response time
of over 1 second appears on 8 test instances. Both implemen-
tations are tested on the four cloud configurations consisting
of 1, 2, 4 and 8 instances.
5. EXPERIMENTAL RESULTS
This section presents experimental results in the form of
line graphs focusing on response time and throughput. Ram-
say et. al [13] noted negative user behavior with response
times of 200ms or higher. Throughout all our results we fo-
cus on maintaining a response time of less than 200ms, and
decide not to display results over 350ms averaged.
In Section 5.1 we present experimental results measur-
ing response time over various cloud configurations. In Sec-
tion 5.2 we present experimental results measuring through-
put on a single cloud instance. Lastly, in Section 5.3 we
present experimental results measuring response time of heavy
stress loads through a single user.
5.1 Response Time
This section contains line graphs comparing the two im-
plementations (blockchain and non-blockchain) in terms of
different user loads using the scale-free network and 1 to n
test scenarios. The two messaging functions tested in each
testing scenario are the RetrieveAllMessages function and
the SendMessage. These two functions combined with the
two implementations give four different combinations to test.
The metric to measure scalability in this section is the Av-
erage response time over a minute.
5.2 Throughput
This section focuses on one of the two messaging func-
tions RetrieveAllMessages and SendMessage while com-
bining the blockchain implementation & non-blockchain im-
plementation with the scale-free testing scenario & 1 to n
10All instances on the Azure scale set are running the latest
stable release of Debian version 8.7.
Figure 5: Scale-Free Network Test: compares Re-
trieveAllMessages against SendMessage for both im-
plementations on a single D3 (4 Core 13GB RAM)
instance
Figure 6: 1 to nTest: compares RetrieveAllMes-
sages against SendMessage on both implementations
(blockchain & non-blockchain) on a single D3 (4
Core 13GB RAM) instance
testing scenario to give four different testing combinations
for each line graph. The metric used to measure scalability
in this section is the average transactions per second over a
minute.
5.3 User 1 vs User n
In this section User 1 represents the heavily loaded user
that receives all messages in the 1 to ntest scenario while
User nrepresents each of the remaining n1 users. The
users in this test are represented as a rooted tree where each
user is a node and each edge is a message sent. The user
receiving all messages is the the root node of the rooted tree
and all the remaining users are the leaf nodes. In this section
we will use the terminology of a root node to represent User
1 and a leaf node to represent the remaining n1 users.
This test compares the average response times of the Re-
trieveAllMessages function being called on the blockchain
and non-blockchain implementations. This test proves how
the two implementations handle the stress of a single heavily
loaded user.
Figure 7: Scale-Free Network Test: compares Re-
trieveAllMessages against SendMessage on both imple-
mentations (blockchain & non-blockchain) on 2 x D3
(4 Core 13GB RAM) instances
Figure 8: 1 to nTest: compares RetrieveAllMes-
sages against SendMessage on both implementations
(blockchain & non-blockchain) on 2 x D3 (4 Core
13GB RAM) instances
6. ANALYSIS
6.1 Expectations
We anticipated that the function RetrieveAllMessages
would be the bottleneck on the blockchain implementation.
This is due to the large number of queries the blockchain per-
forms within the function. The blockchain data is stored us-
ing merkle tree data structure, and thus it takes O(log n) [3]
time to search a block containing ntransactions. The func-
tion RetrieveAllMessages retrieves all the users messages
(m) from the database, and then queries the blockchain on
each of them. This implies a running time of O(m log n)
added to the database query.
The send message function performs a single insertion to
the database, as well as a single call to the function Insert-
ToBlockchain, the latter being a constant time operation [3].
Due to the asynchronous nature of how the implementation
adds messages to the blockchain, we expected the sending
of messages to perform well. Insertion to the database is ex-
pected to be much slower than querying due to write locks
Figure 9: Scale-Free Network Test: compares Re-
trieveAllMessages against SendMessage on both imple-
mentations (blockchain & non-blockchain) on four x
D3 (4 Core 13GB RAM) instances
Figure 10: 1 to nTest: compares RetrieveAllMes-
sages against SendMessage on both implementations
(blockchain & non-blockchain) on four x D3 (4 Core
13GB RAM) instances
on the database but these locks [11].
We did not expect to return consistent results due to un-
predictable network traffic on the azure cloud that can cause
unexpected response times with inconsistent latencies. Evi-
dence of unpredictable network traffic on the azure cloud is
visible in [4] where the latencies throughout the tests ran-
domly double over a testing period of 45 seconds.
6.2 Response Time
It is visible from Figures 5 to 12 that the results scale lin-
early until they reach their threshold, and then have a seem-
ingly exponential rate of growth. This is due to the time outs
that occur when the implementation can no longer handle
the load. In most tests, the majority of reliable results are
those under 200ms on average. From these figures it is clear
that the scalability of both implementations is linear. As
concrete example, in figures 5 and 11 a single instance of
RetrieveAllMessages has a threshold of 50 users, whereas
8 instances can handle 400.
We also find that the non-blockchain implementation can
Figure 11: Scale-Free Network Test: compares Re-
trieveAllMessages against SendMessage on both imple-
mentations (blockchain & non-blockchain) on eight
x D3 (4 Core 13GB RAM) instances
Figure 12: 1 to nTest: compares RetrieveAllMes-
sages against SendMessage on both implementations
(blockchain & non-blockchain) on eight x D3 (4 Core
13GB RAM) instances
handle 4 to 8 times the load as the blockchain implemen-
tation before reaching its threshold, while the blockchain
implementation incur a penalty of multiplicative 2 to 4 on
the response time. Figures 5 6 7 8 9 10 11 12 also show
that the function SendMessage in the blockchain implemen-
tation keeps pace with the non-blockchain implementation.
This is due to the asynchronous non-blocking design pattern
choice that our application follows. The SendMessage func-
tion does not wait until each message is validated and added
to the blockchain before returning.
We can also conclude that the RetrieveAllMessages func-
tion on the blockchain implementation has a harder time
coping with the same user load on the 1 to N test scenario
as the scale-free network test scenario. All querying of the
blockchain occurs through the local blockchain which can-
not handle the heavy load directed on a single user in the 1
to n test scenario.
6.3 Throughput
Figures 13 and 14 imply that the non-blockchain imple-
Figure 13: Comparing the SendMessage function on
both tests (Scale-Free & 1 to n) and implementa-
tions (blockchain & non-blockchain) on a single D3
(4 Core 13GB RAM) instance
Figure 14: Comparing the RetrieveAllMessages func-
tion on both tests (Scale-Free & 1 to n) and im-
plementations (blockchain & non-blockchain) on a
single D3 (4 Core 13GB RAM) instance
mentation has linear throughput growth throughout all tests
while the blockchain implementation grows linearly until a
threshold is reached. The throughput is throttled on both
functions of the blockchain implementation due to the Re-
trieveAllMessages function timing out. The testing soft-
ware is built to run on threads which disallow the test to
continue until the time out is finished. As seen in figures 5
and 6 the response time of the RetrieveAllMessages func-
tion starts increasing dramatically from 100 users onwards
which is where the linear growth of the throughput stops.
It is valid to note that the transactions per second on the
RetrieveAllMessages is a scaled down representation of the
actual reads that occur on the blockchain. As a specific
example, when testing with 100 users on the user 1 to n test
scenario from Figure 14, user 1 queries the blockchain over
10000 times each time the RetrieveAllMessages function is
called within the last 10 seconds of this test.
The scale-free test scenario has an extra delay of (2n)
MS (where nis the number of users), which the 1 to ntest
Figure 15: Comparing the RetrieveAllMessages func-
tion on the root node against the leaf nodes on both
implementations (blockchain & non-blockchain) on
a 2 x D3 (4 Core 13GB RAM) instances
scenario does not 11. The additional delay slightly lowers the
throughput of the scale-free test scenario, which is visible in
Figures 13 and 14.
6.4 User 1 vs User N
In Figure 15, a blockchain root node has a polynomial rate
of growth while the non-blockchain root node seems to be
constant. This type of behavior was expected after analyzing
the running time of the RetrieveAllMessages function on
the blockchain implementation in Section 6.1. Figure 15
shows that the leaf nodes are almost identical regardless
of the implementation. This proves that blockchains are
capable of keeping up with non-blockchain solutions given
they are not under heavy load.
7. CONCLUSION
We have shown that the blockchain implementation scales
linearly as the number of instances is increased, until we
reach the throughput threshold mentioned in Section 6.3.
We learned also from Section 6.2 that using the tendermint
blockchain incurs a 4-8 multiplicative factor on scalability,
and a multiplicative factor of 2-4 on the average response
times. These two findings imply that high throughput and
low response times can still be achieved if enough servers are
deployed. For well-established companies concerned with
transaction immutability and ledger security, paying 4 to 8
times more for cloud computing costs is unlikely to be any
concern. We have also shown in Section 6.4 that blockchains
perform particularly poorly when handling heavy traffic load
through single users. This implies that such solutions are
more vulnerable to cyber-attacks such as denial of service.
In future work we will be measuring the performance and
scalability of a other proof of stake blockchain implementa-
tions.
8. ACKNOWLEDGEMENT
This research was supported by the European Blockchain
Center http://www.ebccenter.eu
11This delay is described in Section 4.1.
9. REFERENCES
[1] Albert-L´aszl´o Barab´asi, R´eka Albert, and Hawoong
Jeong. Mean-field theory for scale-free random
networks. Physica A: Statistical Mechanics and its
Applications, 272(1):173–187, 1999.
[2] J¨
org Becker, Dominic Breuker, Tobias Heide, Justus
Holler, Hans Peter Rauer, and Rainer B¨
ohme. Can we
afford integrity by proof-of-work? scenarios inspired by
the bitcoin currency. In The Economics of Information
Security and Privacy, pages 135–156. Springer, 2013.
[3] Ethan Buchman. Tendermint: Byzantine Fault
Tolerance in the Age of Blockchains. PhD thesis, 2016.
[4] Atusa Mohammadian Casper Frimodt,
Maya Nordhild. Implementing scalability and security
features for the first development cycles of a web
application. http: // spasovski. dk/ wp-content/
uploads/ 2017/ 06/ Implementing% 20scalability%
20and% 20security% 20features. pdf , 2016.
[5] Konstantinos Christidis and Michael Devetsikiotis.
Blockchains and smart contracts for the internet of
things. IEEE Access, 4:2292–2303, 2016.
[6] Tien Tuan Anh Dinh, Ji Wang, Gang Chen, Rui Liu,
Beng Chin Ooi, and Kian-Lee Tan. BLOCKBENCH:
A framework for analyzing private blockchains. In
Proceedings of the 2017 ACM International
Conference on Management of Data, SIGMOD
Conference 2017, Chicago, IL, USA, May 14-19, 2017,
pages 1085–1100, 2017.
[7] Justin Fisher and Maxwell Henry Sanchez.
Authentication and verification of digital data
utilizing blockchain technology, u.s. patent application
no. 15/083,238., 2016.
[8] Sunny King and Scott Nadal. Ppcoin: Peer-to-peer
crypto-currency with proof-of-stake.
https: // archive. org/ details/ PPCoinPaper , 2012.
[9] Leslie Lamport, Robert Shostak, and Marshall Pease.
The byzantine generals problem. ACM Trans.
Program. Lang. Syst., 4(3):382–401, July 1982.
[10] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic
cash system. https: // bitcoin. org/ bitcoin. pdf ,
2008.
[11] Suyog S Nyati, Shivanand Pawar, and Rajesh Ingle.
Performance evaluation of unstructured nosql data
over distributed framework. In Advances in
Computing, Communications and Informatics
(ICACCI), 2013 International Conference on, pages
1623–1627. IEEE, 2013.
[12] Kyriacos E. Pavlou and Richard T. Snodgrass.
Forensic analysis of database tampering. Transactions
on Database Systems (TODS), 33(4), 2008.
[13] Judith Ramsay, Alessandro Barbesi, and Jenny
Preece. A psychological investigation of long retrieval
times on the world wide web. Interacting with
computers, 10(1):77–86, 1998.
[14] Matei Ripeanu, Ian T. Foster, and Adriana Iamnitchi.
Mapping the gnutella network: Properties of
large-scale peer-to-peer systems and implications for
system design. CoRR, cs.DC/0209028, 2002.
[15] Guy Zyskind, Oz Nathan, and Alex Pentland.
Decentralizing privacy: Using blockchain to protect
personal data. 2015 IEEE Security and Privacy
Workshops, pages 180–184, 2015.
... • Performance assessment and other limitations (Croman et al., 2016;Eyal et al., 2015;Pongnumkul et al., 2017;Scherer and Eriksson, 2017;Spasovski and Eklund, 2017;Yli-Huumo et al., 2016;Zheng et al., 2017Zheng et al., , 2016. ...
... In most cases, when using a blockchain to increase the security, the scalability and performance of the application are significantly decreased. This is due mainly to the overhead of the different consensus algorithms that secure the blockchain (Spasovski and Eklund, 2017). In the next sections, we cover other concepts and features of blockchain and how they are related to system security and are directly influenced by it. ...
... Compared to PoW, proof of stake (PoS) is an alternative and more efficient consensus mechanism, where to achieve consensus the responsible nodes to verify and publish blocks are selected proportionally to their stake in the blockchain. In cryptocurrencies means their holding of the currency (number of coins) within the blockchain network, while in non-cryptocurrency blockchains alternative approaches such as voting are required (Spasovski and Eklund, 2017). The procedure to publish blocks consists first in a participant 'locking' a number of coins in order to be allowed to publish blocks in the network. ...
Article
Full-text available
Since the launch of Bitcoin, the interest in Blockchain technology has grown over the years and has attracted many researchers. There are several proposals to improve the performance of the Blockchain, however these proposals bring a series of changes, which are difficult to implement and most of them are not compatible with existing applications. The current limitations prevent Blockchain from being used on a large scale for other types of applications or even replace the currently known electronic payment methods, making studies necessary to address these gaps and evolve the technology. This paper presents a literature review of Blockchain technology with focus in architecture, security, and performance, providing an understanding about the main features and exploring the current open gaps, in light of the main tools used in the systematic literature review methodology. A taxonomy is also proposed to support design solution and helping to classify Blockchain systems.
... • Performance assessment and other limitations (Croman et al., 2016;Eyal et al., 2015;Pongnumkul et al., 2017;Scherer and Eriksson, 2017;Spasovski and Eklund, 2017;Yli-Huumo et al., 2016;Zheng et al., 2017Zheng et al., , 2016. ...
... In most cases, when using a blockchain to increase the security, the scalability and performance of the application are significantly decreased. This is due mainly to the overhead of the different consensus algorithms that secure the blockchain (Spasovski and Eklund, 2017). In the next sections, we cover other concepts and features of blockchain and how they are related to system security and are directly influenced by it. ...
... Compared to PoW, proof of stake (PoS) is an alternative and more efficient consensus mechanism, where to achieve consensus the responsible nodes to verify and publish blocks are selected proportionally to their stake in the blockchain. In cryptocurrencies means their holding of the currency (number of coins) within the blockchain network, while in non-cryptocurrency blockchains alternative approaches such as voting are required (Spasovski and Eklund, 2017). The procedure to publish blocks consists first in a participant 'locking' a number of coins in order to be allowed to publish blocks in the network. ...
... Consensus mechanism represents the process of approving/verifying blockchain transactions. [6,45,47,49,54,56,57,59,60,63,71,73,83,84,90,[98][99][100][101][102][103][104][105][106][107][108][109][110][111][112][113][114][115] It should be mentioned here that public blockchain scalability is not a singular term. It is a combination of various parameters, and these parameters are interdependent. ...
Article
Blockchain technology is fast becoming the most transformative technology of recent times and has created hype and optimism, gaining much attention from the public and private sectors. It has been widely deployed in decentralized crypto currencies such as Bitcoin and Ethereum. Bitcoin is the success story of a public blockchain application that propelled intense research and development into blockchain technology. However, scalability remains a crucial challenge. Both Bitcoin and Ethereum are encountering low-efficiency issues with low throughput, high transaction latency, and huge energy consumption. The scalability issue in public Blockchains is hindering the provision of optimal solutions to businesses and industries. This paper presents a systematic literature review (SLR) on the public blockchain scalability issue and challenges. The scope of this SLR includes an in-depth investigation into the scalability problem of public blockchain, associated fundamental factors, and state-of-art solutions. This project managed to extract 121 primary papers from major scientific databases such as Scopus, IEEE explores, Science Direct, and Web of Science. The synthesis of these 121 articles revealed that scalability in public blockchain is not a singular term. A variety of factors are allied to it, with transaction throughput being the most discussed factor. In addition, other interdependent vita factors include storages, block size, number of nodes, energy consumption, latency, and cost. Generally, each term is somehow directly or indirectly reliant on the consensus model embraced by the blockchain nodes. It is also noticed that the contemporary available consensus models are not efficient in scalability and thus often fail to provide good QoS (throughput and latency) for practical industrial applications. Our findings exemplify that the Internet of Things (IoT) would be the leading application of blockchain in industries such as energy, finance, resource management, healthcare, education, and agriculture. These applications are, however, yet to achieve much-desired outcomes due to scalability issues. Moreover, Onchain and offchain are the two major categories of scalability solutions. Sagwit, block size expansion, sharding, and consensus mechanisms are examples of onchain solutions. Offchain, on the other hand, is a lighting network.
... Performance studies for blockchains [21], [37], [38], [46] usually follow common distributed system testing practices, keeping as many parameters as possible constant to obtain the best like-for-like comparison around variability in resource demand, throughput and/or transaction latency. In these studies, it is easy to choose an experimental set-up that will bias for (or against) a given blockchain framework, so while such studies are self-contained, it is difficult to draw conclusions about the performance of different blockchain systems between them. ...
Preprint
Full-text available
This paper examines the feasibility of blockchain solutions for national and transnational business-to-business and business-to-government (B2B/B2G) compliance frameworks, namely a trust-less, de-centralised, self-regulating distributed ledger. In particular, the paper examines whether blockchain platforms scale to support national and transnational e-business trading. The case study looks at the resources required to operate a B2B/B2G compliance framework in two different geographic scenarios. The first considers a national scale based on Denmark, the tenth largest European country by GDP. The second scenario considers a solution at the scale of the 27-member states of the European Union (EU) (and the UK). The paper addresses the performance of blockchain solutions-two of which are Byzantine fault tolerant (BFT)-compared to a blockchain solution which deploys a centrally-authorised distributed replicated database systems-that is crash fault tolerant (CFT). Specifically, the paper measures the additional cost of the trust that results from BFT at scale compared to CFT. Index Terms-distributed ledger; blockchain; survey of system performance; distributed network scalability.
Article
The Delegated Proof of Stake (DPoS) consensus mechanism is the fastest, most effective, most decentralized, and most flexible consensus model. The DPoS consensus uses the power of stakeholders to agree to vote in resolving consensus issues in a fair and democratic manner. However, in a traditional DPoS consensus mechanism, the degree of decentralization is undefined, and the number of agent nodes is fixed in advance. In this paper, a new fixed degree of decentralization for the DPoS consensus mechanism is proposed based on the adjacency vote and the average fuzziness of vague value. Moreover, the degree of decentralization is defined and discussed. As nodes are dynamically added and withdrawn, the total number of nodes in the blockchain changes. The proposed new consensus mechanism can automatically determine the number of agent nodes to be selected, based on the degree of decentralization and the total number of nodes in the blockchain. The adjacency vote and the average fuzziness of vague value are used to select agent nodes, and this method improves the fairness and security of the blockchain. We analyze five agent nodes, selected from 15 nodes, using the balloting distribution results. The feasibility and effectiveness of our new consensus mechanism are confirmed based on two test examples.
Article
Full-text available
Blockchain is a revolutionary technology that gained widespread popularity since the emergence of cryptocurrencies. The potential uses of Blockchain surpassed digital currency into a wider space that includes the Internet of Things (IoT), security applications and smart embedded systems, among others. As the number of Blockchain users increases, several drawbacks start to emerge, since Blockchains consume excessive amounts of energy to store and manipulate data. Furthermore, the limited scalability nature of Blockchains due to their massive storage requirements might become an issue. To improve the overall performance, several challenges in the current Blockchain structure should be tackled. This paper presents a hybrid system architecture that combines the distributed nature of Blockchains with the centralized feature of servers. Users will connect to servers via personal Blockchains, while servers will share a chain of Blockchains to ensure integrity and security. This will significantly decrease the storage requirements of end-users and enhance the scalability of networks. Businesses will highly benefit from this proposed structure, since it creates a reliable scalable business model.
Conference Paper
Full-text available
Blockchain after its discovery and application to bitcoin has become a vital platform for data validation and verification across diverse sectors such as healthcare, supply chain, governance, and many others. The era of cloud computing has facilitated the access of one's data on the go making it almost impossible to lose data as your work. However, the use of the cloud demands constant aces to the internet warranting the relevance of the dew computing paradigm with terms to give access to one's data locally without the use of the internet and then updating the document on the cloud based on the internet restoration. In this paper, we seek to conduct a review of the above areas of blockchain and dew computing drawing the need for the integration of both technologies. Keywords-blockchain, cloud computing, dew computing, public blockchain, private blockchain, proof of work, proof of stake, depreciated proof of stake.
Article
Full-text available
Blockchain technologies are taking the world by storm. Public blockchains, such as Bitcoin and Ethereum, enable secure peer-to-peer applications like crypto-currency or smart contracts. Their security and performance are well studied. This paper concerns recent private blockchain systems designed with stronger security (trust) assumption and performance requirement. These systems target and aim to disrupt applications which have so far been implemented on top of database systems, for example banking, finance applications. Multiple platforms for private blockchains are being actively developed and fine tuned. However, there is a clear lack of a systematic framework with which different systems can be analyzed and compared against each other. Such a framework can be used to assess blockchains' viability as another distributed data processing platform, while helping developers to identify bottlenecks and accordingly improve their platforms. In this paper, we first describe BlockBench, the first evaluation framework for analyzing private blockchains. It serves as a fair means of comparison for different platforms and enables deeper understanding of different system design choices. Any private blockchain can be integrated to BlockBench via simple APIs and benchmarked against workloads that are based on real and synthetic smart contracts. BlockBench measures overall and component-wise performance in terms of throughput, latency, scalability and fault-tolerance. Next, we use BlockBench to conduct comprehensive evaluation of three major private blockchains: Ethereum, Parity and Hyperledger Fabric. The results demonstrate that these systems are still far from displacing current database systems in traditional data processing workloads. Furthermore, there are gaps in performance among the three systems which are attributed to the design choices at different layers of the software stack.
Conference Paper
Full-text available
Various organizations are dependent on structured database like Oracle, MySQL etc. but these database systems do not harness the requirements of all organizations like scalability, availability etc. When data and number of requests increases, structure database cannot handle huge data and requests efficiently. One of the solution to overcome these issues is to shift datacenters on NoSQL unstructured databases. In this paper we explain few NoSQL unstructured databases and present performance analysis of MongoDB. We compare the time required to insertion in different databases as well as searching with different number of threads in database with different number of entries. This work also studies the importance of the Sharding and Configuration of the cluster for MongoDB.
Article
Full-text available
Cancer is a complex disease resulting from alterations of multiple signaling networks. Cancer networks have been identified as scale-free networks and may contain a functionally important key player called a hub that is linked to a large number of interactors. Since a hub can serve as a biological marker in a given network, targeting the hub could be an effective strategy for enhancing the efficacy of cancer treatment. Chemotherapies and radiotherapies are generally used to treat tumors not amenable to resection, and target single or multiple molecules associated with hubs. However, these therapies may unexpectedly induce the resistance of cancer cells to drugs and radiation. Cancer cells can overcome therapy-induced damage via the activation of back-up signaling pathways and flexible modulation of affected networks. These activities are considered to be the main reasons for chemoresistance and radioresistance, and subsequent failure of cancer therapies. Much effort is required to identify the key molecules that control the modulation of signaling networks in response to drugs and radiation. Network-based therapy that affects network flexibility, including rewired network structures and hub molecules in these networks, could minimize the occurrence of side-effects and be a promising strategy for enhancing the therapeutic efficacy of cancer treatments. This review is intended to offer an overview of current research efforts including ones focused on cancer-associated complex networks, their modulation in response to cancer therapy, and further strategies targeting networks that may improve cancer treatment efficacy.
Conference Paper
Full-text available
Proof-of-Work (PoW), a well-known principle to ration resource access in client-server relations, is about to experience a renaissance as a mechanism to protect the integrity of a global state in distributed transaction systems under decentralized control. Most prominently, the Bitcoin cryptographic currency protocol leverages PoW to 1) prevent double spending and 2) establish scarcity, two essential properties of any electronic currency. This paper asks the important question whether this approach is generally viable. Citing actual data, it provides a first cut of an answer by estimating the resource requirements, in terms of operating cost and ecological footprint, of a suitably dimensioned PoW infrastructure and comparing them to three attack scenarios. The analysis is inspired by Bitcoin, but generalizes to potential successors, which fix Bitcoin’s technical and economic teething troubles discussed in the literature.
Conference Paper
Blockchain technologies are taking the world by storm. Public blockchains, such as Bitcoin and Ethereum, enable secure peer-to-peer applications like crypto-currency or smart contracts. Their security and performance are well studied. This paper concerns recent private blockchain systems designed with stronger security (trust) assumption and performance requirement. These systems target and aim to disrupt applications which have so far been implemented on top of database systems, for example banking, finance and trading applications. Multiple platforms for private blockchains are being actively developed and fine tuned. However, there is a clear lack of a systematic framework with which different systems can be analyzed and compared against each other. Such a framework can be used to assess blockchains' viability as another distributed data processing platform, while helping developers to identify bottlenecks and accordingly improve their platforms. In this paper, we first describe BLOCKBENCH, the first evaluation framework for analyzing private blockchains. It serves as a fair means of comparison for different platforms and enables deeper understanding of different system design choices. Any private blockchain can be integrated to BLOCKBENCH via simple APIs and benchmarked against workloads that are based on real and synthetic smart contracts. BLOCKBENCH measures overall and component-wise performance in terms of throughput, latency, scalability and fault-tolerance. Next, we use BLOCKBENCH to conduct comprehensive evaluation of three major private blockchains: Ethereum, Parity and Hyperledger Fabric. The results demonstrate that these systems are still far from displacing current database systems in traditional data processing workloads. Furthermore, there are gaps in performance among the three systems which are attributed to the design choices at different layers of the blockchain's software stack. We have released BLOCKBENCH for public use.
Article
Motivated by the recent explosion of interest around blockchains, we examine whether they make a good fit for the Internet of Things (IoT) sector. Blockchains allow us to have a distributed peer-to-peer network where non-trusting members can interact with each other without a trusted intermediary, in a verifiable manner. We review how this mechanism works and also look into smart contracts-scripts that reside on the blockchain that allow for the automation of multi-step processes. We then move into the IoT domain, and describe how a blockchain-IoT combination: 1) facilitates the sharing of services and resources leading to the creation of a marketplace of services between devices and 2) allows us to automate in a cryptographically verifiable manner several existing, time-consuming workflows. We also point out certain issues that should be considered before the deployment of a blockchain network in an IoT setting: from transactional privacy to the expected value of the digitized assets traded on the network. Wherever applicable, we identify solutions and workarounds. Our conclusion is that the blockchain-IoT combination is powerful and can cause significant transformations across several industries, paving the way for new business models and novel, distributed applications.
Article
A peer-to-peer crypto-currency design derived from Satoshi Nakamoto's Bitcoin. Proof-of-stake replaces proof-of-work to provide most of the network security. Under this hybrid design proof-of-work mainly provides initial minting and is largely non-essential in the long run. Security level of the network is not dependent on energy consumption in the long term thus providing an energy-efficient and more cost-competitive peer-to-peer crypto-currency. Proof-of-stake is based on coin age and generated by each node via a hashing scheme bearing similarity to Bitcoin's but over limited search space. Block chain history and transaction settlement are further protected by a centrally broadcasted checkpoint mechanism.
Article
A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution. Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending. We propose a solution to the double-spending problem using a peer-to-peer network. The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power. As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers. The network itself requires minimal structure. Messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone.
Article
Random networks with complex topology are common in Nature, describing systems as diverse as the world wide web or social and business networks. Recently, it has been demonstrated that most large networks for which topological information is available display scale-free features. Here we study the scaling properties of the recently introduced scale-free model, that can account for the observed power-law distribution of the connectivities. We develop a mean-field method to predict the growth dynamics of the individual vertices, and use this to calculate analytically the connectivity distribution and the scaling exponents. The mean-field method can be used to address the properties of two variants of the scale-free model, that do not display power-law scaling.