# PrivCrowd: A Secure Blockchain-Based Crowdsourcing Framework with Fine-Grained Worker Selection

Authors: Qiliang Yang; Tao Wang; Wenbo Zhang; Bo Yang; Yong Yu; Haiyu Li; Jingyi Wang; Zirui Qiao
Journal: Wireless Communications and Mobile Computing
 (2021)

---

## Abstract

Blockchain-based crowdsourcing systems can mitigate some known limitations of the centralized crowdsourcing platform, such as single point of failure and Sybil attacks. However, blockchain-based crowdsourcing systems still endure the issues of privacy and security. Participants’ sensitive information (e.g., identity, address, and expertise) have the risk of privacy disclosure. Sensitive crowdsourcing tasks such as location-based data collection and labeling images including faces also need privacy-preserving. Moreover, current work fails to balance the anonymity and public auditing of workers. In this paper, we present a secure blockchain-based crowdsourcing framework with fine-grained worker selection, namedPrivCrowd which exploits a functional encryption scheme to protect the data privacy of tasks and to select workers by matching the attributes. In PrivCrowd, requesters and workers can achieve both exchange and evaluation fairness by calling smart contracts. Solutions collection also can be done in a secure, sound, and noninteractive way. Experiment results show the feasibility, usability, and efficiency of PrivCrowd.


---

## Body

## 1. Introduction

