Conference PaperPDF Available

Analysis of the Possibilities for Improvement of BlockChain Technology

Conference Paper

Analysis of the Possibilities for Improvement of BlockChain Technology

XXVI ТЕЛЕКОМУНИКАЦИОНИ ФОРУМ ТЕЛФОР 2018
2018 26th Telecommunications Forum (TELFOR)
Authors
Аутори
TELFOR 2018
ТЕЛФОР 2018
Papers
Радови
Copyright and Reprint Permission: Abstracting is permitted with credit to the source. Libraries are permitted to photocopy beyond the
limit of U.S. copyright law for private use of patrons those articles in this volume that carry a code at the bottom of the first page,
provided the per-copy fee indicated in the code is paid through Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923.
For reprint or republication permission, email to IEEE Copyrights Manager at pubs-permissions@ieee.org. All rights reserved.
Copyright ©2018 by IEEE.
Technical inquiries: TELFOR Technical support, tel: +381 11 3221419, , fax: +381 11 3218 399, e-mail: office@telfor.rs
Proceedings of Papers
Зборник радова
Organizers:
School of Electrical
Engineering,
University of Belgrade
Telecommunications
Society
IEEE Part Number:
CFP1898P-CDR
ISBN: 978-1-5386-7170-2
Belgrade, Serbia, November, 20-21, 2018
Reviewers
Рецензенти

TELFOR 2018
&RPPLWWHHV2GERUL
6WHHULQJ&RPPLWWHH8SUDYQLRGERU
3URI'UĈRUÿH3DXQRYLü&KDLU3UHGVHGQLN76'7(7)%HOJUDGH6HUELD
3URI'U0LOR7RPDãHYLü'HDQ'HNDQ(7)%HOJUDGH6HUELD
3URI'U$OHNVDQGDU1HãNRYLü&KDLU3UHGVHGQLN73&(7)%HOJUDGH6HUELD
3URI'U/MLOMDQD0LOLü&KDLU3UHGVHGQLN2UJ&RPPLWWHH,03(7)%HOJUDGH6HUELD
3URI'U,ULQL5HOMLQ9LFH&KDLU3RWSUHGVHGQLN73&(7)%HOJUDGH6HUELD
3URI'U9HUD0DUNRYLü&KDLU,(((606HFWLRQ()1,ã6HUELD
7HFKQLFDO3URJUDP&RPPLWWHH73&3URJUDPVNLRGERU
3URI'U$OHNVDQGDU1HãNRYL&KDLU3UHGVHGQLN(7)%HOJUDGH6HUELD
3URI'U,ULQL5HOMLQ9LFH&KDLU3RWSUHGVHGQLN(7)%HOJUDGH6HUELD
'RFHQW'U-HOHQDûHUWLü(7)%HOJUDGH6HUELD
3URI'U9ODGR'HOLü)711RYL6DG6HUELD
3URI'U'XãDQ'UDMLü(7)%HOJUDGH6HUELD
3URI'U9XMR'UQGDUHYLü(7)%HOJUDGH6HUELD
$FDGHPLFLDQ3URI'U$QWRQLMHĈRUÿHYLü6$18(7)%HOJUDGH6HUELD
3URI'U-RYDQĈRUÿHYLü(7)%HOJUDGH6HUELD
3URI'U1DWDãD*RVSLü6)%HOJUDGH6HUELD
3URI'U'HMDQ*YR]GLü(7)%HOJUDGH6HUELD
3URI'U3UHGUDJ,YDQLã(7)%HOJUDGH6HUELD
3URI'U%UDQNR.ROXQGåLMD(7)%HOJUDGH6HUELD
'U1HQDG.UDMQRYLü'776%HOJUDGH6HUELD
3URI'U0LURVODY/XWRYDF$(66%HOJUDGH6HUELD
3URI'U0LRPLU0LMLü(7)%HOJUDGH6HUELD
3URI'U/MLOMDQD0LOLü,03(7)%HOJUDGH6HUELD
3URI'U1DWDãD1HãNRYLü(7)%HOJUDGH6HUELD
3URI'U=RULFD1LNROLü()1Lã6HUELD
3URI'UĈRUÿH3DXQRYLü(7)%HOJUDGH6HUELD
3URI'U3UHGUDJ3HMRYLü(7)%HOJUDGH6HUELD
3URI'U9ODGLPLU3HWURYLü76%HOJUDGH6HUELD
3URI'U*UR]GDQ3HWURYLü(7)%HOJUDGH6HUELD
3URI'U0LOND3RWUHELü(7)%HOJUDGH(7)
3URI'U0LRGUDJ3RSRYLü(7)%HOJUDGH6HUELD
3URI'U-HOHQD3RSRYLü%RåRYLü(7)%HOJUDGH6HUELD
3URI'U-HOLFD3URWLü(7)%HOJUDGH6HUELD
3URI'U%UDQLPLU5HOMLQ(7)%HOJUDGH6HUELD
3URI'U$OHNVDQGUD6PLOMDQLü(7)%HLJUDG6HUELD
3URI'U9RMLQâHQN)711RYL6DG6HUELD
3URI'U'UDJDQDâXPDUDF3DYORYLü(7)%HOJUDGH6HUELD
'U9ODGLFD7LQWRU5$7(/6HUELD
3URI'U0LOR7RPDãHYLü(7)%HOJUDGH6HUELD
3URI'U$EGDOOD$EGXOJDGHU8QLY/LE\D
3URI'UĈXUDÿ%XGLPLU8QLY:HVWPLQVWHU/RQGRQ8.
3URI'U=RUDQ9HOMRYLü(7)3RGJRULFD0RQWHQHJUR

