Topcoder - PoC Challenge Review Process with Blockchain - Project and Challenge Creation

Welcome to Topcoder - Challenge Review Processing with Blockchain challenge creation and member registration

Challenge Objectives 
 

• Create initial setup for POC for Challenge Review process using Hyperledger Fabric v1.2, for showcasing the blockchain capabilities in Topcoder platform

Project Background
 

• Topcoder is trying to determine if Blockchain can be used to control the review process of challenges
• To build the blockchain network Hyperledger Fabric 1.2 is going to be used
• To store the submission files IPFS (Inter-Planetary File System) must be used
• The idea is to have the chaincode of Hyperledger Fabric 1.2 doing all business logic and the challenge data related to review process (review, appeal, appeals response and manager response) will be store into the blockchain ledger
• This is the challenge of a series of challenges to build this PoC application

Technology Stack
 

• Hyperledger Fabric 1.2
• IPFS (Inter-Planetary File System)
• Node.Js - for chaincode and client SDK
• Docker

Individual requirements
 

• The new review process flow using blockchain can be found in forum. Please register to get access.
• In this challenge we want to:

1. Use the initial setup from previous challenge (found in forum). Below is the configuration:

• Network: topcoder-review
• Orgs: Topcoder, Clients, Members, & Moderators
• Peers: 2 peers for each org
• Channels: topcoder-client (Topcoder and Clients) and topcoder-review (Topcoder, Members, and Moderators)
• Orderer: Solo

2. Create a Node.Js API service client to accept HTTP posts with the following endpoints and corresponding chaincodes:

2.1 POST /projects and PUT /projects/{projectId}

2.1.1 API

• Create/Update the project
• The project must be created/updated in topcoder-client channel and must be made available also to topcoder-review channel.
• createdBy must be used to create the data on blockchain
• While creating the project on topcoder-review channel, budget must be omitted
• During POST prevent duplicated projects (same project id)
• Payload (required/optional is only for creating projects. For update, all fields are optionals with the exception of projectId):

  {
    "projectId": 001, <- required
    "copilotId": 002, <- optional
    "name": "A great name", <- required
    "description": "A long description", <- optional
    "budget": 1000, <- required
    "createdBy": "user@email.com", <- required
  }
  

2.1.2 Chaincode

• Implement chaincode to put the data in blockchain
• Key for project should be prj_{project_id}
• Role from attributes must be checked before performing the operation
• Only client/manager can create the project

 

2.2. POST /users

2.2.1 API

• This will enroll users against specific organization using organization's MSP
• Use email id to register the user on blockchain
• While registering the user on blockchain, stoer the role of user as an attribute; so later that can be used for ABA (Attribute Based Access)
• Role v/s Orgs:
  • client -> Client
  • manager -> Topcoder
  • member -> Members
  • copilot -> Moderators
  • reviewer -> Moderators
• Payload:

  ������{
      "roles": "[<possible values client/copilot/manager/member/reviewer>]",
      "memberId": 005,
  ���    "memberEmail": "user@email.com"
  }

 

2.3 POST /challenges and PUT /challenges/{challengeId}

2.3.1 API

• Create/Update the challenge
• The challenge must be created in topcoder-review channel
• createdBy must be used to create the data on blockchain
• Challenge must be created by only members of Moderator and Topcoder organizations
• During POST prevent duplicated challenges (same challenge id)
• Payload (required/optional is only for creating challenges. For update, all fields are optional with the exception of challengeId. projectId cannot be changed after created):

  {
     "challengeId": 001, <- required
     "projectId": 0001, <- required
     "name": "A great name", <- required
     "description": "A long description" <- optional,
     "createdBy": "user@topcoer.com"
  }

2.3.2 Chaincode

• Implement chaincode to put the data in blockchain
• Role from attributes must be checked before performing the operation
• Only manager/copilot can create the challenge
• For challenge creation/updation, project object should be fetched and the challenge data should be appended and store the entire object, e.g.

  {
     "projectId": 001, <- required
     "copilotId": 0001, <- optional
     "name": "A great name", <- required
     "description": "A long description" <-optional
     "challanges": 
                 [
                      {
                          "challengeId": 001, <- required
                          "name": "A great name", <- required
                          "description": "A long description" <- optional
                      }
                 ]
  }

 

2.4 POST /register, DELETE /register

2.4.1 API

• Register/De-Register the member to challange
• DELETE endpoint we will do "soft delete" - change data status from "active" to "deleted"
• memberId must be used to create the data on blockchain
• During POST prevent duplicated entries (same member id and status active)
• Payload:

  {
     "memberId": 005, <- required
     "challengeId": 001, <- required
     "projectId": 0001 <- required
  }

2.4.2 API

• Implement chaincode to put the data in blockchain
• Role from attributes must be checked before performing the operation
• Only member can register against the challenge
• For member registration/de-registration, project object should be fetched and the challenge data should be updated and store the entire object, e.g.

  {
     "projectId": 001, <- required
     "copilotId": 0001, <- optional
     "name": "A great name", <- required
     "description": "A long description" <-optional
     "challanges": 
                 [
                      {
                          "challengeId": 001, <- required
                          "name": "A great name", <- required
                          "description": "A long description" <- optional,
                          "members":
                                    [
                                        {
                                            "memberId": 005,
                                            "status": 1 <- active
                                        },
                                        {
                                            "memberId": 007,
                                            "status": 0 <- deleted
                                        }
                                    ]
                      }
                 ]
  }

  
Deployment guide and validation document

 

 

• You will need to provide a deployment guide (README.md) and a validation document (Validation.md).
• README.md should cover:
  • All steps necessary to configure the Hyperledger and Node.Js applications
• Validation.md should show all the steps necessary to verify the application:
  • Setup and start Node.Js application
  • Setup and start HyperLedger application with new configuration
  • All tests to verify the system

Final Submission Guidelines

• Zip file with submission files
  • Chaincode file
  • Node.Js application
• Detailed documentation for configuring and deploying