Information Processing and Management

the privacy of system components, and assure that data, location, identity, and usage information are not exposed. We evaluate and compare PF-BTS performance, with a recently proposed Blockchain-based task scheduling protocol, in a simulated environment. Our evaluation and experiments show high privacy awareness of PF-BTS, along with noticeable enhancement in execution time and network load.

(GPUs). BC has been proven to provide secure and trusted transaction (TX) validation and confirmation without the interference of a Trusted Third Party (TTP).
A BC miner is, in most cases, a rather fast computer that is able to relatively conduct huge number of computational tasks per second Crosby, Pattanayak, Verma, Kalyanaraman et al. (2016). When Bitcoin was firstly introduced in 2008 Nakamoto (2019), BC was the foundation of a peer-to-peer network, where peers are challenged to solve a mathematical problem using a Brute-Force approach. As demonstrated in Fig. 1, once a BC node reaches a solution for the problem, also named puzzle, the solution is broadcast among other peers for confirmation Zheng, Xie, Dai, Chen, and Wang (2018). Reaching a consensus of 51% or more on the validity of the solution, as well as on other information related to the puzzle and the performed TXs by end users, results in confirming the block of TXs and adding it to a publicly available ledger Vukolić (2015).
The miner node who solves the puzzle is then awarded by the network and by the end users whose TXs were confirmed. The difficulty of the puzzle is conditionally determined Kraft (2016). For example, Bitcoin requires one block to be confirmed every 10 minutes, while Ethereum average block time is 15 seconds Ethereum (2020). Hence, if a BC miner is able to solve the puzzle in less time, the algorithm increases the difficulty so that the average time of puzzle solution, and hence the block generation, remains Garay, Kiayias, and Leonardos (2017). This mentioned approach for reaching a consensus is what PoW actually is; the winning miner must prove its work on the puzzle by providing the solution, in order to get rewarded.
Bitcoin is a cryptocurrency secured by a PoW-based BC, where money TXs, merchandise and exchange can be performed. Ethereum, on the other hand, is a PoW-based BC that can handle wider range of applications, including money transfer. Specifically, Ethereum provides a platform where on-line Smart Contracts (SC) can be generated and agreed-on by different users. Those contracts are conditionally automated providing higher trust measures for sensitive applications. Further, the smartness of these contracts is highly flexible as users write and agree on the terms of each contract, hence each contract is different than other contracts and users are not forced to play by any body's rules. The need of SCs does not appear in Bitcoin, or similar cryptocurrency systems, as the rules and terms are unified for all TXs. Although there is no SCs in Bitcoin, we can still project it, as a concept, on its workflow. That is, a user generates a TX to another user, hence she is generating a SC in which a certain amount of digital coins are unconditionally transferred to another user. Miner nodes pick this TX according to some criteria, such as the preferred TX fees waived by the first user, and accumulate many TXs in one block. Once a block reaches a completeness status (configured by the system) such as specific number of TXs per block, the block is mined (i.e. hashed and the nonce is found in a Brute-Force manner). Consequently, the first miner node to find the nonce broadcasts the new block with its nonce and all network peers validate the correctness of the solution and add the block to the locally saved chain. Once the block is added to the chain, all TXs within are confirmed and hence the amount of the sender's digital coins is decreased while the amount of the receiver's digital coins is increased.
In Ethereum, a SC does not have to include transferring digital coins to another user, although it can. That is, all the above mentioned steps apply in Ethereum, except that users actually write a code, which is the SC, that is run on one Ethereum node. The SC can include any type of implementation, and the user who generates this SC provides TX fees that is given for the node who runs the SC code. Depending on how power consuming the SC code is, and fees decided by the system per each computational cycle, the TX fee is decided. This is why the TX fees in Ethereum are called GAS, as the node that runs the code consumes fees as much as needed to compensate its power consumption for running the code. However, GAS coupled with each SC is also flexible as it is decided by the user, not the system. If GAS was sufficient to perform the SC, it is completely and successfully run and the unused GAS is returned to the generator. Thus, the SC is run as long as the GAS is available. If the GAS was consumed before the SC is finished, then the SC is terminated, and the TX is not conducted, yet the provided GAS is waived to the node who ran the code.
In our present research, we propose exploiting BC miners (e.g. peers of Ethereum Blockchain), who usually perform computational puzzle solving in order to receive digital coins from the BC network. By generating a SC to the platform, we aim to exploit BC nodes to assign end users' task into the cloud VRs. We deploy the fog nodes to control the communication among end users, BC network, and the cloud. The fog node in our proposed system is responsible for choosing the best schedule according to specific criteria, which reduces the latency compared to the case of BC network generating the best schedule by consensus. That is, a BC node picks the SC generated by the fog node, and sends its proposed schedule back to the fog node. The fog node then chooses the best H. Baniata, et al. Information Processing and Management 58 (2021) 102393 schedule among the received ones and sends it to the cloud. The cloud accordingly performs the tasks using the assigned VRs and returns the results to the fog node, who forwards them to end users. The direct incentive for BC miners who run the SCs is provided in the form of GAS, while incentives for generating new blocks are given by the BC network itself. Notably, the results are saved on the chain by BC peers consensus (e.g. PoW in the case of Ethereum) for future reference and analysis. However, the time needed for reaching a consensus in order to save the data on the chain is not included in the time required to generate the optimal schedule. Thus, the type of consensus algorithm deployed in the BC network does not affect the latency. If some related information are needed, by the system administrators, the cloud, or the fog, it can be easily retrieved as the result of each SC is immutably saved on the chain. To evaluate our proposed system, we adopt two different approaches of parallel computing Stauffer, Hehl, Ito, Winkelmann, and Zabolitzky (2012). The first is the Single Instruction Multiple Data (SIMD), used to enforce BC miners who pick the generated-by-fog SCs to run the required code and computations. The second is the Multiple Instruction Multiple Data (MIMD), which we use to simulate the Blockchain Scheduling (BS) system proposed in Wilczyński and Kołodziej (2020), for evaluating our results by comparison. To clarify, SIMD enforces simulated miner nodes to run the similar SCs that hold the same code (i.e. ACO in our proposed system), yet each of them provides different output. The TPC then recognizes the best schedule proposed from the SIMD-enabled miners. Finally, each MIMD-enabled miner runs different SC with different code, resulting in different outputs. The outputs of the two groups are compared and the best result is sent to the cloud. Nevertheless, all outputs are saved on the chain for future reference. Originally, miner nodes in BS were grouped into four categories, each group ran a different algorithm with the same input. They proposed the Proof-of-Schedule (PoSch) algorithm using Game Theory, in order to obtain the best assignment from the four groups. Some miners in BS provide the same results however, so we believe there was no need to recruit more than one miner in that group. For example, the SJF algorithm was run on four miner nodes, yet they all shall, by definition, output the same exact result. This also applies for the FCFS and RR algorithms as, initially, all miner nodes receive the same input, all tasks have the same arrival time, and all miner nodes use the same quantum value. Following these mentioned insights, we performed our experimentation on eight virtual machines, five of them ran the ACO assignment optimization presented in the following subsection, while the other three performed SJF, FCFS, and RR assignment. We excluded the fourth group studied in Wilczyński and Kołodziej (2020) since it presented the worst performance in most cases that were originally evaluated in the BS proposal.

