Sage Journals: Discover world-class research

Abstract

The crowdsourcing schemes which utilize the social network to solve complex tasks are an important part of open cooperation over the Internet. Although blockchain-based crowdsourcing schemes have considerable advantages in decentralization and data sharing, there is still a challenge to gurantee the security of crowdsourced-sensitive information and the fairness of crowdsourcing on the blockchain. To this end, this article investigates a crowdsourcing scheme based on blockchain. First, we define the basic requirements of blockchain-based crowdsourcing schemes including fairness, confidentiality, and integrity. And then, using secure hash, commitment, and homomorphic encryption, we propose a blockchain-based secure and fair crowdsourcing scheme, that is, BFC. The analysis results show that our scheme can satisfy the above requirements. Finally, the experimental results show that the computational overhead of the BFC scheme is acceptable to both the requester and the workers. In a word, our proposed crowdsourcing scheme has good expansibility in reality.

Keywords

Crowdsourcing scheme blockchain secure hash commitment homomorphic encryption

Introduction

In recent years, the rise of crowdsourcing has attracted more and more attention. Therefore, many companies adopt crowdsourcing models on the Internet to solve some difficult problems in a distributed manner. The crowdsourcing schemes are a distributed problem-solving model for publicly recruited solutions.^1,2 Traditional social-network-based crowdsourcing schemes include three types of participants:³ requester, workers, and a centralized crowdsourcing platform. The requester publishes a crowdsourcing task and a corresponding incentive policy. A group of workers interested in the task submit the solutions to the crowdsourcing platform. Then, the platform will select the appropriate solutions and reward the prominent workers. When there is a dispute between the requester and the worker, the third-party platform will arbitrate the crowdsourcing process.^4,5 For example, voting mechanism⁶ and auction mechanism⁷ are typical crowdsourcing tasks in real life.

Traditional centralized crowdsourcing schemes require third-party platforms to ensure that the crowdsourcing process is readily conducted to achieve a fair exchange between crowdsourcing solutions and rewards.⁸ However, this model brings many inevitable challenges to crowdsourcing. First, the crowdsourcing schemes, which rely entirely on centralized servers to maintain the crowdsourcing, are not suitable for distributed environments. Second, when there is a dispute⁹ between users, the platform may make dishonest decisions leading to “false reporting” and “free-riding.” Third, the crowdsourcing sensitive information is typically stored in centralized servers, which possibly leads to data leakage.¹⁰ Fourth, the centralized crowdsourcing schemes are vulnerable to denial-of-service (DoS) attacks, remote hijacking, and Sybil attacks to cause the failure of crowdsourcing service.¹¹

The idea of introducing decentralization in the crowdsourcing is imminent. The blockchain based on peer-to-peer network^13,14 is an open, transparent, and distributed data storage model. All nodes in the network jointly maintain the operation of the blockchain. In recent years, there have been many blockchain-based cryptographic protocols.^15–17 Therefore, the blockchain has the potential to be one of the attempts for the decentralized crowdsourcing schemes.

Compared to traditional crowdsourcing schemes based on centralized management, a blockchain-based crowdsourcing scheme should satisfy the following requirements. First, it is essential to guarantee the verifiability of crowdsourced-sensitive information while ensuring the confidentiality. And then, because the interaction between users is directly on the blockchain, the integrity of the information should also be protected. Most importantly, on account of the decentralization of blockchain, the fairness of crowdsourcing should be ensured, that is, completing the fair exchange between the requester and the workers is a crucial challenge. In the crowdsourcing process, first, the requester may refuse to execute the incentive policy or execute it dishonestly. Second, when the requester is dissatisfied with existing solutions, it is possible to collude with dishonest workers and create an unfair distribution of rewards. For example, in the auction, if the owner thinks that the bids are not up to expectation, it may combine with other buyers to interrupt the auction process with a higher bid. Third, since the incentive policy may include the privacy of the requester, such as location and identity, it is not appropriate to be disclosed before receiving the solutions to avoid workers submitting false reports. For example, in the voting, the requester may be unwilling to disclose the conditions for the candidate to be elected (similar to more than half) in advance, causing the worker to vote dishonestly. Fourth, workers may change their own solutions by observing others on the blockchain. In summary, all of the above behaviors may undermine the fairness of the crowdsourcing process.

However, using only the common cryptosystems, such as public key authentication,¹⁸ password authentication,¹⁹ attribute-based encryption,²⁰ digital signature,²¹ privacy-preserving outsourced calculation,^22,23 and location-based verification,²⁴ cannot completely solve the problems in the blockchain-based crowdsourcing schemes, especially in terms of ensuring fairness.

Our contributions

In this article, we focus on a blockchain-based crowdsourcing scheme that satisfies the requirements of confidentiality, integrity, and fairness. We first adopt the homomorphic encryption^25,26 to simultaneously ensure the confidentiality and verifiability of the solutions. In this way, any user can verify the reward distribution based on the solution ciphertexts. And then, the secure hash^27,28 and commitment^29,30 are used to satisfy the requirement of fairness, that is, to ensure that the requester’s incentive policy and the workers’ solutions are unchangeable and unavailable at some phases.

Our contributions in this article are fourfold, as follows:

We classify the required properties of blockchain-based secure crowdsourcing scheme including confidentiality, integrity, and fairness, especially to defend against the collusion of the dishonest requester and workers.

We propose BFC, a novel blockchain-based secure and fair crowdsourcing scheme. The BFC scheme can provide the fair exchange between the requester and the workers, while protecting the confidentiality and integrity of the crowdsourcing information.

We theoretically analyze that BFC satisfies the above required properties.

We report experimental evaluations and show that BFC is feasible for both the requester and the workers.

Related work

Centralized crowdsourcing scheme

Since Jeff Howe proposed the concept of crowdsourcing in 2006, it has acquired the considerable attention and adoption. The existing centralized crowdsourcing schemes include Upwork,³¹ Amazon Mechanical Turk (MTurk),³² Waze,³³ and Airbnb.³⁴ These schemes provide services such as worker selection, incentive policy implementation, and solution verification from centralized crowdsourcing platforms. The requester can hire workers through a crowdsourcing platform to get correct solutions for the task. However, taking MTurk as an example, since the workers send plaintexts of the solutions to the third-party crowdsourcing platform, there may be data leakage and the single-point failure. At the same time, this scheme cannot completely avoid dishonest behaviors of the crowdsourcing platform. X Zhang et al.³⁵ proposed the auction-based schemes, EFF and DFF, in which the EFF mechanism arbitrates the disputes with the help of a trusted third party to eliminate dishonesty; the DFF mechanism can deny the dishonest behaviors without any third party. Y Zhang and M van der Schaar³⁶ introduced a reputation-based incentive mechanism in the crowdsourcing system. Although the above schemes have solved the problems of fairness to a certain extent, the confidentiality of crowdsourcing information is still neglected. Most importantly, none of the above schemes are fully applicable to distributed crowdsourcing scenarios.

Blockchain-based crowdsourcing scheme

