Figure 2 shows a cloudlet which hosts a blockchain miner and coordinates the whole blockchain based MAC. It also maintains a credit based rewarding system and a ranking based reputation system for maintaining the reliability of the data analysis performed by the participants of the MAC. This section covers the details of blockchain along with its importance in implementing the rewarding and reputation system in MAC.
Distributed ledger of blockchain
Blockchain  has already been proven for removing dependency on a single entity and distributing authority among multiple independent entities. Bitcoin is the first and most popular application based on the blockchain . However, now it has been used in many different types of applications . There are many important features in blockchain that makes it unique and effective in comparison to other application development techniques. Among all these features, the immutable shared ledger is considered as one of the salient feature of blockchain. Blockchain achieves the immutability by linking multiple blocks of the blockchain through the one-way hash, which cannot be modified or decrypted.
The first block of the blockchain is known as the genesis block and its hash is included in the second block as a data element. Hash of the second block is included as a data element in the third block and thus any change in any of the previous blocks alters the hash of the final block of the blockchain. This ensures the immutability of blockchain and it is shared with all the participants so that everyone can keep an eye on the growth of the blockchain. Blockchain has been used for storing the earned credits and reputation score of the participating mobile devices. Since the blockchain is shared with all the participants as an immutable ledger, therefore, even the owner cannot modify or remove the existing data of the blockchain. This feature of blockchain gives confidence to the participants of the MAC that their earned credits and reputation rank will remain intact.
Types of blockchain based on read/write access
In contrast to other storage systems, data can only be created or extracted from the blockchain. Figure 3 refers to the data creation rights under the names of blockchain types while the data reading rights over the same names. Data is written in blockchain by adding new blocks with the existing blocks of the blockchain and it is the responsibility of the miners to decide which block is legitimate that can be added in the blockchain. Miners run a consensus algorithm to check if a block is accepted as a legitimate block or not. Following are the details of each blockchain category with respect to the access of data reading and writing:
In Private blockchain only the central authority decides which nodes can get the blockchain ledger. Private blockchain restricts the ledger to the participating nodes only. With respect to the data writing feature, only the owner hosts the miner and no other participant can claim the mining rights. In the case of MAC, blockchain is heavy  therefore, we have used the private blockchain (also known as permissioned-blockchain) to restrict the mining at the cloudlet only.
In public blockchain anyone can join the blockchain network and can get the blockchain ledger for reading purpose. Similarly, anyone can also join as the miner as well.
In consortium blockchain some of the predefined members can read or write the data to the blockchain.
Semi-private blockchain is in-between the private and consortium blockchains. In semi-private blockchains, there is an owner which selects the consortium members and can also update these members as well. Selected consortium members act similar to the members of consortium blockchain.
Iroha based private blockchain for MAC
Iroha  is a project of hyperledger by Linux foundation which was proposed in 2016 by Colu, Hitachi, NTT Data and Soramitsu. It is developed in C++ and is specifically targeting mobile devices by offering the libraries for iOS and Android platforms. Some of the other libraries come with Iroha are ed25519 library for digital signatures, SHA-3 hashing library, a serialization library for transactions, a P2P library, an API server library etc. The main strength of Iroha is its lightweight nature which makes it a perfect solution for mobile applications.
Following are the three main objectives that we are achieving through the integration of blockchain within MAC:
As permissioned-blockchain has been implemented using Iroha, only the authenticated mobile devices can join as the participant of MAC.
The participants of MAC have been incentivized by offering the credits against the computation performed by these devices and the utilization of blockchain for storing the details of earned credits (covered in Section 3.4). This is done in order to gain the confidence of the participants.
Malicious device detection algorithm (covered in Section 3.5) generates a reputation rank for each of the participants of the MAC and uses the blockchain for retrieving the previously stored rank and storing the updated rank. All of the generated ranks are shared with all the participants of the MAC and this policy of transparency again employed to gain the trust of the participants.
Blockchain based credit system for Incentivizing the crowdsourcing
Crowdsourcing is an important way of offloading the computation and the computation based crowdsourcing is sometimes termed as the crowd computing . Since the participants of crowdsourcing are self-interested and rational therefore, a proper incentivizing system is required to convince them  for sharing their resources to join as the participant of the crowdsourcing. Research also suggests that a rewarding system is the best option for motivating and getting better results from participants of crowdsourcing . Credit-based rewarding system not only used for incentivizing the participants but also using blockchain for earning the trust of the participants. This section presents the importance of blockchain for implementing the reliable rewarding system in MAC.
Figure 4 shows the procedure of earning credits through our private blockchain network. Cloudlet hosts the validating device and it controls the growth of the blockchain. All the participants of MAC are acting as non-validating devices of MAC. Step 1, 2 and 3 in Fig. 4 show the requests made by the non-validating devices and following are the details of each of these steps:
Step 1: A new non-validating device makes a request for joining the MAC. This request is received by the validating node of Iroha based blockchain network which generates a unique id for the requesting node along with the unique private key (which will act as its signature) and returns it to the requesting node.
Step 2: An already registered non-validating device uses its id and signature for getting the data for analysis from the validating device. Validating device not only gives the computation task to the non-validating device but also assign an id to the task and broadcasts the starting time of each task to all the participants of MAC so that these nodes can store this information in their distributed ledgers of blockchain.
Step 3: Non-validating device uses the id of the task, along with its signature, for submitting the response to the validating device which again broadcasts the end time of the computational task along with the details of earned credits against that task to all the participants of MAC.
Before this final broadcast, at the end of step 3, validating device first confirms the accuracy of the submitted result by the non-validating device. This is to ensure that reward can only be claimed after legitimate computational efforts. However, for some of the scenarios, the results can be easily verified with almost negligible computation effort like the popular way of finding nonce, during the mining process of bitcoin . However, for the results of other computational operations (e.g. mapReduce), an equal amount of computation is required for both producing and verifying the results. In that case, there is a need to reduce the computation for verifying the results and this is what we have achieved in this paper. More details of the proposed approach are given in the next section.
Blockchain based reputation system for reliable crowdsourcing
Berkeley Open Infrastructure for Network Computing (BOINC) is the popular computational crowdsourcing project and it uses the task replication for the verification of the results . However, this task replication takes the duplication of computational and we have developed an algorithm to reduce the number of reanalyses for verifying the results of data analysis through crowdsourcing. Our algorithm is based on the blockchain based reputation system and this sub-section covers its details.
Figure 5 illustrates the algorithm for providing reliable data analysis by identifying the malicious nodes. The main idea of the algorithm is to categorize the non-validating devices into following four categories (also given in the Fig. 4 of evaluation scenario):
Non-trusted Devices: When a new non-validating device joins the MAC, it is considered as the non-trusted device and a threshold, defined by the validating device, is required to convert the non-trusted device into a trusted device. Whenever a result is submitted by a non-validating device, it is being verified through the reanalysis by the trusted devices. Upon each correct submission, the device gets the increment in the rank and it is being shifted to trust device after gaining the rank more than the threshold.
Trusted Devices: As a trusted device has already submitted the correct results after many iterations therefore, no more verification is performed for the results submitted by the trusted devices.
Malicious Devices: Each device which will submit the fake results in the future is nominated as the malicious device and it can be a trusted or a non-trusted device. Algorithm given in Fig. 5 is focused on finding both trusted and non-trusted malicious devices and results given in Fig. 7 have shown the effectiveness of our proposed algorithm in finding the malicious devices.
Blocked Devices: Once a malicious device is identified with a fake result submission, it is shifted to the group of blocked devices and no further computational tasks are granted to that device.
The steps of algorithm illustrated in Fig. 5 are presented below:
Response1 is the response generated after the analytics.
Status of Response generating node is collected to determine if this response needs the validation or not?
If the score of response generating node is greater than the threshold value then it is considered as the trusted node else it is marked as the non-trusted node.
If the node is trusted then both of its credit and score are updated in the blockchain.
If the node is non-trusted then the response is pushed to an empty array of RESPONSES.
The next step is to find the trusted node which is having a score more than the threshold value.
Existence of the trusted node is confirmed to verify the data generated in Response1.
If there is no existing trusted node in the MAC network then Miner of cloudlet performs the analysis by itself to verify if the non-trusted node has submitted the correct response.
Miner updates the blockchain by increasing the score and credit in case of correct response or shifts the response generating node to the malicious group, if the generated response of miner does not match the generated response by the non-trusted node.
If the trusted node found then the least trusted node is selected which is having the least score, after passing the given threshold value.
The same analysis of non-trusted node is performed by the trusted node N to confirm if the generated response is correct or not.
Trusted node N returns the ResponseN against the same data and analysis of non-trusted node.
Responses array may contain one or many responses and the ResponseN is compared with the existing responses in the array of RESPONSES.
If the ResponseN matches any of the responses in the RESPONSES array then it not only validates the matching results but also prove its trustfulness.
If the ResponseN generated by the trusted node N does not match any of the existing responses then its result also needs to be validated and thus being pushed to the array of RESPONSES.
This is not the last step of the algorithm as it again starts the validation of all of the existing responses in the RESPONSES array. This loop will keep on repeating until it exits in one of the following two ways:
At point 15, after being verified by a more trusted node.
At point 9, after being verified the cloudlet based miner. It only happens if none of the results in RESPONSES array is matched after being iterating the all trusted nodes. In that case, miner will update the blockchain by placing all the nodes of non-matching results in the category of malicious nodes.