A Blockchain Approach of Model Architecture for Crowdsourcing Design Services under the Context of Social Manufacturing

Abstract

Crowdsourcing design is generally monitored by the platform. However, the traditional crowdsourcing platforms face problems such as centralization, lack of credibility and vulnerability to single point of failure. Under the context of social manufacturing, how to address these potential issues has both research and substantial value. In this paper, we introduce decentralized blockchain technology for crowdsourcing service systems and propose a method to manage and control the process of crowdsourcing design services. We depict complex crowdsourcing logic by smart contract. The process of crowdsourcing design is not dependent on any third party. It is decentralized, tamper-proof, traceable and protects the privacy of users to a certain extent. We implement this crowdsourcing design system on a specific blockchain test network to experiment and test its functionalities. Experiment results show the feasibility and usability of our crowdsourcing design system. In the future, we will further improve the algorithmic logic of smart contracts so that they can run stably and securely in a complex node network environment.

1. Introduction

As crowdsourcing theory has matured, it has triggered a crowdsourcing design [1] model for product development. Crowdsourcing design is based on traditional centralized crowdsourcing platforms. However, under the context of social manufacturing, crowdsourcing design requires a decentralized platform and traditional crowdsourcing platforms can hardly meet this demand.

Social manufacturing is a networking manufacturing model based on distributed, self-organized collaboration and sharing of social resources [2]. Its decentralization is an important feature that distinguishes it from other manufacturing models [3]. The decentralized and traceable features of blockchain technology exactly fit the needs of crowdsourcing design service systems under the context of social manufacturing.

Blockchain technology originated from Nakamoto’s proposal of Bitcoin [4], which is a decentralized digital currency. Initially, this technology was mainly used in digital cryptocurrency systems. With blockchain platforms such as Ethereum [5] supporting smart contract [6] development and deployment, blockchain technology has shown more possibilities, such as supply-chain traceability, data sharing and crowdsourcing [7].

The idea of combining crowdsourcing platforms with blockchain is to deploy the crowdsourcing platform to the blockchain and replace the centralized platform of the traditional crowdsourcing system with the blockchain platform. The introduction of blockchain technology can bring the following advantages to crowdsourcing services [8]: solving the problem of having a single point of failure, a certain degree of privacy protection and eliminating subjective factors affecting the fairness of the decision.

At present, many scholars have applied the blockchain and crowdsourcing model to their own research fields. Ding et al. combined blockchain technology with crowdsourcing to design credit mechanisms and arbitration mechanisms to discipline the entire crowdsourcing process to ensure that users were serious about completing crowdsourcing operations [9]. In response to the problems of security and reliability in the field of agricultural products logistics, Wu et al. built a seven-level crowdsourcing platform architecture to realize a crowdsourcing-based agricultural product logistics platform based on blockchain technology [10]. In the context of crowdsourcing services, Yang et al. designed a trusted management framework for crowdsourcing intellectual property that contains four levels and three modules. Based on the blockchain on-chain and off-chain decomposition and fusion technology, it realized the credible management of crowdsourced testing intellectual property and solved the long-standing problems of irregular management and lack of credibility of crowdsourced testing services [11]. Ghaffaripour et al. proposed a zk-SNARK cryptographic primitive privacy-preserving method for crowdsourcing medical research to address the fair reciprocal exchange reward problem seen in medical relationships [12]. Gao et al. presented a blockchain crowdsourcing solution for spatial crowdsourcing tasks based on a specific rule, the Task-Select-Worker Mechanism, for sorting and assigning spatial crowdsourcing tasks [13]. Although most of the abovementioned studies have given corresponding blockchain-based application solutions or methods for their specific fields with better results, crowdsourcing design differs from the abovementioned fields in terms of business logic, task nature and worker characteristics. To accommodate these characteristics, and in conjunction with the social manufacturing environment, specialized research is needed on how to introduce blockchain technology into the crowdsourcing design model.