Ant colony optimization (ACO) and problem statement
Algorithms of Meta-heuristics are the state of the art solution for complex optimization problems. Most of these algorithms are socalled ǣnature-inspired algorithmsǥ Saka and Dogan (2012). Specifically, Ant Colony Optimization (ACO) Dorigo et al. (2006) is an optimization algorithm that is motivated by the behaviour of some type of ants in real-life. Ants of the colony communicate by depositing chemical pheromones along the paths they take from home colony to food sources. Such behaviour provokes other ants of the colony to follow the paths that are most recommended by the majority of ants, indicated by high levels of pheromones deposited. Implementing this nature-inspired methodology was shown to provide high ability of solving different versions of the assignment problem Chen and Cheng (2005) ;Srikanth, Maheswari, Palaniswami, and Siromoney (2016). There are several proposed versions of ACO depending on the problem to be solved. Generally, ACO works over the following phases: 1. Construct Ant Solutions: each ant stochastically constructs its solution from a finite set of available solutions. 2. Update Pheromone: In this phase the pheromone values are modified to indicate promising/bad solutions. Moreover, all pheromone values are equally decreased every predefined number of iterations due to the pheromone evaporation concept. 3. The final solution is biased by the pheromone values deposited by all ants. We adopted a Multi-Objective ACO with Global Pheromone Evaluation, improved by a greedy optimal assignment approach to get even better solutions. That is, once an ant constructed a solution, it improves the proposed solution through local greedy search, which results in the Best Individual Assignment (BIA). Consequently, BIA is updated through the run, and the assignment obtained depending on the pheromone matrix is compared to the BIA. The best of the two is then proposed as the final solution. Following, we will describe the version we adopted, its equations, our proposed improvement, and final solution algorithm. It is worth noting that what we present in this subsection is how each BC miner performs in PF-BTS. On the higher level of PF-BTS, however, our optimization model is inspired by the Multi-Colony Parallel ACO described in Pedemonte, Nesmachnow, and Cancela (2011). The problem that needs to be solved by our task scheduling protocol, is the assignment of n tasks, denoted by T i where = … i n 1 , to m machines denoted by M j where = j m 1. .. , such that each task is assigned to one machine. Our objective function is to find a schedule where the time consumption, required by the cloud VRs to perform the computational tasks, is minimal. The utilization of the machines, denoted by u ij , relates to two parameters. First, the computing power of M j , measured by MFLOPS (Million FLoating point Operations Performed in one Second). Second, the length of T i , which is the number of operations or instructions needed to execute the task T i expressed in MFLO (milion floating point operations). The utilization values of a machine performing any task is calculated using Eq. 1.
Based on these values the algorithm constructs the utilization matrix U whose size is n × m. The number of rows equals the number of tasks, while the number of columns equals the number of machines. The element of utilization matrix is real numbers. A sample of the utilization matrix is presented in Table 1.
H. Baniata, et al. Information Processing and Management 58 (2021) The scheduling can be presented using a n × m binary matrix called schedule matrix S whose entries are denoted by s ij . That is, = s 1 ij if task i is assigned to machine j, and equals zero otherwise. Our algorithm makes sure that no more than one '1' is in the same row to make sure that each task is assigned for exactly one machine. However, there can be several tasks performed by one machine, depending on the best assignment criteria. This means that there are no restrictions on the number of 1's in any given column. The reason behind implementing our algorithm as for each task is assigned to exactly one machine, is that assigning a task to multiple machines complicates the problem even more, which is highly inefficient in terms of time and energy. That is, the state space under our mentioned condition is decreased from n! to m n , hence the optimum assignment is more likely to appear during the search (for huge number of iterations and ants). Further, the Single-Task-Multi-VR approach is doable only if tasks were partition-able, which is a condition that may not apply in all cases. However, if for some reason this was necessary, we believe our model and its algorithm can be easily developed to handle it using a multi-threading scenario.
The global pheromone matrix is also represented using a n × m matrix. The elements of the pheromone matrix called pheromone values, denoted by τ ij . The pheromone values indicate the preference of assigning specific task on a specific machine. τ ij in the pheromone matrix is conditionally affected by a probability of p(i, j). That is, higher probability of performing task i on machine j is obtained for assignments that were recommended by more ants. Initially, all pheromone values are equal. During the iterations of the algorithm, the pheromone matrix is updated by each ant. The assignment of T i to M j , by an ant who just finished its iterations, increases the values of τ ij according to Eqs. 2 and 3. Also these values are affected, during run time, by an evaporation factor ρ after each ant finishes its iterations. That is, the pheromone is decreased relatively to ρ to simulate the pheromone evaporation over time. For example, if = 0.6 is the evaporation factor, then the evaporation rate is 1 which equals to 0.4. Accordingly, all elements in the pheromone matrix is decreased using Eq. 4.
In our version of ACO, the first ant creates a schedule, so-called LOCAL, where each task is randomly assigned to a machine. After that the ant iterates a number of modifications, at which each task is assigned to a different machine, while other tasks remain assigned to their original machines as in LOCAL. Each new modified LOCAL is compared to the original random assignment. If an iteration resulted in a better schedule, in terms of machines maximum execution time, LOCAL is replaced with the better schedule. The evaluation is done by comparing the values of schedule usage, which is the total time consumption of VRs to perform the tasks. To get the Time Consumption R, the utilization matrix is multiplied by the schedule matrix (element-wise multiplication), which outputs a n × m matrix. After each ant finishes its iterations, the ant's best assignment is compared with the best assignment obtained from all previous ants. This comparison is beneficial later for the comparison between the best individual assignment (BIA) with the assignment obtained depending on the pheromone matrix.
Usually, after all ants finish their iterations, the pheromone matrix becomes ready to extract an assignment that the majority of the ants agreed on. That is, the maximum value of each row 'i' indicates that most ants recommended assigning task T i to the correlated M j . However, our aim is obtaining the best possible assignment of the tasks. Hence, we improved the ACO algorithm a bit, using a simple Greedy approach, to compare the BIA proposed by an individual ant with the assignment proposed by the majority of ants. The algorithm then chooses the best of the two and considers it the output of the algorithm. Eq. 5 presents how the algorithm computes the time consumption of tasks in a proposed assignment. Eqs. 6 and 7 clarify how the algorithm extracts the schedule's time consumption, and the estimate cost, respectively. Algorithm 1 illustrates the workflow of our version of ACO.