3URI'U%UDQND9XþHWLü8QLY6LGQHM$XVWUDOLD
3URI'U2FWDYLDQ)UDWX8QLY3ROLWHKQLFD%XFKDUHVW5RPDQLD
3URI'U/LOMDQD*DYULORYVND8.,06NRSMH0DNHGRQLD
'U$OH[DQGHU*HOPDQ,(((&RP6RF86$
'U$SRVWRORV*HRUJLDGLV+HULRW:DWW8QLYHUVLW\(GLQEXUJK6FRWODQG8.
3URI'U6LPRQD+DOXQJD8QLY3ROLWHKQLFD%XFKDUHVW5RPDQLD
3URI'U7RQL-DQHYVNL8.,06NRSMH0DNHGRQLD
3URI'U9HQFHVODY.DIHGåLVNL8.,06NRSMH0DNHGRQLD
3URI'U,YR.RVWLü(7)3RGJRULFD0RQWHQHJUR
'U*HRUJH.RXWLWDV,QWHUQDWLRQDO+HOOHQLF8QLYHULVW\7KHVVDORQLNL*UHHFH
3URI'U5ROI.UDHPHU,+30LFURHOHFWURQLFV)UDQNIXUW*HUPDQ\
'U0LORã.UVWLü,+30LFURHOHFWURQLFV)UDQNIXUW*HUPDQ\
'RFHQW'U'XãNR/XNDþ8QLYHUVLW\RI$SSOLHG6FLHQFHV.ROQ*HUPDQ\
3URI'U-DQ0LNNHOVHQ$DOERUJ8QLYHUVLW\'HQPDUN
3URI'U0LOLFD3HMDQRYLüĈXULãLü(7)3RGJRULFD0RQWHQHJUR
3URI'U,JRU5DGXVLQRYLü(7)3RGJRULFD0RQWHQHJUR
3URI'U=E\QHN5DLGD'HSW5DGLR(O%UQR&]HFK5HSXEOLF
3URI'U.XUW5LFKWHU7HFK8QLY*UD]$XVWULD
3URI'U6KHULI:HOVHQ6KDNHU.XDQJ&KL,QVWRI$GY7HFKQRORJ\&KHQ]KHQ&KLQD
3URI'U=RUDQ6WDPHQNRYLü,+30LFURHOHFWURQLFV)UDQNIXUW*HUPDQ\
3URI'U+DQQHV7RSIHU7HFK8QLY,OPHQDX*HUPDQ\3URI
'U,RQ7XWDQHVFX)DF(&&8QLYRI3LWHVWL5RPDQLD
3URI'U0DWHM=DMF8QLY/MXEOMDQD6ORYHQLD
6FLHQWLILF&RPPLWWHH1DXþQLRGERU
3URI'U/MLOMDQD0LOLü,03(7)%HOJUDGH6HUELD
3URI'U'XãDQ'UDMLü(7)%HOJUDGH6HUELD
)LOLS%DQNRYLü7HOHNRP6HUELD
3URI'U0LODQ%MHOLFD(7)%HOJUDGH6HUELD
'U'UDJDQ%RJRMHYLü76%HOJUDGH6HUELD
3URI'U'UDJDQ%RMLü(7)%HOJUDGH6HUELD
3URI'U=RUDQ%RMNRYLü6)%HOJUDGH6HUELD
3URI'UĈXUDÿ%XGLPLU8QLY:HVWPLQVWHU/RQGRQ8.
3URI'U9ODGR'HOLü)711RYL6DG6HUELD
'U'HMDQ'UDMLü,ULWHO(7)%HOJUDGH6HUELD
3URI'U-RYDQĈRUÿHYLü(7)%HOJUDGH6HUELD
$FDGHPLFLDQ3URI'U$QWRQLMHĈRUÿHYLü(7)6$18%HOJUDGH6HUELD
/MLOMDQDĈRUÿHYLü7HOHNRP6HUELD
3URI'U*RUDQĈRUÿHYLþ()1Lã6HUELD
0LOLYRMHäXQLü76%HOJUDGH6HUELD
3URI'U2FWDYLDQ)UDWX8QLY3ROLWHKQLFD%XFKDUHVW5RPDQLD
3URI'U/LOMDQD*DYULORYVND8.,06NRSMH0DNHGRQLD
'U$OH[DQGHU*HOPDQ,(((&RP6RF86$
'U$SRVWRORV*HRUJLDGLV+HULRW:DWW8QLYHUVLW\(GLQEXUJK6FRWODQG8.
3URI'U1DWDãD*RVSLü6)%HOJUDGH6HUELD
3URI'U'HMDQ*YR]GLü(7)%HOJUDGH6HUELD
3URI'U6LPRQD+DOXQJD8QLY3ROLWHKQLFD%XFKDUHVW5RPDQLD
3URI'U3UHGUDJ,YDQLã(7)%HOJUDGH6HUELD
3URI'U7RQL-DQHYVNL8.,06NRSMH0DNHGRQLD
'U0LODQ-DQNRYLü76%HOJUDGH6HUELD
0U0LKDLOR-RYDQRYLü*RY6HUELD
3URI'U9HQFHVODY.DIHGåLVNL8.,06NRSMH0DNHGRQLD

