Project — Building a Simple Blockchain-based Crowdsensing System

Posted on | In

Project — Building a Simple Blockchain-based Crowdsensing System

Author: Lingkun Kong, Linghe Kong, Please indicate the source for reproduction.

Abstract

Motivated by constructing a crowd-sensing system with security and low services fee, we propose building a blockchain-based crowd-sensing framework that replaces traditional triangle architecture by decentralized blockchain system. Also, in order to accelerate the formation of the fabric of trust, instead of releasing a new virtual currency, the proposed framework implements applications of smart contracts to reward sensing-task workers which offers reliable anonymity. Also, by leveraging blockchain technology in crowd-sensing, the proposed framework is also an exploration on the mining puzzles of proof-of-usefulness.

Background and Motivation

Crowd-sensing systems, which take advantage of pervasive mobile devices to efficiently collect data, have gained considerable interest and adoption in recent years [1][2]. However, the majority of existing crowd-sensing systems rely on central servers, which are subject to the weaknesses of the traditional trust-based model, such as single point of failure and privacy disclosure [3][4]. They are also vulnerable to distributed denial of service (DDoS) and Sybil attacks due to malicious users’ involvement [5]. In addition, high service fees charged by the crowd-sensing platform which has monopolized the market may stem the development of crowd-sensing. How to address these potential issues remains to be an open problem.

There have been several studies to deal with part of the aforementioned open problem [6-10], while the majority of these researches are built on the traditional triangular structure crowd-sensing models, which suffer from breakdown of trust. Thus, this research proposal is motivated by this: Can we design a decentralized crowd-sensing system with security and low services fee?

Introduction of Blockchain-based Crowd-sensing System

The past few years have witnessed the emergence of blockchain as well as its multiple applications [11,12,16,17,19,22], which provides us an opportunity to solve all of the above issues in crowd-sensing systems simultaneously. Therefore, I propose building a blockchain-based decentralized framework for crowd-sensing, with the purpose of alleviating privacy leakage and reducing the charge of the central platform.

To illustrate, by leveraging blockchain architecture, we can replace the centralized crowd-sensing platform by decentralized blockchain system. Therefore, the services fee charged by the platform can be used more efficiently, as it now is all paid to workers and blockchain miners [14]. Also, since now the crowd-sensing process does not depend on any central third party, there is no single point of failure issue. Besides, for the sake of properties of blockchain, we can guarantee privacy by allowing users to register without true identity and storing encrypted sensory data in the distributed database. Further, by stipulating that each identity must make a deposit before participation in smart contract protocols, we can efficiently prevent various attacks (e.g. DDoS, Sybil and “false-reporting” attacks [13]).

In the context of blockchain applications, current prevalent blockchain-based systems such as Bitcoin [11], Litecoin [16], and Zcash [17], etc., always issue virtual currencies to incentivize miners and try to convince both miners and users that the virtual currency is worthy of being hold. However, to earn the trust from users and maintain the fabric of trust are quite difficult. Also, legal problems always ensue the issue of virtual currencies, and Governments worry about the high anonymity within currency systems will found the breeding ground for the crime [18]. When dealing with crowd-sensing problems, it is unrealistic to quickly build the reputation of the system and win the trust from users by issuing new virtual currencies. Additionally, with the awareness of legal issues, it is impractical to universally apply systems which release the virtual currency.

Moreover, in traditional blockchain-based systems, there’s a concern that Bitcoin mining is extremely profligate, since massive energy is wasted by miners in solving “useless” puzzles for block discovery [21]. Thus, “Is there a puzzle, whose solution provides useful benefit to society, while still satisfying the basic requirements of Blockchain puzzles?” is raised to be a natural question. There have been several studies which attempted to reduce blockchain-based system’s energy waste, such as Primecoin and Permacoin [19,22]. However, their methods are not feasible for a lot of potential candidates such as problems of protein folding [23], space signal searching [20], which are of great scientific usefulness while needs a trusted administrator. In this case, building a blockchain-based crowd-sensing framework will also be an exploration of the proof-of-usefulness puzzle, which might be helpful to reduce the energy waste in traditional blockchain systems.

Faced with these challenges, in our proposed framework, we introduce applications of smart contracts to reward users, which should be first initiated by sensing-task requesters with certain reserve money. On the one hand, by this method, we can build the reputation of the framework and raise the enthusiasm of both miners and workers in a short time. On the other hand, since there is deposit in the smart contract, and the methods of getting rewards are substantiated by published smart contract, both requesters and workers can trust the immutable codes from published smart contract as a credible administrator. Therefore, the new framework will be feasible for broad implementation of proof-of-usefulness puzzles.

