PF-BVM: A Privacy-aware Fog-enhanced

Blockchain Validation Mechanism

H. Baniata and A. Kertesz

University of Szeged, H-6720 Szeged, Dugonics ter 13, Hungary

Keywords:

Privacy, Fog Computing, Blockchain, IoT, Validation, Trust.

Abstract:

Blockchain technology has been successfully implemented in cryptocurrency industries, yet it is in the re-

search phase for other applications. Enhanced security, decentralization and reliability are some of the ad-

vantages of blockchain technology that represent beneﬁcial integration possibilities for computing and storage

infrastructures. Fog computing is one of the recently emerged paradigms that needs to be improved to serve

Internet of Things (IoT) environments of the future. In this paper we propose PF-BVM, a Privacy-aware Fog-

enhanced Blockchain Validation Mechanism, that aims to support the integration of IoT, Fog Computing, and

the blockchain technology. In this model the more trusted a fog node is, the higher the authority granted to

validate a block on behalf of the blockchain nodes. To guarantee the privacy-awareness in PF-BVM, we use

a blockchain-based PKI architecture that is able to provide higher anonymity levels, while maintaining the

decentralization property of a blockchain system. We also propose a concept for measuring reliability levels

of blockchain systems. We validated our proposed approach in terms of execution time and energy consump-

tion in a simulated environment. We compared PF-BVM to the currently used validation mechanism in the

Proof-of-Work (PoW) consensus algorithm, and found that PF-BVM can effectively reduce the total validation

time and total energy consumption of an IoT-Fog-Blockchain system.

1 INTRODUCTION

Fog Computing (FC) as deﬁned in (Yi et al., 2015) is

a geographically distributed computing architecture,

in which various heterogeneous devices at the edge of

network are ubiquitously connected to collaboratively

provide elastic computation, communication and stor-

age services. While according to another deﬁnition

in (Markakis et al., 2017), FC is a horizontal, physi-

cal or virtual resource paradigm that resides between

smart end-devices and traditional cloud datacenters.

FC, also known as Fog Networking and Fogging, was

introduced by Cisco in 2013, as the future of the cur-

rent Cloud Computing systems, and mostly an exten-

sion of the continuous chain of development of the

Radio Access Networks (RAN). Such integration is

usually referred to as Fog RAN (F-RAN) (Yousefpour

et al., 2019).

Blockchain is a distributed ledger technology in

the form of a distributed transactional database, se-

cured by cryptography, and governed by a consen-

sus mechanism (Beck et al., 2017), where participants

that do not fully trust each other agree on the ledger’s

content by running the consensus algorithm (Faria,

2018). In the beginning, the main aim of a blockchain

(Nakamoto et al., 2008) was to:

1. Transfer money without the Trusted Third Party

(TTP), usually required in a traditional system,

2. Reduce the fees required for performing a trans-

action,

3. Reduce the time needed to perform the transac-

tion.

As the topics of Blockchain, IoT, and FC are be-

coming more of hot research topics each year, we

needed to investigate the current research trends in

these ﬁelds. To do so, we searched for published

articles having the key words ’Fog Computing’, ’In-

ternet of Things’, and ’Blockchain’, in their titles

As presented in Figure 1, we have found that, in the

years 2018 and 2019, the number of published papers

having ’Blockchain’ keyword in their title exceeds

the number of published papers having ’Internet of

Things’ keyword in their title. As Figure 2 suggests,

we have found that most of the integration proposals

Numbers presented in the ﬁgures are gained by search-

ing in Google Scholar: Accessed on 09-November-2019

430

Baniata, H. and Kertesz, A.

PF-BVM: A Privacy-aware Fog-enhanced Blockchain Validation Mechanism.

DOI: 10.5220/0009487904300439

In Proceedings of the 10th International Conference on Cloud Computing and Services Science (CLOSER 2020), pages 430-439

ISBN: 978-989-758-424-4

Figure 1: Research trends in the ﬁelds of Fog Computing,

Internet of Things, and Blockchain, in the the period 2015-

2019.

Figure 2: Research trends concerning the integration of

Blockchain with Fog Computing and the Internet of Things

in the the period 2015-2019.

of Blockchain were performed with an IoT system,

and only a small number of approaches tried to inte-

grate the Fog computing paradigm with Blockchain.

In this paper, we propose a new Validation mech-

anism that maintains an equivalent consensus feature,

where trusted fog nodes are able to validate trans-

actions on behalf of blockchain nodes authenticated

with it. Meanwhile, all nodes are deployed for the

block conﬁrmation and mining. The proposed mech-

anism is an approach for reducing the heavy load on

the network, represented by extended validation time,

and high energy consumption. On the other hand, the

privacy-awareness property is preserved in our pro-

posed mechanism by limiting the number of network

nodes verifying a transaction generator.

The remainder of this paper is organized as fol-

lows. Section 2 presents the state of the art regard-

ing integration approaches of blockchain, IoT, and fog

computing. Secrion 3 explains the currently used val-

idation mechanism in the Proof-of-Work (PoW) al-

gorithm. Section 4 presents the motivations of our

work, the proposed Un-Reliability concept, and the

proposed framework of the PF-BVM. The experiment

model and its results are presented in section 5, while

Section 6 concludes our current and future work.

2 RELATED WORK

