Hyperledger Mentorship Program 2020
By: Hritik Gupta
Tags: Blockchain, Distributed Ledgers, Hyperledger, Mentorship Program, Hyperledger Fabric

Background

The Hyperledger Summer Mentorship Program, now in it’s 4th iteration, presents an exciting opportunity to gain exposure to Hyperledger open source development and contribute to the open source blockchain ecosystem. This year, a cohort of 18 mentees worked on a diverse array of projects. I got to work as a part-time mentee on a project titled “A fully distributed citizens pulse platform for state/city councils — with Hyperledger Fabric” along with my mentor Anoop Vijayan. The article elaborates in detail the work and learning accomplished in this stint.

Overview

Many city councils want to know the voice of citizens whenever a change is implemented. Usually when a city approves a plan, there is always a small minority affected/opposing it. The city always wants feedback from the citizens on their decisions and they never have a proper channel to do so. Though the usage of online forums are common in developed and developing countries, it is usually challenging to get the public to agree on a common platform as the platforms are controlled by individual companies/government bodies. Also, the public is worried about privacy and safety of the platform. Further, there are also situations where some NGOs who host the platform have financial challenges and hence discontinue their services.

Proposed Solution

Via a framework like Hyperledger Fabric, it is possible to decentralize the ownership. Moreover, due to its immutable nature, there is one source of truth existing in the system. With the Hyperledger components shared across the stakeholders, the ownership is distributed. We thus propose a platform for the council to create proposals/plans and the citizens to be able to express their views and support for the same remaining anonymous in the process.

Implementation

We leverage the concept of Private Data Collections, a way to manage confidential data that two or more organisations in a single channel can secure from other organisations in the same channel. The collection definition describes the set of organisations that are entitled to store and transact with this private data.

To begin with, there are two organisations within a channel in our network, namely Council Org (called as Org1) and City Org (called as Org2). Any user registered to Org1 CA would be entitled to create plans on the platform and begin polling for it, close polling; whereas a user registered to Org2 CA would be able to upvote/downvote a plan, make and edit comments, view all his/her votes. Polling for a plan stops automatically on the date set by Org1 user while creating the plan. Once closed, both council and city users would be able to see insights and reports of that particular plan on the platform. Downloadable reports are available as well.

From the Hyperledger Fabric front, implementation has been primarily based on the test-network in fabric-samples. There are two sets of collections defined: Global Plan Collection and Private Plan Collection. When a plan gets created by an Org1 user, data is appended to both of these collections having metadata like planid, description, deadline, comments, upvote, downvote etc. The global collection is accessible to peers of both the Orgs, whereas Private collection is persisted in only Org1 peers. Whilst the polling lasts, changes are made to private collection data and no updates are made to the global collection. This is to ensure that no citizen can view other citizen’s votes/comments, that might make the process of getting the pulse biased. Also, to make sure that the council is not able to see who voted/commented what, we hash the user credentials before storing it in the private collection. As soon as the voting ends for a plan, the global collection is updated with the final data obtained from its private collection; and the private collection for that plan is deleted.

To be able to take requests from clients, there is an API server [implemented in Express] in place that fetches the appropriate request headers and payloads and redirects the request to the running Hyperledger Fabric instance. The server uses Fabric’s Node SDK to interact with the blockchain behind the hood. Moreover, there is a database storing user details i.e. mapping between username-password to Hyperledger Fabric certificates, user comments and votes. To achieve an alternate data backup and reliability, Fabric’s file system wallet has been used to store user identity information. We plan to move this to Couch docker instances.

Overall Architecture

Functionality Walk-through

Users have the option to send requests via a Web or Mobile client.

An Org1 user, when logged in, can create plans. The add plan button at the navbar presents to the council user a modal to enter in plan details viz. plan-id, description and a deadline. Once pressed on submit, the request goes to the API server, which further delegates it to Fabric to invoke the InitPlan method of the chaincode installed on the Org peers. This step involves creation of the Global and Private Plan Collection. As mentioned earlier, the global collection is persisted on peers of both orgs, whereas private plan is persisted only on Council org peers. Org1 users are also authorized to close the polling for a plan manually. A manual trigger to closing a plan involves deletion of the Private Plan collection and updating all the information on the Global plan, thus making results for polling public. We have an automatic plan closure system as well, implemented via a scheduler [similar to cron] running on the API server that queries the list of active plans each day at 12.00 AM, iterates through them and compares each of the plan’s deadlines with the current date. If the current date has surpassed the deadline, the scheduler internally calls the method to close the plan by passing the planid. Commenting has been made open to council users for making any announcements or similar requirements.