Specifically, the traditional crowd-sensing process consists of three groups of roles: requesters, workers and a centralized crowd-sensing system, where requesters submit tasks to the system and receive sensing results from the system; workers pull tasks from the system, complete tasks they interested in and submit sensing results to the system; the centralized system deals with submissions from requesters and workers and responds them accordingly. Figure below presents the crowd-sensing by traditional centralized systems.

In the blockchain-based decentralized system which we propose, there is no centralized platform in crowd-sensing process anymore. Instead, by leveraging blockchain techniques, the crowd-sensing process is managed by a decentralized system, which is presented in Figure below.

Basically, the crowd-sensing process can be divided into following steps:

Step1: Requesters post tasks, and, meanwhile, they need to initialize the examining rules and send to communication platform, which, in our design, actually is to publish a smart contract and then create the function in smart contract.

Step2: Workers, by querying blockchain and fetching message from communication platform, i.e., querying the published smart contract, obtain attractive sensing tasks. After finishing tasks by recording sensing data, they post the message to the communication platform, i.e., call specific functions in smart contracts.

Step3: By querying blockchain and listening to the communication platform, miners fetch unsubstantiated sensing data, and they can examine the quality of this data based on rules the requester establishes. After miners substantiate the quality of sensing data, they will get the reward after pushing processed sensing data into blocks. In general, miners obtain reward by contributing computing power for running smart contracts.

Step4: Requesters listen to the blockchain periodically. Once they are satisfied with sensed data or decide to not continue collecting data for other reasons, they can send message to the system to burn the blockchain and get the remained reserve money from smart contract. As this message will be broadcasted in the system, miners and workers will then cease to work.

Detailed Implementation of Smart Contract

Additionally, we propose to add applications of smart contracts over the whole framework with the purpose of quickly obtaining users’ trust and making the design feasible for various purposes, such as aforementioned problems of protein folding and aliens discovery. Figure below shows the structure of decentralized system after adding smart contracts.

In this figure, the number indicates the order of the operation in a certain crowd-sensing task, where operation 3* means this operation can be processed concurrently with operation 3, and operation mark x means this operation can be undertaken in any time after operation 2. Moreover, the solid lines in the figure stand for operations being necessarily done in a certain task, while the unfilled lines indicate these operations might not be properly processed.

In this system, the requester enters in the system and create the smart contract by setting requirements for sensing data and stores a certain amount of deposits for determining the rewards. After that, once workers are attracted by the rewards as well as their data are substantiated by miners, they can get rewards stored in the smart contract protocol right away. Therefore, the reputation of this system can be quickly built, and the enthusiasm of both miners and workers can be aroused as once they got works done, they can receive valuable rewards. Also, since rules are “printed” in the smart contract, both workers and miners can trust the published smart contract as a credible administrator. Therefore, the challenge of lacking trusted administrators for puzzles like protein folding and space signal searching is overcome in this proposed framework.

Remarks: The submission of collected data will cost workers certain amount of gas in smart contract. In fact, it is tantamount for workers to make security deposits before participation in crowd-sensing task, which efficiently prevents various attacks (e.g. DDoS, Sybil and “false-reporting” attacks [13]).

Using an Simple Example to Show How the System Works

Here, we use a simple wifi-sensing task to show how the system works.

First of all, we present the source code of smart contract of wifi-sensing.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
pragma solidity ^0.4.21;