As FC was found a suitable paradigm to overcome

IoT limitations, authors of (Puliaﬁto et al., 2019)

highlighted six IoT application domains that may ben-

eﬁt from the use of FC paradigm such as health care

applications, vehicle applications, and smart cities.

Cisco started its own virtual Fog Data Services

platform early in 2019 (Cisco, 2019), with at least

1.00 GHz computing power, 4-GB vRAM, and 23

GB storage. Authors of (Marin-Tordera et al., 2016)

deﬁned fog nodes as mini-clouds and categorized

them according to the devices they are connected to;

’dump’ and ’smart’. Authors of (Capra et al., 2019)

surveyed the main techniques to design hardware plat-

forms able to cope with IoT requirements. They dis-

cussed power consumption and management, IO ar-

chitecture, security, memory, processing, and multi-

core enhancement.

Despite the fact that most previous works con-

sidered miners to be computationally-strong devices

relatively to other nodes, some researchers proposed

ideas where miners can be moderately strong mobile

devices too (Suankaewmanee et al., 2018).

L.Axon (Axon, 2015) and colleagues (Axon and

Goldsmith, 2016) discussed the public key infras-

tructure (PKI) concepts, and proposed a privacy-

aware Blockchain-based PKI architecture. The trust

in Blockchain is typically gained by the majority con-

sensus of a piece of information validity, and a user

verify-ability (Steem, 2017). However, the proposed

architecture in (Axon, 2015) limits the necessity of

veriﬁcation by all nodes of the network. That is, pub-

lic keys and private keys -online and ofﬂine versions-

are only registered and veriﬁed by few previously-

veriﬁed and trusted neighbours. Those keys are times-

tamped and have an expiration so that they should

be regularly replaced. Also, a user-controlled iden-

tity disclosure mechanism is built, where each user

chooses whether and when to disclose their iden-

tities or past public keys. Consequently, a PKI

in which users have total anonymity and neighbour

group anonymity is used.

A privacy-preserving carpooling system that uses

PF-BVM: A Privacy-aware Fog-enhanced Blockchain Validation Mechanism

431

a private blockchain in a vehicular fog computing

context, where the evaluation criteria were computa-

tional costs and communication overhead (Li et al.,

2018). The second paper proposed an approach for

using Blockchain to ensure the privacy of patient

medical data in Fog environment by limiting autho-

rized users accessing the patient’s medical informa-

tion (Silva et al., 2019).

Authors of (Debe et al., 2019) proposed a reputa-

tion system for fog nodes that are delivering services

to the IoT devices, using Blockchain Ethereum smart

contracts. The system suggests that IoT devices rate

fog nodes according to speciﬁc modiﬁable criteria.

Accordingly, fog nodes obtain trustworthiness value

that would indicate how reliable they are. IoT de-

vices’ credibility is also computed, according to spe-

ciﬁc contributions, for the more credible the IoT de-

vice, the more effective its evaluation is on the ﬁnal

score of evaluated fog nodes.

3 VALIDATION IN A PoW-BASED

BLOCKCHAIN SYSTEM

The probability that different nodes solving the puzzle

at the same time is quite low yet existing. Such event

is solved by Forking. Once a fork appears, two differ-

ent versions of the blockchain will be considered valid

to two different groups of nodes. After a while, the

distribution of the two versions through the network

will result in the consensus algorithm accrediting the

longer chain, and withdrawing the shorter. How-

ever, each consensus algorithm has different forking

protocol. Proof-of-Work (PoW) algorithm, speciﬁ-

cally, is used in Bitcoin, Litecoin, and Ethereum plat-

forms (Andrew Tar, 2018). Other examples of used

consensus algorithms include versions of Proof-of-

Stack (PoS), Distributed Proof-of-Stack (DPoS), and

Practical Byzantine Fault Tolerance (PBFT) (Zee Ali,

2019).

Transaction validation is the process of checking

whether the generator of the transaction (i.e. sender)

has sufﬁcient amount of money to spend, or determin-

ing whether the new transaction conforms to the net-

work or consensus algorithm rules. This is usually

performed in the nodes’ level by checking the com-

panion signature of a transaction; if the signature is

valid, the transaction is accepted. The checking pro-

cess includes comparing the amount of money the

sender is willing to spend, to the amount of money

registered in the sender’s wallet in the blockchain,

which is held locally within the nodes’ memory (Chen

et al., 2018). Once the transaction is validated by a

miner, it is held in the miner’s mempool until it is

processed and added to a new block, hence conﬁrmed

(chytrik, 2017). When a whole block is conﬁrmed, the

miner broadcasts it to all nodes in the network. All

recipient nodes then validate all transactions within

the new block again (Nakamoto, 2008), and check if

the solution of the puzzle was correct. If the block

is valid in terms of transactions and puzzle solution,

it is conﬁrmed and added as the head of the locally

saved blockchain, otherwise the block is ignored and

the block generator is reported as malicious (Macdon-

ald et al., 2017). However, as clariﬁed in (Nguyen

and Kim, 2018), the puzzle condition applies in

most proof-based consensus algorithms such as the

Proof of Work (PoW), Proof of Schedule (PoSch)

(Wilczy

nski and Kołodziej, 2019), and Proof of Stack

(PoS) algorithms(Wahab and Mehmood, 2018). In