System characteristics and protocol
Next, we present our proposed deployment of ACO algorithm in BC miners, for the benefit of a fog-enabled environment. The ACO algorithm, implemented in a form of a SC, optimizes the assignment of tasks to the available cloud VRs, while fog nodes control the process and guarantees the anonymity of end-users and tasks' information. Fig. 2 clarifies the framework of our proposed protocol in a FC architecture, while Algorithm 2 clarifies how the fog node enforces the needed measures to preserve the privacy of end-users, and controls the communications between end-users, BC miners, and the cloud.
The key steps of the proposed protocol are as follows: 1. End-users send their computation tasks to the fog node they are authenticated with. 2. Fog nodes are the Task Pool Coordinator (TPC) component in our protocol. Fog nodes receive the tasks from end-users, and receive information about the capacities of available VRs from the cloud. 3. Unless the TPC is capable of performing the computational tasks, it randomly assigns each task, or group of tasks, a unique ID (anonymization). The abilities of the TPC to perform the tasks is determined by different criteria, such as the CPU computational power, the length of each task, the network load balancing, etc. 4. After that, the TPC generates a number of SCs into the BC network which include: the optimization algorithm (i.e. ACO), a list of tasks IDs each coupled with its task length, a list of VRs capacities, the public address of the fog node, and some appropriate amount of GAS. 5. As the SCs are successfully generated, each SC is picked and run by a BC miner. According to a defined criteria (e.g. the least time consumption/ the least cost) each miner proposes a different optimal schedule that is immediately sent back to the TPC. All miners are expected to finish their iterations and send the results at approximately the same time because the SIMD principle applies. 6. Each time the TPC receives a better schedule than a previously proposed one, the best assignment is updated. 7. TPC waits for a pre-determined time to check if it receives a better schedule. If the time passes and no other better schedule appears, the tasks are deanonymized and sent to the cloud. Otherwise, TPC replaces the schedule with the better one and waits again. However, if the number of received schedules equals the number of generated SCs, the best is chosen and sent to the cloud regardless of the waiting time. 8. After the cloud receives the optimal schedule from TPC, the cloud performs the tasks and sends the results back to the TPC, which forwards the results back to end-users. 9. Later, the results of the SCs are saved On-Chain using any consensus algorithm (e.g. PoW in the case of Ethereum) for future reference. Those saved results are immutable and private. That is, all information are anonymized and can not be used/analyzed from any party other than the trusted ones (i.e. the cloud and TPC).