contract SensingWifi{
    uint public rewardUnit;
    uint public rewardNum;
    uint public dataCount;
    bytes32 public wifiName;
    address public requester;
    enum State {Uncreated, Created, Inactive}
    State public state;

    mapping(bytes32 => string) dataStatuses; // Either '' or 'Committed'

    modifier condition(bool _condition) {
        require(_condition);
        _;
    }

    modifier onlyRequester() {
        require(msg.sender == requester);
        _;
    }

    modifier inState(State _state) {
        require(state == _state);
        _;
    }

    event Aborted();
    event TaskInited(uint ru, uint rn, bytes32 wn);
    event ViewTask(uint ru, uint rn, bytes32 wn, uint cnt);
    event DataCommited(bytes32 l, bytes32 w, int s);
    event TaskDone();
    event dataCheck(uint cnt);

    // Init the task as requster.
    // The requster need to set the value of reward for each sensing data,
    // as well as the maximum number of data he needed.
    function initTask(uint _rewardUnit, uint _rewardNum, bytes32 _wifiName)
        public
        inState(State.Uncreated)
        condition(msg.value >= _rewardUnit * _rewardNum)
        payable
    {
        requester = msg.sender;
        rewardUnit = _rewardUnit;
        rewardNum = _rewardNum;
        wifiName = _wifiName;
        state = State.Created;
        emit TaskInited(_rewardUnit, _rewardNum, _wifiName);
    }

    // Abort the Task and reclaim the ether,
    // Can only be called by the requester.
    function abort()
        public
        onlyRequester
        inState(State.Created)
    {
        require(dataCount <= rewardNum);
        state = State.Inactive;
        requester.transfer(this.balance);
        emit Aborted();
    }
    
    function getDataCnt()
        public
        onlyRequester
        inState(State.Created)
    {
        emit dataCheck(dataCount);
    }
    
    // Worker answer the task by sending data
    // such as {"41-24-12.2-N 2-10-26.5-E", "SJTU", -51}
    
    function getTask()
        public
        inState(State.Created)
    {
        emit ViewTask(rewardUnit, rewardNum, wifiName, dataCount);
    }

    function commitTask(bytes32 _location, bytes32 _wifiName, int _signalDegree)
        public
        inState(State.Created)
    {
        require(dataCount < rewardNum);
        bytes memory sensingDataCommit = bytes(dataStatuses[_location]);
        // Requester wants to get data from different location
        require(sensingDataCommit.length == 0);
        
        // Make sure that the wifi signal sensed is what requester wants
        require(wifiName==_wifiName);
        
        // The theoretical maximum value of signal strength is -30 dBm
        require(_signalDegree < -30);
        
        dataStatuses[_location] = "Committed";
        
        dataCount += 1;
        if(dataCount == rewardNum){
            state = State.Inactive;
            requester.transfer(this.balance);
            emit TaskDone();
        }
        msg.sender.transfer(rewardUnit);
        emit DataCommited(_location, _wifiName, _signalDegree);
    }
}

Functions for Requesters:

For requesters, they are the initiators of the wifi-sensing tasks. Therefore, they have responsibilities to write the smart contract and initiate the wifi-sensing task.

initTask(): Requesters can call the initTask() function to create a wifi-sensing task and determine the rewards for each processed sensing data. In this function, requesters need to save certain amount of deposits in the smart contract and specify the value of each reward as well as the maximum number of data required.

abort(): Requesters have the rights to abort the task once they believe they have collected enough data by viewing the number of data in getDataCnt(). This function will give requesters refunds of their deposits.

Also, we developed a simple interface for users to play the role as requesters, and figure below is the screenshot of the interface.

Here, users, playing as requesters, create a wifi-sensing task by setting Value of Each Reward as 100000000 wei, number of Data Required as 5 and wifi name as SJTU. Similarly, users can abort the task and check the current status of the task by click buttons of Abort and Check. The text beneath the title of Wifi Sensing — Requester will present corresponding information.

Functions for Workers:

For workers, they choose the tasks they are interested in and submit data for this tasks. Here we assume that workers are interested in the wifi-sensing task and try to work for it.

commitTask(): Workers call this function to submit their collected data. Before they submit their data, they need to watch carefully about the requirements of the data “enacted” by the requesters as they are writers of commitTask() function. Here, for example, requesters need the data of wifi signal which are collected from different places, named as SJTU and measured to be restricted in a conscionable range. To be noticed, if data submitted by the workers do not meet the requirements, workers cannot receive a single penny from their work but waste money in paying the transaction fee, i.e., gas to miniers. Therefore, workers need to be really careful when trying to submitting the data, and it is always a good idea for workers to call getTask() function first though a little amount of gas fee will be costed (about 0.00011 ETH ~ 0.05 USD in 04/11/2018).

We also provide a simple interface for workers to submit their data and get reward.

This figure is about the screenshot of worker interface after a worker clicking the View Task button.

This figure presents the screenshot of worker interface after a worker submits his data by clicking Commit button.