case of private blockchain systems, voting-based con-

sensus algorithms are preferred, such as the Practical

Byzantine Fault Tolerance (PBFT) algorithm used by

IBM (Gerrit, 2018).

We also use the term ’Veriﬁcation’ in this paper,

which is also used in some papers to indicate what we

call here validation as in (Pungila and Negru, 2019)

and (Huang et al., 2019), while others might use the

term Approval to indicate what we call here Veriﬁca-

tion as in (Wilczy

nski and Kołodziej, 2019). Never-

theless, we use the ’Veriﬁcation’ term in this paper to

indicate the recognition of a transaction generator by

other network entities through the linkage with his/her

public/private keys.

4 PF-BVM: OUR PROPOSED

VALIDATION MECHANISM

4.1 Motivations

1. Privacy Awareness: as declared in the global

Blockchain survey (Deloitte, 2019), 62% of Chi-

nese surveyed business owners believed that the

biggest concern for them adopting Blockchain-

based technologies is privacy. The percentage

is close in Malaysia and USA with 51%. On

the other hand, 50% of surveyed companies in

twelve different countries think it would be bet-

ter if they only could use Blockchain technolo-

gies privately/internally. Hence, we believe that

the term Data-Protection-By-Design that was re-

cently introduced for enhancing privacy (Varadi

et al., 2020), needs to be adopted in Blockchain

systems.

2. Data Validation: Blockchain is currently used

in cryptocurrenies, but it is expected that within

CLOSER 2020 - 10th International Conference on Cloud Computing and Services Science

432

few years blockchain will be used in most of the

applications that require high security and relia-

bility. For example, Blockchain-enabled e-voting

(BEV) systems implementation is lately highly

investigated and researched (Hanifatunnisa and

Rahardjo, 2017)(Kshetri and Voas, 2018)(Ayed,

2017)(Hjalmarsson and Hjlmtsson, 2018). 43% of

surveyed IT managers and CEOs think that they

would recommend blockchain solutions for data

validation, while 37% would recommend it for

payment issues.

3. Latency Enhancement: Fog computing is

mainly targeting delay-sensitive applications and

services. On the other hand, the less validation

time a Blockchain node consumes, the more time

it spends on accepting new transactions (Pungila

and Negru, 2019). This absolutely means higher

operational efﬁciency of the system. However, not

all fog nodes are resource rich; some of them have

limited computation power, memory and storage

(Yi et al., 2015). Authors of (Xu et al., 2018)

categorized blockchain nodes into three types,

namely: super, regular, and light nodes. Similarly,

we consider two types of fog nodes; resource rich

nodes, and resource poor nodes.

4. Energy Efﬁciency: Maintaining Blockchain se-

curity, reliability, and trust, depends on very

high total power consumption rates (Miller et al.,

2016). A single bitcoin transaction conﬁrmation,

for instance, consumes more power than an av-

erage U.S. household in 21 days (digiconomist,

2019). We are motivated by this fact to come up

with a solution that maintains the decentralization

and reliability of blockchain, yet be more energy

efﬁcient.

4.2 Trust in Blockchain

According to (Babar et al., 2010), Security, Privacy,

and Trust are different but related concepts. Trust

as viewed by (Kochovski et al., 2019), can mainly

be described using probability, and, in a Fog Com-

puting environment, should rely on binary decisions:

Trusted or not Trusted. The privacy awareness, on

the other hand, should consider identity, data, us-

age patterns, and location information. However, pri-

vacy in blockchain is preserved by different means.

In blockchain, ledgers and blocks are transmitted to

all connected nodes, blocks can be easily detected

but can hardly be related to speciﬁc identity. This

anonymity is caused by keeping public keys avail-

able for all nodes, yet anonymous. Blockchain re-

lies on the exponential reduction of attack probabil-

ity as the chain is growing, leading to the state where

it is computationally impractical to attack the chain

and change transactions. However, multi transaction

generations with the same public key indicates the

ownership of all these transactions by the same en-

tity, which was proven to be a privacy threat in Bit-

coin (Androulaki et al., 2013). Also, authors of (Chen

et al., 2018) have shown the ability to infer identity

information from smart contracts’ source codes.

Trust, speciﬁcally, in a blockchain system ma-

jorly increases by the reliability the system provides

(Lemieux, 2017). As will be shown later in this paper,

the more transactions held in a block, the higher the

time consumption for a block validation. Relatively,

it should also be agreed on that the higher the num-

ber of transactions per block, the lower the trust in the

system should be.

To clarify, we propose a concept for measuring

the reliability of a Blockchain system called Un-

Reliability (denoted by R), which depends on the

probability of withdrawing a conﬁrmed transaction,

after a while of adding it to the chain, because of a

malicious behaviour of the miner who generated the

block, or simply because of the forking ”Longest-

Chain-Remains” protocol. If the probability of fork-

ing is p, then the probability a block being withdrawn

is p/2 since one block will be withdrawn and the other

will remain. For example, if p equals to 0.001%, and

the number of transactions tx per a block B equals to

’5’, then the probability that these transactions will be

withdrawn, equals to 5 *p/2 relative to total number of

generated transactions on that day T. To generate the

concept of percentage Un-Reliability R, we propose

equation 1.

R =

t ∗(p/2)