Buccafurri et al.³⁷ proposed an alternative scheme to blockchain based on online social networks to implement crowdsourcing services, but it did not guarantee the confidentiality of the information and there was no incentive mechanism. C Tanas et al.³⁸ utilized the blockchain as a channel to pay rewards, but their proposed scheme cannot defend against some malicious users’ attacks, such as the requester’s dishonest execution of incentive policy, undermining the fairness of crowdsourcing. And the confidentiality of crowdsourcing information is not protected. M Li et al.¹⁶ designed CrowdBC, a distributed crowdsourcing framework based on blockchain. Although it can enforce incentive policy by deploying smart contracts, the requester has a certain probability to collude with the workers to dishonestly interrupt the crowdsourcing processes. Y Lu et al.¹⁷ proposed ZebraLancer, a private and anonymous crowdsourcing system based on the blockchain. Even if the solutions are encrypted with the requester’s public key, similar to the CrowdBC, this scheme cannot solve the problem of complicity between a dishonest requester and the workers. All in all, because the above schemes are impossible to avoid dishonest users from collusion, they are flawed in ensuring the fairness of crowdsourcing.

Preliminaries

Secure hash function

For the function $v$ , if there is an integer $c$ for any constant $n_{0}$ , such that when $n > n_{0}$ , there is always $0 \leq v (n) < \frac{1}{n^{c}}$ , then the function $v$ is negligible. A hash function refers to an algorithm that inputs a message of arbitrary length and outputs a fixed length value; it is very easy to calculate the output for any one of the inputs.^27,28

Definition 1

For a given hash function $Hash : {0, 1}^{*} \to {0, 1}^{*}$ , it is a secure hash function if it satisfies the following conditions:

1. One-wayness. The algorithm $A$ is an arbitrary probability polynomial-time algorithm and $k$ is a sufficiently large parameter. The probability of computing a pseudo-inverse for $Hash$ is negligible. That is

\begin{matrix} \Pr [Hash (A (Hash (x))) = Hash (x) : x \leftarrow {0, 1}^{k}] \\ \leq v (k) \end{matrix}

2. Collision resistance. It is computationally infeasible to try to find two different messages to make them hash to the same value. That is

\begin{matrix} \Pr [y \leftarrow Hash (x_{1}) : x_{1} \leftarrow {0, 1}^{k}; y \leftarrow Hash (x_{2}) : \\ x_{2} \leftarrow {0, 1}^{k}, x_{1} \neq x_{2}] < v \end{matrix}

Homomorphic encryption

Homomorphic encryption is a cryptographic technique based on computational complexity theory of mathematical problems. When the output calculated by the homomorphic encrypted data is decrypted, the obtained result is the same as that obtained by calculating the original data in the same manner.^25,26 In this section, we mainly introduce homomorphic encryption based on public key cryptosystem.

Definition 2

Let $< H_{1}, ° >$ and $< H_{1}, * >$ are two algebraic structures, $f : H_{1} \to H_{2}$ is a mapping from $H_{1}$ to $H_{2}$ , and $\forall a, b \in H_{1}$ has $f (a ° b) = f (a) * f (b)$ , then $f : H_{1} \to H_{2}$ is a homomorphic mapping. The homomorphic encryption algorithm consists of four parts: $KGen$ , $HEnc$ , $HDec$ , and $Cal$ , as follows:

$KGen$ : $(hpk, hsk) \leftarrow U$ . This algorithm outputs the key pair $(hpk, hsk)$ on inputting the security parameter $U$ .

$HEnc$ : $C \leftarrow (hpk, P)$ . This algorithm outputs the homomorphic encryption ciphertext $C$ on inputting the plaintext $P$ and the public key $hpk$ .

$HDec$ : $P \leftarrow (hsk, C)$ . This algorithm outputs the homomorphic decryption result $P$ on inputting the ciphertext $C$ and the private key $hsk$ .

$Cal$ : $(C, °) \leftarrow (P, °)$ . This algorithm converts the operation ° performed on the plaintext $P$ into operation ° on the ciphertext $C$ and makes them equivalent.

The homomorphic encryption algorithm based on public key cryptosystem should satisfy the following conditions:

1. Confidentiality. In the case of known plaintext $P$ and public key $hpk$ , the probability that the adversary successfully inverts the encryption result is negligible for the attacker. That is

\begin{matrix} \Pr [(hpk, hsk) \leftarrow KGen (U) : Attacker \\ (hpk, HEnc (P, hpk)) = P] < v (k) \end{matrix}

2. Homogeneity. For the encryption algorithm and the operation ° on the plaintext $P$ , there is

\begin{matrix} \Pr [(hpk, hsk) \leftarrow KGen (U) : C \leftarrow HEnc (P, hpk) \\ : HDec (hsk, Cal (C, °)) = Cal (P, °)] = 1 \end{matrix}

Commitment scheme

Typically, the commitment scheme is a two-phase protocol between the sender and the receiver of two polynomial-time algorithms, and the protocol satisfies validity, completeness, binding, and hiding.^29,30 The specific description is as follows.

Definition 3

The general commitment scheme consists of three polynomial-time algorithms: $SetUp$ , $Commit$ , and $Verify$ , as follows:

$SetUp$ : $crs \leftarrow 1^{k}$ . The input of this algorithm is a “1” bit string of length $k$ , and its output is a common reference string $crs$ .

$Commit$ : $(com, dec) \leftarrow (crs, m)$ . The inputs of this algorithm are the common reference string $crs$ and the message $m$ which needs to be committed. The outputs are the commitment $com$ and the evidence $dec$ used to solve the commitment.

$Verify$ : The sender sends the message $m$ and $dec$ to the receiver, and the receiver verifies whether the equation $Verify (crs, com, dec, m) = 1$ is true. For any possible message $m$ , there is

\begin{matrix} \Pr [crs \leftarrow SetUp (1^{k}); (com, dec) \leftarrow Commit (crs, m) \\ : Verify (crs, com, dec, m) = 1] = 1 \end{matrix}

The general commitment scheme should satisfy at least the following secure conditions:

1. Binding. For the sender of the arbitrary polynomial-time algorithm and all sufficiently large $k$ , there is

\begin{matrix} \Pr [crs \leftarrow SetUp (1^{k}); (com, m_{0}, m_{1}, de c_{0}, de c_{1}) \leftarrow \\ sender (crs) : m_{0} \neq m_{1}, Verify (crs, com, de c_{0}, m_{0}) = \\ Verify (crs, com, de c_{1}, m_{1}) = 1] < v (k) \end{matrix}

2. Hiding. As the receiver of the attacker, for all sufficiently large $k$ and possible information $m_{0}$ , $m_{1} (| m_{0} | \neq | m_{1} |)$ , there is

\begin{matrix} \Pr [crs \leftarrow SetUp (1^{k}); b \leftarrow {0, 1}; (com, dec) \leftarrow \\ Commit (crs, m_{b}) : b \leftarrow receiver (com)] < \frac{1}{2} + v (k) \end{matrix}

Blockchain

The blockchain based on peer-to-peer network^13,14 is an open, transparent, and distributed data storage model. A series of chronological transactions are recorded in a structure called a “block.” Since each block contains the hash value of the previous block, these blocks can form a chain structure. A blockchain is essentially a public, immutable, and ordered distributed ledger. The miners compete to get the right to add new blocks to the blockchain by providing power, and the winners will obtain the rewards.