Therefore, in this paper, according to the characteristics of the crowdsourcing design model, we use blockchain technology, distributed memory, and the keccak256 algorithm to implement the workflow logic of crowdsourcing design services through smart contracts. A blockchain-based control method of crowdsourcing design service process in the context of social manufacturing is proposed to realize query, tracking and traceability of the crowdsourcing design service. Crowdsourcing design services are guaranteed to be decentralized, fairly and equitably executed. The main contributions of this paper are summarized as follows:

• We build a new crowdsourcing design model based on blockchain technology. Smart contracts on the blockchain are used to enable interaction between users and to ensure that the crowdsourcing design system fits into a community-based manufacturing context.
• Two types of smart contracts are designed to achieve information management and task control of crowdsourcing design users.
• We design a task state machine model in the smart contract to describe the task state of the crowdsourcing design service process, which is convenient for subsequent users to query the traceability of the crowdsourcing design tasks.
• Experiments were conducted to verify that the “blockchain and crowdsourcing” model proposed in this paper is applicable to the crowdsourcing design service process in the context of social manufacturing.

The sections of this paper are organized as follows. Section 2 presents the background knowledge of the study. Section 3 demonstrates the framework proposed in this paper. Section 4 specifies the smart contract protocols in this framework. In Section 5, we conduct an experimental analysis of the crowdsourcing design process simulation. Section 6 gives the conclusions.

2. Background

2.1. Crowdsourcing Workflow

Traditional crowdsourcing systems consist of three roles: requester, worker and a centralized crowdsourcing platform. As shown in Figure 1, the requester and the worker interact through a crowdsourcing platform. The requester uses the crowdsourcing platform to publish task requirements. The worker receives rewards for completing the tasks on the crowdsourcing platform.

Crowdsourcing platforms have a key role in the overall workflow; thus, the security of the platform is related to the whole crowdsourcing process. The traditional centralized crowdsourcing platform is vulnerable to the following problems: single point of failure problem, user-privacy-protection problem and platform-fairness problem. The above problems can discourage crowdsourcing workers and negatively affect the development of crowdsourcing platform services.

2.2. Blockchain

A blockchain consists of blocks linked to blocks, which is essentially a decentralized, tamper-evident, traceable and distributed database. It is maintained by each node according to the consensus mechanism; each node records the complete ledger information. Newly occurring transactions will only be allowed to be recorded on the blockchain if they have the consensus of a majority of nodes. Transactions will not be modified once they are confirmed on the chain [4]. As the data structure of the blockchain shown in Figure 2, the block header of each block contains the hash value of the previous block. If a user tampers with the transaction data of a block, it will affect all subsequent blocks and will not be able to reach consensus with the ledger maintained by other nodes, which is an important guarantee of blockchain security.

2.3. Smart Contract

In 1995, Szabo introduced the concept of smart contracts, a set of commitments defined in digital form [6]. Smart contracts have been further developed with the introduction of blockchain technology. An executable program facilitates consensus between two or more nodes in the blockchain network. Once the contract is validated and deployed on the blockchain, it cannot be tampered with. Subsequent on-chain operations that meet the trigger conditions will be executed automatically, completing the predefined transactions in the contract.

The operation mechanism of smart contracts is shown in Figure 3. In Ethereum, smart contracts encapsulate predefined variables, code execution logic and its trigger conditions, which are filled in as executable code in a transaction on the blockchain that is distributed to each network node through the P2P network. Contracts are subsequently triggered by external accounts by sending transactions. The corresponding functions in the contract are called and executed based on the relevant information of the transaction. The generated results and variable status are updated and written into the blockchain.

Smart contracts on the blockchain have the following advantages [8]:

• The contract code is recorded and verified by the blockchain with tamper-evident characteristics;
• Smart contracts are executed between distrustful nodes, without centralized control and without third-party coordination, ensuring fair execution of contract content;
• Traceability of information on the chain can be achieved through function calls of smart contracts.

The above advantages satisfy the control of the crowdsourcing service process and ensure the fairness and safety of the process.