The interesting thing is that as in this example, the requester sets 100000000 wei (about 0.00000000001 ETH) as the value of each reward, which is much smaller than the costs of gas fee the worker pay for calling commitTask() and getTask() function (about 0.00046 ETH). Therefore, the worker fells into the trap set by the requester — the worker works for requester and loses money. In other words, the worker actually needs to be really careful when calling getTask() to view the reward of each data, since he can only earn money as long as the reward of each collected data is larger than transaction fees paid to hidden miniers (in this case, the reward should be larger than 0.00046 ETH).

Remarks for Miners: The miners are hidden behind the smart contract, and they earn money by contributing their computing power to run the complied program in smart contracts. Actually, both requesters and workers pay for miners by providing gas fee.

The source code of smart contract as well as the interfaces has been published on the webpage: https://github.com/Ohyoukillkenny/BCS

Analysis of the Blockchain-based Crowd-sensing System

In this part, we briefly analyze our blockchain-based crowd-sensing system from the aspects of security and the financial efficiency.

Security:

  1. By implementing smart contracts, the anomynity of workers as well as requesters can be highly assured, since they only know the ETH accounts of each others. Also, for workers, if they believe their collected data may include several private information which make them uncomfortable to share, they can directly refuse to submit the data.
  2. As we have mentioned in the Remark of Introduction of Blockchain-based Crowd-sensing System, workers actually need to make security deposits, i.e., pay transaction fees to miners, before participation in crowd-sensing task, which efficiently prevents various attacks (e.g. DDoS, Sybil and “false-reporting” attacks [13]).
  3. One potential attack of our system is so called front-run attacking, which has been leveraged in attacking Bancor protocol [27]. In our schema, attackers can use front-run attacking to steal the rewards which are supposed to provide to workers. To illustrate, attackers always listen to the network , fetch the submitted data from workers and then submit these data immediately. Since many crowd-sensing tasks require the uniqueness of the data and the attacker has chances to get submitted data substantiated by miners earlier, the “real” worker might not be able to get his reward as expected. However, there has been several solutions which we can refered to avoid this attack, even in the article [27] which discovered the front-run attacking toward applications of smart contracts. In fact, in our system, we can simply spread rumors among the networks to prevent this attack. That is we can submit a lot of invalid data to the smart contract while not confirm it, otherwise we will waste transaction fee. When attackers fetch these rumor message, they, however, will directly submit this message and waste a large bunch of money. Therefore, the attacking will be stemed.

Financial Efficiency:

The minimum cost of requesters for each data largely depends on the cost of transaction fee workers need to pay. This is because if the reward for each data cannot cover the transaction fee workers need to pay for submitting the data, no one will be willing to work for the requester.

Therefore, using the wifi-sensing task as an instance, we use the table below to briefly count the average cost of transaction fees workers need to pay by lauching experiments of the participation of 1000 workers.

Cost of getTask() Call Cost of commitTask() Call Size of the Data avg Total Cost
0.00011 ETH 0.00041 ETH 97.8 bytes 0.00052 ETH

Due to the violent fluctuation of the price of ETH, it is hard to evaluate the value of 0.00052 ETH in real-world market. Here we use the exchange rate between USD and ETH in 04/11/2018 [28] to roughly estimate the the value of 0.00052 ETH as 0.217 USD, which means that requesters need to pay each wifi-sensing data for at least 0.217 USD.

This value might be too high for a simple wifi-sensing task. However, when the data the requester attempts to collect are essentially sensitive and require high anonymity, e.g., personal income, medical history and etc., this price might be totally acceptable. After all, the key advantage of decentralized crowdsensing system is to break the control of centralized data manage system as well as the monopoly price of data-sensing task. We hope our blockchain-based crowd-sensing system can offer users an another option when try to participate in crowd-sensing tasks.

Conclusion

To sum up, in this article, we propose building a blockchain-based crowd-sensing to make up for the paucity of decentralized crowd-sensing systems with security and low services fee. Since we are still in the early stage of blockchain technology, this project will be of importance to research in distributed systems by providing a concrete blockchain-based solution for a known scientific problem, i.e., crowd-sensing management.

Reference

[1] Ma, H., Zhao,D., & Yuan, P. (2014). Opportunities in mobile crowd sensing. IEEECommunications Magazine, 52(8), 29-35.

[2] Zhang, X.,Yang, Z., Sun, W., Liu, Y., Tang, S., Xing, K., & Mao, X. (2016).Incentives for mobile crowd sensing: A survey. IEEE Communications Surveys& Tutorials, 18(1), 54-67.