(1)

In the case of Bitcoin, the average number

of transactions per block is 2,700 transactions as

announced on Mar. 29. 2019 (Mitchell Moos, 2019).

While the probability of forking evaluates to ap-

proximately (5.54 ∗ 10

−6

). This is about 0.000554%

i.e. we’d expect two blocks to occur within two

seconds once every 180k blocks (Murch, 2019).

The total average transactions per day announced on

Nov. 03. 2019 is about 290 thousand transactions

(BlockChain.com, 2019). Here we can calculate R

/day as: 2700∗(0.000554/2)/290000% = 2.6 ∗10

−6

Consequently, the following result can be observed:

”The higher the probability of forking, or the

higher the number of transactions per block, the

higher the Un-Reliability indicator of the system,

hence, the lower the level of Trust in the system

should be.”

PF-BVM: A Privacy-aware Fog-enhanced Blockchain Validation Mechanism

433

Out of the box, the concept of Un-reliability can

be extended using other factors to indicate how reli-

able and trust-worthy the evaluated system is. Fac-

tors may include the probability of attacks, such as

51% attack (Dai et al., 2019) or selﬁsh mining attack

(Eyal and Sirer, 2018), encryption deployment, or the

privacy-awareness in the system all in all (Androulaki

et al., 2013). For instance, some famous blockchain

systems, like Bitcoin and Ethereum, do not encrypt

network messages (Faria, 2018), which shall nega-

tively affect the level of trust in the system due to

the lack of privacy, which is a foundation principal

in some applications (Tuli et al., 2019). Private keys

in those systems, however, are speciﬁcally encrypted

using the Elliptic Curve Digital Signature (ECDS)

