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

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, named PrivCrowd 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.


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 problemsolving 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][7][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-prefixlinkable 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 blockchainbased 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 anonymity Next, 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].

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-yetaccountable 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 Section 2, 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.

Overview of our Proposed Framework
2.1. System Model. We propose a novel secure and privacypreserved blockchain-based crowdsourcing framework with fine-grained worker selection, called PrivCrowd. In Priv-Crowd, 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.
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][20][21][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 Post-Task 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 contracts PostTask, CollectSol, and UpdateProf. Post-Task 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 2 Wireless Communications and Mobile Computing 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.

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.

Intuition.
In this section, we will overview the key ideas for designing the PrivCrowd. 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]. Zeb-raLancer is one of the priori works that tempts to present some privacy-preserved schemes. They proposed a common-prefixlinkable 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 tamperproof 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

Wireless Communications and Mobile Computing
(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 anonymity Therefore, with these designs, our overall goal of the Priv-Crowd 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.

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 named Priv-Crowd 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 the PrivCrowd 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

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 For a group element g, we use g U ! to denote a vector ðg u 1 , g u 2 , ⋯, g u d Þ. [25]. For an inner product predicate P, a functional encryption scheme for P is defined as follows:

Wang's Scheme
(i) FE.Setup ð1 λ Þ. This algorithm takes the security parameter λ as input. First, it runs Gð1 n Þ and gets ðp , q, r, Then, it computes g p , g q , g r as generators of G p , G q , G r , respectively. In addition, it chooses random Finally, it outputs public parameters PP ≔ ðG, g p , g r Þ along with the public key: It keeps MSK ≔ ðg α p , x, X ! Þ private as the master secret key.
Finally, it outputs a predicate key: (iv) FE.Dec ðSK P , CÞ. This algorithm takes a token SK K ! for a predicate P FE K ! and ciphertext C as inputs, it outputs: where 3.3.3. Correctness of the FEforIP. Let C and SK P be as above. Then, where ðxA + X, For all ðA, KÞ ∈ A × K such that P FE K ! ðA ! Þ = 1 which means hK, Ai = 0 mod N, 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 Σ * = Σ ∪ f * g. A symbol " * " means a wildcard or "do not care" value.
In other words, the vector x 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: Then, the secret key can be obtained by running FE.KeyGen for predicate P HVE

MÞÞ
We can easily find that for ðσ 1 and A ! be as above. It is clear that Then, correctness and security of this HVE system hold.

Zero-Knowledge Proof System and Zk-SNARK.
For a NPcomplete language L = fx|∃w, s:t:,Cðx, wÞ = 1g, a zeroknowledge 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 zeroknowledge proof system include (i) Completeness. For every proof π produced by legal instance-witness pair ðx, wÞ, P ½V ðπ, 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 : F n × F h ⟶ F ℓ is captured by the relation R C = fðx, wÞ ∈ F n × F h : Cðx, wÞ = 0 ℓ g, its language is L C = fx ∈ F n : ∃w ∈ F h s:t:Cð x, wÞ = 0 ℓ g. 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.Setup ð1 λ , 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 pub-lic parameters and can be used, any number of times, to prove/verify membership in L C (ii) SNARK.Prove ðpk, x, wÞ ⟶ π. It takes as input a proving key pk and a tuple ðx, wÞ ∈ R C , and outputs a noninteractive proof π for the statement x ∈ L C (iii) SNARK.Verify ðvk, x, πÞ ⟶ ð0, 1Þ. It takes as input a verification key vk, a statement x, and a proof π, For 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.

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 fL1, L2, L5g and expertise = Writing . We formalize this example using vectors representing the attributes required by the requester and profiles of workers. Let R = ðr 1 , r ! 2 , r 3 Þ denote the requiring attributes; in this case, r 1 is the reputation value, r ! 2 the location set, and r 3 the expertise. Let W = ðw 1 , w 2 , w 3 Þ denote the profiles that a worker has, that is, w 1 is his/her exact reputation value, w 2 current location, and w 3 his/her expertise. Formally, workers can participate in this job who satisfy the following predicate: 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.
where R where R Then, build a vector σðR ! Þ = ðσ i,j Þ ∈ Σ ′ d as follows:  To argue correctness and security, observe that P Com 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.
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 Figure 2, our fine-grained workers' selection protocol works as follows: secret key K T which in turn enable them to decrypt the task's data Therefore, our protocol provides a scheme for requesters to select workers in a noninteractive and fine-grained way.

Noninteractive Solution Submission and Evaluation
Protocol: Submission Protocol 4.2.1. Concrete Protocol. According to our designing goal, the proposed scheme PrivCrowd 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) GenCert ðmsk, pk i Þ. This algorithm is run by the RA in the user registration phase. On input a worker's 8