We take Bitcoin³⁹ as an example to introduce the basic construction principle of blockchain. Transactions on the blockchain typically include three parts: input, output, and digital signature. For a valid transaction, the input must be the unspent of the previous transaction. In the case of Bitcoin, each transaction generates a hash value for the previous transaction and the next user’s public key, and signs it with the private key. Other users can verify the signature. In addition, users can add some additional information to the transaction. So, all transactions over a period of time are interrelated. Miners organize legitimate transactions into a structure called “merkle tree” and fill it into new blocks with the hash of previous block. Later, the miners run the consensus mechanism (proof-of-work) to try to find a nonce for attaching the new block to the blockchain. When the block is added to the blockchain, these transactions will no longer be able to be modified.

Problem formulations

System model

The system model of our BFC scheme is shown in Figure 1. There are three participants in this model including requester, workers, and blockchain. Briefly, the requester first publishes a crowdsourcing task on the blockchain. Workers who want to get rewards submit their own solutions on the blockchain after receiving the requester’s task. Finally, the requester rewards the workers for their correct solutions. To be specific, consider the following.

Figure 1.

The system model.

Requester

A requester in crowdsourcing system aims to publish a crowdsourcing task, with task descriptions, a incentive policy, a budget and a period of validity on the blockchain. After the task is released, the requester collects the solutions submitted by workers within the validity period and verifies their correctness. According to the original incentive policy established, the requester distributes rewards to corresponding workers.

Workers

Workers in crowdsourcing system aim to submit solutions for the task published by the requester and expect to receive rewards. In order to ensure the fair exchange between correct solutions and rewards, all users as well as workers can continually verify the entire crowdsourcing process.

Blockchain

As an open decentralized platform, blockchain applies to crowdsourcing scenarios. The requester and workers communicate with each other via the blockchain and issue crowdsourcing information in the form of transactions.

Threat model

The entities in decentralized crowdsourcing system have the possibility to play the role of attackers.

Requester

A requester is semi-honest and curious. It may have following adversarial behaviors: First, the requester may launch the change-incentive policy attack after publishing a crowdsourcing task to affect the fairness of crowdsourcing. And then, the requester is potential to launch the dishonestly-run-incentive policy attack to refuse to reward the appropriate workers for their correct solutions in an attempt to reduce the task spending. Next, the requester may launch the known-solution attack before reward distribution to conspire with the malicious workers, resulting in unfair distribution of rewards.

Workers

Workers are semi-honest and curious. They may have following adversarial behaviors: In order to get more rewards, the workers may attempt to initiate the change-own solution attack after submission through snooping on solutions submitted by others on the blockchain. Besides, it is possible for the workers to launch the known-incentive policy attack before reward distribution to spy on the sensitive information of the requester.

Outsiders

Outsiders are malicious users outside the crowdsourcing system. They may launch the modify-incentive policy attack and the modify-solution attack without the users’ permission to prevent the crowdsourcing processes from proceeding smoothly. For the task that has already been completed, the outsiders may try to launch the illegally-acquire-correct solution attack to maliciously get desired solutions on the blockchain.

Design goals

This article intends to propose a secure and fair crowdsourcing scheme in a decentralized environment. The requester publishes the crowdsourcing request and related information to the blockchain. Then, the workers get the task and submit solutions. After that, the corresponding workers receive rewards from the requester if they offer the proper solutions.

The BFC scheme proposed in this article should have the following attributes:

Fairness. The fairness of crowdsourcing refers to the fair exchange of labor outcomes and rewards between the requester and the workers who submitted the correct solutions. In this process, the possible attacks of users must be foiled. It is mainly reflected in five aspects, as follows:

The incentive policy must be unchangeable after task publishment against the change-incentive policy attack. In the crowdsourcing system, for preventing the requester from achieving the purpose of misallocating rewards, the incentive policy issued by the requester cannot be changed.

The true information of the incentive policy must be unavailable before reward distribution against the known-incentive policy attack. In practical application scenarios, the crowdsourcing policy may contain specific information about how the solutions should be verified. In order to prevent workers from getting rewards through dishonestly submitting solutions, it is necessary to ensure that the policy is unavailable for workers at some phases.

The solutions must be unchangeable after submission against the change-own solution attack. Due to the open and transparent nature of the data on the blockchain, it is easy for workers to get solutions submitted by others. Therefore, in order to prevent workers from changing their own solutions with reference to others, once the solution is submitted, it cannot be changed.

The solutions must be unavailable before reward distribution against the known-solution attack. In order to eliminate the possibility that the requester obtains the solutions in advance and colludes with the malicious workers to undermine the fair distribution of the rewards, the solutions have to be unavailable until the requester begins to distribute the rewards.

The final distribution results of the requester must be verified against the dishonestly-run-incentive policy attack. In the premise that the incentive policy has not been changed, in order to ensure that the requester fairly rewards the workers who correctly submit the solutions according to the initial published policy, our scheme must guarantee that the requester is honest in verifying the solutions and distribution. Any user can check whether the requester correctly rewards the workers.

Confidentiality. The confidentiality of a scheme means that only certain users can get confidential information. And in our scheme, the confidentiality refers to the inability to obtain the appropriate solutions for a crowdsourcing task against the illegally-acquire-correct solution attack. That is, the correct solutions must be confidential for malicious outsiders.

Integrity. The integrity of a scheme means that the users can verify the integrity of the crowdsourcing information they have sent. In our scheme, the integrity refers to the inability to alter the crowdsourcing information against the modify-incentive policy attack and the modify-solution attack. That is, the incentive policy and soluions must be unforgeable for malicious outsiders.

The proposed scheme

Overview

Our BFC scheme consists of the following four phases: initialization phase, task publishment phase, solution submission phase, and reward distribution phase.

In the initialization phase of the BFC scheme, the registered requester generates a homomorphic encryption key pair. And during the task publishment phase, the requester commits to the policy and publishes the task, the commitment, and related parameters on the blockchain. Then, the workers encrypt the solutions with the requester’s homomorphic public key and generate commitments to the ciphertext, which will be submitted to the blockchain in the solution submission phase. Finally, in the reward distribution phase, the requester and the workers open the commitments separately. If the crowdsourcing information on the blockchain is valid, the requester will verify the solutions according to the policy and distributes rewards to the workers. Any user can check whether the requester honestly assigns rewards on the basis of the solution ciphertexts.

In Figure 2, we indicate the crowdsourcing information that the users need to publish on the blockchain at various phases except the initialization phase. The details of our BFC scheme will be described in the following sections.

Figure 2.

Process of the BFC scheme.

Initialization

As the initialization phase begins, each user $u$ needs to register and obtain a certified key pair $(p k_{u}, s k_{u})$ , generating a unique identity identifier $I D_{u}$ in the meantime. The requester $R$ who intends to issue a crowdsourcing task carries out the algorithm $KGen ()$ to generate a homomorphic encryption key pair $(hp k_{R}, hs k_{R})$ for processing the solutions of the workers $W$ , where $W = {W_{1}, W_{2}, . . ., W_{n}}$ .

In general, each user in crowdsourcing system obtains the unique identifier and the key pair used to publish transactions. The requester $R$ will also generate a homomorphic encryption key pair by entering the security parameter $λ$ , that is, $R = (I D_{R}, p k_{R}, s k_{R}, hp k_{R}, hs k_{R})$ and $W_{i} = (I {D_{W}}_{i}, p {k_{W}}_{i}, s {k_{W}}_{i})$ , $W_{i} \in W$ , $i = 1, . . ., n$ .