Jeff Howe first used the notion of “crowdsourcing” in 2006 [1], as time goes on, crowdsourcing becomes a very promising industry. Crowdsourcing provides a distributed problem-solving paradigm which is not the same as traditional outsourcing computation [2, 3]. In a crowdsourcing platform, a requester can post an open call for solutions submitted by workers for her crowdsourcing task, such as creating writing and image labeling. Some popular crowdsourcing businesses include MTurk (https://www.mturk.com/mturk/), Upwork (https://www.upwork.com), and Freelancer (https://www.freelancer.com). These systems are generally centralized platforms where match the requesters’ and workers’ task pair with fair exchange of rewards. A centralized crowdsourcing framework at least includes the following drawbacks: (1) the platform must be trusted, (2) the platform usually charges transaction fee from both requesters and workers, (3) sensitive information is stored in the platform, (4) single point of failure, and (5) manipulation to the participants’ attributes.Many works try to solve the above-mentioned problems from different perspectives. Some try to design distributed crowdsourcing systems [4, 5]. Some try to leverage the blockchain to build a decentralized crowdsourcing platform to alleviate these known issues [6–8]. Some try to protect the data privacy of tasks [9, 10]. Blockchain-based crowdsourcing platforms have some core advantages which include to maintain participants’ attributes publicly and manipulation-resiliently, to build a fair trading platform between requesters and workers by exploiting the smart contracts, and to avoid the single point of failure. However, there is a dilemma in blockchain-based crowdsourcing schemes, that is, tamper-proofing of public ledger make the workers’ and requesters’ profiles be trusty in a decentralized way. On the other hand, plaintext profiles recorded by blockchain will leak massive sensitive data about participants’ identity, expertise, etc. Some works tackle the privacy leak by using expensive tools. [7] uses the group signature to provide anonymity with accountability. [8] proposed a common-prefix-linkable anonymous authentication scheme which also provides anonymity with accountability. But these works hinder the platform to take advantage of the transparency of blockchain, that is, identity anonymity makes the public auditing of worker’s attributes impossible. Especially in the reputation-based crowdsourcing scheme, anonymity and accountability need to be a tradeoff. On the other hand, some proposals fail to protect the data privacy of the tasks and the solutions [6, 8]. For some sensitive crowdsourcing tasks, such as geographic location collection and images labeling containing faces, the risk of privacy information leakage is still serious.Thus, this work is motivated by designing a blockchain-based crowdsourcing framework which meets the following requirements:(i)
Using blockchain to provide trustworthiness of workers in a decentralized way(ii)
Protecting the data privacy of both tasks and solutions(iii)
Providing protection of identity anonymityNext, we will briefly review the related literature about blockchain-based crowdsourcing systems.


### 1.1. Related Work

#### 1.1.1. Blockchain-Based Crowdsourcing Systems

CrowdBC is a fancy blockchain-based crowdsourcing framework which can effectively thwart many attacks such as DDoS, Sybil, and “false-reporting” attacks. However, CrowdBC provides no privacy protection for the task’s data, neither for the solution [6]. Tanas et al. used blockchain to decentralize data crowdsourcing, but they did not consider privacy and anonymity which are fundamentally arguable for basic utility [11]. Zhang et al. using secure hash, commitment, and homomorphic encryption, proposes a blockchain-based crowdsourcing scheme named BFC [12]. Zhu et al. proposed a hybrid blockchain-based named zkCrowd. In this platform, they integrated with a hybrid blockchain structure, smart contract, dual ledgers, and dual consensus protocols, but their work mainly focuses on the consensus protocol [13]. Feng et al. proposed a blockchain-based MCS system, named MCS-Chain, to realize fully distributed and decentralized trust management in MCS, but they did not consider the privacy concerns [14].


#### 1.1.2. Anonymous and Security

Li et al. also adopted a pseudonym method to achieve anonymous crowdsourcing, but their proposal cannot detect malicious workers who pretend pseudo IDs for rewards [15]. Rahaman et al. used a group signature with sublinear revocation and backward unlinkability and exculpability to construct an anonymous-yet-accountable crowdsourcing system [16]. Gisdakis et al. focused on privacy issues during the data crowdsourcing and introduced more authorities to deal with different functionalities [17]. The distributed authority could reduce the excessive trust; however, the instantiation of these authorities in practice is still intractable. ZebraLancer is one of the priori works that tempts to present some privacy-preserved schemes. They proposed a common-prefix-linkable anonymous authentication scheme which also provides anonymity with accountability [8]. SecBCS exploits the group signature, CPABE to provide anonymity and privacy protection [7].


### 1.2. Organization

The remainder of the paper is organized as follows. In Section2, we present the overview of our proposed framework. In Section 3, we review the preliminaries. The building blocks, posting protocol, and submission protocol are given in Section 4. In Section 5, the description and security analysis of our proposed framework is given. Next, we present a series of security analysis in Section 6 and efficiency analysis for our framework in Section 7, and finally, we conclude and discuss the future work of the paper in Section 8.


## 1.1. Related Work

### 1.1.1. Blockchain-Based Crowdsourcing Systems

CrowdBC is a fancy blockchain-based crowdsourcing framework which can effectively thwart many attacks such as DDoS, Sybil, and “false-reporting” attacks. However, CrowdBC provides no privacy protection for the task’s data, neither for the solution [6]. Tanas et al. used blockchain to decentralize data crowdsourcing, but they did not consider privacy and anonymity which are fundamentally arguable for basic utility [11]. Zhang et al. using secure hash, commitment, and homomorphic encryption, proposes a blockchain-based crowdsourcing scheme named BFC [12]. Zhu et al. proposed a hybrid blockchain-based named zkCrowd. In this platform, they integrated with a hybrid blockchain structure, smart contract, dual ledgers, and dual consensus protocols, but their work mainly focuses on the consensus protocol [13]. Feng et al. proposed a blockchain-based MCS system, named MCS-Chain, to realize fully distributed and decentralized trust management in MCS, but they did not consider the privacy concerns [14].


### 1.1.2. Anonymous and Security

Li et al. also adopted a pseudonym method to achieve anonymous crowdsourcing, but their proposal cannot detect malicious workers who pretend pseudo IDs for rewards [15]. Rahaman et al. used a group signature with sublinear revocation and backward unlinkability and exculpability to construct an anonymous-yet-accountable crowdsourcing system [16]. Gisdakis et al. focused on privacy issues during the data crowdsourcing and introduced more authorities to deal with different functionalities [17]. The distributed authority could reduce the excessive trust; however, the instantiation of these authorities in practice is still intractable. ZebraLancer is one of the priori works that tempts to present some privacy-preserved schemes. They proposed a common-prefix-linkable anonymous authentication scheme which also provides anonymity with accountability [8]. SecBCS exploits the group signature, CPABE to provide anonymity and privacy protection [7].


## 1.1.1. Blockchain-Based Crowdsourcing Systems

CrowdBC is a fancy blockchain-based crowdsourcing framework which can effectively thwart many attacks such as DDoS, Sybil, and “false-reporting” attacks. However, CrowdBC provides no privacy protection for the task’s data, neither for the solution [6]. Tanas et al. used blockchain to decentralize data crowdsourcing, but they did not consider privacy and anonymity which are fundamentally arguable for basic utility [11]. Zhang et al. using secure hash, commitment, and homomorphic encryption, proposes a blockchain-based crowdsourcing scheme named BFC [12]. Zhu et al. proposed a hybrid blockchain-based named zkCrowd. In this platform, they integrated with a hybrid blockchain structure, smart contract, dual ledgers, and dual consensus protocols, but their work mainly focuses on the consensus protocol [13]. Feng et al. proposed a blockchain-based MCS system, named MCS-Chain, to realize fully distributed and decentralized trust management in MCS, but they did not consider the privacy concerns [14].


## 1.1.2. Anonymous and Security

Li et al. also adopted a pseudonym method to achieve anonymous crowdsourcing, but their proposal cannot detect malicious workers who pretend pseudo IDs for rewards [15]. Rahaman et al. used a group signature with sublinear revocation and backward unlinkability and exculpability to construct an anonymous-yet-accountable crowdsourcing system [16]. Gisdakis et al. focused on privacy issues during the data crowdsourcing and introduced more authorities to deal with different functionalities [17]. The distributed authority could reduce the excessive trust; however, the instantiation of these authorities in practice is still intractable. ZebraLancer is one of the priori works that tempts to present some privacy-preserved schemes. They proposed a common-prefix-linkable anonymous authentication scheme which also provides anonymity with accountability [8]. SecBCS exploits the group signature, CPABE to provide anonymity and privacy protection [7].


## 1.2. Organization

The remainder of the paper is organized as follows. In Section2, we present the overview of our proposed framework. In Section 3, we review the preliminaries. The building blocks, posting protocol, and submission protocol are given in Section 4. In Section 5, the description and security analysis of our proposed framework is given. Next, we present a series of security analysis in Section 6 and efficiency analysis for our framework in Section 7, and finally, we conclude and discuss the future work of the paper in Section 8.


## 2. Overview of our Proposed Framework

### 2.1. System Model

We propose a novel secure and privacy-preserved blockchain-based crowdsourcing framework with fine-grained worker selection, calledPrivCrowd. In PrivCrowd, the participants, i.e., the requesters and workers can do crowdsourcing tasks in a secure way, which means the requester’s posting task’s data are encrypted by a functional encryption (FE) scheme specifically carved for PrivCrowd. Moreover, the solution data are submitted also in the ciphertext. Our framework can run atop a public blockchain, e.g., Ethereum [18], which uses pseudonyms to protect the user’s privacy. Therefore, the privacy of outsourcing tasks can be guaranteed because the task data and solution data are processed and transferred in the ciphertext. There are five roles in our PrivCrowd. As shown in Figure 1, these roles are requester, worker, crowdsourcing authority (CA), smart contract (blockchain), and storage. They logically operate in three layers which are top-down named task layer, blockchain layer, and storage layer.Figure 1
The architecture ofPrivCrowd.


#### 2.1.1. Task Layer

Almost every practical crowdsourcing platform involves a role named registration authority (RA) to prevent malicious participants [8], and RA also acts to identity authentication to avoid complicated mutual authentication [19–22]. So in our framework, we need a crowdsourcing authority (CA) that acts as a RA at the user registration phase and also acts as a key generation center (KGC) to generate keys for the functional encryption scheme. The requester in task layer posts his tasks by sending to the smart contract PostTask a message including task requirements, and metadata which usually is a pointer addressing the encrypted task’s data, stored at the storage. The worker who wants to participate in the task requests CA (who acts as KGC right now) a predicate key for further decryption, submits the solution to the smart contract CollectSol, and gets a reward if the solution is qualified.


#### 2.1.2. Blockchain Layer

In blockchain layer, there are three smart contractsPostTask, CollectSol, and UpdateProf. PostTask waits for requesters’ contact, receives the posted task, and notifies the CollectSol to begin collecting solutions. CollectSol then collects worker’s submissions and evaluates them by checking the zk-SNARK proof. If a worker finishes the job, he gets the rewards. Besides the above two smart contracts, there is another contract UpdateProf for updating the public profile of the workers who have accomplished the task. The workers’ profiles, such as expertise, reputation, and location, are publicly recorded on the blockchain which obviously are unforgeable by any party. Moreover, there are miners in the blockchain layer, just like in a public blockchain system, who will persistently receive newly proposed blocks, and faithfully execute “programs” defined by current states with taking messages in new blocks as inputs.


#### 2.1.3. Storage Layer

Considering that the task data and solution data usually should be too large to be stored directly in the smart contract, a storage layer is necessary. The entity in the storage layer is third-party storage, such as the public cloud or IPFS [23]. We do not need the storage to be trusted, because both task data and solution data are stored after encryption. It should be noted that our scheme adopts the hybrid encryption paradigm for task data encryption, that is, a symmetric encryption scheme (such as AES) is used to encrypt the task data, and the symmetric key is encrypted with the FE scheme. Qualified workers will get a predicate key that can decrypt the FE ciphertext and, then, decrypt the FE ciphertext to get the symmetric key to decrypt task data. Our scheme uses the public key encryption scheme for the encryption of the solution, that is, encrypts the solution data directly with the public key of the requester. Clearly, the hybrid encryption paradigm can also be used here to process the solution data.


### 2.2. Intuition

In this section, we will overview the key ideas for designing thePrivCrowd. Blockchain-based crowdsourcing systems still endure the issues of privacy and security. CrowdBC is a fancy blockchain-based crowdsourcing framework which can effectively thwart many attacks such as DDoS, Sybil, and “false-reporting” attacks. However, CrowdBC provides no privacy protection for the task’s data, neither for the solution [6]. Tanas et al. used blockchain to decentralize data crowdsourcing, but they did not consider privacy and anonymity which are fundamentally arguable for basic utility [11]. ZebraLancer is one of the priori works that tempts to present some privacy-preserved schemes. They proposed a common-prefix-linkable anonymous authentication scheme which also provides anonymity with accountability, but the solutions evaluation procedure needs the requester to be only and interactive with the smart contract [8]. SecBCS exploits the group signature, CPABE to provide anonymity and privacy protection, but this platform needs a trusted hardware [7].Based on our motivation, different from the zebraLancer [8] and SecBCS [7], our strategies are(1)
To provide a blockchain-based, public, and tamper-proof attribute maintaining scheme for workers in the first move(2)
To provide a fair trading platform for crowdsourcing task between requesters and workers by exploiting the smart contracts(3)
To protect task’s privacy by using an elaborated functional encryption scheme to encrypt the sensitive data of the task, such as images containing human privacy information and sensitive map data. This move provides a noninteractive and fine-grained worker selection mechanism(4)
To protect solution’s privacy also by using public-key encryption, but with the encrypted solution, to let the worker to submit a zk-SNARK proof to convince the verifier, the smart contract, to believe that solution is qualified(5)
To use pseudonyms protecting participants’ identity anonymityTherefore, with these designs, our overall goal of thePrivCrowd can be achieved. We think that although it just provides weak privacy protection for the identity of participants, i.e., pseudonym, due to protections by encrypting the sensitive data of the tasks and the solutions, even if the adversary succeeds to attack the identity anonymous, he will get no more information of the participants for crowdsourcing tasks.


### 2.3. Our Contributions

In a nutshell, the contributions of this work are presented as follows:(i)
We propose a blockchain-based, privacy-preserved, and secure crowdsourcing framework namedPrivCrowd which does not depend on any centralized crowdsourcing platform to accomplish crowdsourcing process. Moreover, users do not need to pay the costly service fees to traditional crowdsourcing platform anymore, only required to pay a small amount of transaction fees(ii)
Requester can post a task by publishing task’s encrypted data then goes offline by using our functional encryption scheme for the inner product. This design provides a fine-grained access control mechanism for crowdsourcing data which can select the qualified workers through the attributes in a public way. This means only those workers who satisfy the requirements specified by the requester in advance can decrypt the task’s data and participate in this task(iii)
A worker can submit a solution also in a noninteractive way by submitting a proof as well to the smart contract. The smart contract then verifies that proof meets the requirements of the requester, if yes, payment will be made automatically, and the profile of the worker will be updated as well(iv)
We introduce three standard smart contracts in the framework:PostTask, CollectSol, and UpdateProf, by which crowdsourcing functionalities can be achieved such as posting, receiving a task, and submitting a solution without interaction between the requester and the worker(v)
We implement the building blocks of thePrivCrowd to verify the feasibility. For fine-grained workers selection protocol with task’s data privacy-preserving, we present the core component, the FEforIP, which is efficient. For noninteractive solution submission and evaluation protocol, we also evaluate the core component, zk-SNARK, in the scenario of range proof for an integer, which also proves that our submission protocol is efficient(vi)
We also implement the smart contracts on the Ethereum public test network and evaluate the deployment cost and running cost. Experiment results show the usability and scalability of our proposed crowdsourcing system. Furthermore, we illustrate a discussion of future improvements to this scheme


## 2.1. System Model

We propose a novel secure and privacy-preserved blockchain-based crowdsourcing framework with fine-grained worker selection, calledPrivCrowd. In PrivCrowd, the participants, i.e., the requesters and workers can do crowdsourcing tasks in a secure way, which means the requester’s posting task’s data are encrypted by a functional encryption (FE) scheme specifically carved for PrivCrowd. Moreover, the solution data are submitted also in the ciphertext. Our framework can run atop a public blockchain, e.g., Ethereum [18], which uses pseudonyms to protect the user’s privacy. Therefore, the privacy of outsourcing tasks can be guaranteed because the task data and solution data are processed and transferred in the ciphertext. There are five roles in our PrivCrowd. As shown in Figure 1, these roles are requester, worker, crowdsourcing authority (CA), smart contract (blockchain), and storage. They logically operate in three layers which are top-down named task layer, blockchain layer, and storage layer.Figure 1
The architecture ofPrivCrowd.


### 2.1.1. Task Layer

Almost every practical crowdsourcing platform involves a role named registration authority (RA) to prevent malicious participants [8], and RA also acts to identity authentication to avoid complicated mutual authentication [19–22]. So in our framework, we need a crowdsourcing authority (CA) that acts as a RA at the user registration phase and also acts as a key generation center (KGC) to generate keys for the functional encryption scheme. The requester in task layer posts his tasks by sending to the smart contract PostTask a message including task requirements, and metadata which usually is a pointer addressing the encrypted task’s data, stored at the storage. The worker who wants to participate in the task requests CA (who acts as KGC right now) a predicate key for further decryption, submits the solution to the smart contract CollectSol, and gets a reward if the solution is qualified.


### 2.1.2. Blockchain Layer

In blockchain layer, there are three smart contractsPostTask, CollectSol, and UpdateProf. PostTask waits for requesters’ contact, receives the posted task, and notifies the CollectSol to begin collecting solutions. CollectSol then collects worker’s submissions and evaluates them by checking the zk-SNARK proof. If a worker finishes the job, he gets the rewards. Besides the above two smart contracts, there is another contract UpdateProf for updating the public profile of the workers who have accomplished the task. The workers’ profiles, such as expertise, reputation, and location, are publicly recorded on the blockchain which obviously are unforgeable by any party. Moreover, there are miners in the blockchain layer, just like in a public blockchain system, who will persistently receive newly proposed blocks, and faithfully execute “programs” defined by current states with taking messages in new blocks as inputs.


### 2.1.3. Storage Layer

Considering that the task data and solution data usually should be too large to be stored directly in the smart contract, a storage layer is necessary. The entity in the storage layer is third-party storage, such as the public cloud or IPFS [23]. We do not need the storage to be trusted, because both task data and solution data are stored after encryption. It should be noted that our scheme adopts the hybrid encryption paradigm for task data encryption, that is, a symmetric encryption scheme (such as AES) is used to encrypt the task data, and the symmetric key is encrypted with the FE scheme. Qualified workers will get a predicate key that can decrypt the FE ciphertext and, then, decrypt the FE ciphertext to get the symmetric key to decrypt task data. Our scheme uses the public key encryption scheme for the encryption of the solution, that is, encrypts the solution data directly with the public key of the requester. Clearly, the hybrid encryption paradigm can also be used here to process the solution data.


## 2.1.1. Task Layer

Almost every practical crowdsourcing platform involves a role named registration authority (RA) to prevent malicious participants [8], and RA also acts to identity authentication to avoid complicated mutual authentication [19–22]. So in our framework, we need a crowdsourcing authority (CA) that acts as a RA at the user registration phase and also acts as a key generation center (KGC) to generate keys for the functional encryption scheme. The requester in task layer posts his tasks by sending to the smart contract PostTask a message including task requirements, and metadata which usually is a pointer addressing the encrypted task’s data, stored at the storage. The worker who wants to participate in the task requests CA (who acts as KGC right now) a predicate key for further decryption, submits the solution to the smart contract CollectSol, and gets a reward if the solution is qualified.


## 2.1.2. Blockchain Layer

In blockchain layer, there are three smart contractsPostTask, CollectSol, and UpdateProf. PostTask waits for requesters’ contact, receives the posted task, and notifies the CollectSol to begin collecting solutions. CollectSol then collects worker’s submissions and evaluates them by checking the zk-SNARK proof. If a worker finishes the job, he gets the rewards. Besides the above two smart contracts, there is another contract UpdateProf for updating the public profile of the workers who have accomplished the task. The workers’ profiles, such as expertise, reputation, and location, are publicly recorded on the blockchain which obviously are unforgeable by any party. Moreover, there are miners in the blockchain layer, just like in a public blockchain system, who will persistently receive newly proposed blocks, and faithfully execute “programs” defined by current states with taking messages in new blocks as inputs.


## 2.1.3. Storage Layer

Considering that the task data and solution data usually should be too large to be stored directly in the smart contract, a storage layer is necessary. The entity in the storage layer is third-party storage, such as the public cloud or IPFS [23]. We do not need the storage to be trusted, because both task data and solution data are stored after encryption. It should be noted that our scheme adopts the hybrid encryption paradigm for task data encryption, that is, a symmetric encryption scheme (such as AES) is used to encrypt the task data, and the symmetric key is encrypted with the FE scheme. Qualified workers will get a predicate key that can decrypt the FE ciphertext and, then, decrypt the FE ciphertext to get the symmetric key to decrypt task data. Our scheme uses the public key encryption scheme for the encryption of the solution, that is, encrypts the solution data directly with the public key of the requester. Clearly, the hybrid encryption paradigm can also be used here to process the solution data.


## 2.2. Intuition

In this section, we will overview the key ideas for designing thePrivCrowd. Blockchain-based crowdsourcing systems still endure the issues of privacy and security. CrowdBC is a fancy blockchain-based crowdsourcing framework which can effectively thwart many attacks such as DDoS, Sybil, and “false-reporting” attacks. However, CrowdBC provides no privacy protection for the task’s data, neither for the solution [6]. Tanas et al. used blockchain to decentralize data crowdsourcing, but they did not consider privacy and anonymity which are fundamentally arguable for basic utility [11]. ZebraLancer is one of the priori works that tempts to present some privacy-preserved schemes. They proposed a common-prefix-linkable anonymous authentication scheme which also provides anonymity with accountability, but the solutions evaluation procedure needs the requester to be only and interactive with the smart contract [8]. SecBCS exploits the group signature, CPABE to provide anonymity and privacy protection, but this platform needs a trusted hardware [7].Based on our motivation, different from the zebraLancer [8] and SecBCS [7], our strategies are(1)
To provide a blockchain-based, public, and tamper-proof attribute maintaining scheme for workers in the first move(2)
To provide a fair trading platform for crowdsourcing task between requesters and workers by exploiting the smart contracts(3)
To protect task’s privacy by using an elaborated functional encryption scheme to encrypt the sensitive data of the task, such as images containing human privacy information and sensitive map data. This move provides a noninteractive and fine-grained worker selection mechanism(4)
To protect solution’s privacy also by using public-key encryption, but with the encrypted solution, to let the worker to submit a zk-SNARK proof to convince the verifier, the smart contract, to believe that solution is qualified(5)
To use pseudonyms protecting participants’ identity anonymityTherefore, with these designs, our overall goal of thePrivCrowd can be achieved. We think that although it just provides weak privacy protection for the identity of participants, i.e., pseudonym, due to protections by encrypting the sensitive data of the tasks and the solutions, even if the adversary succeeds to attack the identity anonymous, he will get no more information of the participants for crowdsourcing tasks.


## 2.3. Our Contributions

In a nutshell, the contributions of this work are presented as follows:(i)
We propose a blockchain-based, privacy-preserved, and secure crowdsourcing framework namedPrivCrowd which does not depend on any centralized crowdsourcing platform to accomplish crowdsourcing process. Moreover, users do not need to pay the costly service fees to traditional crowdsourcing platform anymore, only required to pay a small amount of transaction fees(ii)
Requester can post a task by publishing task’s encrypted data then goes offline by using our functional encryption scheme for the inner product. This design provides a fine-grained access control mechanism for crowdsourcing data which can select the qualified workers through the attributes in a public way. This means only those workers who satisfy the requirements specified by the requester in advance can decrypt the task’s data and participate in this task(iii)
A worker can submit a solution also in a noninteractive way by submitting a proof as well to the smart contract. The smart contract then verifies that proof meets the requirements of the requester, if yes, payment will be made automatically, and the profile of the worker will be updated as well(iv)
We introduce three standard smart contracts in the framework:PostTask, CollectSol, and UpdateProf, by which crowdsourcing functionalities can be achieved such as posting, receiving a task, and submitting a solution without interaction between the requester and the worker(v)
We implement the building blocks of thePrivCrowd to verify the feasibility. For fine-grained workers selection protocol with task’s data privacy-preserving, we present the core component, the FEforIP, which is efficient. For noninteractive solution submission and evaluation protocol, we also evaluate the core component, zk-SNARK, in the scenario of range proof for an integer, which also proves that our submission protocol is efficient(vi)
We also implement the smart contracts on the Ethereum public test network and evaluate the deployment cost and running cost. Experiment results show the usability and scalability of our proposed crowdsourcing system. Furthermore, we illustrate a discussion of future improvements to this scheme


## 3. Preliminaries

### 3.1. Blockchain and Smart Contract

A blockchain is a distributed public and append-only ledger, typically managed by a peer-to-peer network collectively adhering to a protocol for inter-node communication and validating new blocks. Blockchain-based smart contracts are proposed contracts that can be partially or fully executed or enforced without human interaction [24]. One of the main objectives of a smart contract is automated escrow. The blockchain network executes the contract on its own. Some properties (We remark here that we only present partial properties of blockchain which are useful to our framework. For other properties, e.g., consensus, we refer interested readers to literature.) of the blockchain and smart contract can be informally abstracted as follows [8]:(i)
Transparency. All internal states of the blockchain will be visible to the whole blockchain. Therefore, all message deliveries and computations via the blockchain are in the clear(ii)
Tamper-Proof. A blockchain is a permanent record of transactions. Once a block is added, it cannot be altered. This creates trust in the transaction record(iii)
Decentralized. A key feature of smart contracts is that they do not need a trusted third party to act as an intermediary between contracting entities


### 3.2. Digital Signature System

A digital signature system consists of a tuple of three algorithms (Sig.Setup, Sig.Sign, and Sig.Verify) working as follows:(i)
Sig.Setup1λ⟶vk,sk. On input a security parameter λ, this algorithm generates a key pair vk,sk(ii)
Sig.Signsk,m⟶σ. On input a sign key sk and a message m, this algorithm outputs a signature σ(iii)
Sig.Verifyvk,σ⟶0,1. On input a verification key vk and a signature σ, this algorithm outputs 1 if σ is valid. Otherwise, it outputs 0


### 3.3. Functional Encryption for Inner Product Predicates

#### 3.3.1. Notations

Given two vectorsU⟶=u1,u2,⋯,ud and V⟶=v1,v2,⋯,vd, we use the notation U⟶,V⟶ to denote dot product U⟶TV⟶. For a group element g, we use gU⟶ to denote a vector gu1,gu2,⋯,gud.


#### 3.3.2. Wang’s Scheme [25]

For an inner product predicateP, a functional encryption scheme for P is defined as follows:(i)
FE.Setup1λ. This algorithm takes the security parameter λ as input. First, it runs G1n and gets p,q,r,G,GT,e^, where G=Gp×Gq×GrN=p×q×r. Then, it computes gp,gq,gr as generators of Gp,Gq,Gr, respectively. In addition, it chooses random α,x∈RℤN∗ and X⟶∈RℤNd. Finally, it outputs public parameters PP≔G,gp,gr along with the public key:(1)MPK≔gpx,gpX⟶,e^gp,gpα.It keepsMSK≔gpα,x,X⟶ private as the master secret key.(ii)
FE.EncMPK,A⟶,M. Let A⟶=a1,⋯,ad∈Σd, this algorithm takes the public key MPK and a pair A⟶,M as inputs and chooses random exponent s∈RℤN∗, then it outputs C as the ciphertext, where(2)C≔C0≔e^gp,gpαs·M,C1≔gpsxA⟶+X⟶,1.(iii)
FE.KeyGenMSK,PK⟶FE. Let K⟶=k1,⋯,kd∈Σ, this algorithm takes as inputs master secret key MSK and a predicate PK⟶FE, and chooses random y∈RℤN∗,W⟶∈RℤNd+1. Finally, it outputs a predicate key:(3)SKP≔gpyK⟶,α−yX⟶,K⟶grW⟶.(iv)
FE.DecSKP,C. This algorithm takes a token SKK⟶ for a predicate PK⟶FE and ciphertext C as inputs, it outputs:(4)FK⟶,M≔M≔C0e^C1,SKK⟶PK⟶FEA⟶=1⊥PK⟶FEA⟶=0,where(5)PK⟶FEA⟶≔1ifK⟶,A⟶=00otherwise.


#### 3.3.3. Correctness of the FEforIP

LetC and SKP be as above. Then,(6)M=C0e^C1,SKP=e^gp,gpαs·Me^C1,SKP=e^gp,gpαs·Me^gpsxA+X,1,gpyK,α−yX,KgrW=e^gp,gpαs·Me^gpsxA+X,1,gpyK,α−yX,K·e^gpsxA+X,1,grW=e^gp,gpαs·Me^gpsxA+X,1,gpyK,α−yX,K=e^gp,gpαs·Me^gps,gpxA+X,1T·yK,α−yX,K,where xA+X,1T·yK,α−yX,K=xA+XT·yK+α−yX,K=xyA,K+yX,K+α−yX,K=xyA,K+α.For allA,K∈A×K such that PK⟶FEA⟶=1 which means K,A=0modN, then the data M will be recovered correctly.


### 3.4. Hidden-Vector Encryption from FEforIP

LetΣ be a finite set, a Hidden Vector System (HVE) over Σℓ is a selectively secure HVE searchable encryption system [26]. Define Σ∗=Σ∪∗. A symbol “∗” means a wildcard or “do not care” value.Forσ=σ1,⋯,σℓ,x=x1,⋯,xℓ∈Σ∗ℓ define a predicate PσHVE over Σℓ as follows:(7)PσHVEx≔1ifσi=xiorσi=∗,fori=1toℓ0otherwise.In other words, the vectorx match σ in all the coordinates where σ is not ∗.With our functional encryption system for inner product predicates [25], we can easily build an HVE system following the method from [27]. For Σ=ℤN, a HVE system can be realized as follows:(i)
The setup algorithm is the same as FE.Setup(ii)
To generate a secret key corresponding to the predicatePσHVE, construct a vector K⟶=k1,⋯,k2ℓ, where k2i−1≔0,k2i≔0 when σi=∗, and k2i−1≔1,k2i≔xi otherwise. Then, the secret key can be obtained by running FE.KeyGen for predicate PσHVE(iii)
To encrypt a messageM for the attribute A′⟶=a1′,⋯,a2ℓ′, choose random r1,⋯,rℓ∈ℤN and construct a vector A⟶=a1,⋯,a2ℓ, where a2i−1≔−ri·ai,a2i≔ri. Then, output the ciphertext C by running FE.EncMPK,A⟶,MWe can easily find that forσ1,⋯,σℓ, K⟶, a1′,⋯,aℓ′, r⟶, and A⟶ be as above. It is clear that(8)PσHVEx=1⇐∀r⟶:K⟶,A⟶=0⇐∀r⟶:PK⟶FEA⟶=1.Then, correctness and security of this HVE system hold.


### 3.5. Zero-Knowledge Proof System and Zk-SNARK

For a NP-complete languageL=x∣∃w,s.t.,Cx,w=1, a zero-knowledge proof system is composed of triple algorithms G,P,V that work as follows. The generator G, on input the security parameter k, outputs a public parameter pp. The honest prover P produces a proof π to prove the trueness of a statement x∈L with witness w; then, the verifier V can verify π deterministically. The security properties of a zero-knowledge proof system include(i)
Completeness. For every proof π produced by legal instance-witness pair x,w, PVπ,x=1 always holds(ii)
Soundness. The proof is computationally sound (i.e., it is infeasible to fake a proof of a false NP statement). Such a proof system is also called an argument(iii)
Zero-Knowledge. The verifier learns nothing from the proof besides the truth of the statement (i.e., the witness w).Based on the definition in [28], for the arithmetic circuit satisfiability problem of an F-arithmetic circuit C:Fn×Fh⟶Fℓ is captured by the relation RC=x,w∈Fn×Fh:Cx,w=0ℓ, its language is LC=x∈Fn:∃w∈Fhs.t.Cx,w=0ℓ. Then, given a field F, a publicly verifiable preprocessing zero-knowledge succinct noninteractive argument of knowledge (zk-SNARK) for F-arithmetic circuit satisfiability is a triple of polynomial-time algorithms (SNARK.Setup, SNARK.Prove, SNARK.Verify):(i)
SNARK.Setup1λ,C⟶pk,vk. It takes as input a security parameter λ and an F-arithmetic circuit C, and probabilistically samples a proving key pk and a verification key vk. Both keys are published as public parameters and can be used, any number of times, to prove/verify membership in LC(ii)
SNARK.Provepk,x,w⟶π. It takes as input a proving key pk and a tuple x,w∈RC, and outputs a noninteractive proof π for the statement x∈LC(iii)
SNARK.Verifyvk,x,π⟶0,1. It takes as input a verification key vk, a statement x, and a proof π, outputs b=1 if the verifier is convinced that x∈LCFor a zk-SNARK, there are two more necessary properties:(i)
Succinctness. The proof is short and easy to verify(ii)
Noninteractivity. The proof is a string (i.e., it does not require back-and-forth interaction between the prover and the verifier)We remark that there is a rigorous formal definition of succinctness [29], we omit that for the sake of simplicity.


## 3.1. Blockchain and Smart Contract

A blockchain is a distributed public and append-only ledger, typically managed by a peer-to-peer network collectively adhering to a protocol for inter-node communication and validating new blocks. Blockchain-based smart contracts are proposed contracts that can be partially or fully executed or enforced without human interaction [24]. One of the main objectives of a smart contract is automated escrow. The blockchain network executes the contract on its own. Some properties (We remark here that we only present partial properties of blockchain which are useful to our framework. For other properties, e.g., consensus, we refer interested readers to literature.) of the blockchain and smart contract can be informally abstracted as follows [8]:(i)
Transparency. All internal states of the blockchain will be visible to the whole blockchain. Therefore, all message deliveries and computations via the blockchain are in the clear(ii)
Tamper-Proof. A blockchain is a permanent record of transactions. Once a block is added, it cannot be altered. This creates trust in the transaction record(iii)
Decentralized. A key feature of smart contracts is that they do not need a trusted third party to act as an intermediary between contracting entities


## 3.2. Digital Signature System

A digital signature system consists of a tuple of three algorithms (Sig.Setup, Sig.Sign, and Sig.Verify) working as follows:(i)
Sig.Setup1λ⟶vk,sk. On input a security parameter λ, this algorithm generates a key pair vk,sk(ii)
Sig.Signsk,m⟶σ. On input a sign key sk and a message m, this algorithm outputs a signature σ(iii)
Sig.Verifyvk,σ⟶0,1. On input a verification key vk and a signature σ, this algorithm outputs 1 if σ is valid. Otherwise, it outputs 0


## 3.3. Functional Encryption for Inner Product Predicates

### 3.3.1. Notations

Given two vectorsU⟶=u1,u2,⋯,ud and V⟶=v1,v2,⋯,vd, we use the notation U⟶,V⟶ to denote dot product U⟶TV⟶. For a group element g, we use gU⟶ to denote a vector gu1,gu2,⋯,gud.


### 3.3.2. Wang’s Scheme [25]

For an inner product predicateP, a functional encryption scheme for P is defined as follows:(i)
FE.Setup1λ. This algorithm takes the security parameter λ as input. First, it runs G1n and gets p,q,r,G,GT,e^, where G=Gp×Gq×GrN=p×q×r. Then, it computes gp,gq,gr as generators of Gp,Gq,Gr, respectively. In addition, it chooses random α,x∈RℤN∗ and X⟶∈RℤNd. Finally, it outputs public parameters PP≔G,gp,gr along with the public key:(1)MPK≔gpx,gpX⟶,e^gp,gpα.It keepsMSK≔gpα,x,X⟶ private as the master secret key.(ii)
FE.EncMPK,A⟶,M. Let A⟶=a1,⋯,ad∈Σd, this algorithm takes the public key MPK and a pair A⟶,M as inputs and chooses random exponent s∈RℤN∗, then it outputs C as the ciphertext, where(2)C≔C0≔e^gp,gpαs·M,C1≔gpsxA⟶+X⟶,1.(iii)
FE.KeyGenMSK,PK⟶FE. Let K⟶=k1,⋯,kd∈Σ, this algorithm takes as inputs master secret key MSK and a predicate PK⟶FE, and chooses random y∈RℤN∗,W⟶∈RℤNd+1. Finally, it outputs a predicate key:(3)SKP≔gpyK⟶,α−yX⟶,K⟶grW⟶.(iv)
FE.DecSKP,C. This algorithm takes a token SKK⟶ for a predicate PK⟶FE and ciphertext C as inputs, it outputs:(4)FK⟶,M≔M≔C0e^C1,SKK⟶PK⟶FEA⟶=1⊥PK⟶FEA⟶=0,where(5)PK⟶FEA⟶≔1ifK⟶,A⟶=00otherwise.


### 3.3.3. Correctness of the FEforIP

LetC and SKP be as above. Then,(6)M=C0e^C1,SKP=e^gp,gpαs·Me^C1,SKP=e^gp,gpαs·Me^gpsxA+X,1,gpyK,α−yX,KgrW=e^gp,gpαs·Me^gpsxA+X,1,gpyK,α−yX,K·e^gpsxA+X,1,grW=e^gp,gpαs·Me^gpsxA+X,1,gpyK,α−yX,K=e^gp,gpαs·Me^gps,gpxA+X,1T·yK,α−yX,K,where xA+X,1T·yK,α−yX,K=xA+XT·yK+α−yX,K=xyA,K+yX,K+α−yX,K=xyA,K+α.For allA,K∈A×K such that PK⟶FEA⟶=1 which means K,A=0modN, then the data M will be recovered correctly.


## 3.3.1. Notations

Given two vectorsU⟶=u1,u2,⋯,ud and V⟶=v1,v2,⋯,vd, we use the notation U⟶,V⟶ to denote dot product U⟶TV⟶. For a group element g, we use gU⟶ to denote a vector gu1,gu2,⋯,gud.


## 3.3.2. Wang’s Scheme [25]

For an inner product predicateP, a functional encryption scheme for P is defined as follows:(i)
FE.Setup1λ. This algorithm takes the security parameter λ as input. First, it runs G1n and gets p,q,r,G,GT,e^, where G=Gp×Gq×GrN=p×q×r. Then, it computes gp,gq,gr as generators of Gp,Gq,Gr, respectively. In addition, it chooses random α,x∈RℤN∗ and X⟶∈RℤNd. Finally, it outputs public parameters PP≔G,gp,gr along with the public key:(1)MPK≔gpx,gpX⟶,e^gp,gpα.It keepsMSK≔gpα,x,X⟶ private as the master secret key.(ii)
FE.EncMPK,A⟶,M. Let A⟶=a1,⋯,ad∈Σd, this algorithm takes the public key MPK and a pair A⟶,M as inputs and chooses random exponent s∈RℤN∗, then it outputs C as the ciphertext, where(2)C≔C0≔e^gp,gpαs·M,C1≔gpsxA⟶+X⟶,1.(iii)
FE.KeyGenMSK,PK⟶FE. Let K⟶=k1,⋯,kd∈Σ, this algorithm takes as inputs master secret key MSK and a predicate PK⟶FE, and chooses random y∈RℤN∗,W⟶∈RℤNd+1. Finally, it outputs a predicate key:(3)SKP≔gpyK⟶,α−yX⟶,K⟶grW⟶.(iv)
FE.DecSKP,C. This algorithm takes a token SKK⟶ for a predicate PK⟶FE and ciphertext C as inputs, it outputs:(4)FK⟶,M≔M≔C0e^C1,SKK⟶PK⟶FEA⟶=1⊥PK⟶FEA⟶=0,where(5)PK⟶FEA⟶≔1ifK⟶,A⟶=00otherwise.


## 3.3.3. Correctness of the FEforIP

LetC and SKP be as above. Then,(6)M=C0e^C1,SKP=e^gp,gpαs·Me^C1,SKP=e^gp,gpαs·Me^gpsxA+X,1,gpyK,α−yX,KgrW=e^gp,gpαs·Me^gpsxA+X,1,gpyK,α−yX,K·e^gpsxA+X,1,grW=e^gp,gpαs·Me^gpsxA+X,1,gpyK,α−yX,K=e^gp,gpαs·Me^gps,gpxA+X,1T·yK,α−yX,K,where xA+X,1T·yK,α−yX,K=xA+XT·yK+α−yX,K=xyA,K+yX,K+α−yX,K=xyA,K+α.For allA,K∈A×K such that PK⟶FEA⟶=1 which means K,A=0modN, then the data M will be recovered correctly.


## 3.4. Hidden-Vector Encryption from FEforIP

LetΣ be a finite set, a Hidden Vector System (HVE) over Σℓ is a selectively secure HVE searchable encryption system [26]. Define Σ∗=Σ∪∗. A symbol “∗” means a wildcard or “do not care” value.Forσ=σ1,⋯,σℓ,x=x1,⋯,xℓ∈Σ∗ℓ define a predicate PσHVE over Σℓ as follows:(7)PσHVEx≔1ifσi=xiorσi=∗,fori=1toℓ0otherwise.In other words, the vectorx match σ in all the coordinates where σ is not ∗.With our functional encryption system for inner product predicates [25], we can easily build an HVE system following the method from [27]. For Σ=ℤN, a HVE system can be realized as follows:(i)
The setup algorithm is the same as FE.Setup(ii)
To generate a secret key corresponding to the predicatePσHVE, construct a vector K⟶=k1,⋯,k2ℓ, where k2i−1≔0,k2i≔0 when σi=∗, and k2i−1≔1,k2i≔xi otherwise. Then, the secret key can be obtained by running FE.KeyGen for predicate PσHVE(iii)
To encrypt a messageM for the attribute A′⟶=a1′,⋯,a2ℓ′, choose random r1,⋯,rℓ∈ℤN and construct a vector A⟶=a1,⋯,a2ℓ, where a2i−1≔−ri·ai,a2i≔ri. Then, output the ciphertext C by running FE.EncMPK,A⟶,MWe can easily find that forσ1,⋯,σℓ, K⟶, a1′,⋯,aℓ′, r⟶, and A⟶ be as above. It is clear that(8)PσHVEx=1⇐∀r⟶:K⟶,A⟶=0⇐∀r⟶:PK⟶FEA⟶=1.Then, correctness and security of this HVE system hold.


## 3.5. Zero-Knowledge Proof System and Zk-SNARK

For a NP-complete languageL=x∣∃w,s.t.,Cx,w=1, a zero-knowledge proof system is composed of triple algorithms G,P,V that work as follows. The generator G, on input the security parameter k, outputs a public parameter pp. The honest prover P produces a proof π to prove the trueness of a statement x∈L with witness w; then, the verifier V can verify π deterministically. The security properties of a zero-knowledge proof system include(i)
Completeness. For every proof π produced by legal instance-witness pair x,w, PVπ,x=1 always holds(ii)
Soundness. The proof is computationally sound (i.e., it is infeasible to fake a proof of a false NP statement). Such a proof system is also called an argument(iii)
Zero-Knowledge. The verifier learns nothing from the proof besides the truth of the statement (i.e., the witness w).Based on the definition in [28], for the arithmetic circuit satisfiability problem of an F-arithmetic circuit C:Fn×Fh⟶Fℓ is captured by the relation RC=x,w∈Fn×Fh:Cx,w=0ℓ, its language is LC=x∈Fn:∃w∈Fhs.t.Cx,w=0ℓ. Then, given a field F, a publicly verifiable preprocessing zero-knowledge succinct noninteractive argument of knowledge (zk-SNARK) for F-arithmetic circuit satisfiability is a triple of polynomial-time algorithms (SNARK.Setup, SNARK.Prove, SNARK.Verify):(i)
SNARK.Setup1λ,C⟶pk,vk. It takes as input a security parameter λ and an F-arithmetic circuit C, and probabilistically samples a proving key pk and a verification key vk. Both keys are published as public parameters and can be used, any number of times, to prove/verify membership in LC(ii)
SNARK.Provepk,x,w⟶π. It takes as input a proving key pk and a tuple x,w∈RC, and outputs a noninteractive proof π for the statement x∈LC(iii)
SNARK.Verifyvk,x,π⟶0,1. It takes as input a verification key vk, a statement x, and a proof π, outputs b=1 if the verifier is convinced that x∈LCFor a zk-SNARK, there are two more necessary properties:(i)
Succinctness. The proof is short and easy to verify(ii)
Noninteractivity. The proof is a string (i.e., it does not require back-and-forth interaction between the prover and the verifier)We remark that there is a rigorous formal definition of succinctness [29], we omit that for the sake of simplicity.


## 4. Building Blocks

### 4.1. Fine-Grained Workers Selection Protocol with task’s Data Privacy-Preserving: Posting Protocol

In this section, we show how to build a fine-grained data access control scheme by exploiting Wang’s scheme. Different from some related works, such as using CP-ABE with a fixed LSSS access structure [7], our design goal is to let qualified workers can decrypt the task’s data which are priori uploaded and stored in blockchain in the posting task phase, enabling a more powerful worker’s profile expression, such as arbitrary CNF/DNF formulas.For example, a requester posts a crowdsourcing task which restricts those workers can involve in whose reputation≥15 or location in L1,L2,L5 and expertise=Writing. We formalize this example using vectors representing the attributes required by the requester and profiles of workers. Let R=r1,r⟶2,r3 denote the requiring attributes; in this case, r1 is the reputation value, r⟶2 the location set, and r3 the expertise. Let W=w1,w2,w3 denote the profiles that a worker has, that is, w1 is his/her exact reputation value, w2 current location, and w3 his/her expertise. Formally, workers can participate in this job who satisfy the following predicate:(9)Priwi≔1ifw1≥r1∨w2∈r⟶2∧w3=r30otherwise.Now, the core problem here is how to encode predicates into vectors that we can leverage the FEforIP directly. We did not describe this in [25] which is important for our scheme, so we will show the specific encoding method step by step.


#### 4.1.1. Conjunctive Equality

LetΣ be some finite set. For W⟶∈Σ define an equality test predicate PW⟶EqR⟶ as(10)PW⟶EqR⟶≔1ifwi=ri,foralli=1tod0otherwise,where R⟶≔r1,r2,⋯,rd∈Σd, and W⟶≔w1,w2,⋯,wd∈Σd. Let ΦEq=PW⟶Eq,forallW⟶∈Σ. Then, implementing this equality test with our PEforIP is fairly easy.For the ciphertext attributeR⟶, set R′⟶≔−R⟶,1 and encrypt a message pair R′⟶,M using algorithm FE.Enc(MPK,R′⟶,M). To generate secret key SKW⟶ for the key attribute W⟶, set W′⟶≔1,W⟶. Observe that W′⟶,R′⟶=0 if and only if for all i=1 to d, wi=ri holds, which means, for any predicate PW⟶Eq∈ΦEq, and an attribute R⟶, we have that PW⟶EqR⟶=1 if and only if PW′⟶FER′⟶=1. Therefore, correctness and security follow from the properties of the FEforIP. We also remark that if we set d=1, then the scheme degenerates to the singleton equality test.


#### 4.1.2. Conjunctive Compare/Range

Different from equality, compare/range and subset are pretty complicated but subtle. For a predicatePW⟶ComR⟶, we show how to realize a compare predicate by leveraging a FEforIP. Given a finite set Σ′=0,1, set Σ′∗=0,1,∗. Let (HVE.Setup, HVE.Enc, HVE.KeyGen, HVE.Dec) be a secure HVE system over Σ′∗ defined as in Section 3.4. Then, for W⟶∈Σ, define a conjunctive compare test predicate PW⟶ComR⟶ as(11)PW⟶ComR⟶≔1ifwi≥ri,foralli=1tod0otherwise,where R⟶≔r1,r2,⋯,rd∈ℤNd, and W⟶≔w1,w2,⋯,wd∈ℤNd. Let ΦCom=PW⟶Com,forallW⟶∈Σ.Then, build a vectorσR⟶=σi,j∈Σ′d as follows:(12)σi,j≔1ifj≥ri,0otherwise,output HVE.Enc PK,σR⟶,M as ciphertext.For generating a secret key for predicatePW⟶Com, define σ∗W⟶=σi,j∈Σ∗′d as follows:(13)σi,j≔1ifj=ri,0otherwise,then output HVE.KeyGen SK,σ∗W⟶ as secret key SKW⟶.To argue correctness and security, observe thatPW⟶ComR⟶=1⇐Pσ∗W⟶HVEσR⟶=1⇐W⟶,R⟶=0⇐PW⟶FER⟶=1. Therefore, correctness and security follow from the properties of the FEforIP. We also note that a system that supports comparison tests can also support range tests. For example, to select workers for some property x∈a,b, the requester encrypts the vector a,b with task’s data. The predicate then tests x≥a⋀x≤b. However, how to realize “∧” or “∨” still not be resolved; we leave this problem later in this section.


#### 4.1.3. Conjunctive Subset

LetΣ be a set of size n, for some subsets Ri⊆Σ and R⟶≔R1,R2,⋯,Rd define a conjunctive subset test predicate PW⟶SubR⟶ as(14)PW⟶SubR⟶≔1ifwi∈Ri,foralli=1tod0otherwise,where W⟶≔w1,w2,⋯,wd∈Σd.Then, build a vectorσ∗R⟶=σi,j∈Σ′d as follows:(15)σi,j≔1ifj∉Ri,0otherwise,output HVE.EncPK,σ∗R⟶,M as ciphertext.For generating a secret key for predicatePW⟶Sub, define σW⟶=σi,j∈Σ′d as follows:(16)σi,j≔1ifj=wi,0otherwise,then output HVE.KeyGen SK,σW⟶ as secret key SKW⟶.To argue correctness and security, observe that:PW⟶SubR⟶=1⇐PσW⟶HVEσ∗R⟶=1⇐W⟶,R⟶=0⇐PW⟶FER⟶=1. Therefore, correctness and security follow from the properties of the FEforIP.


#### 4.1.4. Polynomial and CNF/DNF

Similar to [25], we can also encode a polynomial predicate to vectors by defining the classes of predicates accordingly. For polynomials of degree ≤d, define the predicate set Φ≤dPoly≔PW⟶PolyR⟶∣p∈ℤNx,degp≤d, where(17)PW⟶PolyR⟶≔1ifpx=0modN0otherwise,for x∈ℤN. We map the polynomial px=w0+w1x1+⋯+wdxd to W⟶≔w0,w1,⋯,wd. For ciphertext attribute, R⟶ is mapped onto a key attribute vector R⟶≔r0modN,r1modN,⋯,rdmodN. Then, for predicate PW⟶PolyR⟶∈Φ≤dPoly, correctness and security follows from the properties of the FEforIP, since px=0 whenever W⟶,R⟶=0.Based on FEforIP forPW⟶PolyR⟶∈Φ≤dPoly, we can easily support the conjunctions, disjunctions, and their extensions CNF/DNF. We show this ability using an example of conjunctions of equality tests. To do this, for some W⟶≔w1,w2 and R⟶≔r1,r2, we define the conjunction predicate as Pw1,w2ANDr1,r2, where Pw1,w2ANDr1,r2=1 iff both w1=r1 and w2=r2. This predicate can be a polynomial as(18)p′x1,x2=r·x1−w1+x2−w2,where r⟵$ℤN. If Pw1,w2ANDr1,r2=1, then p′r1,r2=0; otherwise, with all but negligible probability over choice of r, it will hold that p′r1,r2≠0.In a similar fashion, we can define the predicate for the disjunction of equality tests. For someW⟶≔w1,w2 and R⟶≔r1,r2, we define the disjunction predicate as Pw1,w2ORr1,r2, where Pw1,w2ORr1,r2=1 iff either w1=r1 or w2=r2. This predicate also can be a polynomial as(19)p″x1,x2=x1−w1·x2−w2.IfPw1,w2ORr1,r2=1, then p′′r1,r2=0; otherwise, p′′r1,r2≠0.We can combine disjunctions, conjunctions, and boolean variables to handle arbitrary CNF or DNF formulas.


#### 4.1.5. Putting All in Together

Now, we know how to handle the equality, compare/range, subset, polynomial, and CNF/DNF. All these properties enable our FEforIP scheme to support testing on the ciphertext task’s data encrypted by the requester associated with an attribute vector which constrains the qualified workers who hold the predicate which is associated with another vector and will be true. As shown in Figure2, our fine-grained workers' selection protocol works as follows:(i)
A requester would describe her task’s requirements which are encoded as a vectorR⟶, and input it to the Ciphertext compiler which will output a requirements vector R′⟶(ii)
The ciphertext compiler encodes various requirementsR⟶ as different vectors, e.g., equality test requirement and subset test requirement. These vectors then are combined as one vector R′⟶(iii)
Then, the requester invokes FE.EncMPK,R′⟶,KT to encrypt a secret key KT which is used by a symmetric encryption algorithm to encrypt task’s data which is stored at the storage in ciphertext(iv)
On the other hand, interested workers would submit their credentials to the KGC to generate their predicate keys. We emphasize that the worker does not submit their profile attributes to the KGC. Their profile attributes are stored and maintained publicly in blockchain which means the KGC can direct read these attributes(v)
Worker’s attribute would be as the input of the predicate compiler. According to the type of the requirements vector, the predicate compiler will formalize the predicates, e.g., equality test predicate and subset test predicate. Then, different predicates are encoded in a single form predicate, i.e., polynomial predicatePW′⟶PolyR′⟶ by the combiner(vi)
The KGC then invokes FE.KeyGen(MSK, PW′⟶PolyR′⟶) to generate the predicate keys SKP accordingly(vii)
Finally, only those qualified workers who hold the predicate keysSKP such that PW′⟶PolyR′⟶=1 get the secret key KT which in turn enable them to decrypt the task’s dataFigure 2
Overview of our fine-grained workers’ selection scheme.Therefore, our protocol provides a scheme for requesters to select workers in a noninteractive and fine-grained way.


### 4.2. Noninteractive Solution Submission and Evaluation Protocol: Submission Protocol

#### 4.2.1. Concrete Protocol

According to our designing goal, the proposed schemePrivCrowd protects the task’s privacy twofold. That is to encrypt the task’s data by exploiting the FEforIP, as well as to encrypt the solution using the requester’s public key before submitting it. Then, the challenge here is how to evaluate solutions at blockchain publicly, considering the worker submits solutions are encrypted.(i)
Setupλ. This algorithm initializes the public parameter Params for the zk-SNARK system and generates a key pair mpk,msk for a digital signature scheme (We remark this algorithm can be invoked by RA as other setups which need a trusted party)(ii)
GenCertmsk,pki. This algorithm is run by the RA in the user registration phase. On input a worker’s public key pki, it outputs a signature Ci which is signed pki by msk as worker’s certificate(iii)
Submitsi,ski,pki,Ci,Params. This algorithm is run by the worker who wants to submit a solution for task TIDi. It invokes the Sig.Sign() algorithm to sign the task’s ID TIDi using ski and receives signature SigskiTIDi. It also invokes the SNARK.Prove(si, LTIDi) to generate a proof πi, where si is solution data, and LTIDi≔x=TIDi,Params∣∃w,s.t.SolEvalsi=1(iv)
EvaluateΠ. Use π1 to verify the worker’s certificate, π2 to verify whether pki and ski are consistent, and π3 to verify whether solution si is satisfied SolEval·


#### 4.2.2. Instantiate zk-SNARK for the Protocol

For the submission protocol of ourPrivCrowd, the role of the zk-SNARK is pretty simple. We just need to prove that a worker’s submission meets the requirements when he submits the solution. Meanwhile, the privacy of the solution needs to be protected when the worker’s submission is verified by the smart contract publicly. That is, for a solution si of a worker, the zk-SNARK checks that SolEvalsi=1 holds.We must emphasize that we are not going further to instantiate the functionSolEval· in our PrivCrowd, which results in that we neither going further to instantiate the zk-SNARK by presenting the specific circuit for it. The reason is that different solution evaluation functions will lead to different implementations of the zk-SNARK. We leave the SolEval· as an open interface to compatible with any kind of evaluation scheme. For example, one can easily implement an evaluation scheme for checking the numeric solution data in a range by instantiating a zk-SNARK for this specific NP statement. We first translate these mathematical statements into their corresponding boolean circuit satisfiability representations. Furthermore, we establish zk-SNARK for each boolean circuit, such that all required public parameters are generated. All the above steps are done offline, as they are executed only once when the system is launched.


## 4.1. Fine-Grained Workers Selection Protocol with task’s Data Privacy-Preserving: Posting Protocol

In this section, we show how to build a fine-grained data access control scheme by exploiting Wang’s scheme. Different from some related works, such as using CP-ABE with a fixed LSSS access structure [7], our design goal is to let qualified workers can decrypt the task’s data which are priori uploaded and stored in blockchain in the posting task phase, enabling a more powerful worker’s profile expression, such as arbitrary CNF/DNF formulas.For example, a requester posts a crowdsourcing task which restricts those workers can involve in whose reputation≥15 or location in L1,L2,L5 and expertise=Writing. We formalize this example using vectors representing the attributes required by the requester and profiles of workers. Let R=r1,r⟶2,r3 denote the requiring attributes; in this case, r1 is the reputation value, r⟶2 the location set, and r3 the expertise. Let W=w1,w2,w3 denote the profiles that a worker has, that is, w1 is his/her exact reputation value, w2 current location, and w3 his/her expertise. Formally, workers can participate in this job who satisfy the following predicate:(9)Priwi≔1ifw1≥r1∨w2∈r⟶2∧w3=r30otherwise.Now, the core problem here is how to encode predicates into vectors that we can leverage the FEforIP directly. We did not describe this in [25] which is important for our scheme, so we will show the specific encoding method step by step.


### 4.1.1. Conjunctive Equality

LetΣ be some finite set. For W⟶∈Σ define an equality test predicate PW⟶EqR⟶ as(10)PW⟶EqR⟶≔1ifwi=ri,foralli=1tod0otherwise,where R⟶≔r1,r2,⋯,rd∈Σd, and W⟶≔w1,w2,⋯,wd∈Σd. Let ΦEq=PW⟶Eq,forallW⟶∈Σ. Then, implementing this equality test with our PEforIP is fairly easy.For the ciphertext attributeR⟶, set R′⟶≔−R⟶,1 and encrypt a message pair R′⟶,M using algorithm FE.Enc(MPK,R′⟶,M). To generate secret key SKW⟶ for the key attribute W⟶, set W′⟶≔1,W⟶. Observe that W′⟶,R′⟶=0 if and only if for all i=1 to d, wi=ri holds, which means, for any predicate PW⟶Eq∈ΦEq, and an attribute R⟶, we have that PW⟶EqR⟶=1 if and only if PW′⟶FER′⟶=1. Therefore, correctness and security follow from the properties of the FEforIP. We also remark that if we set d=1, then the scheme degenerates to the singleton equality test.


### 4.1.2. Conjunctive Compare/Range

Different from equality, compare/range and subset are pretty complicated but subtle. For a predicatePW⟶ComR⟶, we show how to realize a compare predicate by leveraging a FEforIP. Given a finite set Σ′=0,1, set Σ′∗=0,1,∗. Let (HVE.Setup, HVE.Enc, HVE.KeyGen, HVE.Dec) be a secure HVE system over Σ′∗ defined as in Section 3.4. Then, for W⟶∈Σ, define a conjunctive compare test predicate PW⟶ComR⟶ as(11)PW⟶ComR⟶≔1ifwi≥ri,foralli=1tod0otherwise,where R⟶≔r1,r2,⋯,rd∈ℤNd, and W⟶≔w1,w2,⋯,wd∈ℤNd. Let ΦCom=PW⟶Com,forallW⟶∈Σ.Then, build a vectorσR⟶=σi,j∈Σ′d as follows:(12)σi,j≔1ifj≥ri,0otherwise,output HVE.Enc PK,σR⟶,M as ciphertext.For generating a secret key for predicatePW⟶Com, define σ∗W⟶=σi,j∈Σ∗′d as follows:(13)σi,j≔1ifj=ri,0otherwise,then output HVE.KeyGen SK,σ∗W⟶ as secret key SKW⟶.To argue correctness and security, observe thatPW⟶ComR⟶=1⇐Pσ∗W⟶HVEσR⟶=1⇐W⟶,R⟶=0⇐PW⟶FER⟶=1. Therefore, correctness and security follow from the properties of the FEforIP. We also note that a system that supports comparison tests can also support range tests. For example, to select workers for some property x∈a,b, the requester encrypts the vector a,b with task’s data. The predicate then tests x≥a⋀x≤b. However, how to realize “∧” or “∨” still not be resolved; we leave this problem later in this section.


### 4.1.3. Conjunctive Subset

LetΣ be a set of size n, for some subsets Ri⊆Σ and R⟶≔R1,R2,⋯,Rd define a conjunctive subset test predicate PW⟶SubR⟶ as(14)PW⟶SubR⟶≔1ifwi∈Ri,foralli=1tod0otherwise,where W⟶≔w1,w2,⋯,wd∈Σd.Then, build a vectorσ∗R⟶=σi,j∈Σ′d as follows:(15)σi,j≔1ifj∉Ri,0otherwise,output HVE.EncPK,σ∗R⟶,M as ciphertext.For generating a secret key for predicatePW⟶Sub, define σW⟶=σi,j∈Σ′d as follows:(16)σi,j≔1ifj=wi,0otherwise,then output HVE.KeyGen SK,σW⟶ as secret key SKW⟶.To argue correctness and security, observe that:PW⟶SubR⟶=1⇐PσW⟶HVEσ∗R⟶=1⇐W⟶,R⟶=0⇐PW⟶FER⟶=1. Therefore, correctness and security follow from the properties of the FEforIP.


### 4.1.4. Polynomial and CNF/DNF

Similar to [25], we can also encode a polynomial predicate to vectors by defining the classes of predicates accordingly. For polynomials of degree ≤d, define the predicate set Φ≤dPoly≔PW⟶PolyR⟶∣p∈ℤNx,degp≤d, where(17)PW⟶PolyR⟶≔1ifpx=0modN0otherwise,for x∈ℤN. We map the polynomial px=w0+w1x1+⋯+wdxd to W⟶≔w0,w1,⋯,wd. For ciphertext attribute, R⟶ is mapped onto a key attribute vector R⟶≔r0modN,r1modN,⋯,rdmodN. Then, for predicate PW⟶PolyR⟶∈Φ≤dPoly, correctness and security follows from the properties of the FEforIP, since px=0 whenever W⟶,R⟶=0.Based on FEforIP forPW⟶PolyR⟶∈Φ≤dPoly, we can easily support the conjunctions, disjunctions, and their extensions CNF/DNF. We show this ability using an example of conjunctions of equality tests. To do this, for some W⟶≔w1,w2 and R⟶≔r1,r2, we define the conjunction predicate as Pw1,w2ANDr1,r2, where Pw1,w2ANDr1,r2=1 iff both w1=r1 and w2=r2. This predicate can be a polynomial as(18)p′x1,x2=r·x1−w1+x2−w2,where r⟵$ℤN. If Pw1,w2ANDr1,r2=1, then p′r1,r2=0; otherwise, with all but negligible probability over choice of r, it will hold that p′r1,r2≠0.In a similar fashion, we can define the predicate for the disjunction of equality tests. For someW⟶≔w1,w2 and R⟶≔r1,r2, we define the disjunction predicate as Pw1,w2ORr1,r2, where Pw1,w2ORr1,r2=1 iff either w1=r1 or w2=r2. This predicate also can be a polynomial as(19)p″x1,x2=x1−w1·x2−w2.IfPw1,w2ORr1,r2=1, then p′′r1,r2=0; otherwise, p′′r1,r2≠0.We can combine disjunctions, conjunctions, and boolean variables to handle arbitrary CNF or DNF formulas.


### 4.1.5. Putting All in Together

Now, we know how to handle the equality, compare/range, subset, polynomial, and CNF/DNF. All these properties enable our FEforIP scheme to support testing on the ciphertext task’s data encrypted by the requester associated with an attribute vector which constrains the qualified workers who hold the predicate which is associated with another vector and will be true. As shown in Figure2, our fine-grained workers' selection protocol works as follows:(i)
A requester would describe her task’s requirements which are encoded as a vectorR⟶, and input it to the Ciphertext compiler which will output a requirements vector R′⟶(ii)
The ciphertext compiler encodes various requirementsR⟶ as different vectors, e.g., equality test requirement and subset test requirement. These vectors then are combined as one vector R′⟶(iii)
Then, the requester invokes FE.EncMPK,R′⟶,KT to encrypt a secret key KT which is used by a symmetric encryption algorithm to encrypt task’s data which is stored at the storage in ciphertext(iv)
On the other hand, interested workers would submit their credentials to the KGC to generate their predicate keys. We emphasize that the worker does not submit their profile attributes to the KGC. Their profile attributes are stored and maintained publicly in blockchain which means the KGC can direct read these attributes(v)
Worker’s attribute would be as the input of the predicate compiler. According to the type of the requirements vector, the predicate compiler will formalize the predicates, e.g., equality test predicate and subset test predicate. Then, different predicates are encoded in a single form predicate, i.e., polynomial predicatePW′⟶PolyR′⟶ by the combiner(vi)
The KGC then invokes FE.KeyGen(MSK, PW′⟶PolyR′⟶) to generate the predicate keys SKP accordingly(vii)
Finally, only those qualified workers who hold the predicate keysSKP such that PW′⟶PolyR′⟶=1 get the secret key KT which in turn enable them to decrypt the task’s dataFigure 2
Overview of our fine-grained workers’ selection scheme.Therefore, our protocol provides a scheme for requesters to select workers in a noninteractive and fine-grained way.


## 4.1.1. Conjunctive Equality

LetΣ be some finite set. For W⟶∈Σ define an equality test predicate PW⟶EqR⟶ as(10)PW⟶EqR⟶≔1ifwi=ri,foralli=1tod0otherwise,where R⟶≔r1,r2,⋯,rd∈Σd, and W⟶≔w1,w2,⋯,wd∈Σd. Let ΦEq=PW⟶Eq,forallW⟶∈Σ. Then, implementing this equality test with our PEforIP is fairly easy.For the ciphertext attributeR⟶, set R′⟶≔−R⟶,1 and encrypt a message pair R′⟶,M using algorithm FE.Enc(MPK,R′⟶,M). To generate secret key SKW⟶ for the key attribute W⟶, set W′⟶≔1,W⟶. Observe that W′⟶,R′⟶=0 if and only if for all i=1 to d, wi=ri holds, which means, for any predicate PW⟶Eq∈ΦEq, and an attribute R⟶, we have that PW⟶EqR⟶=1 if and only if PW′⟶FER′⟶=1. Therefore, correctness and security follow from the properties of the FEforIP. We also remark that if we set d=1, then the scheme degenerates to the singleton equality test.


## 4.1.2. Conjunctive Compare/Range

Different from equality, compare/range and subset are pretty complicated but subtle. For a predicatePW⟶ComR⟶, we show how to realize a compare predicate by leveraging a FEforIP. Given a finite set Σ′=0,1, set Σ′∗=0,1,∗. Let (HVE.Setup, HVE.Enc, HVE.KeyGen, HVE.Dec) be a secure HVE system over Σ′∗ defined as in Section 3.4. Then, for W⟶∈Σ, define a conjunctive compare test predicate PW⟶ComR⟶ as(11)PW⟶ComR⟶≔1ifwi≥ri,foralli=1tod0otherwise,where R⟶≔r1,r2,⋯,rd∈ℤNd, and W⟶≔w1,w2,⋯,wd∈ℤNd. Let ΦCom=PW⟶Com,forallW⟶∈Σ.Then, build a vectorσR⟶=σi,j∈Σ′d as follows:(12)σi,j≔1ifj≥ri,0otherwise,output HVE.Enc PK,σR⟶,M as ciphertext.For generating a secret key for predicatePW⟶Com, define σ∗W⟶=σi,j∈Σ∗′d as follows:(13)σi,j≔1ifj=ri,0otherwise,then output HVE.KeyGen SK,σ∗W⟶ as secret key SKW⟶.To argue correctness and security, observe thatPW⟶ComR⟶=1⇐Pσ∗W⟶HVEσR⟶=1⇐W⟶,R⟶=0⇐PW⟶FER⟶=1. Therefore, correctness and security follow from the properties of the FEforIP. We also note that a system that supports comparison tests can also support range tests. For example, to select workers for some property x∈a,b, the requester encrypts the vector a,b with task’s data. The predicate then tests x≥a⋀x≤b. However, how to realize “∧” or “∨” still not be resolved; we leave this problem later in this section.


## 4.1.3. Conjunctive Subset

LetΣ be a set of size n, for some subsets Ri⊆Σ and R⟶≔R1,R2,⋯,Rd define a conjunctive subset test predicate PW⟶SubR⟶ as(14)PW⟶SubR⟶≔1ifwi∈Ri,foralli=1tod0otherwise,where W⟶≔w1,w2,⋯,wd∈Σd.Then, build a vectorσ∗R⟶=σi,j∈Σ′d as follows:(15)σi,j≔1ifj∉Ri,0otherwise,output HVE.EncPK,σ∗R⟶,M as ciphertext.For generating a secret key for predicatePW⟶Sub, define σW⟶=σi,j∈Σ′d as follows:(16)σi,j≔1ifj=wi,0otherwise,then output HVE.KeyGen SK,σW⟶ as secret key SKW⟶.To argue correctness and security, observe that:PW⟶SubR⟶=1⇐PσW⟶HVEσ∗R⟶=1⇐W⟶,R⟶=0⇐PW⟶FER⟶=1. Therefore, correctness and security follow from the properties of the FEforIP.


## 4.1.4. Polynomial and CNF/DNF

Similar to [25], we can also encode a polynomial predicate to vectors by defining the classes of predicates accordingly. For polynomials of degree ≤d, define the predicate set Φ≤dPoly≔PW⟶PolyR⟶∣p∈ℤNx,degp≤d, where(17)PW⟶PolyR⟶≔1ifpx=0modN0otherwise,for x∈ℤN. We map the polynomial px=w0+w1x1+⋯+wdxd to W⟶≔w0,w1,⋯,wd. For ciphertext attribute, R⟶ is mapped onto a key attribute vector R⟶≔r0modN,r1modN,⋯,rdmodN. Then, for predicate PW⟶PolyR⟶∈Φ≤dPoly, correctness and security follows from the properties of the FEforIP, since px=0 whenever W⟶,R⟶=0.Based on FEforIP forPW⟶PolyR⟶∈Φ≤dPoly, we can easily support the conjunctions, disjunctions, and their extensions CNF/DNF. We show this ability using an example of conjunctions of equality tests. To do this, for some W⟶≔w1,w2 and R⟶≔r1,r2, we define the conjunction predicate as Pw1,w2ANDr1,r2, where Pw1,w2ANDr1,r2=1 iff both w1=r1 and w2=r2. This predicate can be a polynomial as(18)p′x1,x2=r·x1−w1+x2−w2,where r⟵$ℤN. If Pw1,w2ANDr1,r2=1, then p′r1,r2=0; otherwise, with all but negligible probability over choice of r, it will hold that p′r1,r2≠0.In a similar fashion, we can define the predicate for the disjunction of equality tests. For someW⟶≔w1,w2 and R⟶≔r1,r2, we define the disjunction predicate as Pw1,w2ORr1,r2, where Pw1,w2ORr1,r2=1 iff either w1=r1 or w2=r2. This predicate also can be a polynomial as(19)p″x1,x2=x1−w1·x2−w2.IfPw1,w2ORr1,r2=1, then p′′r1,r2=0; otherwise, p′′r1,r2≠0.We can combine disjunctions, conjunctions, and boolean variables to handle arbitrary CNF or DNF formulas.


## 4.1.5. Putting All in Together

Now, we know how to handle the equality, compare/range, subset, polynomial, and CNF/DNF. All these properties enable our FEforIP scheme to support testing on the ciphertext task’s data encrypted by the requester associated with an attribute vector which constrains the qualified workers who hold the predicate which is associated with another vector and will be true. As shown in Figure2, our fine-grained workers' selection protocol works as follows:(i)
A requester would describe her task’s requirements which are encoded as a vectorR⟶, and input it to the Ciphertext compiler which will output a requirements vector R′⟶(ii)
The ciphertext compiler encodes various requirementsR⟶ as different vectors, e.g., equality test requirement and subset test requirement. These vectors then are combined as one vector R′⟶(iii)
Then, the requester invokes FE.EncMPK,R′⟶,KT to encrypt a secret key KT which is used by a symmetric encryption algorithm to encrypt task’s data which is stored at the storage in ciphertext(iv)
On the other hand, interested workers would submit their credentials to the KGC to generate their predicate keys. We emphasize that the worker does not submit their profile attributes to the KGC. Their profile attributes are stored and maintained publicly in blockchain which means the KGC can direct read these attributes(v)
Worker’s attribute would be as the input of the predicate compiler. According to the type of the requirements vector, the predicate compiler will formalize the predicates, e.g., equality test predicate and subset test predicate. Then, different predicates are encoded in a single form predicate, i.e., polynomial predicatePW′⟶PolyR′⟶ by the combiner(vi)
The KGC then invokes FE.KeyGen(MSK, PW′⟶PolyR′⟶) to generate the predicate keys SKP accordingly(vii)
Finally, only those qualified workers who hold the predicate keysSKP such that PW′⟶PolyR′⟶=1 get the secret key KT which in turn enable them to decrypt the task’s dataFigure 2
Overview of our fine-grained workers’ selection scheme.Therefore, our protocol provides a scheme for requesters to select workers in a noninteractive and fine-grained way.


## 4.2. Noninteractive Solution Submission and Evaluation Protocol: Submission Protocol

### 4.2.1. Concrete Protocol

According to our designing goal, the proposed schemePrivCrowd protects the task’s privacy twofold. That is to encrypt the task’s data by exploiting the FEforIP, as well as to encrypt the solution using the requester’s public key before submitting it. Then, the challenge here is how to evaluate solutions at blockchain publicly, considering the worker submits solutions are encrypted.(i)
Setupλ. This algorithm initializes the public parameter Params for the zk-SNARK system and generates a key pair mpk,msk for a digital signature scheme (We remark this algorithm can be invoked by RA as other setups which need a trusted party)(ii)
GenCertmsk,pki. This algorithm is run by the RA in the user registration phase. On input a worker’s public key pki, it outputs a signature Ci which is signed pki by msk as worker’s certificate(iii)
Submitsi,ski,pki,Ci,Params. This algorithm is run by the worker who wants to submit a solution for task TIDi. It invokes the Sig.Sign() algorithm to sign the task’s ID TIDi using ski and receives signature SigskiTIDi. It also invokes the SNARK.Prove(si, LTIDi) to generate a proof πi, where si is solution data, and LTIDi≔x=TIDi,Params∣∃w,s.t.SolEvalsi=1(iv)
EvaluateΠ. Use π1 to verify the worker’s certificate, π2 to verify whether pki and ski are consistent, and π3 to verify whether solution si is satisfied SolEval·


### 4.2.2. Instantiate zk-SNARK for the Protocol

For the submission protocol of ourPrivCrowd, the role of the zk-SNARK is pretty simple. We just need to prove that a worker’s submission meets the requirements when he submits the solution. Meanwhile, the privacy of the solution needs to be protected when the worker’s submission is verified by the smart contract publicly. That is, for a solution si of a worker, the zk-SNARK checks that SolEvalsi=1 holds.We must emphasize that we are not going further to instantiate the functionSolEval· in our PrivCrowd, which results in that we neither going further to instantiate the zk-SNARK by presenting the specific circuit for it. The reason is that different solution evaluation functions will lead to different implementations of the zk-SNARK. We leave the SolEval· as an open interface to compatible with any kind of evaluation scheme. For example, one can easily implement an evaluation scheme for checking the numeric solution data in a range by instantiating a zk-SNARK for this specific NP statement. We first translate these mathematical statements into their corresponding boolean circuit satisfiability representations. Furthermore, we establish zk-SNARK for each boolean circuit, such that all required public parameters are generated. All the above steps are done offline, as they are executed only once when the system is launched.


## 4.2.1. Concrete Protocol

According to our designing goal, the proposed schemePrivCrowd protects the task’s privacy twofold. That is to encrypt the task’s data by exploiting the FEforIP, as well as to encrypt the solution using the requester’s public key before submitting it. Then, the challenge here is how to evaluate solutions at blockchain publicly, considering the worker submits solutions are encrypted.(i)
Setupλ. This algorithm initializes the public parameter Params for the zk-SNARK system and generates a key pair mpk,msk for a digital signature scheme (We remark this algorithm can be invoked by RA as other setups which need a trusted party)(ii)
GenCertmsk,pki. This algorithm is run by the RA in the user registration phase. On input a worker’s public key pki, it outputs a signature Ci which is signed pki by msk as worker’s certificate(iii)
Submitsi,ski,pki,Ci,Params. This algorithm is run by the worker who wants to submit a solution for task TIDi. It invokes the Sig.Sign() algorithm to sign the task’s ID TIDi using ski and receives signature SigskiTIDi. It also invokes the SNARK.Prove(si, LTIDi) to generate a proof πi, where si is solution data, and LTIDi≔x=TIDi,Params∣∃w,s.t.SolEvalsi=1(iv)
EvaluateΠ. Use π1 to verify the worker’s certificate, π2 to verify whether pki and ski are consistent, and π3 to verify whether solution si is satisfied SolEval·


## 4.2.2. Instantiate zk-SNARK for the Protocol

For the submission protocol of ourPrivCrowd, the role of the zk-SNARK is pretty simple. We just need to prove that a worker’s submission meets the requirements when he submits the solution. Meanwhile, the privacy of the solution needs to be protected when the worker’s submission is verified by the smart contract publicly. That is, for a solution si of a worker, the zk-SNARK checks that SolEvalsi=1 holds.We must emphasize that we are not going further to instantiate the functionSolEval· in our PrivCrowd, which results in that we neither going further to instantiate the zk-SNARK by presenting the specific circuit for it. The reason is that different solution evaluation functions will lead to different implementations of the zk-SNARK. We leave the SolEval· as an open interface to compatible with any kind of evaluation scheme. For example, one can easily implement an evaluation scheme for checking the numeric solution data in a range by instantiating a zk-SNARK for this specific NP statement. We first translate these mathematical statements into their corresponding boolean circuit satisfiability representations. Furthermore, we establish zk-SNARK for each boolean circuit, such that all required public parameters are generated. All the above steps are done offline, as they are executed only once when the system is launched.


## 5.PrivCrowd: Concrete Scheme

### 5.1. Security Challenges

In this section, we specify the basic security requirements for our blockchain-based crowdsourcing platform. For blockchain-based crowdsourcing, with the majority honest security assumption, fully fraud resilient property is inherent [6]. So, we mainly focus on the security and privacy of tasks and solutions.


#### 5.1.1. Data Privacy of Task

In a crowdsourcing system, the posed tasks may include highly sensitive data such as map data, location information, and sensitive images. Due to the publicity of blockchain, sensitive data cannot be stored directly in the blockchain. Otherwise, this would result in leakage of information and compromise the requester’s privacy. Although some related proposals did not provide privacy protection [6, 8], we treat the protection for sensitive data as our first concern.


#### 5.1.2. Data Privacy of Solution

Sensitive tasks are most likely to collect sensitive solutions. The data privacy protection of solutions is also very important, which is also the design goal of our scheme. Using encryption can provide privacy protection and can also prevent a “free-riding” attack which refers to malicious workers who get solutions submitted by other workers and directly use them as their own submission. Our design goals also include resistance to this kind of attack.


#### 5.1.3. Soundness of Solution

In our scheme, we want to build a fair and noninteractive platform for requesters and workers. Those workers who submit right and good solutions must get payment, but those who free-ride must get nothing. One of the big challenges is how to ensure that the submitted solutions are qualified. We name this property the soundness of the solution. Moreover, using encryption to protect the solution makes this challenge more complicated. That is, how to evaluate the encrypted solution at the smart contracts in a noninteractive way. Lu et al. adopt an interactive solution evaluation procedure between the requester and the smart contract [8]. We want to avoid this kind of interaction.


#### 5.1.4. Trustworthy of Workers

We think in a blockchain-based crowdsourcing platform, using the tamper-proof property of blockchain to enforce the trustworthy of workers and make the attributes of workers’ manipulation resistance is a key idea, especially in reputation-based incentive mechanism.


### 5.2. The Outsourcing Process

Now, we are ready to present a specific procedure for the crowdsourcing tasks. As the FEforIP and zk-SNARK require a setup phase, we consider that a setup algorithm generated the public parametersPP=PPFE,PPZK for this purpose and published it as common knowledge.We treat blockchain as an infrastructure in which many miners, for the sake of their interests, participate to confirm transactions and to execute smart contracts. Any type of user can initiate a transaction, that is, broadcast the transaction message signed by him to the blockchain and wait for the blockchain to confirm. We omit the process of miner selection by the consensus protocol after the requester publishes the task. In our scheme, when we say that the requester or worker sends a message to the blockchain, it means that the message is sent to a smart contract associated with an address.In ourPrivCrowd, the outsourcing process consists of five sequential procedures including User registering, Requester posting task, Attribute keys generation, Solutions submitting and evaluation, and Workers profile updating. Moreover, the first three procedures are used to implement the fine-grained workers’ selection protocol detailed described in Section 4.1, and the last two procedures are used to implement the noninteractive solution submission and evaluation protocol described in Section 4.2. As shown in Figure 3, these procedures work as follows.(1)
User Registering. In this procedure, any type of users, i.e., requesters and workers, generate the key pair pk,sk and register at CA who act as the registration authority (RA) to get a certificate Cert binding pk. For a requester R, we denote by pkR,skR his key pair and CertR his certificate. Similarly, we denote by pkW,skW a key pair of a worker W and CertW his certificate. We need to emphasize that PrivCrowd just likes the other applications atop on a public blockchain, e.g., Bitcoin, allows participants to generate a fresh address for a task as a simple solution to avoid deanonymization in the underlying blockchain. We omit the detailed address generating process(2)
Requester Posting Task. Once a requester R has an outsourcing task, R encrypts the task’s data by running FE.Enc(MPK,R′⟶,KT) to get a ciphertext CTτ, where MPK is the master public key included in PPFE, R′⟶ is requirements vector, τ is a unique session identifier of the task, and KT is a secret key used by a symmetric encryption algorithm to encrypt task’s data stored at the storage in ciphertext. Then, R sends a signed tuple (To simplify the presentation, we assume implicitly that signed messages can be extracted from their signatures.) SigskRτCTτDesτTτTotRewRPS to the smart contract PostTask, where Tτ is a deadline to collect solutions, TotRew is total reword for this task τ, RPS is the reword per solution, and Desτ is a description of the requirements for the workers who are willing to participate in the task, so that interested workers can judge whether they are qualified. Furthermore, this description Desτ also determines the combination order of different type requirements vectors and attributes vectors as well. We will argue that this combination order does not compromise the security of our workers’ selection protocol described in Section 4.1. On the other hand, R also sends a solution evaluation function SolEval· to the smart contract PostTask to be a criterion for evaluating the solutions. It is worth noting that interested workers can get the task’s information (ciphertext stored on the storage or just encrypted metadata) from the smart contract PostTask right now; either they can do it after they get the predicate key in the next phase. This order has a no different effect on the scheme(3)
Attribute Keys Generation. If an interested worker W wants to participate in the task τ, he will request CA for a decryption key by submitting his certificate CertW. Upon receiving the CertW, the CA, who acts as the KGC right now, will first identify W by verifying the certificate CertW, and then consult the blockchain for profile of W which is publicly recorded and maintained on the blockchain. The profile of W will then be encoded in an attributes vector W′⟶ whose formula is constrained by the description Desτ posted by the requester R. Finally, the CA runs FE.KeyGenMSK,PW′⟶PolyR′⟶ to generate the predicate keys SKP accordingly for the worker W, where MSK is the master secret key for FEforIP scheme, PW′⟶PolyR′⟶ is the predicate exactly detailed in Section 4.2. The CA sends the predicate key SKP to W. We remark that whether W has the ability to decrypt the task data completely depends on the attributes maintained by the public blockchain. If his profile meets the requirement of W, that is, W′⟶,R′⟶=0 technically, W can get the key Kτ then decrypt the task data. Otherwise, the security of the FEforIP ensures that W cannot get any information about the encrypted task’s data. R selects qualified workers in this noninteractive and oblivious manner. Moreover, the worker’s profile, maintained by blockchain, is tamper-proof, which against the malicious manipulation to the profile of workers which is potential in a centralized crowdsourcing platform(4)
Solutions Submitting and Evaluation. At this phase, before the deadline, once a worker Wi finishes the job, he can submit a solution si encrypted under R’s public key pkW and a zk-SNARK proof Πi to the smart contract CollectSol (If the solution data is big, it will be stored at the storage in ciphertext just like treatment to the task’s data. In this case, the worker’s submission si is an encrypted symmetric key, say KS, which will be further forwarded to the requester.). He also needs to make a deposit to the smart contract in order to initiate this evaluation. We remark that the worker also sends a signature σsi for this submission, and we denote encrypted solution by si. CollectSol then collects and evaluates this solution si. According to the noninteractive solution submission and evaluation protocol, CollectSol first verifies the Wi’s identity and then verifies the zk-snark proof Πi. If any of these verifications fail, the solution collection process for this worker is terminated. Otherwise, it forwards the encrypted solution si to R, pays the worker Wi reward (the reward comes from R’s deposit), and notifies the smart contract UpdateProf to update Wi’s public profile(5)
Workers Profile Updating. Upon receiving the notification from the smart contract CollectSol, the UpdateProf contract will update the profile of this worker Wi’ by creating a transaction. Our priority in this paper is to protect the data privacy of tasks and solution as well. We do not discuss here which attributes of workers need to and how to update. Because these issues involve reputation evaluation and incentive mechanisms in crowdsourcing platforms, which is orthogonal to the focus of this paper. We refer interested readers to read the relevant literatureFigure 3
The outsourcing process in thePrivCrowd.After a lift cycle of outsourcing process, if the protocols are not terminated, a requester gets his solutions and a worker gets his reward accordingly.


### 5.3. Smart Contracts

In this section, we will show in ourPrivCrowd the details of the three smart contracts, i.e., PostTask, CollectSol, and UpdateProf. These smart contracts can be seen as a logical party who is interactive with the requesters, workers, and the CA. In Table 1, we show some notations for the smart contracts.(i)
PostTask. This contract gets the posted task information from requesters. For each pair of requester and task, it takes requester’s public key pkRi and requester’s certificate CertRi as input and verifies the certificate of the requester first, then verifies the signature of the task’s message and checks if the request transfers sufficient deposit to the contract’s address by invoking function getBalance (For the public blockchain infrastructure, checking an account address’s balance is an essential function. We do not care how to implement it in specific, we refer interested readers to related literature.). If all these verification results are negative, this contract terminates immediately and task’s posting fails. Otherwise, before the deadline Tτ, it broadcasts a new task recruiting workers and transfers the deposit to the smart contract CollectSol. The algorithm 1 illustrates the implementation of this contract(ii)
CollectSol. This contract takes as input worker’s public key pkWi, workers’ certificate CertWi, and task posting message including task identifier τ, solution evaluation function SolEval·, deadline of submission Tτ, total reword TotRew, and reward per solution RPS. Whenever gets the transfer from the contract PostTask, it begins to accept worker’s submission. On receiving a signed submission from Wi, parses the submission as (σsisiΠi). Then, verifies the certificate of Wi and the signature of the task’s message in turn. If all these verification results are negative, it terminates this submission. Otherwise, it invokes the SNARK.verify Πi to verify that this submission si pass the evaluation, i.e., SolEvalsi=1. If yes, it forwards the encrypted solution to the requester, pays the reward to Wi, and notifies the contract UpdateProf to update the worker’s public profile. In case of the time is up, solutions collection needs to be terminated, and it refunds the money left to the requester. Once the balance of &CollectSol less than RPS, this contract terminates. Otherwise, Wi gets nothing. The algorithm 2 illustrates the implementation of this contract(iii)
UpdateProf. This contract takes as input worker’s public key pkWi, task identifier τ, and description of the task Desτ. Upon receiving a notification from the contract UpdateProf, it consults the description of the task Desτ for the updating policy. As the algorithm 3 shown, we do not instantiate the updateProfile, but present it as an API for one reason, that is, our scheme is not limited to the incentive mechanism of specific crowdsourcing platforms, but to a general-purpose design. Therefore, whether it is reputation-based or other types of incentive mechanisms can be compatible with our scheme. e.g., for the reputation-based incentive mechanism [30], it may be just update the reputation of the worker Wi onlyTable 1
Notations for the smart contracts.
&RiBlockchain address of the requesterRi.&WiBlockchain address of the workerWi.&PostTaskContract address ofPostTask.&CollectSolContract address ofCollectSol.&UpdateProfContract address ofUpdateProf.getBalance·Read balance of blockchain address.transfersrc,dst,vTransferv from address src to dst.broadcast·Broadcast message to blockchain.updateProfile·Function to update workers’ profile.Algorithm 1: The smart contract: PostTask.
Input: This contract’s address &PostTask; requester’s public key pkRi; requester’s certificate CertRi; task identifier τ; description of the task Desτ; deadline of submission Tτ; total reword TotRew; reward per solution RPS; encrypted task’s data(metadata) CTτ; signature of posting task στ.1:for each Ri and τdo2:ifAuthCertRi,pkRi==⊥3:goto final; ⊳ Certificate invalid or requester unregister4:end if5:Verifyστ==⊥then6:goto final; ⊳ Posting task's signature invalid7:end if8:if getBalance(&PostTask) <TotRewthen9:goto final; ⊳ Deposit Insufficient10:end if11:whileTτ is not expired do12:  broadcast(τ, Desτ, RPS, CTτ, SolEval·) as a new task identified by τ;13:  transfer(&PostTask,&CollectSol,TotRew);14:end while15:end for16:final;17:return;Algorithm 2: The smart contract: CollectSol.
Input: This contract’s address &CollectSol; worker’s public key pkWi; workers’s certificate CertWi; workers’s deposit DepWi; task identifier τ; solution evaluation function SolEval·; deadline of submission Tτ; total reword TotRew; reward per solution RPS.1:while (getBalance(&CollectSol) >RPS) and Tτ is not expired do2: Upon receiving a signed submission fromWi, parses the submission as (σsisiΠi);3:ifAuthCertWi,pkWi==⊥then4:continue; ⊳ Certificate invalid or worker unregister5:end if6:ifVerifyσsi==⊥then7:continue; ⊳ Submission's signature invalid8:end if9:ifDepWi is not sufficient then10:continue; ⊳ Worker's deposit is not sufficient11:end if12:if SNARK.VerifyΠi==accthen13:  Sendsi to the request Ri; ⊳ Forward the solution to the requester14:  transfer(&PostTask,&Wi,PRS+DepWi); ⊳ Pay the reward and refund the deposit15:UpdateProf(pkWi,τ);Invoke the smart contract UpdateProf16:end if17:end while18:if getBalance(&CollectSol) >0then⊳ Refund residue money to the request19: transfer(&CollectSol,&Ri,20:getBalance&CollectSol);21:end if22:return;Algorithm 3: The smart contract: UpdateProf.
Input: This contract’s address &UpdateProf; worker’s public key pkWi; task identifier τ; description of the task Desτ.1: Upon receiving a notification from the contractUpdateProf, consult the description of the task Desτ for the updating policy;2: updateProfile(pkWi, ·);3:return;


## 5.1. Security Challenges

In this section, we specify the basic security requirements for our blockchain-based crowdsourcing platform. For blockchain-based crowdsourcing, with the majority honest security assumption, fully fraud resilient property is inherent [6]. So, we mainly focus on the security and privacy of tasks and solutions.


### 5.1.1. Data Privacy of Task

In a crowdsourcing system, the posed tasks may include highly sensitive data such as map data, location information, and sensitive images. Due to the publicity of blockchain, sensitive data cannot be stored directly in the blockchain. Otherwise, this would result in leakage of information and compromise the requester’s privacy. Although some related proposals did not provide privacy protection [6, 8], we treat the protection for sensitive data as our first concern.


### 5.1.2. Data Privacy of Solution

Sensitive tasks are most likely to collect sensitive solutions. The data privacy protection of solutions is also very important, which is also the design goal of our scheme. Using encryption can provide privacy protection and can also prevent a “free-riding” attack which refers to malicious workers who get solutions submitted by other workers and directly use them as their own submission. Our design goals also include resistance to this kind of attack.


### 5.1.3. Soundness of Solution

In our scheme, we want to build a fair and noninteractive platform for requesters and workers. Those workers who submit right and good solutions must get payment, but those who free-ride must get nothing. One of the big challenges is how to ensure that the submitted solutions are qualified. We name this property the soundness of the solution. Moreover, using encryption to protect the solution makes this challenge more complicated. That is, how to evaluate the encrypted solution at the smart contracts in a noninteractive way. Lu et al. adopt an interactive solution evaluation procedure between the requester and the smart contract [8]. We want to avoid this kind of interaction.


### 5.1.4. Trustworthy of Workers

We think in a blockchain-based crowdsourcing platform, using the tamper-proof property of blockchain to enforce the trustworthy of workers and make the attributes of workers’ manipulation resistance is a key idea, especially in reputation-based incentive mechanism.


## 5.1.1. Data Privacy of Task

In a crowdsourcing system, the posed tasks may include highly sensitive data such as map data, location information, and sensitive images. Due to the publicity of blockchain, sensitive data cannot be stored directly in the blockchain. Otherwise, this would result in leakage of information and compromise the requester’s privacy. Although some related proposals did not provide privacy protection [6, 8], we treat the protection for sensitive data as our first concern.


## 5.1.2. Data Privacy of Solution

Sensitive tasks are most likely to collect sensitive solutions. The data privacy protection of solutions is also very important, which is also the design goal of our scheme. Using encryption can provide privacy protection and can also prevent a “free-riding” attack which refers to malicious workers who get solutions submitted by other workers and directly use them as their own submission. Our design goals also include resistance to this kind of attack.


## 5.1.3. Soundness of Solution

In our scheme, we want to build a fair and noninteractive platform for requesters and workers. Those workers who submit right and good solutions must get payment, but those who free-ride must get nothing. One of the big challenges is how to ensure that the submitted solutions are qualified. We name this property the soundness of the solution. Moreover, using encryption to protect the solution makes this challenge more complicated. That is, how to evaluate the encrypted solution at the smart contracts in a noninteractive way. Lu et al. adopt an interactive solution evaluation procedure between the requester and the smart contract [8]. We want to avoid this kind of interaction.


## 5.1.4. Trustworthy of Workers

We think in a blockchain-based crowdsourcing platform, using the tamper-proof property of blockchain to enforce the trustworthy of workers and make the attributes of workers’ manipulation resistance is a key idea, especially in reputation-based incentive mechanism.


## 5.2. The Outsourcing Process

Now, we are ready to present a specific procedure for the crowdsourcing tasks. As the FEforIP and zk-SNARK require a setup phase, we consider that a setup algorithm generated the public parametersPP=PPFE,PPZK for this purpose and published it as common knowledge.We treat blockchain as an infrastructure in which many miners, for the sake of their interests, participate to confirm transactions and to execute smart contracts. Any type of user can initiate a transaction, that is, broadcast the transaction message signed by him to the blockchain and wait for the blockchain to confirm. We omit the process of miner selection by the consensus protocol after the requester publishes the task. In our scheme, when we say that the requester or worker sends a message to the blockchain, it means that the message is sent to a smart contract associated with an address.In ourPrivCrowd, the outsourcing process consists of five sequential procedures including User registering, Requester posting task, Attribute keys generation, Solutions submitting and evaluation, and Workers profile updating. Moreover, the first three procedures are used to implement the fine-grained workers’ selection protocol detailed described in Section 4.1, and the last two procedures are used to implement the noninteractive solution submission and evaluation protocol described in Section 4.2. As shown in Figure 3, these procedures work as follows.(1)
User Registering. In this procedure, any type of users, i.e., requesters and workers, generate the key pair pk,sk and register at CA who act as the registration authority (RA) to get a certificate Cert binding pk. For a requester R, we denote by pkR,skR his key pair and CertR his certificate. Similarly, we denote by pkW,skW a key pair of a worker W and CertW his certificate. We need to emphasize that PrivCrowd just likes the other applications atop on a public blockchain, e.g., Bitcoin, allows participants to generate a fresh address for a task as a simple solution to avoid deanonymization in the underlying blockchain. We omit the detailed address generating process(2)
Requester Posting Task. Once a requester R has an outsourcing task, R encrypts the task’s data by running FE.Enc(MPK,R′⟶,KT) to get a ciphertext CTτ, where MPK is the master public key included in PPFE, R′⟶ is requirements vector, τ is a unique session identifier of the task, and KT is a secret key used by a symmetric encryption algorithm to encrypt task’s data stored at the storage in ciphertext. Then, R sends a signed tuple (To simplify the presentation, we assume implicitly that signed messages can be extracted from their signatures.) SigskRτCTτDesτTτTotRewRPS to the smart contract PostTask, where Tτ is a deadline to collect solutions, TotRew is total reword for this task τ, RPS is the reword per solution, and Desτ is a description of the requirements for the workers who are willing to participate in the task, so that interested workers can judge whether they are qualified. Furthermore, this description Desτ also determines the combination order of different type requirements vectors and attributes vectors as well. We will argue that this combination order does not compromise the security of our workers’ selection protocol described in Section 4.1. On the other hand, R also sends a solution evaluation function SolEval· to the smart contract PostTask to be a criterion for evaluating the solutions. It is worth noting that interested workers can get the task’s information (ciphertext stored on the storage or just encrypted metadata) from the smart contract PostTask right now; either they can do it after they get the predicate key in the next phase. This order has a no different effect on the scheme(3)
Attribute Keys Generation. If an interested worker W wants to participate in the task τ, he will request CA for a decryption key by submitting his certificate CertW. Upon receiving the CertW, the CA, who acts as the KGC right now, will first identify W by verifying the certificate CertW, and then consult the blockchain for profile of W which is publicly recorded and maintained on the blockchain. The profile of W will then be encoded in an attributes vector W′⟶ whose formula is constrained by the description Desτ posted by the requester R. Finally, the CA runs FE.KeyGenMSK,PW′⟶PolyR′⟶ to generate the predicate keys SKP accordingly for the worker W, where MSK is the master secret key for FEforIP scheme, PW′⟶PolyR′⟶ is the predicate exactly detailed in Section 4.2. The CA sends the predicate key SKP to W. We remark that whether W has the ability to decrypt the task data completely depends on the attributes maintained by the public blockchain. If his profile meets the requirement of W, that is, W′⟶,R′⟶=0 technically, W can get the key Kτ then decrypt the task data. Otherwise, the security of the FEforIP ensures that W cannot get any information about the encrypted task’s data. R selects qualified workers in this noninteractive and oblivious manner. Moreover, the worker’s profile, maintained by blockchain, is tamper-proof, which against the malicious manipulation to the profile of workers which is potential in a centralized crowdsourcing platform(4)
Solutions Submitting and Evaluation. At this phase, before the deadline, once a worker Wi finishes the job, he can submit a solution si encrypted under R’s public key pkW and a zk-SNARK proof Πi to the smart contract CollectSol (If the solution data is big, it will be stored at the storage in ciphertext just like treatment to the task’s data. In this case, the worker’s submission si is an encrypted symmetric key, say KS, which will be further forwarded to the requester.). He also needs to make a deposit to the smart contract in order to initiate this evaluation. We remark that the worker also sends a signature σsi for this submission, and we denote encrypted solution by si. CollectSol then collects and evaluates this solution si. According to the noninteractive solution submission and evaluation protocol, CollectSol first verifies the Wi’s identity and then verifies the zk-snark proof Πi. If any of these verifications fail, the solution collection process for this worker is terminated. Otherwise, it forwards the encrypted solution si to R, pays the worker Wi reward (the reward comes from R’s deposit), and notifies the smart contract UpdateProf to update Wi’s public profile(5)
Workers Profile Updating. Upon receiving the notification from the smart contract CollectSol, the UpdateProf contract will update the profile of this worker Wi’ by creating a transaction. Our priority in this paper is to protect the data privacy of tasks and solution as well. We do not discuss here which attributes of workers need to and how to update. Because these issues involve reputation evaluation and incentive mechanisms in crowdsourcing platforms, which is orthogonal to the focus of this paper. We refer interested readers to read the relevant literatureFigure 3
The outsourcing process in thePrivCrowd.After a lift cycle of outsourcing process, if the protocols are not terminated, a requester gets his solutions and a worker gets his reward accordingly.


## 5.3. Smart Contracts

In this section, we will show in ourPrivCrowd the details of the three smart contracts, i.e., PostTask, CollectSol, and UpdateProf. These smart contracts can be seen as a logical party who is interactive with the requesters, workers, and the CA. In Table 1, we show some notations for the smart contracts.(i)
PostTask. This contract gets the posted task information from requesters. For each pair of requester and task, it takes requester’s public key pkRi and requester’s certificate CertRi as input and verifies the certificate of the requester first, then verifies the signature of the task’s message and checks if the request transfers sufficient deposit to the contract’s address by invoking function getBalance (For the public blockchain infrastructure, checking an account address’s balance is an essential function. We do not care how to implement it in specific, we refer interested readers to related literature.). If all these verification results are negative, this contract terminates immediately and task’s posting fails. Otherwise, before the deadline Tτ, it broadcasts a new task recruiting workers and transfers the deposit to the smart contract CollectSol. The algorithm 1 illustrates the implementation of this contract(ii)
CollectSol. This contract takes as input worker’s public key pkWi, workers’ certificate CertWi, and task posting message including task identifier τ, solution evaluation function SolEval·, deadline of submission Tτ, total reword TotRew, and reward per solution RPS. Whenever gets the transfer from the contract PostTask, it begins to accept worker’s submission. On receiving a signed submission from Wi, parses the submission as (σsisiΠi). Then, verifies the certificate of Wi and the signature of the task’s message in turn. If all these verification results are negative, it terminates this submission. Otherwise, it invokes the SNARK.verify Πi to verify that this submission si pass the evaluation, i.e., SolEvalsi=1. If yes, it forwards the encrypted solution to the requester, pays the reward to Wi, and notifies the contract UpdateProf to update the worker’s public profile. In case of the time is up, solutions collection needs to be terminated, and it refunds the money left to the requester. Once the balance of &CollectSol less than RPS, this contract terminates. Otherwise, Wi gets nothing. The algorithm 2 illustrates the implementation of this contract(iii)
UpdateProf. This contract takes as input worker’s public key pkWi, task identifier τ, and description of the task Desτ. Upon receiving a notification from the contract UpdateProf, it consults the description of the task Desτ for the updating policy. As the algorithm 3 shown, we do not instantiate the updateProfile, but present it as an API for one reason, that is, our scheme is not limited to the incentive mechanism of specific crowdsourcing platforms, but to a general-purpose design. Therefore, whether it is reputation-based or other types of incentive mechanisms can be compatible with our scheme. e.g., for the reputation-based incentive mechanism [30], it may be just update the reputation of the worker Wi onlyTable 1
Notations for the smart contracts.
&RiBlockchain address of the requesterRi.&WiBlockchain address of the workerWi.&PostTaskContract address ofPostTask.&CollectSolContract address ofCollectSol.&UpdateProfContract address ofUpdateProf.getBalance·Read balance of blockchain address.transfersrc,dst,vTransferv from address src to dst.broadcast·Broadcast message to blockchain.updateProfile·Function to update workers’ profile.Algorithm 1: The smart contract: PostTask.
Input: This contract’s address &PostTask; requester’s public key pkRi; requester’s certificate CertRi; task identifier τ; description of the task Desτ; deadline of submission Tτ; total reword TotRew; reward per solution RPS; encrypted task’s data(metadata) CTτ; signature of posting task στ.1:for each Ri and τdo2:ifAuthCertRi,pkRi==⊥3:goto final; ⊳ Certificate invalid or requester unregister4:end if5:Verifyστ==⊥then6:goto final; ⊳ Posting task's signature invalid7:end if8:if getBalance(&PostTask) <TotRewthen9:goto final; ⊳ Deposit Insufficient10:end if11:whileTτ is not expired do12:  broadcast(τ, Desτ, RPS, CTτ, SolEval·) as a new task identified by τ;13:  transfer(&PostTask,&CollectSol,TotRew);14:end while15:end for16:final;17:return;Algorithm 2: The smart contract: CollectSol.
Input: This contract’s address &CollectSol; worker’s public key pkWi; workers’s certificate CertWi; workers’s deposit DepWi; task identifier τ; solution evaluation function SolEval·; deadline of submission Tτ; total reword TotRew; reward per solution RPS.1:while (getBalance(&CollectSol) >RPS) and Tτ is not expired do2: Upon receiving a signed submission fromWi, parses the submission as (σsisiΠi);3:ifAuthCertWi,pkWi==⊥then4:continue; ⊳ Certificate invalid or worker unregister5:end if6:ifVerifyσsi==⊥then7:continue; ⊳ Submission's signature invalid8:end if9:ifDepWi is not sufficient then10:continue; ⊳ Worker's deposit is not sufficient11:end if12:if SNARK.VerifyΠi==accthen13:  Sendsi to the request Ri; ⊳ Forward the solution to the requester14:  transfer(&PostTask,&Wi,PRS+DepWi); ⊳ Pay the reward and refund the deposit15:UpdateProf(pkWi,τ);Invoke the smart contract UpdateProf16:end if17:end while18:if getBalance(&CollectSol) >0then⊳ Refund residue money to the request19: transfer(&CollectSol,&Ri,20:getBalance&CollectSol);21:end if22:return;Algorithm 3: The smart contract: UpdateProf.
Input: This contract’s address &UpdateProf; worker’s public key pkWi; task identifier τ; description of the task Desτ.1: Upon receiving a notification from the contractUpdateProf, consult the description of the task Desτ for the updating policy;2: updateProfile(pkWi, ·);3:return;


## 6. Security Analysis

In this section, we explain how the proposed scheme can satisfy the aforementioned security and privacy requirements.


### 6.1. Privacy Preserved and Fine-Grained Worker Selection

In our scheme, a requester posts a task using the posing protocol which integrates a specially designed functional encryption scheme, i.e., the FEforIP. We do not present the tedious security proof but refer the reader to [25]. The FEforIP is a functional encryption scheme that supports inner product evaluations on encrypted data which adaptive security has to be proven under general subgroup decision assumptions. The task’s data is encrypted by the FEforIP then uploaded to blockchain. With the security of the FEforIP, workers whose attributes vector do not suffice for the task’s requirements can get nothing about the task’s data, which means the inadequate workers cannot decrypt and participate in. Powerful computing ability on encrypted data of the FEforIP makes a requester select workers in a fine-grained and noninteractive way with perfect data privacy protection.


### 6.2. Solution’s Privacy Protection and Soundness

In the submission protocol, a worker submits a solution encrypted by a public key encryption scheme which is not a specific scheme for the sake of generality of thePrivCrowd. With the security of underlying PKE scheme, the data privacy of the solution should be perfectly protected. We note that if the worker adds the identification information with the solution and encrypts, the malicious workers cannot launch a free-riding attack. Because this design is trivial for our scheme, we do not present details in the proposed protocol. On the other hand, a submitted solution needs to attach a zk-SNARK proof for the further solution evaluation. With the soundness assumption of underlying zk-SNARK, the probability of a not qualified solution is accepted by the verifier, that is the smart contract ColletSol, is negligible. So our submission protocol is sound and noninteractive.


### 6.3. Trustworthy of Workers

Trustworthy of workers is also easy to be implemented, because the smart contractUpdateProf cannot be created by workers themselves and can only be invoked by the smart contract CollectSol, which means the modification of worker’s attributes must be done by the smart contract, and also means only the worker who submits a good solution is qualified to get his attributes updated. Therefore, for reputation-based incentive mechanism, the reputation and the reliability of workers are unforgeable.


### 6.4. Pseudonymity

In our scheme, we use pseudonym to provide identity privacy protection for participants. Considering we protect not only the task’s data but also the solution privacy, as we argued before, we think the pseudonymity is enough. In our framework, similar to the CrowdBC [6], we also utilize the pseudonymous Bitcoin-like addresses to identify requesters and workers, which enables privacy-preserving without submitting true identity to finish a crowdsourcing task.In our design, in addition to the above security properties, thePrivCrowd also fulfills several security properties and we discuss them here.(i)
Security against False-Reporting. In PrivCrowd, solutions are evaluated automatically by predefined function SolEval(·) within the smart contract. Malicious requesters launching false-reporting attacks by creating a forked chain to tamper with the results of the smart contract are infeasible under the assumption that the majority of miners are honest(ii)
Security against Free-riding Attacks. Workers cannot get original solutions submitted by other workers due to encryption. So malicious workers cannot launch free-riding attacks(iii)
DDoS and Sybil Attack Resistant. PrivCrowd requires deposits from requesters and workers to thwart DDoS and Sybil attacks. Therefore, malicious attackers may pay a huge cost to launch these attacks under the deposit-based mechanism. Workers are required to make deposits in the smart contract CollectSol before submission. They are automatically assigned rewards according to the results of the evaluation function. Thus, if they contribute low-quality solutions, they will not only get rewards but also lose deposits(iv)
No Single Point of Failure. Similar to [6], in PrivCrowd, no single point of failure is obvious with the blockchain-based decentralized architecture under the majority honest security assumption. According to the peer-to-peer architecture, even though there remains only one miner, requesters and workers can access the crowdsourcing service normally


## 6.1. Privacy Preserved and Fine-Grained Worker Selection

In our scheme, a requester posts a task using the posing protocol which integrates a specially designed functional encryption scheme, i.e., the FEforIP. We do not present the tedious security proof but refer the reader to [25]. The FEforIP is a functional encryption scheme that supports inner product evaluations on encrypted data which adaptive security has to be proven under general subgroup decision assumptions. The task’s data is encrypted by the FEforIP then uploaded to blockchain. With the security of the FEforIP, workers whose attributes vector do not suffice for the task’s requirements can get nothing about the task’s data, which means the inadequate workers cannot decrypt and participate in. Powerful computing ability on encrypted data of the FEforIP makes a requester select workers in a fine-grained and noninteractive way with perfect data privacy protection.


## 6.2. Solution’s Privacy Protection and Soundness

In the submission protocol, a worker submits a solution encrypted by a public key encryption scheme which is not a specific scheme for the sake of generality of thePrivCrowd. With the security of underlying PKE scheme, the data privacy of the solution should be perfectly protected. We note that if the worker adds the identification information with the solution and encrypts, the malicious workers cannot launch a free-riding attack. Because this design is trivial for our scheme, we do not present details in the proposed protocol. On the other hand, a submitted solution needs to attach a zk-SNARK proof for the further solution evaluation. With the soundness assumption of underlying zk-SNARK, the probability of a not qualified solution is accepted by the verifier, that is the smart contract ColletSol, is negligible. So our submission protocol is sound and noninteractive.


## 6.3. Trustworthy of Workers

Trustworthy of workers is also easy to be implemented, because the smart contractUpdateProf cannot be created by workers themselves and can only be invoked by the smart contract CollectSol, which means the modification of worker’s attributes must be done by the smart contract, and also means only the worker who submits a good solution is qualified to get his attributes updated. Therefore, for reputation-based incentive mechanism, the reputation and the reliability of workers are unforgeable.


## 6.4. Pseudonymity

In our scheme, we use pseudonym to provide identity privacy protection for participants. Considering we protect not only the task’s data but also the solution privacy, as we argued before, we think the pseudonymity is enough. In our framework, similar to the CrowdBC [6], we also utilize the pseudonymous Bitcoin-like addresses to identify requesters and workers, which enables privacy-preserving without submitting true identity to finish a crowdsourcing task.In our design, in addition to the above security properties, thePrivCrowd also fulfills several security properties and we discuss them here.(i)
Security against False-Reporting. In PrivCrowd, solutions are evaluated automatically by predefined function SolEval(·) within the smart contract. Malicious requesters launching false-reporting attacks by creating a forked chain to tamper with the results of the smart contract are infeasible under the assumption that the majority of miners are honest(ii)
Security against Free-riding Attacks. Workers cannot get original solutions submitted by other workers due to encryption. So malicious workers cannot launch free-riding attacks(iii)
DDoS and Sybil Attack Resistant. PrivCrowd requires deposits from requesters and workers to thwart DDoS and Sybil attacks. Therefore, malicious attackers may pay a huge cost to launch these attacks under the deposit-based mechanism. Workers are required to make deposits in the smart contract CollectSol before submission. They are automatically assigned rewards according to the results of the evaluation function. Thus, if they contribute low-quality solutions, they will not only get rewards but also lose deposits(iv)
No Single Point of Failure. Similar to [6], in PrivCrowd, no single point of failure is obvious with the blockchain-based decentralized architecture under the majority honest security assumption. According to the peer-to-peer architecture, even though there remains only one miner, requesters and workers can access the crowdsourcing service normally


## 7. Efficiency Analysis

In thePrivCrowd, we present the two core protocols which are the posting protocol and the submission protocol. In the posting protocol, the requester, the worker, the CA, and the smart contract interact in a loose way, which means they are not necessary to keep online for posting or receiving an outsourcing task. Therefore, the communication costs of the posting protocol are not our concern. We focus on the computation costs incurred by the core component, that is, the FEforIP. Similarly, in the submission protocol, we focus on the core component, i.e., the zk-SNARK. Table 2 illustrates the executors and locations of the algorithms of the two cryptographic components. For the FEforIP and zk-SNARK, the Setup algorithm will be run once and off-chain. The CA runs the Keygen algorithm of the FEforIP for the worker to generate keys. The requester runs the Encrypt algorithm off-chain when he wants to post a task. The interested workers run the decrypt algorithm off-chain when they get the encrypted task’s data. For the zk-SNARK, the worker who wants to submit a solution runs the SNARK.Prove off-chain to generate the proof, and the SNARK.Verify needs to be done on-chain, i.e., the smart contract.Table 2
Computation executors and locations.
CARequesterWorkerBlockchainFEforIPSetup×××Off-chainKeygen√××Off-chainEncrypt×√×Off-chainDecrypt××Off-chainzk-SNARKSetup×××Off-chainProve××√Off-chainVerify×××On-chain


### 7.1. The Efficiency of the Posting Protocol

Here, we analyze the efficiency of the posing protocol. As mentioned above, the communication overhead is not the issue because the participants act in a noninteractive and loose way. We mainly analyze the computational overhead. In the protocol, the requester runs the algorithm FE.Enc to encrypt the task’s data then uploads the smart contractPostTask as a posing task. Interested workers request a functional key to the CA who acts as a KGC right now by running the algorithm FE.KeyGen for the further decrypt the data to receive the task, and when getting a functional key, they run the FE.Dec to decrypt. Table 3 shows that the time cost in seconds of algorithms in the FEforIP, where d is the length of attributes vectors. We get these evaluation results by implementing the algorithms using pairing-based cryptography library pbc-0.5.14 [31] on a PC with 3.3GHz Intel, i5-6600 CPU, and 8 GB memory. As shown in Table 3, when d≤10, the time cost of the FE.Enc is roughly around 0.5 s and the FE.KeyGen and FE.Dec less than 0.75 s. In the setting of d=10, our protocol works for most workers selection scenarios, which means the requester can use 10-dimension attributes to pick the workers in a fine-grained way and in an efficient way. The illustration results for d from 1 to 10 are shown in Figure 4(a). We also present the illustration results for the case of d=10to100 in Figure 4(b) and d=100to1000 in Figure 4(c), although there are rare cases for the requester to select worker using so many attributes like 1000.Table 3
Time costs (in seconds) of algorithms of the FEforIP.
dFE.SetupFE.EncFE.KeyGenFE.Dec10.4350.1380.1610.18720.4960.1910.2460.26130.5340.2350.350.33640.5890.2880.4420.39650.6640.3390.4370.46760.7430.3940.5370.52970.7360.4460.6350.61680.770.4770.6750.62190.8840.4930.7360.745100.9220.5510.870.8271005.3124.8977.3677.28350024.65824.35840.89139.912100048.6447.79772.21169.047Figure 4
The time cost (in seconds) for running the algorithms of the FEforIP for the posting protocol in thePrivCrowd.
(a)(b)(c)


### 7.2. The Efficiency of the Submission Protocol

For the submission protocol, we are not going further to instantiate the functionSolEval· in our PrivCrowd as mentioned in 4.2.24.2.2. Therefore, we cannot evaluate a concrete zk-SNARK implementation. But as an example, we evaluate a range proof which is a very useful proof for several scenarios, such as to prove an integer solution exactly in a range and to prove a position coordinates exactly in a specific area. To do this, we exploit a well-known zk-SNARK library libSnark [29] to implement a range proof. On a PC with 3.3 GHz Intel, i5-6600 CPU, and 8 GB memory, for a range proof which is a proof of an integer in 30,60, we find that it costs 0.047139 s to run SNARK.Setup, 0.013065 s to run SNARK.Prove and 0.00813 s to run SNARK.Verify. These results have shown our submission protocol should be practical.


### 7.3. The Cost of the Smart Contracts

For the smart contracts, we have discussed that in thePrivCrowd, we do not instantiate the function updateProfile in the smart contact UpdateProf. Leave that as an interface to make the PrivCrowd be compatible with various incentive mechanisms. Therefore, we just evaluate the other two smart contracts here. We use Remix IDE (Remix IDE allows developing, deploying, and administering smart contracts for Ethereum-like blockchains. http://remix.ethereum.org) and Rinkeby (Rinkeby is an open test network for smart contracts. https://rinkeby.etherscan.io) as a testing environment for the smart contracts. As shown in Table 4, the gas usage for deploy a PostTask transaction is 7.08248. Currently, at the exchange rate on April 21, 2021, each deployment of PostTask costs about 14.16496 ETH (or 1.6821 USD). Each call of PostTask costs about 5.16214 ETH (or 0.6130 USD). Each deployment of CollectSol costs about 25.04604 ETH (or 2.9742 USD). Each call of CollectSol costs about 2.87166 ETH (or 0.3410 USD). Considering these two smart contracts are one deployment multiple calls, our scheme is fairly efficient.Table 4
Costs of the smart contracts with exchange rate:1Gas=2×10−9ETH, 1ETH=2.375×10−6 USD (date: 4/21/2021).
OperationGas (×105)ETH (×10−4)USDPostTask deployment7.0824814.164961.6821PostTask call2.581075.162140.6130CollectSol deployment12.5230225.046042.9742CollectSol call1.435832.871660.3410


## 7.1. The Efficiency of the Posting Protocol

Here, we analyze the efficiency of the posing protocol. As mentioned above, the communication overhead is not the issue because the participants act in a noninteractive and loose way. We mainly analyze the computational overhead. In the protocol, the requester runs the algorithm FE.Enc to encrypt the task’s data then uploads the smart contractPostTask as a posing task. Interested workers request a functional key to the CA who acts as a KGC right now by running the algorithm FE.KeyGen for the further decrypt the data to receive the task, and when getting a functional key, they run the FE.Dec to decrypt. Table 3 shows that the time cost in seconds of algorithms in the FEforIP, where d is the length of attributes vectors. We get these evaluation results by implementing the algorithms using pairing-based cryptography library pbc-0.5.14 [31] on a PC with 3.3GHz Intel, i5-6600 CPU, and 8 GB memory. As shown in Table 3, when d≤10, the time cost of the FE.Enc is roughly around 0.5 s and the FE.KeyGen and FE.Dec less than 0.75 s. In the setting of d=10, our protocol works for most workers selection scenarios, which means the requester can use 10-dimension attributes to pick the workers in a fine-grained way and in an efficient way. The illustration results for d from 1 to 10 are shown in Figure 4(a). We also present the illustration results for the case of d=10to100 in Figure 4(b) and d=100to1000 in Figure 4(c), although there are rare cases for the requester to select worker using so many attributes like 1000.Table 3
Time costs (in seconds) of algorithms of the FEforIP.
dFE.SetupFE.EncFE.KeyGenFE.Dec10.4350.1380.1610.18720.4960.1910.2460.26130.5340.2350.350.33640.5890.2880.4420.39650.6640.3390.4370.46760.7430.3940.5370.52970.7360.4460.6350.61680.770.4770.6750.62190.8840.4930.7360.745100.9220.5510.870.8271005.3124.8977.3677.28350024.65824.35840.89139.912100048.6447.79772.21169.047Figure 4
The time cost (in seconds) for running the algorithms of the FEforIP for the posting protocol in thePrivCrowd.
(a)(b)(c)


## 7.2. The Efficiency of the Submission Protocol

For the submission protocol, we are not going further to instantiate the functionSolEval· in our PrivCrowd as mentioned in 4.2.24.2.2. Therefore, we cannot evaluate a concrete zk-SNARK implementation. But as an example, we evaluate a range proof which is a very useful proof for several scenarios, such as to prove an integer solution exactly in a range and to prove a position coordinates exactly in a specific area. To do this, we exploit a well-known zk-SNARK library libSnark [29] to implement a range proof. On a PC with 3.3 GHz Intel, i5-6600 CPU, and 8 GB memory, for a range proof which is a proof of an integer in 30,60, we find that it costs 0.047139 s to run SNARK.Setup, 0.013065 s to run SNARK.Prove and 0.00813 s to run SNARK.Verify. These results have shown our submission protocol should be practical.


## 7.3. The Cost of the Smart Contracts

For the smart contracts, we have discussed that in thePrivCrowd, we do not instantiate the function updateProfile in the smart contact UpdateProf. Leave that as an interface to make the PrivCrowd be compatible with various incentive mechanisms. Therefore, we just evaluate the other two smart contracts here. We use Remix IDE (Remix IDE allows developing, deploying, and administering smart contracts for Ethereum-like blockchains. http://remix.ethereum.org) and Rinkeby (Rinkeby is an open test network for smart contracts. https://rinkeby.etherscan.io) as a testing environment for the smart contracts. As shown in Table 4, the gas usage for deploy a PostTask transaction is 7.08248. Currently, at the exchange rate on April 21, 2021, each deployment of PostTask costs about 14.16496 ETH (or 1.6821 USD). Each call of PostTask costs about 5.16214 ETH (or 0.6130 USD). Each deployment of CollectSol costs about 25.04604 ETH (or 2.9742 USD). Each call of CollectSol costs about 2.87166 ETH (or 0.3410 USD). Considering these two smart contracts are one deployment multiple calls, our scheme is fairly efficient.Table 4
Costs of the smart contracts with exchange rate:1Gas=2×10−9ETH, 1ETH=2.375×10−6 USD (date: 4/21/2021).
OperationGas (×105)ETH (×10−4)USDPostTask deployment7.0824814.164961.6821PostTask call2.581075.162140.6130CollectSol deployment12.5230225.046042.9742CollectSol call1.435832.871660.3410


## 8. Conclusion

In this paper, we propose a secure blockchain-based crowdsourcing framework,PirvCrowd, where requesters and workers’ data privacy has been protected by using a carved functional encryption scheme which makes the requester can select workers in a fine-grained and noninteractive way. In PirvCrowd, solutions collection also can be done in a secure, noninteractive, and sound way. Finally, intensive experiments are performed to validate the effectiveness of PirvCrowd via showing the efficiency of the building blocks and costs of the smart contracts. We believe our proposed framework, PirvCrowd, has achieved our design goals.



---

*Source: 3758782-2021-08-01.xml*