3. Blockchain-Based Model Architecture of Crowdsourcing Design

3.1. Overview

Blockchain-based model architecture of crowdsourcing design services refers to the application of blockchain technology to the management and control of the process of crowdsourcing design services. Using a blockchain-based platform instead of a traditional centralized database to store transaction data, the whole process of crowdsourcing work is open, transparent, tamper-proof and traceable, the current status of the crowdsourcing design task can be viewed at any time. In this paper, combining the advantages of blockchain to build a decentralized crowdsourcing design service system, we include all crowdsourcing functions such as user registration, posting tasks and receiving tasks. Crowdsourcing task requesters and workers can interact with the blockchain and reach agreements about crowdsourcing design tasks on the chain.

Inspired by [14], the blockchain-based crowdsourcing design service framework is divided into three layers: the application layer, the blockchain layer and the storage layer. As shown in Figure 4, users complete the crowdsourcing process of registering, posting tasks, receiving tasks at the application layer and reaching task agreements at the blockchain layer with task-status changes. Due to the limited storage capacity of the blockchain, files with large memory can seriously affect the operational efficiency of the blockchain. This framework stores the metadata of the files (such as author, hash value, file pointer, etc.) to the blockchain, while the detailed source files are stored to the storage layer to improve the efficiency of the crowdsourcing service.

In order to improve the control of crowdsourcing design services, this paper constructs a task-state machine that describes all the states of a crowdsourcing design task. There exist six states: Pending, Claimed, Unclaimed, Evaluating, Completed, Uncompleted. The task state will shift according to the user’s input in the application layer or the smart contract’s determination of the current task state, as shown in Figure 5, which illustrates the process and reasons for the task-state change. Whenever a task publisher posts a new task in the application layer and it is recorded on the blockchain, the system will automatically generate a task-state machine that tracks the status of the task and can be used by all users to query the current status of the task at any time.

3.2. Structure

3.2.1. Application Layer

The application layer serves as a port for users to participate and complete crowdsourcing design tasks. Its operation is completely independent of any trusted third-party centralized servers, so that even the presence of some bad nodes will not affect the operation of the whole system.

In the application layer, there are two main modules: user management (UM) and task management (TM). Among them, the UM contains user registration and user information management functions. All users can only use subsequent crowdsourcing services after completing registration in the application layer. For each new user registration, the system will send the corresponding transaction information to the blockchain; after the registered transaction information is confirmed on the chain, the system will generate and store an abbreviated information structure of the user for the subsequent management of crowdsourcing services. Blockchain-based crowdsourcing design services can be seen as a program deployed on the blockchain to post, receive, submit and finally distribute rewards for design tasks.

3.2.2. Blockchain Layer

The blockchain layer is located in the middle layer of the framework; its main purpose is to receive valid input from users in the application layer, store the corresponding file metadata to the blockchain and store the larger attachments to the storage layer. All transaction operations of users in the application layer need to be completed on this layer and reach consensus. The process is roughly as follows: the transaction is sent to the blockchain layer; triggering the corresponding smart contract to reach an agreement; the program is compiled and finally confirmed by the miner to be recorded on the blockchain; the miner receives the corresponding incentive. Another purpose of the blockchain layer is to run the task-state machine, where valid user’s inputs at the application layer change the task state of the blockchain layer synchronously.

Generally, blocks in blockchain layer cannot hold large file data, which will consume a lot of local disk space and affect the operational efficiency of the blockchain. To reduce the amount of data stored in the blockchain, the source-file information is split into metadata and source data in this system framework. Source data refers to those attachments with large amounts of data that are kept in the storage layer—the distributed database under the blockchain. Following this, a unique file query string is generated. While metadata only retains basic information about the file, such as owner name, timestamp, file hash pointer, query string, etc., this information, with small amount of data, can be stored on the blockchain. Users can find the source file through the query pointer on the blockchain, they can also confirm whether the data stored in the storage layer has been tampered with using the file hash value.

3.2.3. Storage Layer