Task publishment

The main purpose of this phase is for the requester to publish a crowdsourcing task in the form of a new transaction on blockchain. For each transaction inserted with a crowdsourcing task, the requester $R$ has to generate a unique task identifier $TI D_{R}$ for subsequent retrieval and verification. When the requester $R$ plans to publish a crowdsourcing task, it needs to formulate the task description $T$ , the incentive policy $P$ , the task budget $α$ , and the validity period of the task. Among them, the task validity period is divided into two parts, which are the effective time period $[t_{R}^{1}, t_{R}^{2}]$ of the solution submission phase and the effective time period $[t_{R}^{3}, t_{R}^{4}]$ of the reward distribution phase. Furthermore, the incentive policy $P$ includes the homomorphic function ° used to evaluate the solutions, the statement ${st}_{R}^{1}$ about the evaluation policy, and the statement ${st}_{R}^{2}$ about the distribution of rewards, that is, $P = {°, {st}_{R}^{1}, {st}_{R}^{2}}$ . The specific steps of our scheme at this phase are described as follows:

Step 1. First, the requester $R$ carries out the algorithm $SetUp ()$ to generate a common reference string $cr s_{R}$ for committing the incentive policy $P$ .

Step 2. The requester $R$ then computes $h_{R} = Hash (P)$ , $P = {°, {st}_{R}^{1}, {st}_{R}^{2}}$ .

Step 3. The requester $R$ carries out the algorithm $Commit ()$ to compute $(co m_{R}, de c_{R}) = Commit (h_{R}, cr s_{R})$ , generating the commitment $co m_{R}$ of the policy.

Step 4. Next, the requester $R$ organizes the generated crowdsourcing information into the task request $T R$ and embeds it into a new transaction, $T R = {I D_{R}, TI D_{R}, hp k_{R}, T, cr s_{R}, co m_{R}, [t_{R}^{1}, t_{R}^{2}], [t_{R}^{3}, t_{R}^{4}]}$ . The amount of this transaction is the task budget $α$ . The requester $R$ digitally signs a hash of the previous transaction and the public key of the next owner and adds these to the end of the transaction with its private key $s k_{R} .$ And then, the requester $R$ publishes it to blockchain.

Step 5. Finally, the miners receive the transaction broadcast by the requester $R$ and verify the legitimacy of it. If the transaction is legal, the miners will add it to a new block.

At the end of this phase, the requester $R$ publishes its own legal crowdsourcing task request $T R$ to the blockchain and expects to get solutions within the validity period.

Solution submission

The main purpose of this phase is for the workers to submit their solutions in the form of new transactions on the blockchain. When the worker $W_{i}$ receives the task request $T R$ issued by the requester $R$ , it works out the solution $So l_{i}$ locally based on the task information. Then, the worker $W_{i}$ encrypts the solution $So l_{i}$ with the homomorphic encryption public key $hp k_{R}$ created by the requester $R$ , to generate a ciphertext $ciphSo l_{i}$ . Furthermore, the worker $W_{i}$ needs to generate a commitment of the ciphertext $ciphSo l_{i}$ . The specific steps of our scheme at this phase are described as follows:

Step 1. The worker $W_{i}$ first computes $ciphSo l_{i} = HEnc (So l_{i}, hp k_{R})$ to generate the ciphertext of its own solution.

Step 2. Second, the worker $W_{i}$ carries out the algorithm $Commit ()$ to compute $(co m_{i}, de c_{i}) = Commit (ciphSo l_{i}, cr s_{i})$ , generating the commitment $co m_{i}$ of the solution.

Step 3. Third, within the validity period $[t_{R}^{1}, t_{R}^{2}]$ , the worker $W_{i}$ organizes the information about the solution $So l_{i}$ and attaches the identifier $TI D_{R}$ that can represent the requester’s crowdsourcing task request into the task response $T S$ , $T S = {I {D_{W}}_{i}, TI D_{R}, cr s_{i}, co m_{i}}$ , to embed it into a new transaction. Then, the worker $W_{i}$ digitally signs a hash of the previous transaction and the public key of the next owner, to add them to the end of the transaction with the private key $s {k_{W}}_{i}$ , and submits it on the blockchain.

Step 4. Finally, the miners receive the transaction broadcast by the worker $W_{i}$ and verify the validity of it. If the transaction is legitimate, the miners will add it to a new block.

At the end of this phase, the worker encapsulates its solution $So l_{i}$ in the commitment $co m_{i}$ and publishes the task response $T S$ to the blockchain. Until the next phase begins, it will open the commitment.

Reward distribution

The main purpose of this phase is for the requester to distribute rewards to workers who correctly submit the solutions. During the valid period $[t_{R}^{3}, t_{R}^{4}]$ of this phase, the worker $W_{i}$ opens the solution ciphertext commitment $co m_{i}$ , while the requester $R$ opens the commitment $co m_{R}$ of the incentive policy. Any user in the crowdsourcing system can verify the validity of these commitments. After that, the requester $R$ obtains the solution ciphertexts on blockchain. If the solution ciphertext $ciphSo l_{i}$ is verified available, the requester $R$ first decrypts the ciphertext and generates the solution plaintext $plainSo l_{i}$ locally. And then, based on the original incentive policy $P$ , the requester $R$ evaluates the solution with the evaluation function ° and combines the statement ${{st}_{R}^{1}, {st}_{R}^{2}}$ to make a decision on how to reward the worker $W_{i}$ . Finally, the requester $R$ publishes a reward to the worker $W_{i}$ ; any user can verify the correctness of the reward distribution on the basis of the policy and the solution ciphertext $ciphSo l_{i}$ . In addition, the worker $W_{i}$ publishes the verification result as a receipt to the blockchain. The specific steps of our scheme at this phase are described as follows:

Step 1. The requester $R$ broadcasts the incentive policy $P$ and the evidence $de c_{R}$ on blockchain, attaching the identifier $TI D_{R}$ of the crowdsourcing task. Approximately, the worker $W_{i}$ submits the solution ciphertext $ciphSo l_{i}$ and the evidence $de c_{i}$ .

Step 2. The requester $R$ computes $Verify (cr s_{i}, co m_{i}, de c_{i}, ciphSo l_{i})$ to check whether the solution ciphertext $ciphSo l_{i}$ is unvaried according to the output 0/1. In the same way, the worker $W_{i}$ compares the commitment $co m_{i}$ with the incentive policy $P$ issued by the requester $R$ . If they are matched, the commitments are proven valid and the information committed is unchanged, otherwise discard.

Step 3. And then, the requester $R$ computes $HDec (cip h_{i}, hs k_{R})$ to obtain the solution plaintext $plainSo l_{i}$ .

Step 4. Next, the requester $R$ computes $Cal (plainSo l_{i}, °)$ to evluate the solution.

Step 5. If the evaluation result of the previous step meets the task requirements, the requester $R$ sends an amount of bonus $β_{i}$ to the worker $W_{i}$ , $β_{i} \leq α$ , to reward the worker according to the incentive policy $P$ . In the meantime, the requester $R$ is also required to attach the evaluation result ${res}_{R}^{i}$ obtained in the previous step and the identifier $TI D_{R}$ representing the task for the solution.