Evaluation
In this section we evaluate our proposed protocol in terms of Privacy, Total Execution Time, and Network Load.

Privacy
Privacy issues are considered a challenge when it comes to BC-IoT integration Tseng, Wong, Otoum, Aloqaily, and Othman (2020). Both the layer at which BC is deployed, and the purpose of the deployment affect the privacy measures differently in different cases. Consequently, every integration case needs to be evaluated individually, especially that BC technology itself is not yet standardized, nor privacy measures are unified for a BC-Fog integration Baniata and Kertész (2020). In PF-BTS, SCs generated into the BC network by the TPC expose only the expected computational power needed for each task/group of tasks (i.e. task length). The identities of end-user devices, and the nature of the tasks/applications performed by end-users are anonymous. Further, usage privacy H. Baniata, et al. Information Processing and Management 58 (2021)  H. Baniata, et al. Information Processing and Management 58 (2021) 102393 and location privacy are also guaranteed by the protocol, since no information included in the SC can be related to the identities or location of end-users. Similar approaches were proven effective, in terms of privacy, in Yi, Qin, and Li (2015) and Ni, Zhang, Lin, and Shen (2017).
To systematically validate PF-BTS in terms of privacy, we model the probable attacks that can be launched against End-Users using the Attack Trees modelling Schneier (2015). We assume that fog components and cloud components are trusted but curious components. That is, fog and cloud components can be trusted with data such as timestamps and end-user identities/applications. However, the discussion of the trust in the privacy measures provided by the fog and the cloud are out of the scope of this paper, hence, we recommend referring to Chen, Takabi, and Le-Khac (2019) and Khalid et al. (2019) for details. It is worth noting, though, that malicious BC nodes may misuse the public addresses of fog nodes. Yet,this cannot expose any location or usage data of end users. Simply because such data can only be obtained if the fog node was hackable, which contradicts our initial assumption about fog nodes being trusted and secure entities.
Consequently, our goal here is to prove that no private information about End-Users can leak to/be inferred by BC miners. It is worth adding here that end users are not connected to the blockchain (BC) nor to BC miners. End users are only connected and authenticated with the fog nodes. Further, fog nodes are not authenticated with the BC nor with the miners as well. That is, fog nodes in PF-BTS are simply users of the BC system. To clarify, in a typical public and permission-less BC system (such as Ethereum), users of the BC system (i.e. the fog nodes in PF-BTS) are not required to be authenticated with any entity of the BC network. All users (fog nodes) need to do is to have a BC-readable wallet that is defined using a public key, and a private key, and contains some amount of digital coins so that the user can pay for the smart contracts (SC) Gas. PF-BTS proposes that end users send their computational tasks to the fog nodes they are -classically-authenticated with (such authentication is beyond the scope of our proposal). The fog nodes generate SCs to the BC network as if the fog nodes were users of the BC (using the automation mechanisms clarified in algorithm 2). After that, the BC miners run the SCs (perform the computational tasks), send the results back to the generator of the SC (which is the fog node), and add the result of the SC to the public ledger. The results being sent to the generator of the SC uses a simple encrypted messaging service over the IP. This messaging service is available in most applicable BCs (including Ethereum). Further, Ethereum provides an even more exclusive approach to explore data fields in SCs (i.e. using the etherscan.io platform). Consequently, only the public address of the fog node can be read by a BC miner (for the messaging), and the public wallet address of the fog nodes (for the Gas).
Privacy is usually studied w.r.t. four main concerns, namely Data, Location, Identity, and Usage Patterns. By referring to the architecture presented in Fig. 2 and the protocol description discussed in subsection 3.3, we can build the privacy Attack Trees.
An Attack Tree is a rooted directed acyclic bundle graph, where the grand root represents the attack and its children represents sub attacks/components that need to be conducted to have a successful breach into the grand root attack. A bundle is the connections from the grand root to a multi-set of nodes. Meanwhile, a child may be either an AND-Node or an OR-Node. For a successful breach, AND-Nodes need to be sequentially/simultaneously conducted, while one OR-Node is sufficient. The math behind complex Attack Trees is somewhat complicated so we skip such mathematical representation as our case is not considered complex. More details, however, can be found in Mauw and Oostdijk (2005).
In our case, let C denote a set of attack components where an attack is a finite non-empty multi-set of C and an attack suite is a finite set of attacks. Following these definitions, we can formulate four sets of attack components, each for one of the aforementioned probable privacy threats. That is, C Data , C Location , C Identity , and C Usage , denotes attack components required to breach Data, Location, Identity, and Usage Patterns Privacy, respectively.

