Conference PaperPDF Available
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
3
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
... Every transaction ever performed has a unique and verifiable record on the blockchain. In the past few years, blockchain has operated without any issues and has been successfully utilized in both financial and nonfinancial applications [2]. ...
Conference Paper
Full-text available
The rise of Web 3.0 has created an opportunity for a more decentralized, secure, and transparent internet. Blockchain technology has emerged as a critical enabler for Web 3.0, enabling the development of decentralized applications that build trust and support secure transactions. In this study, we discuss how blockchain technology can improve Web 3.0 by leveraging properties like immutability, consensus mechanisms, and smart contracts. The decentralized nature of blockchain technology improves security and privacy, giving consumers more control over their personal data. It also provides safer and more efficient transactions and can simplify platform compatibility. By providing a transparent and secure platform, decentralized blockchain-based applications have the potential to transform a wide range of industry areas, from supply chain management to digital voting. As Web 3.0 develops, blockchain technology will play an increasingly important role in enabling new use cases and revolutionizing a wide range of businesses. We can build a better internet that is more secure, safer, and more equitable for all users by embracing blockchain technology. In this study, we will compare conventional Web 2.0 centralized systems and the decentralized nature of Web 3.0 by looking at the core ideas of Web 3.0 and the cutting-edge capabilities of blockchain.
... Blockchain is a distributed database of records or public ledger of all time stamped transactions saved in all computers in one peer-to-peer network. This is a growing list of linked blocks [1]. The blocks consist of valid transactions, a timestamp and a hash pointer as a link to the previous block in the chain. ...
Conference Paper
Full-text available
Blockchain is a growing list of linked blocks. Since each participant stores the whole list of transactions, the storage space rapidly increases. Therefore, there is a need of changing the storage concept in blockchain. There are several solutions for this problem based on network coding and secret sharing. In this paper, we propose a novel use of Shamir’s secret sharing scheme for reducing the storage cost in blockchain system.
... There is a chance that the network won't be able to handle many transactions. Visa conducts more than 1600 transactions per second, while Bitcoin can process 1-2 transactions per second and Etherium can process 20 transactions per second [26]. The adaptability of such medical care systems might be constrained by a tradeoff between storing limits and computational skill [12]. ...
Article
Due to its use in the financial sector, block chain technology has recently received a lot of attention. A growing number of researchers are becoming interested in its potential applications in the healthcare industry. This paper examines the idea of a block chain, as well as its attributes and different kinds of block chain networks. The paper also discusses how block chain technology can be used in the healthcare industry and how it can enhance the current healthcare management system. We also talk about the advantages of using block chain in the healthcare industry and the difficulties it may face.
Article
Full-text available
Blockchain is a ground-breaking technology that has changed how we manage and store protected data. It is a decentralized ledger that enables safe, open, and unchangeable record-keeping. It relies on a distributed network of nodes rather than a single central authority to check and verify transactions, guaranteeing that each entry is correct and unchangeable. Transactions in a blockchain network are grouped into blocks, which are then linked together in a chronological and immutable chain. Block size is a critical parameter in blockchain technology, which refers to the maximum size of each block in the chain that is not benchmarked yet. However, we cannot just change the block size of the blockchain. It is challenging and will create security issues. The Block size is crucial because it affects the number of transactions processed per second, the confirmation time, and overall network efficiency. The confirmation time should be faster to ensure stable earnings for the miners. Moreover, it needs help with broader applications due to high transaction fees and long verification times. We have proposed a reinforcement learning model named ROBB that can efficiently create a block considering the current network state and previous transactions. At first, the problem was converted into a reinforcement learning environment to solve using multiple reinforcement algorithms. We developed a blockchain simulator to replicate the network environment. To transform it into a reinforcement learning environment, we integrated it with OpenAI Gym. The simulator was trained by generating random transactions. Finally, we designed a reward function that enables the simulator to hold transactions and create blocks with the pending transactions when it determines that the environment is favourable. In the final results, ROBB successfully minimized the waiting time for transactions and utilized the blocks to their full potential. Additionally, it optimized the block space, building upon the findings of previous researchers. From the research we can see that our propsed models shows impressive results with 100% block utlization and 1.8s average waiting time while creating the least number of blocks.
Article
Full-text available
The accelerated development of information and communication technologies has generated a demand for data storage that is effective, transparent, immutable, and secure. Distributed ledger technology and encryption techniques such as hashing and blockchain technology revolutionised the landscape by meeting these requirements. However, blockchain must overcome obstacles such as low latency, throughput, and scalability for its full potential. Investigating blockchain's structure, types, challenges, promises, and variants is necessary to understand blockchain and its capabilities comprehensively. This paper overviews various aspects, such as emergent blockchain protocols, models, concepts, and trends. We classify blockchain variants into five essential categories, DAG, TDAG, Sharding, Consensus, and Combining methods, based on the structure each follows, and conduct a comparative analysis. In addition, we explore current research tendencies. As technology progresses, it is essential to comprehend the fundamental requirements for blockchain development.
Article
Full-text available
Blockchain technology has gained widespread popularity due to its robust security features, making it an attractive solution for various applications such as cryptocurrency, healthcare, supply chain management, and asset administration. However, limited research has been conducted on the limitations and security issues associated with blockchain technology. In this research article, we focus on the key limitations of blockchain technology, namely, throughput and storage optimization. In this work, we address these issues by designing a faster and less storage-dependent blockchain system while maintaining the security and essential features of blockchain technology. By combining the dual blockchain concept with the Interplanetary File System (IPFS), a higher number of transactions can be accommodated within a single block. This leads to amplified throughput and diminished storage requirements. IPFS is harnessed to circumvent storage limitations and enhance overall transaction throughput. Our proposed system is implemented in real-time, resulting in significantly increased throughput and reduced storage requirements. Our findings demonstrate that this system is suitable for use in both cryptocurrencies and real-life applications.
Chapter
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.
Conference Paper
Full-text available
Blockchain is a distributed database of records or public ledger of all timestamped transactions saved in all computers in one peer-to-peer network. It allows a secure and transparent transfer of digital goods including money and intellectual property. Bitcoin is the first major Blockchain innovation, a digital decentralized cryptocurrency. The public key cryptography provides the confidance of this currency. Exchanging a value or assets between two owners based on a set of conditions is included in an agreement called Smart contract. This paper is a survey about Blockchain in a peer-to-peer network. Here we describe the basic principles of Blockchain technology and its major innovations and applications.
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 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.