3URI'U9ODGLPLU.DWLü)711RYL6DG6HUELD
'UDJDQ0.RYDþHYLü,5,7(/%HOJUDGH6HUELD
'U0LODQĈ.RYDþHYLü6$*$%HOJUDGH6HUELD
3URI'U,YR.RVWLü(7)3RGJRULFD0RQWHQHJUR
'U*HRUJH.RXWLWDV,QWHUQDWLRQDO+HOOHQLF8QLYHULVW\7KHVVDORQLNL*UHHFH
3URI'U5ROI.UDHPHU,+30LFURHOHFWURQLFV)UDQNIXUW*HUPDQ\
'U0LORã.UVWLü,+30LFURHOHFWURQLFV)UDQNIXUW*HUPDQ\
'U-RVLS/RULQF])(6%8QLYRI6SOLW&URDWLD
'U'XãNR/XNDþ8QLYHUVLW\RI$SSOLHG6FLHQFLHV.ROQ*HUPDQ\
3URI'U0LURVODY/XWRYDF$(66%HOJUDGH6HUELD
3URIGU9HOMNR0LOXWLQRYLü(7)%HOJUDGH6HUELD
3URI'U0LRPLU0LMLü(7)%HOJUDGH6HUELD
3URI'U-DQ+0LNNHOVHQ$DOERUJ8QLYHUVLW\'HQPDUN
3URI'U%UDWLVODY0LORYDQRYLü()1Lã6HUELD
3URI'U9ODGLPLU0LORãHYLü)711RYL6DG6HUELD
-XOLMDQD0LUþHYVNL7HOHFRPPXQLFDWLRQV6RFLHW\%HOJUDGH
,YDQ1DGRU7HOHFRPPXQLFDWLRQV6RFLHW\%HOJUDGH
=RULFD1HVWRURYLü7HOHNRP6HUELD
3URI'U$OHNVDQGDU1HãNRYLü(7)%HOJUDGH6HUELD
3URI'U1DWDãD1HãNRYLü(7)%HOJUDGH6HUELD
3URI'U%RãNR1LNROLü(7)%HOJUDGH6HUELD
3URI'U=RULFD1LNROLü()1Lã6HUELD
3URI'UĈRUÿH3DXQRYLü(7)%HOJUDGH6HUELD
3URI'U0LOLFD3HMDQRYLüĈXULãLü(7)3RGJRULFD0RQWHQHJUR
3URI'U9ODGLPLU3HWURYLü76%HOJUDGH6HUELD
3URI'U*UR]GDQ3HWURYLü(7)%HOJUDGH6HUELD
'U3UHGUDJ3HWURYLü,5,7(/%HOJUDGH6HUELD
$FDGHPLFLDQ3URI'U'HMDQ3RSRYLü(7)6$18%HOJUDGH6HUELD
3URI'U0LUMDQD3RSRYLü(7)%HOJUDGH6HUELD
3URI'U0LRGUDJ3RSRYLü(7)%HOJUDGH6HUELD$V
3URI'U0LOND3RWUHELü(7)%HOJUDGH6HUELD
3URI'U-HOLFD3URWLü(7)%HOJUDGH6HUELD
3URI'U-RYDQ5DGXQRYLü(7)%HOJUDGH6HUELD
3URI'U,JRU5DGXVLQRYLü(7)3RGJRULFD0RQWHQHJUR
3URI'U=E\QHN5DLGD'HSW5DGLR(O%UQR&]HFK5HSXEOLF
3URI'U%UDQLPLU5HOMLQ(7)%HOJUDGH6HUELD
3URI'U,ULQL5HOMLQ(7)%HOJUDGH6HUELD
3URI'U.XUW5LFKWHU7HFK8QLY*UD]$XVWULD
3URI'U0LUMDQD6LPLü(7)%HOJUDGH6HUELD
0RPþLOR6LPLü7HOHFRPPXQLFDWLRQV6RFLHW\%HOJUDGH
3URI'U/D]DU6DUDQRYDF(7)%HOJUDGH6HUELD
3URI'U3HWDU6SDOHYLü)DNXOWHWWHKQLþNLKQDXND.RVRYVND0LWURYLFD6HUELD
3URI'U=RUDQ6WDPHQNRYLü,+30LFURHOHFWURQLFV)UDQNIXUW*HUPDQ\
3URI'U6KHULI:HOVHQ6KDNHU.XDQJ&KL,QVWRI$GY7HFKQRORJ\6KHQ]KHQ&KLQD
0LODQ6LPLü7HOHNRP6HUELD
3URI'U1HQDG6LPLü(7)%HOJUDGH6HUELD
3URI'U$OHNVDQGUD6PLOMDQLü(7)%HOJUDGH6HUELD
3URI'U0LUMDQD6WRMDQRYLü6)%HOJUDGH6HUELD
3URI'U=ODWDQ6WRMNRYLü(7)%HOJUDGH6HUELD
3URI'U9RMLQâHQN)711RYL6DG6HUELD
0U,YDQ7HOHþNL761RYL6DG6HUELD
3URI'U0LRGUDJ7HPHULQDF)711RYL6DG6HUELD