Data privacy
Data that may be considered private to end-users is data that can be related to certain users/organizations, such that exposing it would cause legal/personal issues to the users. Examples of data that end-users need not expose to any non-trusted entities are the used applications, the nature of the problem to be solved, the type of end-user devices/protocols used for communications and analysis, etc.
As the fog component, namely TPC, is middling between end-users and miners, BC entities can not directly read any information provided to the TPC by end-users unless they have been sent it to the BC network. However, an indirect approach is expected from malicious BC miners in trials to infer end-users' data from the SCs. For example, if the BC miner knows that a specific end-user asks for a named service/application each day at 11am, then some operational conclusions can be drawn about that end-user. However, multiple pieces of information need to be traced for a successful data privacy breach. H. Baniata, et al. Information Processing and Management 58 (2021) 102393 Specifically, we need to assure that used applications, problem nature, and end-user device/communication types are not exposed. As represented in Fig. 3, these three end-user sensitive data can be exposed either directly or indirectly. By recursively Walking on this attack tree, in all Bottom-Up possible paths, we notice that BC entities can not breach data privacy of end users. For example, a malicious BC miner needs to read the task AND search for clues about the application in which the task is being used. As the first component of the "Infer from provided info." sub-attack is UNAVAILABLE, this sub-attack can not be launched. Hence, the "Used Application" sensitive data can not be inferred, leading to proven Data Privacy from this path.
Similarly, we can see that end-user's Data Privacy can not be breached by walking on any other path. Thus, Data Privacy is guaranteed in PF-BTS.

Identity privacy
This type of privacy considers any information that may be related to any type of identity. Such identities may include the MAC address, IP Address, End-User/Organization name, etc. The identity anonymity is highly important as the NIST computer security handbook Guttman and Roback (1995) defines the Privacy as "a confidentiality term which assures that individuals control the influence of what information related to them may be collected and stored, and by whom and to whom that information may be disclosed". Practically, many types of data are useless unless coupled with the identity of its generator/owner. For example, sensitive military information are useless without recognizing what military is generating them. Consequently, we need to validate PF-BTS in terms of Identity privacy. That is, any direct or indirect information about the identity of end-users, who are requesting PF-BTS services, must be hidden from BC miners. By referring to the attack suite "a" illustrated in Fig. 4, we can notice by walking paths similar to those described in subsection 4.1.1. that no Identity Privacy breaches can be successfully conducted by BC miners against end-users. Thus, PF-BTS is proven to preserve Identity Privacy.