Step 6. For the rewards distributed by the requester $R$ on the blockchain, any user in the crowdsourcing system can compute ${res}_{R}^{i}' = Cal (ciphSo l_{i}, °)$ to verify the correctness of the reward distribution. If there is no issue with the previous steps, the result of the users computing $Cmp (HEnc (({res}_{R}^{i}, hp k_{R}), {res}_{R}^{i}', ⊙))$ should be 1. If the worker $W_{i}$ has no objection to the requester’s assignment, it will write “1” in the receipt. In the case where the result calculated by the user is 0 or the distribution does not conform to the statement ${{st}_{R}^{1}, {st}_{R}^{2}}$ in the policy $P$ , the worker $W_{i}$ will issue the result ${res}_{R}^{i}'$ of verification computed by itself and the statement $s t_{i}$ of the distribution result that it considers to be correct on the blockchain.

It should be added that steps 1, 5, and 6 of this phase require the users to publish the crowdsourcing information to the blockchain in the form of transactions. The specific processing of the transaction is similar to the previous two phases. Here, we omit them.

After the end of this phase, the crowdsourcing process is completed. Any user in the crowdsourcing system can verify the information on the blockchain. If someone has objections to certain parts, he or she can attach the task identifier to post its opinion in the form of a transaction.

Discussion of the BFC scheme

Decentralization. Compared to traditional schemes that rely on crowdsourcing platforms, the proposed BFC scheme ensures that the requester and the workers interact directly on the blockchain. Our scheme has achieved decentralization to defend against the man-in-the-middle attack and prevented the single-point failure due to the participation of the trusted third party.

Double-spending preventing. In our scheme, the requester publishes the task budget and distributes the rewards in the form of transactions. If the requester has double-spending behaviors, depending on the nature of the blockchain, the miners can discover and discard illegal transactions. As a result, our scheme can guarantee the effectiveness of the budget and rewards.

Accountablity. For the history of users participating in crowdsourcing processes, including publishing tasks and submitting solutions, our scheme ensures that they are traceable due to the uniqueness of the users’ identifiers. In these circumstances, it can guarantee the accountability of users who have dishonest behaviors.

Auditability. Since our scheme is deployed on the blockchain, any user can audit the entire crowdsourcing process. For example, crowdsourcing schemes can introduce reputation-based mechanisms to punish dishonest users.

Analysis of scheme

In this section, we analyze our BFC scheme to satisfy the design goals proposed in section “Design goals.”

Fairness

Our scheme should guarantee the fair exchange between the requester and workers, as follows:

1. The incentive policy published by the requester should be unchangeable against the change-incentive policy attack. If the dishonest requester $R$ intends to change the original policy $P$ , combining with the process of our scheme, there are two cases:

Case 1. The requester $R$ searches a new incentive policy $Q (Q \neq P)$ instead of the intial one $P$ and expects the same output $h_{R}$ . Based on the collision resistance of the secure hash, there is

\Pr [h_{R} \leftarrow Hash (P); h_{R} \leftarrow Q, P \neq Q] < v (k)

Therefore, it is computationally infeasible to find a new policy which is different from the original one for the dishonest requester.