The storage layer, as the last layer of the framework, mainly uses distributed databases such as IPFS [15] to keep the original large files of tasks or solutions. The data uploaded by a user should be signed with his/her private key; other users can use his/her public key to verify the authenticity and integrity of the file at the blockchain layer. In particular, before workers submit their solutions to the storage layer, they need to be encrypted with the requester’s public key to prevent data leakage. After the requester finds the corresponding solution file through the data pointer, he/she should first decrypt it with his/her private key, then verify the digital signature with the worker’s public key to ensure the reliability and authenticity of the file. With this method, arbitrary crowdsourcing design services can be achieved, ensuring the security and confidentiality of the entire process.

3.3. Process of Crowdsourcing Design

Step 1: The user completes registration. The system records the valid information entered by the user as a transaction to the blockchain.

Step 2: Transaction information is confirmed by miners and permanently recorded on the blockchain

Step 3: The task requester posts tasks. The requester can set the task conditions; only workers who meet the requirements can receive this task. Moreover, the requester needs to pay a certain task deposit in advance as a deposit for this crowdsourcing design act.

Step 4: Workers receive crowdsourcing design tasks that meet their requirements. Similar to requesters, workers are required to pay a deposit for each task they receive to ensure the quality of their completed task.

Step 5: Worker completes the crowdsourcing design task and submits it before the task deadline. They first sign a digital signature using their private key, then encrypt it using the requester’s public key, then upload the encrypted file to the storage layer, a distributed database. Finally, they store the file’s hash and retrieval pointer to the blockchain.

Step 6: The requester should complete the task evaluation before the task evaluation deadline. The system will automatically issue rewards and reputation value to the worker according to the task evaluation level. Completing high-quality crowdsourcing design tasks will result in more rewards and increased reputation value.

4. Smart Contracts and Algorithm Protocols

4.1. Notations

Before detailing the smart contracts in the framework proposed in this paper, the notations used in smart contracts are shown and explained in

Table 1. The notations of explanation.

Natation	Explanation
${\beta }_W$	The reputation value of workers
addrUser, addrContract	The user’s address and the address of smart contract
$\theta$	The reward of the crowdsourcing design task
$\delta$	The deposit of posting and receiving task
$\lambda$	The number of workers required for the task
dl	The task deadline, which refers to the future block height
pointer	The hash pointer of the attachment of task or solution
coins(v)	The virtual coin of value v

. When the corresponding symbols are used subsequently, they are further explained.

4.2. Smart Contract

Two types of smart contracts are implemented to complete the above crowdsourcing design service process and realize the control of the service process. They are: user register and summary contracts (URSs) and relationship contracts (RCs). The general structure of the contract is shown in Figure 6.

After the user completes the registration, URS will record all the information of the user, such as the user’s address, name and resume information. The task information of the crowdsourcing design will be updated as the user completes the task in the system, such as the reputation value of the worker and the address of the task received. RC mainly records the interaction information between users, such as the details of the posted task and the completion status of the worker after receiving the task. The worker and the publisher reach a crowdsourcing design service agreement in RC.

The contract contains an important protocol: the reputation value update protocol updateReputation( ), which is used to manage the user’s reputation. It automatically increases or decreases the reputation value of the corresponding worker based on the publisher’s evaluation of the task.

While most traditional crowdsourcing systems focus on finding deception or other malicious behaviors after workers complete their tasks, this crowdsourcing design system curb malicious behaviors of workers in advance and improve the quality of crowdsourcing design task completion by setting requirements such as the required minimum reputation value of task workers when requesters post their tasks.

4.2.1. User Register and Summary Contract (URS)