Location privacy
Generally, a discussion related to Location Privacy does not indicate location data that are voluntarily shared by end-users. That is, privacy preserving of such data is discussed under the umbrella of Data Privacy. Rather, Location Privacy is the term used to indicate that no end-users' location information can be inferred using their behaviour or involuntarily provided location by device's sensors. For example, even when end-users turn off all gyroscopes or location sensors in their devices, their location can still be inferred by noticing the selection criteria of communicated Access Points (AP)/fog nodes. To estimate the location of an end-user, if we know that their device connects to the closest AP/TPC, while we also know the specifications of the AP/TPC (i.e. signal strength), then we can infer that the end-user is located within a circle around the AP/TPC whose radius is known. Further, we can track the path that an end-user walks in the spacial domain by using the same above information Butt, Iqbal, Salah, Aloqaily, and Jararweh (2019). However, unless end-users voluntarily share their location data, such privacy breaches require multiple components to be successful. Accordingly, some approaches to defend against such probable Location Privacy breaches were proposed in the literature. Examples include using different selection criteria of APs/Fog nodes Ni et al. (2017), using obfuscation algorithms Yi et al. (2015), and deploying fake APs/Fog components Dong, Ota, and Liu (2015).
For the present case of PF-BTS, we need to assure that, First, the location data provided by end-users to TPC is not exposed to the BC network. Second, TPC selection criteria by end-users is not known to BC network. Accordingly, we present the Location Privacy Attack Tree illustrated in the attack suite "b" of Fig. 4. Similar to the paths described in subsection 4.1.1, we can notice that a malicious BC entity can not breach the location privacy of end users. Accordingly, PF-BTS is proven to preserve Location Privacy of end-users.

Usage privacy
This term refers to keeping data about the frequency of data being sent to the APs/TPC, or data about the patterns of using a certain service or application private Baniata, Almobaideen, and Kertesz (2020). Such data may be used by an adversary to infer H. Baniata, et al. Information Processing and Management 58 (2021) 102393 sensitive information about end-users. Examples of applications whose usage patterns are not advised to be exposed include smart homes, where the usage patterns, during specified times/periods, of fog/cloud applications may reveal the actual times of home/ application functionality. Such information may be valuable for malicious eavesdropping during down times of the facility, leading to different effective security threats. Usage patterns can be inferred by using counters to compute the times and periods of usage, and co-relate them with the intensity of computations, services, or electricity consumption. However, such information are useless without the end-users identities or locations. Since we have already proven the trustworthiness of the PF-BTS in preserving the Location and Identity Privacy measures, it is trivial to conclude that PF-BTS can be trusted to provide accountable Usage Privacy measures. This is illustrated in Fig. 4.

Total execution time of virtual resources
It is proven that the BS scheduling technique, proposed in Wilczyński and Kołodziej (2020), is able to provide more optimal solutions than FCFS, SJF, and RR approaches to problems similar to our problem. Consequently, for 't' tasks to be performed on 'v' resources, BC miners providing assignment schedules of t into v, provide better assignment solution than using FCFS, SJF, or RR alone. Moreover, ACO algorithm performs better than a random assignment on a single computer as shown in Reimann and Leal (2013); Rugwiro, Gu, and Ding (2019), and performs better than FCFS and RR as shown in Kavitha and Sharma (2019);Tawfeek, El-Sisi, Keshk, and Torkey (2013). However, the results presented in Gupta, Kumar, and Sidhu (2017) and Nosheen, Bibi, and Khan (2013) indicated an equivalency of performance of ACO compared to SJF in most cases. Depending on these results, along with the transitivity relation of the two homogeneous problems, we can logically draw some conclusions of an expected superiority of PF-BTS protocol over BS. This is because BS takes the best proposed assignment output from different miner nodes that perform FCFS, SJF, HSGA, and RR. The validity we will be seeking later is that PF-BTS outperforms BS in providing a more optimal schedule with respect to the computing cycles performed by the same tested tasks and VRs, or in providing equivalently optimal schedule using less resources. We logically present our argument as follows:

Definition:
An Optimal Schedule (OS t, v ) is the best assignment of requested computational tasks 't' to be performed on a set of available VRs 'v', in terms of minimal execution time of 'v' to perform 't'. ) proof:

Hypothesis:
To experimentally prove our expectations about PF-BTS outperforming the BS model, we implemented a simulation environment using Python 3.8 programming language 1 . We ran our code on Google Cloud Platform (GCP) using a C2-standard-8 (8 vCPUs, 3.8 GHz, 32 GB memory). In our experiment, we dedicated the first core for the FCFS computations, the second for the SJF computations, the third for the RR computations, and the remaining five cores were dedicated to the ACO computations. As mentioned in Subsection 3.1, there is no need to recruit more than one miner handling each of the scheduling algorithms of BS (i.e. FCFS, SJF, and RR). A note needs to be dropped here, that SCs can be implemented using any language specified for the used BC platform. In Ethereum, for instance, SCs are implemented using the Solidity programming language (which is very similar to Python and Java-Script), while in a Hyperledger Fabric based BC platforms, SCs are implemented using GO, node.js, or Java. However, SCs in PF-BTS are represented by the modules named (ant_alg.py, first_come_first.py, round_robin.py, and short_job_first.py) implemented using Python and can be found in the publicly available Github repository. Only because the whole simulation code was implemented using python, the SCs in our simulation used the same language so that complexity is avoided. That is, the TPC receives the computational tasks from end users, anonymize them, adds them to the templates provided in the mentioned modules (now we have SCs automatically implemented by the TPC), and finally generates them into the BC. Accordingly, the implementation of the SCs is already available in Python. If PF-BTS needs to be implemented using other language, same principles apply as in our version. For PF-BTS suggests that the Ant Colony Optimization be used, the general algorithm of the ant_alg.py is provided in algorithm 1.
As it is clarified in Fig. 5, our simulation initialized the constants, variables, lists, and matrices. Then, if the TPC was not capable of performing the tasks according to certain conditions, the tasks are anonymized and a number of SCs are generated into the BC network. The network, which in our simulation consists of 8 miners, is grouped into four different groups categorized according to the code contained in the SC they picked. Groups A, B, C, and D are miners who picked SCs with FCFS, SJF, RR, and ACO codes, respectively. Each miner runs the SC and sends its result to TPC, where the best assignment among received results from Groups A, B and C is considered the BS result. The best assignment of received results from Group D is considered the PF-BTS result. The results of the SCs of all groups, however, are pooled to be saved on the distributed, publicly available ledger for future references. The TPC compares BS result with PF-BTS result, re-acknowledges the tasks and sends the best assignment to the cloud. Finally, the cloud VMs perform the tasks to the received OS and sends the computation results back to the TPC, who forwards them back to end users. To ease the mapping of Fig. 5 into the architecture presented in Fig. 2, we color-coded the nodes in those figures such that pink coloured, blue coloured, yellow coloured, and green coloured represents the processes performed in the end users layer, fog layer, BC network, and cloud layer, respectively. The results of comparing BS with PF-BTS are presented in Figs. 6, 7 and 8.

Simulation Parameters
• We conducted 33 simulation runs in groups of 12, 12, and 9 runs, for simulating 30, 300, and 3000 tasks, respectively, that need to be computed by 5, 15, 30, and 50 VRs. Sub-consequently, we configured the number of ants differently in each group. That is, we compared the results of BS with configurations of 10, 20, and 30 ants of PF-BTS.
• In each simulation run, same tasks' length and VRs' computing capacities were input into all generated SCs. • Each VR is assigned a random computing capacity that ranges from 4 to 48 MFLOPS. • Each task is assigned a random length that ranges from 100 to 1000 MFLO. • The TPC was assigned a computing capacity of 20 MFLOPS. Accordingly, a maximum total execution time of generated tasks in TPC was configured to be 80 seconds. If this condition was met, the tasks were performed in the fog layer (i.e. the BC miners, the SCs, and the Cloud are not exploited).
• Evaporation factor is stated as 0.3 • One minute cost of VM is stated as 0.1 cent/minute.

Network load
In this subsection, we study a case where computational tasks are sent to the cloud by end user devices. Consequently, we compare PF-BTS with BS w.r.t. two criteria, namely the number of messages exchanged M from the moment of generating the tasks until the results are forwarded back to end users, and the time consumed by the BC network to generate its suggested schedule. To provide a comprehensive evaluation, we considered the two states of the TPC: able to perform the tasks, and unable to perform the tasks.