Case 2. The requester $R$ searches a new hash value $h_{R}' (h_{R}' \neq h_{R})$ and expects the same commitment $co m_{R}$ , that is, the requester attempts to compute $Commit (h_{R}, cr s_{R}) = Commit (h_{R}', cr s_{R})$ . But according to the binding of the commitment, it has

\begin{matrix} \Pr [cr s_{R} \leftarrow SetUp (1^{k}); (co m_{R}, h_{R}, h'_{R}, de c_{R}, dec'_{R}) \\ \leftarrow attacker (cr s_{R}) : h_{R} \neq h'_{R}, Verify (cr s_{R}, co m_{R}, de c_{R}, h_{R}) = \\ Verify (cr s_{R}, co m_{R}, dec'_{R}, h'_{R}) = 1] < v (k) \end{matrix}

Thus, it is computationally infeasible for the dishonest requester to find a new hash value of incentive policy.

2. The true information of the incentive policy must be unavailable before reward distribution against the known-incentive policy attack. The requester $R$ publishes the commitment $co m_{R}$ about the hash $h_{R}$ of its incentive policy $P$ on the blockchain. If the worker wants to obtain the information about the policy, first, it needs to calculate the hash value $h_{R}$ of the policy from the commitment, $h_{R} \leftarrow Hash (co m_{R})$ . Assuming that $k$ is sufficiently large, the hash value $h_{R} (h_{R} = h_{R}^{0} = h_{R}^{1})$ required to be committed is satisfied by the property of hiding that

\begin{matrix} \Pr [crs \leftarrow SetUp (1^{k}); b \leftarrow {0, 1}; (co m_{R}, de c_{R}) \\ \leftarrow Commit (cr s_{R}, h_{R}^{b}) : b \leftarrow attacker (co m_{R})] < \frac{1}{2} + v (k) \end{matrix}

Based on the above analysis of the commitment, the dishonest workers cannot acquire any information about the hash value $h_{R}$ while receiving the commitment.

And then, even if the attacker obtains the hash $h_{R}$ of the policy, according to the one-wayness of the secure hash, it has

\Pr [Hash (A (Hash (P))) = h_{R}] \leq v (k)

Thus, it is computationally infeasible to get the specific incentive policy $P$ from the hash value $h_{R}$ .

3. The solutions must be unchangeable after submission against the change-own solution attack. If the worker $W_{i}$ wants to change the solution $So l_{i}$ submitted by itself, combining with the process of our scheme, there are two cases:

Case 1. The worker $W_{i}$ searches a new solution $So l_{i}' (So l_{i}' \neq So l_{i})$ and expects the same result $ciphSo l_{i}$ , that is, the worker attempts to compute $HEnc (So l_{i}, hp k_{R}) = HEnc (So l_{i}', hp k_{R})$ . However, based on the one-to-one mapping between plaintext and ciphertext of the homomorphic encryption algorithm, it is computationally infeasible for the dishonest worker to find a new solution to replace the original one.

Case 2. The worker $W_{i}$ searches a new solution ciphertext $So l_{i}' (So l_{i}' \neq So l_{i})$ and expects the same commitment $co m_{i}$ , $Commit (So l_{i}, cr s_{i}) = Commit (So l_{i}', cr s_{i})$ . Similar to the above binding analysis of the requester’s commitment $co m_{R}$ , it is computationally infeasible for attacker to forge a new solution ciphertext.

4. The solutions must be unavailable before reward distribution against the known-solution attack. Workers submit their solution ciphertext commitments on the blockchain. If the requester $R$ wants to obtain the solution $So l_{i}$ , it should calculate the solution homomorphic encryption result $ciphSo l_{i}$ from the commitment $co m_{i}$ . But similar to the hiding analysis of the requester’s commitment $co m_{R}$ , it is difficult for the requester to acquire any information about the $ciphSo l_{i}$ .

5. The final distribution results of the requester must be correct against the dishonestly-run-incentive policy attack. In our proposed scheme, not only the requester $R$ but also any user can verify the solution ciphertexts and distribution with the unchangeable policy $P$ . According to the homogeneity of the encryption algorithm, it has

\begin{matrix} \Pr [(hp k_{R}, hs k_{R}) \leftarrow KGen (U) : ciphSo l_{i} \leftarrow HEnc (So l_{i}, hp k_{R}) : \\ HDec (hs k_{R}, Cal (ciphSo l_{i}, °)) = Cal (So l_{i}, °)] = 1 \end{matrix}

Therefore, users can verify the correctness of the solution $So l_{i}$ based on the ciphertext $ciphSo l_{i}$ . Then, since the requester opens the commitment $co m_{R}$ of the incentive policy $P$ , $P = {°, {st}_{R}^{1}, {st}_{R}^{2}}$ , the users can judge whether the reward distribution is reasonable according to the statement ${st}_{R}^{1}$ about the evaluation policy and the statement ${st}_{R}^{2}$ about the distribution of rewards.

Confidentiality

Our scheme should guarantee the confidentiality of correct solutions after distribution against the illegally-acquire-correct solution attack. After the crowdsourcing task is completed, the outsiders can only get the requester’s homomorphic public key $hp k_{R}$ and solution ciphertext $ciphSo l_{i}$ . Due to the confidentiality characteristic of homomorphic encryption based on public key cryptosystem, there is

\begin{matrix} \Pr [(hp k_{R}, hs k_{R}) \leftarrow KGen (U) : Outsider (hpk, ciphSo l_{i}) \\ = So l_{i}] < v (k) \end{matrix}

Therefore, the outsiders cannot decrypt the correct solution ciphertexts without the homomorphic secret key.

Integrity

Our scheme should guarantee the integrity of incentive policy and solutions against the modify-incentive policy attack and the modify-solution attack. We assume that the block containing the transaction of the task policy $P$ and solution $ciphSo l_{i}$ is $Bloc k_{m}$ . According to the nature of the blockchain, block $Bloc k_{m}$ contains the hash value of the previous block $Bloc k_{m - 1}$ . If outsider wants to change the data in block $Bloc k_{m}$ , it needs to perform the consensus mechanism to regenerate block $Bloc k_{m}$ and all subsequent blocks, and meanwhile, the length of the side chain generated by outsider must be longer than the existing chain. In fact, unless the malicious outsider can control more than 51% of the nodes in the whole network, it is pretty difficult to catch up with the honest miners. In this way, our scheme can satisfy the requirement of integrity.

Comparison on security

In this section, we compare our scheme with the several related schemes including MTurk, EFF and DFF, CrowdBC, and ZebraLancer. In Table 1, G1 represents confidentiality, G2 integrity, and G3 fairness. In addtion, A1 represents the illegally-acquire-correct solution attack, A2 modify-incentive policy attack, A3 modify-solution attack, A4 change-incentive policy attack, A5 known-incentive policy attack, A6 change-own solution attack, A7 known-solution attack, and A8 dishonestly-run-incentive policy attack. The table shows the comparison results, where “√” means that the scheme can resist the corresponding attack, “×” means not, and “−” means uninvolved.

Table 1.

Comparison with related works.

Schemes		MTurk	EFF and DFF	CrowdBC	ZebraLancer	Our scheme
G1	A1	×	×	√	√	√
G2	A2	−	√	−	−	√
	A3	−	×	√	√	√
G3	A4	√	−	√	√	√
	A5	×	×	×	×	√
	A6	−	−	√	√	√
	A7	√	×	×	×	√
	A8	√	√	√	√	√

It is obvious that MTurk,³² EFF and DFF,³⁵ CrowdBC,¹⁶ and ZebraLancer¹⁷ cannot fully guarantee the fairness of crowdsourcing. And except for ZebraLancer¹⁷ and our scheme, other schemes also perform poorly in terms of confidentiality and integrity. Therefore, our BFC scheme, which satisfies all the required properties, can be applied to provide secure and fair crowdsourcing service.

Performance evaluation

In this section, we mainly focus on evaluating the computational overhead of our proposed BFC scheme. The performance evaluation consists of four phases, that is, initialization, task publishment, solution submission, and reward distribution. Since the proposed scheme is a universal crowdsourcing model, the choice of specific algorithms is related to the actual needs of the users. Therefore, we selected several representative hash algorithms and semi-homomorphic algorithms in this section and chose Pedersen’s algorithm as the commitment scheme to evalaute and analyze their computational overhead. The experiments are implemented on a PC (Intel(R) Core(TM) i3-4170 CPU with 3.70 GHz, 8G RAM, and Windows 7 OS) using Crypto++ 5.6.2 and gcc/g++.

Initialization

In the initialization phase of our scheme, requester $R$ who intends to issue crowdsourcing task requires to generate a homomorphic encryption key pair $(hp k_{R}, hs k_{R})$ so that workers can encrypt their solutions. We selected two kinds of semi-homomorphic algorithms, RSA algorithm and Paillier’s algorithm, and evaluated the computational overhead with different parameters. Since the homomorphic encryption key pair only needs to be generated once by the requester during the entire crowdsourcing process, the computational overhead of this phase has little impact on our scheme.

Task publishment

In the task publishment phase, the requester first generates a hash value for the established incentive policy and then commits the hash. We assume that the plaintext-space of the incentive policy is 1–1024B. And we adopt Pedersen’s commitment scheme, MD5 algorithm, and SHA-1 algorithm to evaluate the computational overhead of the requester. Since the Pedersen commitment requires the input to be less than or equal to 160 bits, the hash functions we selected are MD5 and SHA-1. In Figure 3, the results show that the difference in the hash function has little effect on the computational overhead of this phase. When the length of the policy is 1KB, the computational overhead of using the MD5 algorithm is about 2.76 ms and the overhead of using the SHA-1 algorithm is about 3.01 ms. Because when the length of the input is short, the computational overhead of the hash function is within microseconds and the overhead of the Pedersen commitment is within milliseconds. The computational overhead of the Pedersen commitment scheme has a major impact on this phase. Moreover, it is obvious to conclude that larger plaintext-space of incentive policy published by the requester will lead to higher computational cost.

Figure 3.

Computational overhead in task publishment phase.

Solution submission

After receiving the crowdsourcing task published by the requester, the workers who intend to submit the solutions first encrypt their solution with the requester’s homomorphic public key and then commit the ciphertexts. We assume that the plaintext-space of the solution created by the worker is 128–1024B. And we adopt Pedersen’s commitment scheme, RSA-1024, RSA-2048, Paillier-1024, and Paillier-2048 algorithms to evaluate the computational overhead of the worker. In Figure 4, first, we notice that the RSA algorithms with different parameters lead to slightly different computational overhead, and the difference in the parameters of the Paillier algorithm has a relatively large impact on the overhead. In this phase, when the length of the solution is 1KB, the computational overhead of using the RSA-1024 algorithm and the RSA-2048 algorithm is about 18.86 and 19.20 ms, respectively. In addtion, the computational overhead is approximately 104.07 and 375.55 ms when using the Paillier-1024 algorithm and Paillier-2048 algorithm, respectively. Second, the computational overhead is positively correlated with the length of the solution. Third, compared to the RSA-1024 algorithm and the RSA-2048 algorithm, using the Paillier algorithm takes much longer when the length of the solution is the same.

Figure 4.

Computational overhead in solution submission phase: (a) evaluation with different RSA algorithms; (b) evaluation with different Paillier algorithms.

Reward distribution

In this phase, the requester and the workers open their own commitments, and if the commitments are valid, the requester decrypts the solution ciphertexts with the private key. Based on the incentive policy developed at the time of the task publishment, the requester evaluates the solutions and sends the assessment results and corresponding rewards to the worker. Any user on the blockchain can verify the correctness of the reward distribution based on the solution ciphertext.

The computational overhead of the Pedersen Commitment scheme when verifying the commitments is similar to the generation. We use RSA-1024, RSA-2048, Paillier-1024, and Paillier-2048 algorithms to evaluate the computational overhead of decrypting a solution ciphertext for the requester in this phase. In Figure 5, we can see that the computational overhead of these four algorithms increases distinctly when the input grows from 128 to 1024B. In addition, in the case of the same solution length, the RSA-1024 algorithm has the shortest decryption time, and the longest is the Paillier-2048 algorithm. Assuming that the requester’s crowdsourcing task is to compute the summation and the product of all effective solutions. According to the multiplicative homomorphism of the RSA algorithm and the additive homomorphism of the Paillier algorithm, any user should multiply all valid solution ciphertexts when verifying the distribution. As shown in Figure 6, we describe the relationship between the number of solution ciphertexts $N$ and the computational overhead using RSA algorithm and Paillier algorithm with different parameters, in the case that each ciphertext is 127B. The results indicate that using the Paillier-1024 algorithm and Paillier-2048 algorithm has greater computational overhead in this phase than the RSA-1024 and the RSA-2048 algorithms. And the more the number of ciphertexts that need to be verified, the more computational overhead the user has in this phase. For example, when $N$ increases from 4 to 100, the time of using Paillier-2048 algorithm increases from 42.78 to 48.91 ms.

Figure 5.

Computational overhead of decryption in reward distribution phase.

Figure 6.

Computational overhead of verification in reward distribution phase: (a) evaluation with different RSA algorithms; (b) evaluation with different Paillier algorithms.

Comparison on performance

In this section, we studied some of the other crowdsourcing schemes mentioned in the related work, and we only focused on the part of the crowdsourcing process. We selected two blockchain-based schemes, CrowdBC¹⁶ and ZebraLancer,¹⁷ and a centralized crowdsourcing scheme EFF.³⁵ Since the schemes CrowdBC¹⁶ and ZebraLancer¹⁷ are based on smart contracts, we ignore the communication overhead and the calculations on the blockchain and only evaluate the computational overhead of the requester and the worker locally at different phases. Similarly, we do not consider the overhead of the crowdsourcing platform for the EFF scheme.³⁵ In the experiments, it is assumed that the policy published by the requester is 1KB, and the solution submitted by the worker is 127B. In addition, the number of solutions that need to be verified is 100. Table 2 shows the results. Since the ZebraLancer¹⁷ scheme uses the RSA-2048 algorithm, the computational overhead of our scheme shown in Table 2 is also based on the RSA-2048 algorithm. Here, “−” means that the computational overhead of the requester and the worker in this scheme is negligible or there is almost no local computation.

Table 2.

Computational overhead in different schemes.

	EFF	CrowdBC	ZebraLancer	Our scheme
Task publishment	–	–	86.91 ms	3.01 ms
Task receiving	–	1.76 ms	–	–
Solution submission	–	20.28 ms	0.032 ms	19.20 ms
Reward distribution	3.53 ms	–	>1 min	64.05 ms

As shown in Table 2, the computational overhead is relatively acceptable to the requester and the worker in the proposed BFC scheme. Although the centralized crowdsourcing shceme EFF³⁵ is efficient, it does not fully satisfy the requirements of crowdsourcing through the previous analysis. The other two blockchain-based schemes have much on-chain computation, which may also reduce the performance.

Conclusion

In this study, we propose BFC, a secure and fair crowdsourcing scheme based on blockchain. The proposed scheme achieves that the requester and workers can share the crowdsourcing information without a third-party platform while ensuring the confidentiality and integrity. In addition, any user in the crowdsourcing system can verify the entire crowdsourcing process to ensure fairness. And the analysis testifies that our scheme is able to satisfy the proposed security requirements and goals. Finally, the experimental results show that the computational overhead is acceptable to both the requester and the worker.

Footnotes

Handling Editor: Francesco Longo

Declaration of conflicting interests

The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.

Funding

The author(s) disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: This study was funded by the National Natural Science Foundation of China (Grant Nos 61872283, U1536202, U1708262, 61672413, 61672415, 61671360, 61602360, and 61702404) and the China 111 project (Grant No. B16037).

ORCID iD

Junwei Zhang

References

Howe

. The rise of crowdsourcing. Wired Mag 2006; 14(6): 1–4.

Brabham

. Crowdsourcing as a model for problem solving: an introduction and cases. Convergence 2008; 14(1): 75–90.

Doan

Ramakrishnan

Halevy

. Crowdsourcing systems on the world-wide web. Commun ACM 2011; 54(4): 86–96.

Yuen

King

Leung

. A survey of crowdsourcing systems. In: Proceedings of IEEE third international conference on privacy, security, risk and trust and IEEE third international conference on social computing, Boston, MA, 9–11 October 2011, pp.766–773. New York: IEEE.

Estellés-Arolas

González-Ladrón-De-Guevara

. Towards an integrated crowdsourcing definition. J Inform Sci 2012; 38(2): 189–200.

Shah

Zhou

Peres

Approval voting and incentives in crowdsourcing. In: Proceedings of the international conference on machine learning, Lille, 6–11 July 2015, pp.10–19. New York: ACM.

Feng

Zhu

Zhang

et al . TRAC: truthful auction for location-aware collaborative sensing in mobile crowdsourcing. In: Proceedings of IEEE INFOCOM 2014—IEEE conference on computer communications, Toronto, ON, Canada, 27 April–2 May 2014, pp.1231–1239. New York: IEEE.

Wang

Cai

Yin

et al . An incentive mechanism with privacy protection in mobile crowdsourcing systems. Comput Netw 2016; 102: 157–171.

Stol

Fitzgerald

. Two’s company, three’s a crowd: a case study of crowdsourcing software development. In: Proceedings of the 36th international conference on software engineering, Hyderabad, India, 31 May–7 June, pp.187–198. New York: ACM.

10.

Yang

Zhang

Ren

et al . Security and privacy in mobile crowdsourcing networks: challenges and opportunities. IEEE Commun Mag 2015; 53(8): 75–81.

11.

Kulkarni

Can

Hartmann

Collaboratively crowdsourcing workflows with turkomatic. In: Proceedings of the ACM 2012 conference on computer supported cooperative work, Seattle, WA, 11–15 February 2012, pp.1003–1012. New York: ACM.

12.

Swan

. Blockchain: blueprint for a new economy. Newton, MA: O’Reilly Media, Inc, 2015.

13.

Schollmeier

. A definition of peer-to-peer networking for the classification of peer-to-peer architectures and applications. In: Proceedings first international conference on peer-to-peer computing, Linkoping, 27–29 August 2001, pp.101–102. New York: IEEE.

14.

Bandara

Jayasumana

. Collaborative applications over peer-to-peer systems–challenges and solutions. Peer Network Appl 2013; 6(3): 257–276.

15.

Zhang

et al . BMPLS: blockchain-based multi-level privacy-preserving location sharing scheme for telecare medical information systems. J Med Syst 2018; 42(8): 147.

16.

Weng

Yang

et al . CrowdBC: a blockchain-based decentralized framework for crowdsourcing. IEEE Trans Parallel Distrib Syst 2018; 30: 1251–1266.

17.

Tang

Wang

ZebraLancer: private and anonymous crowdsourcing system atop open blockchain. In: Proceedings of the 2018 IEEE 38th international conference on distributed computing systems (ICDCS), Vienna, Austria, 2–6 July 2018. New York: IEEE.

18.

Zeadally

et al . Certificateless public key authenticated encryption with keyword search for industrial internet of things. IEEE T Ind Inform 2018; 14(8): 3618–3627.

19.

Wang

Zhang

Wang

et al . Targeted online password guessing: an underestimated threat. In: Proceedings of the 2016 ACM SIGSAC conference on computer and communications security, Vienna, 24–28 October 2016, pp.1242–1254. New York: ACM.

20.

Gao

Zhang

et al . LIP-PA: a logistics information privacy protection scheme with position and attribute-based access control on mobile devices. Wirel Commun Mobile Comput 2018; 2018: 9436120.

21.

Zhang

Moon

. Universally composable one-time signature and broadcast authentication. Sci China Inform Sci 2010; 53(3): 567–580.

22.

Liu

Deng

Ding

et al . Privacy-preserving outsourced calculation on floating point numbers. IEEE Trans Inform Foren Secur 2016; 11(11): 2513–2527.

23.

Liu

Deng

Choo

KKR

et al . An efficient privacy-preserving outsourced calculation toolkit with multiple keys. IEEE Trans Inform Foren Secur 2016; 11(11): 2401.

24.

Zhang

Yang

et al . Universally composable secure positioning in the bounded retrieval model. Sci China Inform Sci 2015; 58(11): 1–15.

25.

Bendlin

Damgård

Orlandi

et al . Semi-homomorphic encryption and multiparty computation. In: Proceedings of the annual international conference on the theory and applications of cryptographic techniques, Tallinn, 15–19 May 2011, pp.169–188. New York: Springer.

26.

Gentry

Boneh

. A fully homomorphic encryption scheme. PhD Thesis, Stanford University, Stanford, 2009.

27.

Carter

Wegman

. Universal classes of hash functions. J Comput Syst Sci 1979; 18(20): 143–154.

28.

Rogaway

Shrimpton

. Cryptographic hash-function basics: definitions, implications, and separations for preimage resistance, second-preimage resistance, and collision resistance. In: Proceedings of the international workshop on fast software encryption, Delhi, India, 5–7 February 2004, pp.371–388. New York: IEEE.

29.

Goldreich

. Secure multi-party computation (manuscript, preliminary version, vol. 78), 1998, http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.122.1554&rep=rep1&type=pdf

30.

Juels

Wattenberg

. A fuzzy commitment scheme. In: Proceedings of the 6th ACM conference on computer and communications security, Kent Ridge Digital Labs, Singapore, 1–4 November 1999, pp.28–36. New York: ACM.

31.

Upwork and Freelancers Union. Freelancing in America2015, https://www.upwork.com/i/freelancing-in-america/2015/

32.

Difallah

Catasta

Demartini

et al . The dynamics of micro-task crowdsourcing: the case of Amazon MTurk. In: Proceedings of the 24th international conference on World Wide Web, International World Wide Web Conferences Steering Committee, Florence, Italy, 18–22 May 2015, pp.238–247. New York: ACM.

33.

Waze Mobile. Waze: outsmarting traffic, together, 2015, http://www.waze.com

34.

Rahimi

Liu

Andris

. Hidden style in the city: an analysis of geolocated Airbnb rental images in ten major cities. In: Proceedings of the 2nd ACM SIGSPATIAL workshop on smart cities and urban analytics, Burlingame, CA, 31 October 2016. p.7. New York: ACM.

35.

Zhang

Xue

et al . Keep your promise: mechanism design against free-riding and false-reporting in crowdsourcing. IEEE Internet Things J 2015; 2(6): 562–572.

36.

Zhang

van der Schaar

Reputation-based incentive protocols in crowdsourcing applications. In: Proceedings IEEE INFOCOM, Orlando, FL, 25–30 March 2012, pp.2140–2148. New York: IEEE.

37.

Buccafurri

Lax

Nicolazzo

et al . Tweetchain: an alternative to blockchain for crowd-based applications. In: Proceedings of the international conference on web engineering, Rome, Italy, 5–8 June 2017, pp.386–393. New York: Springer.

38.

Tanas

Delgado-Segura

Herrera-Joancomartí

. An integrated reward and reputation mechanism for MCS preserving users? Privacy. In: Garcia-Alfaro

Navarro-Arribas

Aldini

et al . (eds) Data privacy management, and security assurance. New York: Springer, 2015, pp.83–99.

39.

Nakamoto

. Bitcoin: a peer-to-peer electronic cash system, 2008, https://bitcoin.org/bitcoin.pdf.

Schemes		MTurk	EFF and DFF	CrowdBC	ZebraLancer	Our scheme
G1	A1	×	×	√	√	√
G2	A2	−	√	−	−	√
	A3	−	×	√	√	√
G3	A4	√	−	√	√	√
	A5	×	×	×	×	√
	A6	−	−	√	√	√
	A7	√	×	×	×	√
	A8	√	√	√	√	√

Schemes		MTurk	EFF and DFF	CrowdBC	ZebraLancer	Our scheme
G1	A1	×	×	√	√	√
G2	A2	−	√	−	−	√
	A3	−	×	√	√	√
G3	A4	√	−	√	√	√
	A5	×	×	×	×	√
	A6	−	−	√	√	√
	A7	√	×	×	×	√
	A8	√	√	√	√	√

Blockchain-based secure and fair crowdsourcing scheme

Abstract

Keywords

Introduction

Our contributions

Related work

Centralized crowdsourcing scheme

Blockchain-based crowdsourcing scheme

Preliminaries

Secure hash function

Definition 1

Homomorphic encryption

Definition 2

Commitment scheme

Definition 3

Blockchain

Problem formulations

System model

Requester

Workers

Blockchain

Threat model

Requester

Workers

Outsiders

Design goals

The proposed scheme

Overview

Initialization

Task publishment

Solution submission

Reward distribution

Discussion of the BFC scheme

Analysis of scheme

Fairness

Confidentiality

Integrity

Comparison on security

Performance evaluation

Initialization

Task publishment

Solution submission

Reward distribution

Comparison on performance

Conclusion

Footnotes

Declaration of conflicting interests

Funding

ORCID iD

References

Schemes		MTurk	EFF and DFF	CrowdBC	ZebraLancer	Our scheme
G1	A1	×	×	√	√	√
G2	A2	−	√	−	−	√
	A3	−	×	√	√	√
G3	A4	√	−	√	√	√
	A5	×	×	×	×	√
	A6	−	−	√	√	√
	A7	√	×	×	×	√
	A8	√	√	√	√	√