3URI'U0LOR7RPDãHYLü(7)%HOJUDGH6HUELD
3URI'U+DQQHV7RSIHU7HFK8QLY,OPHQDX*HUPDQ\
3URI'U'HMDQ7RãLü(7)%HOJUDGH6HUELD
3URI'UäHOMHQ7USRYVNL)711RYL6DG6HUELD
3URI'U=RUDQ9HOMRYLü(7)3RGJRULFD0RQWHQHJUR
3URI'U%UDQND9XþHWLü8QLY6LGQHM$XVWUDOLMD
3URI'U0DWHM=DMF8QLY/MXEOMDQD6ORYHQLD
2UJDQL]LQJ&RPPLWWHH2UJDQL]DFLRQLRGERU
3URI'U/MLOMDQD0LOLü&KDLU3UHGVHGQLN(7),03%HOJUDGH6HUELD
'RFHQW'U-HOHQDûHUWLü7HFKQLFDO6HFUHWDU\(7)%HOJUDGH6HUELD
3URI'U'XãDQ'UDMLü(7)%HOJUDGH6HUELD
3URI'U0LURVODY/XWRYDF$(66%HOJUDGH6HUELD
,YDQ1DGRU7HOHFRPPXQLFDWLRQV6RFLHW\%HOJUDGH6HUELD
'DQND'HVSRWRYLü(7)%HOJUDGH6HUELD
3URI'U0LODQ%MHOLFD(7)%HOJUDGH6HUELD
'U1HQDG.UDMQRYLü(7)%HOJUDGH6HUELD
'RF'U0ODGHQ.RSULYLFD(7)%HOJUDGH6HUELD
,QWHUQHW6XSSRUW,QWHUQHWSRGUãND
*RUGDQ5XåLü5&(7)%HOJUDGH6HUELD
0LUNR.LURYLü5&(7)%HOJUDGH6HUELD
ĈRUÿH6DUDþ(7)%HOJUDGH6HUELD
3UHVV0HGLD
=RULFD3DQLü76%HOJUDGH6HUELD
'DQND'HVSRWRYLü(7)%HOJUDGH6HUELD
6HFWLRQ&RRUGLQDWRUV.RRUGLQDWRULVHNFLMD
3URI'U9ODGR'HOLü3ROLF\5HJXODWRU\$VSHFWVDQG6HUYLFHVLQ7HOHFRPPXQLFDWLRQV
'U9ODGLFD7LQWRU3ROLF\5HJXODWRU\$VSHFWVDQG6HUYLFHVLQ7HOHFRPPXQLFDWLRQV
3URI'U*UR]GDQ3HWURYLü7HOHFRPPXQLFDWLRQV1HWZRUNV
3URI'U$OHNVDQGUD6PLOMDQLü7HOHFRPPXQLFDWLRQV1HWZRUNV
'U1HQDG.UDMQRYLü7HOHFRPPXQLFDWLRQV1HWZRUNV
3URI'U$OHNVDQGDU1HãNRYLü5DGLR&RPPXQLFDWLRQV
3URI'U1DWDãD1HãNRYLü5DGLR&RPPXQLFDWLRQV
'RFHQW'U0ODGHQ.RSULYLFD0RELOHDQG:LUHOHVV1HWZRUNV
3URI'U'XãDQ'UDMLü&RPPXQLFDWLRQV6\VWHPV
3URI'U=RULFD1LNROLü&RPPXQLFDWLRQV6\VWHPV
3URI'U3UHGUDJ,YDQLã&RPPXQLFDWLRQV6\VWHPV
3URI'U%UDQLPLU5HOMLQ6LJQDO3URFHVVLQJ
3URI'U'UDJDQDâXPDUDF3DYORYLü6LJQDO3URFHVVLQJ
'RF'U-HOHQDûHUWLü6LJQDO3URFHVVLQJ
3URI'U'HMDQ*YR]GLü2SWLFDO&RPPXQLFDWLRQV
3URI'U0LRGUDJ3RSRYLü$SSOLHG(OHFWURQLFV
3URI'U9XMR'UQGDUHYLü$SSOLHG(OHFWURQLFV
3URI'U-HOHQD3RSRYLü%RåRYLü$SSOLHG(OHFWURQLFV
3URI'U%UDQNR.ROXQGåLMD$SSOLHG(OHFWURPDJQHWLFV
3URI'U,ULQL5HOMLQ0XOWLPHGLD
3URI'U0LRPLU0LMLü0XOWLPHGLD

3URI'U0LOR7RPDãHYLü6RIWZDUH7RROVDQG$SSOLFDWLRQV
3URI'U0LURVODY/XWRYDF6RIWZDUH7RROVDQG$SSOLFDWLRQV
3URI'U1DWDãD1HãNRYLü6WXGHQW6HFWLRQ
3URI'U0LOND3RWUHELü6WXGHQW6HFWLRQ
26th Telecommunications forum TELFOR 2018 Serbia, Belgrade, November 20-21, 2018.
978-1-5386-7171-9/18/$31.00 ©2018 IEEE
Abstract Bitcoin and Smart Contract are the first major
applications of the BlockChain technology. But, with
increasing the number of transactions, the process of
verification on every transaction is very slow. This is the
reason for a third major innovation called a BlockChain
scaling. The scalability is a process of taking certain steps in
accelerating the performing of transactions in this new
technology.
In this paper we analyze the possibilities for BlockChain
scalability and we examine the advantages and disadvantages
of the proposed solutions.
Keywords Bitcoin, BlockChain, cryptocurrency, double
spending, scalability, SmartContact.
I. INTRODUCTION
ITCOIN is a peer-to-peer version of the electronic cash
and it is the first major application of BlockChain,
for direct online payments from one party to another
without the need of trusted third party. Transactions with
this cryptocurrency are secured by cryptography. In order
to become part of the bitcoin peer-to-peer network it is
necessary to install the open source program that
implements this new protocol [1].
Smart Contract is the other major application of
BlockChain which is an agreement of exchanging a value
or assets between two owners based on a set of conditions,
which can agree between themselves through the
BlockChain [2]. Some of their applications are described
in [3].
Since the process of verification on every transaction is
very slow, there is a need for a third major innovation
called a BlockChain scaling. A scaled BlockChain makes
the process faster by investigating:
- how many confirmations are necessary to validate
each transaction and to separate the work efficiently and
- the limits on the amount of transactions the bitcoin
network can process.
This modification does not sacrifice security of
BlockChain. A scaled BlockChain is expected to be fast
enough to power the Internet of things and go parallel with
the major payment middlemen (for example: VISA and
PayPal) of the banking world [4].
The rest of the paper is organized on the following way.
This research was partially supported by Faculty of Computer Science
and Engineering at the University "Ss Cyril and Methodius" in Skopje
Daniela Mechkaroska, Vesna Dimitrova, Aleksandra Popovska-
Mitrovikj are with the Faculty of Computer Science and Engineering,
University "Ss Cyril and Methodius" - Skopje, P.O. Box 393, R. of
Macedonia (phone: +389-71-277039;
e-mails:{daniela.mechkaroska, vesna.dimitrova,
aleksandra.popovska.mitrovikj}@finki.ukim.mk.
In Section 2, we briefly describe the first major application
of BlockChain technology, the crytocurrency called
Bitcoin and explain the double spending problem.
Analysis of several solutions for BlockChain scalability is
given in Section 3. At the end, we give some conclusions
for possibilities for improvement of BlockChain
technology.
II. BITCOIN AND THE DOUBLE SPENDING PROBLEM
A. Bitcoin
Bitcoin is a crytocurrency that has these three
characteristics: decentralization, confidence and
authentication.
Decentralized means non-existence of a central bank.
Emitters of this currency are the users or holders of
"mining" computers who verify the transactions.
Confidentiality is a property that information is not
made available or disclosed to unauthorized entities. The
confidence of this cryptocurrency is provided by public
key cryptography.
Authentication is a process that ensures and confirms a
user’s identity. Authentication in the transactions from one
to another peer in BlockChain network is made with
digital signature. Digital signatures are ways that enable
integrity, non-repudiation, and authentication in order to
access the contens of networks data transaction.
Bitcoin miners verify the transactions, put them into
blocks of transactions and decide which block is the next
one, i.e., bitcoin system groups the transactions into blocks
and connects them in BlockChain. This protocol in which
miners “mine” cryptocurrency by solving crypto-puzzles is
known as proof of work. Since, many people can create
blocks at the same time, which block will enter first in
BlockChain is decided by using a hash function.
A hash function is a function that takes as input a string
of arbitrary length, performs an operation on it, and returns
output data of a fixed length. In Bitcoin system hash
function is used twice. Most often SHA-256 hashes are
used and RIPEMD-160 hash is used for creating a shorter
hash for a bitcoin address.
B. The double spending problem
As mentioned in the introduction, a scaled BlockChain
makes the process faster without sacrificing security. In
the mining process, a new block is made and included in a
BlockChain approximately every 10 minutes. One
transaction is confirmed when it is included in the block
which is added to the BlockChain [5].
When the transaction is included in a block which is
distributed in BlockChain network, that transaction is
Analysis of the possibilities for improvement of
BlockChain technology
Daniela Mechkaroska, Vesna Dimitrova and Aleksandra Popovska-Mitrovikj
B
mined at depth of one block (one confirmation of the
transaction). With each new block in the BlockChain, the
depth of the existing blocks is increased by one. The
transaction is verified when the block depth is at a specific
level (six is a common number of confirmations) [6].
Double spending means using the same bitcoins more
than once. Once a transaction is confirmed, it is impossible
to double-spend it. The probability of a successful double
spend is calculated according to Poisson distribution [7]:
where
-
q
zp
λ
=
is the mean;
- z is the number of confirmations of transaction (the
number of blocks by which the honest node has an
advantage over the attacker);
- q is the attacker's percentage of Network Hash Rate
(probability the attacker finds the next block);
- p = 1 q is probability an honest node finds the next
block.
Table 1 and Fig. 1 presented the probability of a
successful double spend given by a hash rate proportion
and number of confirmations [8].
Fig. 1. The probability of a successful double spend
TABLE 1: ATTACKER SUCCESS PROBABILITY
Attacker's
% of NHR
2
conf.
4
conf.
5
conf.
6
conf.
5 % 0.01265 0.00164 0.00022 0.00003 0.000004
10 % 0.05098 0.01317 0.00346 0.00091 0.00024
15 % 0.11504 0.04423 0.01725 0.00678 0.00268
20 % 0.20393 0.10324 0.05300 0.02742 0.01425
25 % 0.31544 0.19612 0.12351 0.07836 0.04994
30 % 0.44572 0.32458 0.23913 0.17735 0.13211
35 % 0.58881 0.48446 0.40251 0.33637 0.28217
40 % 0.73640 0.66417 0.60340 0.55063 0.50398
45 % 0.87772 0.84440 0.81561 0.78979 0.76611
50 % 1 1 1 1 1
The number 6 is chosen as an assumption that an
attacker cannot possess more than 10% of the whole hash
rate and the risk of 0.1% or less can be accepted [9]. But,
for example, if the hash rate is around 40% then 90
confirmations are needed to have less than 0.1% chance
for success of the attack (an attack for double spending of
the transaction called "alternative history attack").
How does Bitcoin system handle the double spending
problem?
We present an example to explain handling with double
spending problem:
Let A has one bitcoin and he want to send it to B.
This transaction (called T1) goes to the pool of
unconfirmed transactions and wait to be
confirmed.
At the same time A sends one bitcoin to C. This
transaction (called T2) also goes into the pool and
wait for confirmation.
Let first transaction T1 is pulled out of the pool of
unconfirmed transactions. Before the transaction
is included into the BlockChain, its validity is
checked. This transaction will be valid since A
has one bitcoin and it is inserted into the
BlockChain. Now, transaction T2 is pulled out of
the pool, but it is invalid (since A has no more
bitcoins) and will not be confirmed.
If transactions T1 and T2 are validated
simultaneously, then the BlockChain has two
branches and the first one to reach the next block
of confirmations will be confirmed.
If T1 and T2 achieves the next block
simultaneously, the race for the next block
continue.
Therefore it is recommended to wait 6
confirmations for completing transaction. As, we
can see in Table 1, it is highly improbable that the
transactions will reach the next block
simultaneously more than 6 times. So, at the end
only one transaction will be confirmed.
Alternative history attack is 100% probable to
succeed if the attacker is in control of more than half
of the network hash rate. The attacker can continue
with his private fork until the moment it becomes
longer than the branch built by the honest network
because he can now generate blocks faster than the
other participants of the network [10].
0
11
!
zk
k
z
k
eq
kp
λ
λ
=



−−




III. BLOCKCHAIN SCALING
Nakamoto introduced a block size limit of 1MB for
every block in the public BlockChain. This was a security
measure, so any block over that limit would be
immediately rejected by the P2P network. This limitation
slows down the transactions and cannot keep up with the
speed of other currencies payment and credit cards.
In Table 2 is given a review of the average number of
transactions made with cryptocurrencies and standard
credit card [11]. Bitcoin has a limit of 3 to 4 transaction
per second (although theoretically process up to 7, but that
number is never being reached). This is not the situation
with private BlockChain. They can reach over 1000
transactions per second, because each node on the network
in private BlockChain uses high-quality computer with
strong bandwidth internet connection.
TABLE 2: BITCOIN AND ETHEREUM VS VISA AND PAYPAL
TRANSACTIO NS PER SECOND
Currency
Transaction per second
Bitcoin
3 to 4 transactions per second
Etherium
20 transactions per second
PayPal
193 transactions per second average
Visa
1,667 transaction per second
There are several solutions for BlockChain scalability
that have been or will be implemented. Some of the major
ones are:
Segwit
Block Size Increase
Sharding
Proof of Stake.
Segwit or segregated witness is an alternative solution
for BlockChain scalability, through increasing the number
of transactions in a block, without increasing the size of
the block. Segregated witness helps to enlarge the space
for new transactions by removing signature data from
bitcoin transactions. The proposal in segregated witness is
to remove the digital signatures and store it outside the
base transaction block. In this way "validating" part has
been separated from the "effective" part of the transaction
and more transactions can fit in a block without increasing
the block size [12].
The digital signature takes 65 percent of transaction. If
it is removed, more space will be free up in the bitcoin’s
block for more transactions. A new unit for transaction
size is introduced by Segwit. Now, the transaction is
divided in two parts: non-witness data (which must be
stored on the block like before) and witness data (which is
moved to the extended block). Non-witness data byte
counts as 4 WU (weight units) each, while witness data
byte only counts as 1 WU each. The maximum capacity
of a block is 4 kWU, which would correspond to the old
maximum block size of 1MB if no one uses Segwit. The
Segwit upgrade to the Bitcoin protocol occurred in August
2017. A new format is used by around 30 percent of
transactions [13].
According to BitMEX research the percentage of
transaction that use SegWit is given on Fig 2.
Fig. 2. Percentage of transactions that use SegWit [14]
Block Size Increase. In the bitcoin`s BlockChain the
block size is limited to a maximum of 1MB. There are
several arguments for and against increasing the size of
blocks. A major argument against block size increase is
that it will cause increased centralization.
Each connected computer on the bitcoin network is
called a node. There are two types of nodes in bitcoin
BlockChain: full nodes and lightweight (or partial) nodes.
Full nodes validate every block and transaction.
Therefore, full nodes must store a copy of the complete
BlockChain ledger locally (more than 165 GB).
The lightweight nodes do not store the complete ledger.
They use a simplified payment verification (SPV) mode
which only requires to download a copy of the block
headers of the longest proof of work chain [7].
On the other hand, a miner creates blocks in the
BlockChain that the nodes keep. Bitcoin network is
maintained by roughly 10.000 full nodes, while the
number of miners estimated to be around 100.000.
Increasing the block size makes the full nodes more
expensive to operate. This leads to less hashers running
full nodes and centralized entities would have more power,
that weakens bitcoins value proposition. Miners have
benefit from increasing of the block size, since increased
block size means more transactions per block. This will
increase the amount of transaction fees that a miner can
make from mining a block.
Sharding. One of the biggest problem for
cryptocurrencies is the speed of transaction verification.
Each full node in the network has to store the entire
BlockChain. Sharding breaks down a transaction into
shards, spreads it among the network and nodes work on
individual shards side-by-side. On this way, the overall
time taken is decreased. A normal block has a block
header and a body that contains all transactions in the
block. The Merkle root of all transactions is in the block
header. Sharding changes this into two levels of
interaction.
The first level is the transaction group which is divided
into a transaction group header and a body. Each shard has
its own group of transactions. The transaction group
header is divided in left and right part. The left part
contains: Shard ID, Pre state root (state of the shard root
before the transactions were applied), Post state root (state
of the shard root after the transactions are applied) and
Receipt root (receipt root after all the transactions in the
shard are applied). The right part is full of randomly
chosen validators who verify transactions in the shard. The
transaction group body has the transaction`s IDs of all
transactions in the shard.
The second level is the normal block chain, but here it
contains two primary roots: the state root (represents the
entire state which is broken down into shards) and the
transaction group root (contains all transactions groups
inside that block).
With Sharding many parallel transactions can happen at
the same time and therefore the performances are
increased. Each receipt of transaction can be easily
accessed via multiple Merkle trees from the Merkle root of
the transaction group. Also, the receipts are stored in a
distributed shared memory that can be seen but not
modified by other shards [15].
Zilliqa, a new BlockChain platform based on the
technology of Sharding that solves the scalability issue
faced by current BlockChain platforms like Bitcoin and
Ethereum, has announced the release of their public test
net. In Table 3 comparison of the capability of processing
transactions in Ethereum and Zilliqa is given.
TABLE 3: COMPARISON OF CAPABILITY OF PROCESSING
TRANSACTIONS IN ETHEREUM AND ZILLIQA
Number of full
nodes
Number of
transactions per
sec.
Ethereum
25000
15-20
Zilliqa
1800
1218
If the number of nodes in Zilliqa is double to 3600 the
throughput scales as well to 2488 transactions per second
[16] [17] [18].
From Table 3 it is clear that Zilliqa even with less
number of nodes is able to process much more transactions
per second than Ethereum or Bitcoin.
Proof of Stake. Most cryptocurrencies follow the proof
of work protocol, which means that miners mine
cryptocurrencies by solving crypto-puzzles using
dedicated hardware. In proof of stake protocol there are
validators instead of miners. The validator have to invest
(lock up) some of his assets as stake. Then the validator
starts validating blocks on the following way: if he sees a
block that he thinks can be added to the BlockChain, he
validates the block by putting a bet on it. If the block gets
appended to the BlockChain, the validator will receive a
reward proportional to the invested stake. If the validator
bet a malicious block, the stake he has invested will be
taken from him. Ethereum implement proof of stake
protocol using the Casper consensus algorithm [15]. The
advantage of using proof of stake protocol instead of proof
of work is that it uses considerably less energy and as a
result is more cost effective.
TABLE 4: COMPARISON OF PROOF OF WOR K AND PROOF OF STAKE
PROTOCOLS
Proof of work
Proof of stake
Energy
consumption
High
Low
Required tools
Mining
equipment
No equipment
necessary
Security
High
Untested
Decentralized
vs. Centralized
Tends to
centralize
Users can
remain in control
of their tokens
In Table 4 a comparison of some parameters of proof of
stake and proof of work protocols is given [19].
IV. CONCLUSION
One of the biggest problems in BlockChain technology
is the verification process that slows down the
transactions. In this paper we analyze the possibilities for
improvement of BlockChain without sacrificing security.
First we explained the double spending problem and
how Bitcoin system handles this problem. Then, we
considered several solutions for BlockChain scalability
and analyzed the advantages and disadvantages of the
proposed solutions.
All these BlockChain scalability solutions offer a
unique way to speed up the transactions and some of them
have already been implemented.
Our further research will be focused on examining
whether these solutions can truly solve the scalability
issue. Also, we will consider other applications of
BlockChain, for example in IoT, Machine Learning etc.
REFERENCES
[1] M. Crosby, Nachiappan, P. Pattanayak, S. Verma,V. Kalyanaraman,
"BlockChain technology: Beyond bitcoin", Applied Innovation Review,
Berkeley, Issue No.2, June 2016.
[2] https://blockgeeks.com/guides/smart-contracts/
[3] Mechkaroska D., Dimitrova V., Popovska-Mitrovikj A: A Survey on
Applications of BlockChain Technology, Proc. of the 15th International
Conference on Informatics and Information Technologies CIIT, 2018 (in
print)
[4] V. Gupta, "A Brief History of BlockChain", https://hbr.org/2017/02
/a-brief-history-of-BlockChain, February 28, 2017.
[5] https://www.buybitcoinworldwide.com/confirmations
[6] https://en.bitcoin.it/wiki/Confirmation
[7] S. Nakamoto, "Bitcoin: A peer-to-peer electronic cash system", 2008,
http://bitcoin.org/bitcoin.pdf.
[8] https://people.xiph.org/~greg/attack-success.html.
[9] M. Rosenfeld, "Analysis of hashrate-based double-spending",
arXiv:1402.2009.
[10] https://en.bitcoin.it/wiki/Irreversible-Transactions
[11] http://www.altcointoday.com/bitcoin-ethereum-vs-visa-paypal-
transactions-per-second/
[12] http://learnmeabitcoin.com/faq/segregated-witness
[13] https://cointelegraph.com/tags/segwit
[14] https://blog.bitmex.com/the-segwit-transaction-capacity-increase-
update/
[15] https://blockgeeks.com/guides/blockchain-scalability/
[16] https://www.coinbureau.com/review/zilliqa-zil/
[17] The Zilliqa team, “The Zilliqa Techical Whitepaper”,
https://docs.zilliqa.com/whitepaper.pdf, August 10, 2017.
[18] https://cryptodaily.co.uk/2018/05/zilliqa-zil-answer-blockchain-
scalability/
[19] https://cryptocurrencyhub.io/an-introduction-to-consensus-
algorithms-proof-of-stake-and-proof-of-work-cd0e1e6baf52
... It solves the problem of network security and energy consumption. Mechkaroska et al. (2018) analyzed the possibilities for scalability in blockchain technology. The verification process in the blockchain is the biggest challenge because it reduces the speed of transactions. ...
... Similarly, the user test file and performance benchmark workload can be described using the benchmark configuration file. The blockchain adaptor is responsible for starting and initializing F. Jamil et al. (Mechkaroska, Dimitrova, & Popovska-Mitrovikj, 2018) 1320 25 17-23 Bitcoin-NG (Das, 2021) 1000 600 Limited Elastico (Luu et al., 2016) 1600 711 Four times higher than bitcoin ByzCoin (Xie et al., 2019) 1008 15-20 Two times higher than bitcoin BigchainDB (McConaghy et al., 2016) 32 15-20 1000 Solida (Abraham, Malkhi, Nayak, Ren, & Spiegelman, 2016) 1000 23.6 30 the blockchain network. Moreover, the blockchain adaptor also sends the generated transaction to the client through which the workload is processed. ...
Article
Blockchain technology has revolutionized the ways of processing and storing data in terms of reliability and security. Blockchain plays a pivotal role in transferring the processing hurdle from the client-server to a decentralized and secured platform. Blockchain is deemed to be an efficient technology in a forthcoming era that would beneficiate multifarious industries. An issue that becomes a bottleneck for blockchain-based applications is their restricted ability to process in comparison to distributed database systems. In this paper, we present intelligent traffic control using a hybrid model based on the PSO-based optimization algorithm and fuzzy logic in order to improve blockchain performance. The real-time network feedback model is designed and used as an input to control the transaction traffic across the entire network in a robust way without human intervention. In order to evaluate the effectiveness of the designed model, a clinical trial service framework as a test network is implemented on top of Hyperledger Fabric. The case study is further compared with baseline network, network with fuzzy approach, and network with optimized parameter. The experiments show that the proposed model not only enhanced the network by maximizing the network throughput and minimizing the network latency. A smart contract is implemented to automate the transaction flow as per real-time data of network conditions. An open-source blockchain framework, Hyperledger Fabric, is harnessed for implementation of the experiment environment in order to signify the potential of the proposed model. The outcome of this study indicated a remarkable increase in transaction throughput (i.e., 38.5%) and a decrease in transaction latency of 40.5%. Moreover, the proposed model can easily be integrated with other existing blockchain-based performance-enhancing tools.
... Unfortunately, TPS is number declared by the blockchain founding team or tested for other blockchain systems using test networks. Also, some Blockchain provides simulators but all these numbers are not reliable until it will be seen the performance on production environment [5].The main motivation was to discover the relationship between each chain and performance and provide an overview for scholars and researchers about the current state of blockchain performance. In this paper, we will provide an overview and the current status of blockchains performance. ...
Preprint
Full-text available
0000−0002−9143−5231] , Siham Hattab 2[0000−0002−5344−046X] , and Manuel Mazzara 1[0000−0002−3860−4948] Abstract. Since the introduction of Bitcoin and Ethereum, blockchain introduced new ways to handle payment and dealing with financial transactions. From 2009 till now, several blockchain systems were developed. However, the main issue for each blockchain is to know where to use it and what the best use case fits with it. Transaction per second (TPS) and confirmation time (CT) give the possibility to evaluate the speed and performance of each blockchain. It demonstrates the speed of blockchain in processing any transaction and saving it to the ledger. This work reviews and presents the current status of the state-of-the-art blockchain performance.
... • Slow processing can affect the results in supply and demand scenarios for real-time monitoring and affects the best result for the user in terms of transactions [59]. ...
Conference Paper
Full-text available
In recent years, trends towards user-centered technology are increasing due to various social, economic, and environmental aspects. Concurrently, the success of electromobility is highly dependent on how we provide the charging facility and the security of energy-trading gateways. In this paper, we propose a modeling framework that would address all these challenges and would be ready for real-life implementation when data becomes available. The proposed model works on a two-charging station methodology, which allows us to examine the mutual benefits of vehicle users and electricity supply entities. In addition, the massive data revolutions and blockchain technology are providing enough impetus for the success of the given framework. Undoubtedly, this study is unique and should be considered a milestone to reveal directions for further studies.
Chapter
The current development of power systems requires not only a transition toward sustainable generation technologies but also—at the same time—an increase in the overall reliability in an environment of distributed automation and Local Energy Communities. After a brief introduction to the topic, the first section of the chapter studies the characteristics of monitoring, control, and forecasting infrastructure necessary for the adoption of blockchain solutions. In the second section, we analyze current problems, propose solutions to overcome the lack of data, and review different blockchain-associated services for the creation of and information exchange on monitoring services. Then, different automation techniques such as Consensus Group creation over blockchain are covered; and later with a special emphasis on “Blockchain-based Virtual Redundancy,” an automation solution based on BRILLIANT’s architecture, the chapter presents the system aimed to overcome failures in critical control and monitoring infrastructure. Finally, a short discussion about the future of blockchain-friendly smart meters opens doors to making choices that have mutually exclusive outcomes: choosing resource-efficient processes like green, renewable technologies vis-à-vis resource rationalization as the choice between creating positive environmental impact (while protecting the privacy of consumers’ data) and economic retrogression.
Chapter
A distributed consensus algorithm is at the core of what makes cryptocurrencies a decentralised ledger; they are the tools that facilitate the agreement between millions of users worldwide on what the playing rules are going to be, as well as the punishments and rewards for (dis)obeying them. The first cryptocurrency, Bitcoin, popularised proof-of-work puzzle-solving algorithm, in the form of block mining to process and validate transactions on the blockchain. However, several limitations with proof-of-work, such as enormous energy demand, significant (and increasing) computational power requirement, and lack of scalability, led blockchain enthusiasts and researchers to construct alternatives. One prominent alternative mechanism proposed is the proof-of-stake; a mechanism that does not rely on the mining power but the amount of stake owned by a node, allowing randomly selected validators to create blocks and verify blocks created by other validators. A proof-of-stake mechanism naturally results in the formation of staking pools, whereby multiple stakeholders can pool their resource to earn rewards. In this paper we explore the likely evolution of a competitive staking pool market. We pay particular attention to the importance of security. Staking pools could be subject to a range of attacks by malicious actors and so secure staking pools are essential for a well functioning proof-of-stake currency.KeywordsRansomProof-of-stakeCryptocurrenciesBlockchain
Chapter
Full-text available
Input of data for administrative healthcare workflows is generally experienced in a hybrid form of organization and production, which concerns the human labor actions and computerization infrastructure. During the COVID-19 time, many healthcare organizations found themselves limited in terms of addressing the increased supply and demand and workload generated in hospitals and other healthcare services/products. This complicated scenario has in its base of analysis both the human capability of processing the information generated by new data concerning disease, methods, and technologies to prevent COVID-19 dissemination and computed data treatment of daily new information available in order to predict the behavior of supply chains. Concerning a stage before manufacturing and logistics, and after planning and policies, there is a lacuna where public healthcare organizations need to be able to predict how their infrastructure and daily routines respond to unusual and stressful conditions. For this problem, this chapter focused on the work productivity of the bidding sector responsible for delivering services/goods to the population during 2020–21 in the State of Paraná, Brazil and how it failed to provide correct responses under abnormal conditions imposed by COVID-19.
Article
Bitcoin is the world's first decentralized digital currency. Its main technical innovation is the use of a blockchain and hash-based proof of work to synchronize transactions and prevent double-spending the currency. While the qualitative nature of this system is well understood, there is widespread confusion about its quantitative aspects and how they relate to attack vectors and their countermeasures. In this paper we take a look at the stochastic processes underlying typical attacks and their resulting probabilities of success.
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.
BlockChain technology: Beyond bitcoin
  • M Crosby
  • P Nachiappan
  • S Pattanayak
  • V Verma
  • Kalyanaraman
M. Crosby, Nachiappan, P. Pattanayak, S. Verma,V. Kalyanaraman, "BlockChain technology: Beyond bitcoin", Applied Innovation Review, Berkeley, Issue No.2, June 2016.
A Survey on Applications of BlockChain Technology
  • D Mechkaroska
  • V Dimitrova
  • A Popovska-Mitrovikj
A Brief History of BlockChain
  • V Gupta
V. Gupta, "A Brief History of BlockChain", https://hbr.org/2017/02 /a-brief-history-of-BlockChain, February 28, 2017.