URS contract is mainly used for user registration and managing user information. Users can complete registration without using their real identity information, providing them with a certain level of privacy protection. The main structure of the contract is shown in Figure 7, where a total set of users, UserPool, and a series of data structures recording the user’s details are provided. Each user’s data structure records Username, Address, profile, RegisterTime, Reputation, the number of ongoing crowdsourcing design tasks (ProcessTaskNum), the number of finished crowdsourcing design tasks (FinishTaskNum) and a list of addresses of completed tasks (RC Address). The reputation is an important parameter; the system will issue the default reputation value after the user completes the registration, which will be updated automatically with the user’s work performance in the future. The incentive mechanism of reputation value is based on the literature [16], where the level of reputation value directly can reflect the user’s level of crowdsourcing design. ProcessTaskNum reflects the user’s current level of busyness. FinishTaskNum combined with Reputation reflect the user’s ability to work. RC Address reflects the main areas of work of the user. None of the above data can be easily altered by third parties and can only be updated automatically after a crowdsourcing design task. Therefore, using the above parameters as criteria for receiving tasks ensures that the worker has sufficient time and capacity to complete the task.

In particular, the contract is set up in such a way that the same Username cannot be registered repeatedly, making each username unique. Setting the user’s name as a mapping of the user’s detailed data structure ensures accurate invocation of the user’s information in subsequent smart contracts for crowdsourcing design services. With each new user registration, the system detects the Username in UserPool and automatically updates the mapping of the user data structure.

4.2.2. Relationship Contract (RC)

RC contract records the interaction protocols between publishers and workers, covering the entire process of posting, picking up, submitting and acquiring solutions, evaluating and issuing rewards for tasks. The RC contract architecture is shown in Figure 8. The contract architecture contains a total task set, TaskPool; a data structure, Task Structure, that records task details; and a data structure, Worker Structure, that records worker task processes.

Through a smart contract, the task publisher posts a crowdsourcing design task and sets the corresponding requirements for the worker. The system will automatically generate the corresponding task structure and store it on the blockchain. Before a worker receives a task, the function ReceiveTask( ), defined in the RC contract, evaluates the worker’s ability to work according to the requirements set by the requester. If the task requirements are satisfied, the worker can successfully receive the task. At the same time, the system will generate a corresponding worker structure; the publisher can track the progress of the worker’s crowdsourcing design task at any time. The task-status machine changes the task status from Pending to Claimed. When the number of workers receiving the task reaches the required number of workers set by the publisher, the task will not be available for receiving again. Workers who have received an assignment will need to submit a solution before the deadline.

If the posted task includes some essential large files or folders, requesters should also save the corresponding attachment folders to the storage layer as mentioned above, then store the corresponding generated search pointer to the blockchain. The worker uses the pointer to find the corresponding task document to access the details and background of this crowdsourcing design task. In addition, a simple task deposit agreement is set up in the smart contract. Users are required to pay a certain amount of task deposit when posting or receiving tasks to ensure a fair performance in the crowdsourcing service agreement reached by both parties.

4.3. Reputation Algorithm

Each successfully registered user is assigned a default reputation ${\beta }_W,{\beta }_W\in {\rm Z},\left(0,1,\dots ,{\beta }_W^{Max}\right)$, which reflects the user’s ability to work and reputation level. The reputation value is updated depending on the publisher’s evaluation of the worker’s completion of the crowdsourcing design task, with $a=H$ indicating a positive review and $a=L$ indicating a negative review. The formula for calculating the reputation can be described as:

$${\beta }_W=\{\begin{array}{cc}\min ({\beta }_W^{Max},{\beta }_W + 1),\hfill & \mathit{if} a = H \mathit{and} {\beta }_W \ge h_k\hfill \\ {\beta }_W+1,\hfill & \mathit{if} a = L \mathit{and} {\beta }_W < h_k+1\hfill \\ {\beta }_W-1,\hfill & \mathit{if} a = H \mathit{and} {\beta }_W \ge h_k+1\hfill \\ 0,\hfill & \mathit{if} a = L \mathit{and} {\beta }_W = h_k\hfill \end{array}$$

(1)

where $h_k$ is the social strategy threshold, a method of using social norms to control worker behavior [16]. If the user’s reputation value drops to a threshold and the crowdsourcing design task does not receive a positive review, the user’s reputation value will simply be cleared. The user will not be able to receive tasks normally and will need to complete some simple tasks with no specific requirements for reputation to accumulate positive feedback until the reputation value rises to the threshold, when the user’s task receiving function will return to normal.

4.4. Protocol Algorithm

To completely describe the process of crowdsourcing design services, the following algorithms are designed in the smart contract: Register, PostTask, ReceiveTask, SubmitSolution, GetSolution, EvaluateSolution and other auxiliary algorithms. The user interacts with the smart contract deployed on the blockchain through the crowdsourcing application to complete the crowdsourcing design. The flow of smart contract and protocol interaction for crowdsourcing design services is shown in Figure 9.

4.4.1. Register

Users need to complete identity registration before participating in a crowdsourcing design task. The Register protocol first confirms that the currently registered username is not in use, then publishes the user’s detailed registration information User = {addr_User, Username, Profile, Time_Reg, Num_PT, Num_FT, ${\beta }_W$} to the blockchain, where Time_Reg denotes the user registration time. Num_PT and Num_FT denote the number of tasks being processed and the number of finished tasks by workers, respectively, both with initial values of zero. ${\beta }_W$ is the initial reputation value issued by the system, which is related to the average reputation value of all workers in the current crowdsourcing system.

4.4.2. Posting Task

Once a task publisher has completed registering, they can post crowdsourcing design tasks Task = { addr_URS, Requester, Title, Description, $\theta$, dl_S, dl_E, $\lambda$, ${\beta }_W^{Min}$, Type, Pointer_T} in the crowdsourcing application, where dl_S and dl_E denote the deadline for task workers to submit tasks and the deadline for publishers to complete evaluations, respectively; Type is the type of the current crowdsourcing design task; and Pointer_T denotes a pointer to the necessary attachments for the current crowdsourcing design task. In order to avoid malicious behavior from requesters, such as refusing to pay commission, it is set that requesters need to pay the corresponding task deposit before posting the task. Algorithm 1 shows the concrete implementation of posting task.

Algorithm 1: PostTask

Inputs: the address of URS addrURS, Requester, Title, Description, task reward and deposit $coins\left(\theta +\delta \right)$, the deadline of worker submit task dlS, the deadline of requester evaluate task dlE, maximum workers number $\lambda$, the limited condition of worker ${\beta }_W^{Min}$, Type, pointer of task attachment PointerT

Outputs: RC contract $R{C}_{Task}$, update $UR{S}_{requester}$

01 if Requester is unregistered then

02      Requester has not been registered;

03      go final;

04 if  Title is not unique then

05      Title has been taken;

06      go final;

07 if $coins\left(\theta +\delta \right)<\theta +\delta$ then

08      Requester deposits the reward on blockchain failed;

09      go final;

10 postTaskList( ) ← Title;

11 TaskPool(Title) ← Task{addrURS, Requester, Title, Description, $\theta$, dlS, dlE, $\lambda$, ${\beta }_W^{Min}$, Type, PointerT}

12 $nowWorkerNu{m}_{task}$ ← 0;

13 updateURSContract($R{C}_{Task}$, $UR{S}_{requester}$);

14 final;

15 returns $R{C}_{Task}$

4.4.3. Receiving Task

The worker calls the getPendingTask( ) protocol in the RC contract to query the crowdsourcing design tasks available for collection and receives the task that matches his/her work capability via Algorithm 2. Similar to task requesters, workers are required to pay a certain amount of task deposit before receiving the task in order to prevent them from slacking off and working negatively.

Algorithm 2:ReceiveTask

Inputs: RC contract $R{C}_{Task}$, the address of URS $add{r}_{URS}$, Worker, Title, task reward and deposit $coins\left(\delta \right)$, worker $UR{S}_{worker}$

Outputs: update RC contract $R{C}_{Task}$ and URS contract $UR{S}_{worker}$

01 if Worker is unregistered then

02      Worker has not been registered;

03      go final;

04 if ${\beta }_W<{\beta }_W^{Min}$ then

05      Worker does not satisfy the condition;

06      go final;

07 if checkTaskStatus(Title) is not Pending or Claimed then

08      TaskPool(Title) can be accepted anymore;

09      go final;

10 if $coins\left(\delta \right)<\delta$ then

11      Requester deposits the reward on blockchain failed;

12      go final;

13 workerList( ) ← $worker\left(add{r}_{worker}, W_{username}, Title, Timestamp\right)$

14 $Nu{m}_{PT}++$;

15 receivedTaskList( ) ← Title;

16 $nowWorkerNu{m}_{task}++$;

17 updateTaskStatus(Title);

18 updateURSContract($R{C}_{Task}$, $UR{S}_{worker}$);

19 final;

20 return $R{C}_{Task}$

4.4.4. Submitting and Acquiring Task Solution

A worker completes a task and submits the task solution via the submitSolution( ) protocol, which is set to be invoked by workers who have received the task to complete the solution submission only before the task’s submission deadline. First, the worker signs with the private key and the public key of the task requester to encrypt the content of the solution and store it in the storage layer—the distributed database. Following this, the corresponding file hash value and the file retrieval pointer are submitted and stored in the blockchain. Finally, the requester gets the file pointer through the getSolution( ) protocol to find the source file and decrypts it with his/her private key to access the solution content.

4.4.5. Evaluating Task Solution and Sending Reward

After a worker submits a task, the requester needs to start the process of evaluating the task and paying the task reward before the evaluation deadline. The task reward is determined by the quality of the worker’s completed task via Algorithm 3; based on the evaluation result, the URS contract automatically updates the worker’s reputation value synchronously.

Algorithm 3:Evaluate Solution

Inputs: RC contract $R{C}_{Task}$, Requester, Title, Worker, task evaluate level, social strategy $h_k$

Outputs: update RC contract $R{C}_{Task}$, update URS contract $UR{S}_{requester}$ and $UR{S}_{worker}$, send reward to the worker W

01 if checkTaskOwner(Requester) is failed then

02      $R_{username}$ is not the owner of this task;

03      go final;

04 if checkTaskLevel is success then

05      task has been evaluated;

06      go final;

07 if checkTaskStatus(Title) is Uncompleted then

08      ${\beta }_W \leftarrow 0$;

09      sendReward($coins\left(0\right)$);

10 else if ${\beta }_W \ge h_k \& level \equiv H$ then

11      ${\beta }_W \leftarrow \min \left({\beta }_W^{Max}, {\beta }_W+1\right)$;

12      sendReward($coins\left(\theta +\delta \right)$);

13 else if ${\beta }_W \ge h_k \& level \equiv L$ then

14      ${\beta }_W \leftarrow {\beta }_W-1$;

15      sendReward($coins\left(\delta \right)$);

16 else if ${\beta }_W \equiv h_k \& level \equiv L$ then

17       ${\beta }_W \leftarrow 0$;

18      sendReward($coins\left(\delta \right)$);

19 else if ${\beta }_W<h_k \& level \equiv H$ then

20      ${\beta }_W \leftarrow {\beta }_W+1$;

21      sendReward($coins\left(\delta \right)$);

22 updateReputation($UR{S}_{worker}, {\beta }_W$);

23 updateURSContract($R{C}_{Task}, UR{S}_{worker}$);

24 updateURSContract($R{C}_{Task}, UR{S}_{Requester}$);

25 updateAvgReputation( );

26 final;

27 returns $R{C}_{Task}, UR{S}_{requester}, UR{S}_{worker}$

5. Experiment

5.1. Experiment Environment

This paper is designed to realize blockchain-based process management and control of crowdsourcing design services based on the above framework. The smart contract framework is written and tested using Solidity v0.8.7 programming language and Remix web editor. The experimental environment is Win10 x64 bit operating system, using the current popular blockchain development framework Truffle v5.6.4, then combined with JavaScript and Ganache v2.6.0-beta.3 client to complete the smart contract compilation, deployment and testing.

5.2. Experiment Process and Analysis

To evaluate and validate the feasibility of the framework presented in this paper, we have deployed this crowdsourcing design platform on our regional blockchain, validating the functionality of the smart contract in crowdsourcing design service steps, including user registration, the requester posting a crowdsourcing design task, the worker receiving the task, the worker submitting the task and the user traceability of the crowdsourcing design task.

5.2.1. Smart Contracts Complication and Deployment

The compilation and deployment of the smart contract is completed using commands in the operating system terminal, as shown in Figure 10. The ABI of the smart contract will be generated after compilation, which is used to call the functions in the smart contract and implement the data storage. This is successfully deployed to the Ganache client, as shown in Figure 11.

5.2.2. System Functionality Testing

The following is a test to verify some basic functions of this crowdsourcing design service process control. Figure 12 shows the user registration data recorded on the blockchain and addrList[] stores the address information of the users; currently three users have completed registration.

As shown in Figure 13, the requester R1 posts a task titled “Design a three-axis robot arm” on this crowdsourcing design platform, and the worker W1 receives and submits the task. One must simply follow the prompts to enter the corresponding crowdsourcing design task information and then initiate a transaction to complete the interaction with the blockchain and accomplish the crowdsourcing design service.

After the above simulation of the crowdsourcing design task, the details of this crowdsourcing design task are recorded on the blockchain, as shown in Figure 14: “Requester R1 has posted a crowdsourcing design task, ‘Design a three-axis robot arm’. The design requires ‘It needs an original design with high precision, low cost, simple transmission, simple manufacturing process’. Currently one worker received this task and completed the submission; the status of the task is completed”.

Figure 15 shows the traceability information of worker W1’s completion of the crowdsourcing design task recorded on the chain. The traceability information details the address information of the worker, the time of receiving the task and the time of submitting the task, a brief description of the task and the attached retrieval pointer.

In summary, the test results show that the blockchain-based control of crowdsourcing design services and visual management of crowdsourcing design tasks are achieved. From the posting of a crowdsourcing design task to the final payment of the task reward, the complete details of the user’s operation are recorded on the blockchain and updated as the user interacts with the smart contract. In particular, the data of crowdsourcing design tasks cannot be tampered with or deleted at will. Crowdsourcing design tasks performed under this framework can always track the current status of the task; even after the crowdsourcing design task is finished, the task data will be permanently saved and can be traced back to any task at any time. The entire system consensus is jointly maintained by the participating nodes, which has higher credibility than relying on third parties for data management. The blockchain system and IPFS are both distributed architecture, which does not have the problem of single point of failure and has higher availability.

6. Conclusions

In this paper, we analyze some problems of the traditional crowdsourcing design service platform in the context of social manufacturing, design a blockchain-based approach of model architecture for crowdsourcing design services using the decentralization, tamper-proof and traceability features of blockchain. Combined with IPFS and other technologies, the whole crowdsourcing logic process is implemented with smart contracts. The paper details the composition of the application layer, blockchain layer and storage layer in this method; depicts the data-interaction process between three layers; and solves the problem of blockchain-based crowdsourcing design services involving large files that affect the operation of the blockchain. Finally, we tested the deployment of the entire framework on the blockchain. The results showed that the entire crowdsourcing design workflow can be fully implemented and the control of the crowdsourcing design service process can be achieved.

In this paper, a series of algorithmic protocols are designed based on smart contracts. A task-state machine is designed to accurately describe all the states of the tasks in the crowdsourced design workflow and enhance the flexibility of the crowdsourced design service, combining blockchain technology with a crowdsourcing design model under the context of social manufacturing.

Although the model and method proposed in this paper are feasible and practical, there are still some shortcomings. The experimental validation in Section 5 simply verifies the usability of the model functions with a small scale of experimental data. The presented model performs well when the number of network nodes is low, but as the number of network nodes increases, the uncertainty brought to the model remains to be studied in depth. In the future, we will further improve the algorithmic logic of smart contracts so that they can run stably and securely in a complex node network environment before deploying them to public test networks for testing.