Exchanged messages
The proposed steps in PF-BTS imply that the following messages shall be exchanged. End-user devices send the tasks to the fog node, the messages used for this step are denoted by M t . The cloud sends the available VRs to the fog node, the messages used for this step are denoted by M v . The TPC then generates SCs containing the IDs of the tasks, the length of each task/group of tasks, and the available resources. The messages used for this step are denoted by M i . The BC miners then start the process to produce the optimal schedule. We denote the messages exchanged between miners until reaching a consensus by M c . In PF-BTS, M c equals exactly the number of SCs, since each SC sends one message to the TPC. However, M c in BS increases due to the PoSch consensus algorithm. After the optimal schedule is sent to the cloud by the TPC, which is denoted by M p , the cloud sends the computation results back to end users with M r . In contrast, we expect PF-BTS to require a number of exchanged messages that equals ≈ where q is the number of generated SCs. Consequently, we can conclude the following: Nevertheless, if the computational tasks were performed in the fog node, a property that is available in PF-BTS, then the required number of exchanged messages will be equal to ≈ M t + M r . This is a significantly less number of exchanged messages, than in BS.

Time needed by BC network to generate the optimal schedule
The time required to confirm the optimal schedule might also be critical for some delay-sensitive applications. In BS, the average time consumption to confirm a randomly generated schedule was 0.07 seconds. However, the presented time measurements aimed to highlight the time needed for the PoSch algorithm to reach a consensus on a proposed random schedule, where only four miner nodes were deployed to assign an average of 3 tasks to an average of 3 VRs. Bearing in mind that more BC miners deployment shall increase the confirmation time, due to the 50% of miners agreement rule of PoSch, the scalability and delay-tolerance properties of BS can be deduced differently for different cases.
Supposing that each miner node in BS has a computing capacity as randomized as the VRs of the cloud, a maximum computing capacity of a miner equals 12 MFLOPS. However, the average computing capacity of public BC miner nodes, as reported in Betelgeusian (2018), ranges from 336 MFLOPS to 18,000,000 MFLOPS. This is due to the deployment of the Graphical Processing Unit (GPU) for performing BC computations. Accordingly, the slowest miner node in PF-BTS performs 28 times faster than the fastest miner node in BS. Further, PF-BTS instantly compares all received schedules in the fog node, hence no consensus time consumption is expected.
To highlight the time, in a PF-BTS system, needed from sending the tasks and VRs capacities to the BC network until getting the schedules back from them, we conducted a different experiment. First, we conducted a simulation run where eight tasks need to be assigned into four VRs, the assignment job was distributed to 16 BC miner nodes (16 SCs were generated) with each running 10 ants. The 16 miners sent their assignment suggestions to the TPC within 0.03 seconds. Obviously, this is a better result than the one gained by BS, despite that there were 16 miner nodes involved instead of 4, and the schedules provided are optimal rather than random. Second, we conducted six other simulation runs where five VRs are expected to execute fifty tasks. We ran the simulation for a number of miner nodes ranging from 5 to 16, each miner ran 10 ants. The results we obtained are represented in Fig. 9.
Following the mentioned insights, PF-BTS is expected to outperform BS in terms of schedule generation/confirmation time. A note to be mentioned, ACO algorithm consumes much time to iterate when its input tasks counts in thousands, hence a suggestion of the PF-BTS algorithm is to group each thousand tasks into one block and give the block one ID, as if it was one task that has a computational length of the summation of all tasks lengths.

Conclusion and future work
In this paper, we proposed a Privacy-aware Fog-enhanced Blockchain-assisted Task Scheduling protocol, called PF-BTS. Our proposed protocol deploys the ACO algorithm to find the best assignment schedule of tasks into the cloud's virtual resources in a secure manner. We discussed, how PF-BTS preserves the privacy of end users by keeping their identities, location, and tasks anonymous for BC miners. The cloud utilizing PF-BTS receives the best assignment of tasks into its VRs, in terms of total execution time of the virtual resources. We have shown how our proposed protocol outperforms several previously proposed approaches for solving similar problems, in terms of privacy, efficient scheduling of the virtual resources, and minimal exchanged messages. Moreover, PF-BTS allows the fog node, as an extension of the cloud, to perform the computational tasks at the edge of the network. Hence, we expect that PF-BTS will compensate any increased network load by decreasing the required computational cycles performed by the VRs.
Our future work will be directed towards experimenting other optimization approaches that are competitive with ACO, such as the ACTS-LB Li and Wu (2019), MO-ACO Guo (2017), or the Black Hole Hatamlou (2013) algorithms. We will also investigate the output of BC nodes in terms of assignment solutions quality and time consumption, by enforcing multiprocessing and multi-threading techniques in each miner node. Further, we will investigate the deployment possibilities of SC results into side-chains, and then accumulating all the blocks into one block to be saved on the root chain (similarly to Plasma BCs Ziegler, Gromann, & Krieger (2019)). Such approach may enhance the scalability measures of PF-BTS, and facilitate easy analysis of on-chain data. H. Baniata, et al. Information Processing and Management 58 (2021)