Wireless Communications and Mobile Computing
public key pk i , it outputs a signature C i which is signed pk i by msk as worker's certificate (iii) Submit ðs i , sk i , pk i , C i , ParamsÞ. This algorithm is run by the worker who wants to submit a solution for task TID i . It invokes the Sig.Sign() algorithm to sign the task's ID TID i using sk i and receives signature Sig sk i ðTID i Þ. It also invokes the SNARK.Prove(s i , L TID i ) to generate a proof π i , where s i is solution data, and L TID i ≔ fx = ðTID i , ParamsÞ|∃w, s:t:SolEvalðs i Þ = 1g (iv) Evaluate ðΠÞ. Use π 1 to verify the worker's certificate, π 2 to verify whether pk i and sk i are consistent, and π 3 to verify whether solution s i is satisfied SolEvalð·Þ

Instantiate zk-SNARK for the Protocol.
For the submission protocol of our PrivCrowd, 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 s i of a worker, the zk-SNARK checks that SolEvalðs i Þ = 1 holds. We must emphasize that we are not going further to instantiate the function SolEvalð·Þ 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.

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  Figure 2: Overview of our fine-grained workers' selection scheme. 9 Wireless Communications and Mobile Computing workers and directly use them as their own submission. Our design goals also include resistance to this kind of attack.

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.

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.

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 parameters PP = ðPP FE , PP ZK Þ 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 our PrivCrowd, 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 finegrained 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 ðp k R , sk R Þ his key pair and Cert R his certificate. Similarly, we denote by ðpk W , sk W Þ a key pair of a worker W and Cert W 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′ ! , K T Þ) to get a ciphertext CT τ , where MPK is the master public key included in P P FE , R′ ! is requirements vector, τ is a unique session identifier of the task, and K T 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.) Sig sk R ðτkCT τ kDes τ kT τ kTotRewkRPSÞ 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 Post-Task 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 Cert W . Upon receiving the Cert W , the CA, who acts as the KGC right now, will first identify W by verifying the certificate Cert W , 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 ÞÞ to generate the predicate keys SK P accordingly for the worker W , where MSK is the master secret key for FEforIP scheme, Þ is the predicate exactly detailed in Section 4.2. The CA sends the predicate key SK P 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, hW ′ ! , R ′ ! i = 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 W i finishes the job, he can submit a solution s i encrypted under R ' s public key pk W 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 s i is an encrypted symmetric key, say K S , 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 σ s i for this submission, and we denote encrypted solution by ½s i . CollectSol then collects and evaluates this solution ½s i . Accord-ing to the noninteractive solution submission and evaluation protocol, CollectSol first verifies the W i ' 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 ½s i to R, pays the worker W i reward (the reward comes from R ' s deposit), and notifies the smart contract UpdateProf to update W i ' s public profile (5) Workers Profile Updating. Upon receiving the notification from the smart contract CollectSol, the Upda-teProf contract will update the profile of this worker W i ' 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 literature 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.

Smart Contracts.
In this section, we will show in our Priv-Crowd 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,  Figure 3: The outsourcing process in the PrivCrowd. UpdateProf. This contract takes as input worker's public key pk W i , 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 generalpurpose design. Therefore, whether it is reputationbased 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 W i only

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

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.

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 the PrivCrowd. 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.

Trustworthy of Workers.
Trustworthy of workers is also easy to be implemented, because the smart contract Update-Prof cannot be created by workers themselves and can only

12
Wireless Communications and Mobile Computing 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, the PrivCrowd also fulfills several security properties and we discuss them here. 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 Priv-Crowd, 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

Efficiency Analysis
In the PrivCrowd, 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 offchain. 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.
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 contract PostTask 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   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 = 10 to 100 in Figure 4(b) and d = 100 to 1000 in Figure 4(c), although there are rare cases for the requester to select worker using so many attributes like 1000.  7.2. The Efficiency of the Submission Protocol. For the submission protocol, we are not going further to instantiate the function SolEvalð·Þ 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.

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.

Data Availability
The data used to support the findings of this study are available from the corresponding author upon request.

Conflicts of Interest
The authors declare that there is no conflict of interest regarding the publication of this article.