A few weeks ago, I started working on a project that I later submitted to the Lisk Builder Program. The core idea of the project was to provide a single API to verify claims of feats - on a resume for example. The full presentation of the idea can be read in this post.
The organization registers as an issuer. Once registered as an issuer, it can create a type of feat which can be viewed as a description of what has been achieved by the person who will receive it, and finally, the organization can award people with those feats.
Actually, only three types of transactions exist here: CreateIssuer, CreateFeatType, AwardFeat.
The CreateIssuer transaction simply initializes the asset of the account with the issuer information and an empty featTypes object.
The CreateFeatType transaction comes to add an entry to that featTypes object. The key to that entry is the ID of the transaction. Storing the ID of the transaction allows us to later retrieve the transaction, in order to have information such as, when was the time of the creation, who created the transaction. This translates to business questions, such as when was this feat type first used, or which organization is behind that award.
Of course, we could also directly store the ID of the issuer and the time of the transaction in the object. However, one has to make a decision and I thought in a blockchain environment storage costs more than compute power, so I preferred to only store the ID.
Note: I also stored the number of persons allocated with this award, as Lisk presently doesn't offer a quick and easy way to add a custom SQL request and expose it through an endpoint. In order to achieve this, it would have been necessary to create an entire custom module for this, which would not be worthwhile.
Lastly, the AwardFeat transaction pushes information inside the asset of the receiver account:
I added two properties of metadata: the date of the event and a comment that allows the issuers to set a mention for a certificate. It could also be the criteria on which the award was given, i.e the Feat Type is the “winner of a cookery contest” and the metadata would be the date of the contest (as opposed to the date the award is attributed), and what was actually achieved, which in this case could be “cooked a French soufflé”.
Once again, I used the ID of the transaction as the key of the object entry, in order to allow later retrieval. Since I used the same technique earlier, the featTypeId is actually the ID of the transaction that created the featType and therefore contains its information. Hence making it very easy to query!
Many awards will be attributed during the same period of the year to a lot of people at once. To mitigate the network congestion, you can specify an array of addresses so you can award many people simultaneously when sending an AwardFeat transaction.
The front-end has been built with ReactJS + Redux + RxJs.
For convenience, I made a screen to create an account that is automatically furnished with enough tokens to execute several transactions.
Once logged in, you are redirected to your space where you can download your QR code and see what awards you have received, (if any).
If you become an authority you will be able to create some feat types and awards accounts, and then see them on the account you awarded.
I tried to be as straightforward as possible so things are easy to understand and accomplish.
Finally, the public screen “Verify an account” displays the feats for a specific account in the network.
For further details about the FeatChain project and the code, check out its GitHub repository.
If you feel inspired and want to build your own proof of concept blockchain application, check out the Lisk Builders program. More information about the program and the application procedure can be found on the Lisk web page for the Lisk Builders program.
Disclaimer: This blog post was written by our community member, Jonathan Massuchetti (Lisk.chat username: JesusTheHun) as part of his participation in the Lisk Builders program.