which requires ((2

)

trials in order to successfully

fraud a signature. This is computationally impossi-

ble (Nguyen and Kim, 2018), which shall positively

affect the level of trust in the system.

4.3 Framework and Principals of the

Proposed PF-BVM

The trust management in PF-BVM is, in general

terms, similar to the reputation system proposed by

(Debe et al., 2019). The difference in our mecha-

nism is that a fog node shall maintain 100% match

score, as clariﬁed in this subsection. In contrast, PF-

BVM deploys some trust management concepts pro-

posed in (Debe et al., 2019), yet it is not the same.

Also, PF-BVM aims to provide privacy awareness,

and enhanced BC validation using fog nodes. In or-

der to achieve this goal, we need a trust management

scheme. PF-BVM is a combination of different ser-

vices provided by the fog, who must prove that it is

trustful in order to be allowed to validate blocks in-

stead of network nodes.

Generally, the system proposed by (Debe et al.,

2019) is ﬂexible and modiﬁable, so its deployment in

PF-BVM is possible if some of the conditions were

edited (Thresholds). Nevertheless, this system is only

aiming to rank fog nodes according to their behaviour,

yet it is not concerned with the validation and pri-

vacy as PF-BVM. The following principles present

our proposed PF-BVM:

• Trusted fog nodes are authorized to validate new

transactions on behalf of the nodes authenticated

with it. A fog node is considered trusted as long as

its acceptance/rejection decisions regarding new

transactions match the decisions made by nodes

authenticated with it in a percentage of 100% .

• A default status of a fog node is not Trusted. The

level of trust increases through time by comparing

decisions made by the fog node to decisions made

by the blockchain nodes regarding new transac-

tions. If the match percentage stays 100% for

named number of transactions, the fog node sta-

tus is switched to Trusted.

• A Trusted fog node is randomly, yet regularly,

tested by nodes authenticated with it. In contrast,

a new trusted fog node should be tested more fre-

quently than a trusted fog node that had main-

tained the status of Trusted for longer time.

• The longer the fog node is Trusted, the fewer

times it is tested for maintaining the 100% match.

Yet the frequency of testing should never reach

ZERO times per named number of transactions.

• The privacy awareness of the system is preserved

by applying the PB-PKI architecture proposed in

(Axon and Goldsmith, 2016). Using this archi-

tecture, the real identities of nodes shall be only

known to the least number of users in the net-

work. That is, a node reveals its user’s identity

only to neighbours that share the same fog-node

domain, while the public keys are kept in the fog

node’s local memory. When a new transaction is

generated, the node’s public key is replaced with

the fog-node’s public key. Hence, the transaction

can only be related to all nodes authenticated with

that fog node. Consequently, the probability of

disclosing the generator’s real identity shall be to-

tally minimized. This idea is shown in Figure 3.

In scenario ’a’, all nodes are connected and all

nodes should validate a transaction, hence all net-

work nodes shall verify the generator. In scenario

’b’, only the fog node and the blockchain nodes

connected to it are able to validate the transaction,

yet the transaction is generated to the network as

valid and referred to by the public key of the fog

node domain.

5 EVALUATION

The evaluation experiments in our work considered

two main factors, time consumption, and energy con-

sumption. For doing so, we implemented a Python

simulation

to exactly test what we needed to mea-

sure. Simulators like BlockSim (Alharby and van

Moorsel, 2019), iFogsim (Gupta et al., 2017), and

PeerSim (Montresor and Jelasity, 2009) simulates the

validation time with a delay without actually perform-

ing the validation as it is in reality, hence all transac-

tions in these simulators are considered valid.

https://github.com/HamzaBaniata/BlockChainValida-

tion/blob/master/First%20Code

CLOSER 2020 - 10th International Conference on Cloud Computing and Services Science

434

Figure 3: a PF-BVM conceptual network compared to the

currently used network. a. all blockchain nodes are con-

nected and responsible for a transaction validation. b. all

blockchain nodes are connected yet few are responsible for

a transaction validation.

In our implementation, we simulated a simple

blockchain, where randomly generated numbers rep-

resented the transactions. Once a transaction is gener-

ated, it gets checked whether it is in a list of the valid

transactions. If the data already exists in the list, an

error message is printed on the screen, and the pro-

gram moves to the next randomly generated transac-

tion. If the data is not in the list, the program adds

it to the list. Once the number of Tx/B -or gas limit-

is reached the block is mined. The workﬂow of our

simulation is presented in Figure 4.

5.1 Time Consumption

We performed the ﬁrst experiment using an Intel

i5-8265U CPU, backed up by 12 GB of DDR4

SDRAM and 45 GB vRAM. Figure 5 shows the re-

Figure 4: Workﬂow of our validation simulator.

sults of this experiment in which we tested four sce-

narios. The ﬁrst scenario had a block conﬁguration

of 100 Transaction(Tx)/Block(B). Followed by the

second scenario with a block conﬁguration of 1000

Tx/B, Third scenario with 10000 Tx/B, and Fourth

with 100000 Tx/B. We performed the four scenarios

on eight groups of randomly generated transactions;

10,20,50,100,200,400,1000, and 3000 blocks. And ﬁ-

nally we computed the average block validation time

for each group by adding two variables to the code.

The ﬁrst variable before the start of transaction val-

idation holding the value of current time, while the

second is after the result of the validation holding the

value of current time minus the ﬁrst variable’s value.

A variable holding the summation of elapsed times is

used at the end of the code to compute the average by

dividing its value by the number of processed blocks.

It can be seen in the ﬁgure that the average

time consumption for validating blocks holding 1000

transactions or less evaluates to almost zero. How-

ever, the validation time increased exponentially

when multiplying the Tx/B ratio by ’10’.

According to this experiment, more transactions

saved in the ValidList, or more Tx/B rate, lead to ex-

ponential increase in time consumption of the valida-

tion process in general. such conclusion indicates that

proposing a system where transactions and blocks be

validated outside blockchain nodes, would save much

processing time for them. Consequently, we compare,

as suggested in (Svorobej et al., 2019), the average

PF-BVM: A Privacy-aware Fog-enhanced Blockchain Validation Mechanism

435

Figure 5: Average time consumption for block validation in

a Blockchain node.

validation time consumed by two scenarios similar to

those shown in Figure 3.

To compare the average time, we study a case

where three rich fog nodes are connected to each

other. Each fog node is connected to 10 blockchain

nodes (both miners and non-miners), with total of 30

blockchain nodes. Once a transaction is generated by

a node, it is distributed through the network to all

nodes. Then, locally, all nodes perform the valida-

tion. If the time needed to validate this transaction

equals x, then the total processing time consumed to

validate this transaction equals 30x. In the case of PF-

BVM, the total processing time consumed to validate

this transaction equals 3x. That is, only the three fog

nodes will spend time on validation, while the rest

of network nodes are free to perform what ever else

tasks they need to do. Equations 2 and 3 generalize

the computation.

Time(Current) = nx (2)

Time(PF − BV M) = kx (3)

where;

• Time(Current): the total processing time needed

to validate a transaction

• n: The total number of network nodes,

• x: Time needed to locally validate a transaction

on one node,

• Time(PF-BVM): the total processing time needed

to validate a transaction when using PF-BVM

• k: The number of authorized nodes to validate

transaction.

Regarding the range of the time consumption in

this experiment, it can be noticed that the maximum

time consumed for validating a block is 0.6 sec. This

is because we saved the blocks and the lists of our

code in the RAM, which is faster than, and closer to,

the CPU. To check if the pattern of the time consump-

tion remains, we have implemented our code using

Apache HTTP Server 2.4.41, with the valid transac-

tions being saved in a MySQL database on the hard

disk

. We got similar results of exponential increasing

in time consumption, yet the range was higher. For

example, using SSD disk, the scenarios of 100 Tx/B,

1000 Tx/B, and 10000 Tx/B applied on 10 Blocks re-

sulted an average block validation time of 0.112, 4.9,

and 419.9 seconds respectively.

5.2 Energy Consumption

When there are too many nodes, the communica-

tion performed to exchange agreements between them

would be very complicated (Nguyen and Kim, 2018)

and energy consuming (Kreku et al., 2017). To high-

light energy consumption values of Blockchain sys-

tems, we recall the results shown in paper (Kreku

et al., 2017), and summarize them in Figure 6. Kreu

et al. showed the energy consumption for mining

400 blocks by two blockchain execution platforms:

’Raspberry Pi 2’ and ’Nvidia Jetson TK1’. These re-

sults suggested that the more the miner nodes rela-

tive to the total number of nodes in the network, the

less energy consuming the block conﬁrmation is. Fur-

ther, least energy consumption was gained when us-

ing only one miner node in a network that contains

only one node in total.

Following these investigations, we can state that

there is one explanation for such results, which is the

wasted amount of energy. To clarify this, lets suppose

that a network has two miner nodes out of total ﬁve

network nodes. When a transaction is put in the mem-

pool, the two miner nodes will start their Brute-Force

process for ﬁnding the next block’s nonce. One of

these two miner nodes will ﬁnd the solution before the

other. This leads the winning miner to distribute the

new block, while loser miner accepts the new block

and stops working on it. The amount of energy spent

by the loser miner had been wasted for no use at all,

hence the lower the number of miner nodes working

on a next block at the same time, the lower the energy

consumed -by the system- to generate the block.

Similarly, the lower the number of nodes validat-

ing a transaction, the lower the energy consumed as

a whole in the system. To clarify, lets suppose that

the same ﬁve nodes of the previous example received

a block from some other network entity. The ﬁve

nodes will each consume equal amount of energy ’x’

to validate this block, depending on the Tx/B ratio

and the number of blocks in the locally saved chain

https://github.com/HamzaBaniata/BlockChainValida-

tion/blob/master/Second%20Code

CLOSER 2020 - 10th International Conference on Cloud Computing and Services Science

436

(Suankaewmanee et al., 2018). The total amount of

energy consumed to validate this block equals to 5x.

If a validation protocol -such as ours- in which only

one of the ﬁve nodes is trusted and authorized to vali-

date the block on behalf of the other four nodes, then

the total amount of consumed energy evaluates to 1/5

relative to the energy consumed by the ﬁrst system.

To generate the computation method of the consumed

energy in PF-BVM, we used equation 4.

E =

% (4)

Where;

• E: Consumed energy percentage by PF-BVM

compared to current protocol,

• k: The number of authorized nodes to validate

transactions,

• n: The total number of network nodes

Figure 6: Energy consumption when mining 400 blocks by

two different blockchain execution platforms.

To present the effect of our proposed PF-BVM,

we simulated the energy consumption, using equation

4, in our provided validation simulation code. The

results of our simulation are presented in Figure 7.

In our simulation experiment, the value of k changes,

while the value of n equals 50 nodes.

As it can be seen in Figure 7, the less the num-

ber of nodes validating a transaction, the less the total

energy consumed to validate a transaction, hence, the

more efﬁcient the system is. We also need to mention

here that the same approach of calculations can be ap-

plied for evaluating the storage efﬁciency proposed by

PF-BVM. For example, n∗ 150 and 46 GB storage,

used to locally save Bitcoin and Ethereum chains re-

spectively (Reyna et al., 2018), can be reduced to k/n

% needed storage capacity for the whole system.

Figure 7: Energy consumption when validating a transac-

tion using PF-BVM.

6 CONCLUSION

In this paper we proposed a Privacy-aware Fog-

enhanced Blockchain Validation Mechanism (PF-

BVM), which contributes to the integration of fog

computing, the internet of things and blockchain tech-

niques. We used the concept of Un-Reliability to in-

dicate, how reliable a blockchain system is. As a

conceptual criterion, PF-BVM allows trusted rich fog

nodes to perform transaction validation on behalf of

other network nodes. The trust is gained by randomly

running matching tests by network nodes. Our work

showed that the higher the number of transactions

per block, and the higher the probability of forking,

the higher the Un-Reliability metric of the blockchain

system. To evaluate our proposed mechanism, we im-

plemented a specially designed simulation code and

the experimental results showed that PF-BVM can

signiﬁcantly enhance a blockchain system validation

in terms of time consumption, energy efﬁciency, and

storage capacity. Our future work will be directed to-

wards investigating available BC-FC integration ap-

proaches. According to our investigations, we will

build a simulation environment for BC-FC solution,

relying on the PF-BVM source code. We will also be

developing PF-BVM in order to measure the dynam-

ics of trust evolution over time for BC nodes.

ACKNOWLEDGEMENTS

The research leading to these results was supported

by the Hungarian Government and the European

Regional Development Fund under the grant num-

ber GINOP-2.3.2-15-2016-00037 (”Internet of Living

Things”), by the Hungarian Scientiﬁc Research Fund

under the grant number OTKA FK 131793, and by

the grant TUDFO/47138-1/2019-ITM of the Ministry

for Innovation and Technology, Hungary.

PF-BVM: A Privacy-aware Fog-enhanced Blockchain Validation Mechanism

437

REFERENCES

Alharby, M. and van Moorsel, A. (2019). Blocksim:

A simulation framework for blockchain systems.

ACM SIGMETRICS Performance Evaluation Review,

46(3):135–138.

Andrew Tar (2018). Proof-of-work. https://cointelegraph.

com/explained/proof-of-work-explained. [Online; ac-

cessed 29-October-2019].

Androulaki, E., Karame, G. O., Roeschlin, M., Scherer, T.,

and Capkun, S. (2013). Evaluating user privacy in bit-

coin. In International Conference on Financial Cryp-

tography and Data Security, pages 34–51. Springer.

Axon, L. (2015). Privacy-awareness in blockchain-based

pki. Cdt technical paper series.

Axon, L. and Goldsmith, M. (2016). Pb-pki: A privacy-

aware blockchain-based pki.

Ayed, A. B. (2017). A conceptual secure blockchain-based

electronic voting system. International Journal of

Network Security & Its Applications, 9(3):01–09.

Babar, S., Mahalle, P., Stango, A., Prasad, N., and Prasad,

R. (2010). Proposed security model and threat tax-

onomy for the internet of things (iot). In Interna-

tional Conference on Network Security and Applica-

tions, pages 420–429. Springer.

Beck, R., Avital, M., Rossi, M., and Thatcher, J. B. (2017).

Blockchain technology in business and information

systems research.

BlockChain.com (2019). Blockchain charts. https://www.

blockchain.com/en/charts. [Online; accessed 03-

November-2019].

Capra, M., Peloso, R., Masera, G., Ruo Roch, M., and Mar-

tina, M. (2019). Edge computing: A survey on the

hardware requirements in the internet of things world.

Future Internet, 11(4):100.

Chen, T., Zhu, Y., Li, Z., Chen, J., Li, X., Luo, X., Lin, X.,

and Zhange, X. (2018). Understanding ethereum via

graph analysis. In IEEE INFOCOM 2018-IEEE Con-

ference on Computer Communications, pages 1484–

1492. IEEE.

chytrik (2017). How blockchain transac-

tion veriﬁcation takes place? https:

//bitcoin.stackexchange.com/questions/64455/

how-blockchain-transaction-veriﬁcation-takes-place.

[Online; accessed 03-November-2019].

Cisco (2019). Cisco fog data services. https://www.cisco.

com/c/en/us/products/cloud-systems-management/

fog-data-services/index.html?dtid=osscdc000283.

[Online; accessed 09-November-2019].

Dai, H.-N., Zheng, Z., and Zhang, Y. (2019). Blockchain

for internet of things: A survey. arXiv preprint

arXiv:1906.00245.

Debe, M., Salah, K., Rehman, M. H. U., and Svetinovic,

D. (2019). Iot public fog nodes reputation system:

A decentralized solution using ethereum blockchain.

IEEE Access, 7:178082–178093.

Deloitte (2019). Deloitte’s 2019 global blockchain survey.

digiconomist (2019). Bitcoin energy consumption index.

https://digiconomist.net/bitcoin-energy-consumption.

[Online; accessed 14-November-2019].

Eyal, I. and Sirer, E. G. (2018). Majority is not enough:

Bitcoin mining is vulnerable. Communications of the

ACM, 61(7):95–102.

Faria, C. (2018). Blocksim: Blockchain simulator.

Gerrit (2018). Hyperledger fabric. https://github.com/

hyperledger/fabric. [Online; accessed 09-November-

2019].

Gupta, H., Vahid Dastjerdi, A., Ghosh, S. K., and Buyya,

R. (2017). ifogsim: A toolkit for modeling and

simulation of resource management techniques in

the internet of things, edge and fog computing en-

vironments. Software: Practice and Experience,

47(9):1275–1296.

Hanifatunnisa, R. and Rahardjo, B. (2017). Blockchain

based e-voting recording system design. In 2017 11th

International Conference on Telecommunication Sys-

tems Services and Applications (TSSA), pages 1–6.

IEEE.

Hjalmarsson, Fririk, H. G. K. H. M. and Hjlmtsson, G.

(2018). Blockchain-based e-voting system. In 2018

IEEE 11th International Conference on Cloud Com-

puting (CLOUD), pages 983–986. IEEE.

Huang, H., Li, K.-C., and Chen, X. (2019). Blockchain-

based fair three-party contract signing protocol for fog

computing. Concurrency and Computation: Practice

and Experience, 31(22):e4469.

Kochovski, P., Gec, S., Stankovski, V., Bajec, M., and

Drobintsev, P. D. (2019). Trust management in a

blockchain based fog computing platform with trust-

less smart oracles. Future Generation Computer Sys-

tems, 101:747–759.

Kreku, J., Vallivaara, V. A., Halunen, K., Suomalainen, J.,

Ramachandran, M., Mu

noz, V., Kantere, V., Wills, G.,

and Walters, R. (2017). Evaluating the efﬁciency of

blockchains in iot with simulations. In IoTBDS, pages

216–223.

Kshetri, N. and Voas, J. (2018). Blockchain-enabled e-

voting. IEEE Software, 35(4):95–99.

Lemieux, V. L. (2017). Blockchain and distributed ledgers

as trusted recordkeeping systems. In Future Technolo-

gies Conference (FTC), volume 2017.

Li, M., Zhu, L., and Lin, X. (2018). Efﬁcient and privacy-

preserving carpooling using blockchain-assisted ve-

hicular fog computing. IEEE Internet of Things Jour-

nal.

Macdonald, M., Liu-Thorrold, L., and Julien, R. (2017).

The blockchain: a comparison of platforms and their

uses beyond bitcoin. COMS4507-Adv. Computer and

Network Security.

Marin-Tordera, E., Masip, X., Garcia Almi

nana, J., Jukan,

A., Ren, G.-J., Zhu, J., and Farre, J. (2016). What

is a fog node a tutorial on current concepts towards a

common deﬁnition.

Markakis, E. K., Karras, K., Zotos, N., Sideris, A.,

Moysiadis, T., Corsaro, A., Alexiou, G., Skianis, C.,

Mastorakis, G., Mavromoustakis, C. X., et al. (2017).

Exegesis: Extreme edge resource harvesting for a

virtualized fog environment. IEEE Communications

Magazine, 55(7):173–179.

CLOSER 2020 - 10th International Conference on Cloud Computing and Services Science

438

Miller, A., Xia, Y., Croman, K., Shi, E., and Song, D.

(2016). The honey badger of bft protocols. In Pro-

ceedings of the 2016 ACM SIGSAC Conference on

Computer and Communications Security, pages 31–

42. ACM.

Mitchell Moos (2019). Bitcoin transactions per

block at all-time highs. https://cryptoslate.com/

bitcoin-transactions-per-block-at-all-time-highs/.

[Online; accessed 03-November-2019].

Montresor, A. and Jelasity, M. (2009). Peersim: A scalable

p2p simulator. In 2009 IEEE Ninth International Con-

ference on Peer-to-Peer Computing, pages 99–100.

IEEE.

Murch (2019). What is the probabil-

ity of forking in blockchain? https:

//bitcoin.stackexchange.com/questions/42649/

what-is-the-probability-of-forking-in-blockchain.

[Online; accessed 03-November-2019].

Nakamoto, S. (2008). Bitcoin whitepaper.

Nakamoto, S. et al. (2008). Bitcoin: A peer-to-peer elec-

tronic cash system.

Nguyen, G.-T. and Kim, K. (2018). A survey about consen-

sus algorithms used in blockchain. Journal of Infor-

mation processing systems, 14(1).

Puliaﬁto, C., Mingozzi, E., Longo, F., Puliaﬁto, A., and

Rana, O. (2019). Fog computing for the internet

of things: A survey. ACM Trans. Internet Technol.,

19(2):18:1–18:41.

Pungila, C. and Negru, V. (2019). Improving blockchain

security validation and transaction processing through

heterogeneous computing. In International Joint Con-

ference: 12th International Conference on Computa-

tional Intelligence in Security for Information Systems

(CISIS 2019) and 10th International Conference on

EUropean Transnational Education (ICEUTE 2019),

pages 132–140. Springer.

Reyna, A., Mart

ın, C., Chen, J., Soler, E., and D

ıaz,

M. (2018). On blockchain and its integration with

iot. challenges and opportunities. Future Generation

Computer Systems, 88:173–190.

Silva, C. A. d., de Aquino J

unior, G. S., and Melo, S.

R. M. (2019). A blockchain-based approach for pri-

vacy control of patient’s medical records in the fog

layer. In Proceedings of the 25th Brazillian Sym-

posium on Multimedia and the Web, WebMedia ’19,

pages 133–136, New York, NY, USA. ACM.

Steem (2017). Steem an incentivized, blockchain-

based, public content platform. https://steem.

io/SteemWhitePaper.pdf. [Online; accessed 21-

November-2019].

Suankaewmanee, K., Hoang, D. T., Niyato, D., Sawad-

sitang, S., Wang, P., and Han, Z. (2018). Perfor-

mance analysis and application of mobile blockchain.

In 2018 international conference on computing, net-

working and communications (ICNC), pages 642–

646. IEEE.

Svorobej, S., Takako Endo, P., Bendechache, M., Filelis-

Papadopoulos, C., Giannoutakis, K. M., Gravvanis,

G. A., Tzovaras, D., Byrne, J., and Lynn, T. (2019).

Simulating fog and edge computing scenarios: An

overview and research challenges. Future Internet,

11(3):55.

Tuli, S., Mahmud, R., Tuli, S., and Buyya, R. (2019). Fog-

bus: A blockchain-based lightweight framework for

edge and fog computing. Journal of Systems and Soft-

ware.

Varadi, S., Varkonyi, G. G., and Kert

esz, A. (2020). Le-

gal issues of social iot services: The effects of us-

ing clouds, fogs and ai. In Toward Social Internet of

Things (SIoT): Enabling Technologies, Architectures

and Applications, pages 123–138. Springer.

Wahab, A. and Mehmood, W. (2018). Survey of consensus

protocols. arXiv preprint arXiv:1810.03357.

Wilczy

nski, A. and Kołodziej, J. (2019). Modelling and

simulation of security-aware task scheduling in cloud

computing based on blockchain technology. Simula-

tion Modelling Practice and Theory, page 102038.

Xu, Q., Aung, K. M. M., Zhu, Y., and Yong, K. L. (2018). A

blockchain-based storage system for data analytics in

the internet of things. In New Advances in the Internet

of Things, pages 119–138. Springer.

Yi, S., Hao, Z., Qin, Z., and Li, Q. (2015). Fog computing:

Platform and applications. In 2015 Third IEEE Work-

shop on Hot Topics in Web Systems and Technologies

(HotWeb), pages 73–78. IEEE.

Yousefpour, A., Fung, C., Nguyen, T., Kadiyala, K., Jalali,

F., Niakanlahiji, A., Kong, J., and Jue, J. P. (2019).

All one needs to know about fog computing and re-

lated edge computing paradigms: A complete survey.

Journal of Systems Architecture.

Zee Ali (2019). A simple introduction to blockchain

algorithms. https://blog.goodaudience.com/a-simple-

introduction-to-blockchain-algorithms-ca05b9bcc32f.

[Online; accessed 26-October-2019].

PF-BVM: A Privacy-aware Fog-enhanced Blockchain Validation Mechanism

439