[3]Vergara-Laurens, I. J., Jaimes, L. G., & Labrador, M. A. (2016).Privacy-preserving mechanisms for crowdsensing: Survey and researchchallenges. IEEE Internet of Things Journal.

[4] Pournajaf, L.,Xiong, L., Garcia-Ulloa, D. A., & Sunderam, V. (2014). A survey on privacyin mobile crowd sensing task management. Tech. Rep. TR-2014–002.

[5] Krontiris, I.,Langheinrich, M., & Shilton, K. (2014). Trust and privacy in mobileexperience sharing: future challenges and avenues for research. IEEECommunications Magazine, 52(8), 50-55.

[6] Cardone, G.,Foschini, L., Bellavista, P., Corradi, A., Borcea, C., Talasila, M., &Curtmola, R. (2013). Fostering participaction in smart cities: a geo-socialcrowdsensing platform. IEEE Communications Magazine, 51(6), 112-119.

[7] Cardone, G.,Cirri, A., Corradi, A., & Foschini, L. (2014). The participact mobile crowdsensing living lab: The testbed for smart cities. IEEE CommunicationsMagazine, 52(10), 78-85.

[8] Hamm, J.,Champion, A. C., Chen, G., Belkin, M., & Xuan, D. (2015, June). Crowd-ML: Aprivacy-preserving learning framework for a crowd of smart devices.In Distributed Computing Systems (ICDCS), 2015 IEEE 35th InternationalConference on (pp. 11-20). IEEE.

[9] Jayarajah, K.,Balan, R. K., Radhakrishnan, M., Misra, A., & Lee, Y. (2016, June).LiveLabs: Building In-Situ Mobile Sensing & Behavioural ExperimentationTestBeds. In Proceedings of the 14th Annual International Conference onMobile Systems, Applications, and Services (pp. 1-15). ACM.

[10] Han, G., Liu,L., Chan, S., Yu, R., & Yang, Y. (2017). HySense: A Hybrid MobileCrowdSensing Framework for Sensing Opportunities Compensation under DynamicCoverage Constraint. IEEE Communications Magazine, 55(3), 93-99.

[11] Nakamoto, S.(2015). Bitcoin: A Peer-to-Peer Electronic Cash System. November 2008.

[12] Swan, M.(2015). Blockchain: Blueprint for a new economy. “ O’Reilly Media,Inc.”.

[13] Zhang, X.,Xue, G., Yu, R., Yang, D., & Tang, J. (2015). Keep your promise: Mechanismdesign against free-riding and false-reporting in crowdsourcing. IEEEInternet of Things Journal, 2(6), 562-572.

[14] Li, M., Lu,W., Weng, J., & Yang, A. (2017). CrowdBC: A Blockchain-based Decentralized Framework for Crowdsourcing. IACR Cryptology ePrint Archive, 2017, 444.

[15] https://en.wikipedia.org/wiki/PayPal

[16] Greenberg, A.(2016). Zcash, an untraceable bitcoin alternative, launches in alpha.

[17] Lee, C.(2011). Litecoin.

[18]http://www.gov.cn/gzdt/2013-12/05/content_2542751.htm

[19] King, S.(2013). Primecoin: Cryptocurrency with prime number proof-of-work. July7th.

[20] https://setiathome.berkeley.edu/

[21] https://motherboard.vice.com/en_us/article/aek3za/bitcoin-could-consume-as-much-electricity-as-denmark-by-2020

[22] Miller, A.,Juels, A., Shi, E., Parno, B., & Katz, J. (2014, May). Permacoin:Repurposing bitcoin work for data preservation. In Security and Privacy(SP), 2014 IEEE Symposium on (pp. 475-490). IEEE.

[23] Dill, K. A.,& MacCallum, J. L. (2012). The protein-folding problem, 50 yearson. science, 338(6110), 1042-1046.

[24] Ron Rivest, Leonard Adleman, and Michael L. Dertouzos. On data banks and privacy homomorphisms. Foundations of Secure Computation, 1978.

[25] Craig Gentry. Fully homomorphic encryption using ideal lattices. STOC, 2009.

[26] Jake Loftus, Alexander May, Nigel P. Smart, and Frederik Vercauteren. On CCA-Secure Fully Homomorphic Encryption. Cryptology ePrint Archive 2010/560.

[27] https://hackernoon.com/front-running-bancor-in-150-lines-of-python-with-ethereum-api-d5e2bfd0d798

[28] https://coinmarketcap.com/