PROJECT INFO:
Language:         Node.js + HyperLedger
Framework:      Docker, MongoDB, REST
Duration:          4 weeks
Team Size:       3
As part of the class 'Blockchain and Distributed Ledger Technology' at NUS, this project is a full stack blockchain solution targeting at art trade industry. The objective is to capture the provenance of artwork during trading activities based on IBM's blockchain framework - HyperLedger Fabric. 
I worked as a developer and UX designer on the team. I implemented the chain code with Hyperledger Fabric and middleware with Node.js.
Blockchain Design:
org.acme.Artbook.cto file is written to define participants, assets, and transaction methods as the code snippet shown below.
A permission.acl file is written to define the access control rules for blockchain. For an example, for User participants, only the owner of the artwork has the ‘READ’ access to the artwork (please refer the ACL file for full set of rules). 
To handle complex business logic and allow client application to interact with the blockchain component with ease, a middleware is implemented using Node.js framework. 
The middleware mainly uses composer-client npm module to programmatically connect to the blockchain business network. To interact with the client application, a RESTful API layer, a controller + handler layer and a model layer are implemented using Express JS, mongoDB and Passport JS. 
Experience routes:
Routes for participants:
Routes for individual users, agencies, police, and Artbook branches, are implemented to handle user registration, authentication, retrieve user-related information. mongoDB, together with mongoose npm module, is used to store user authentication information, e.g. id and password. The password is hashed with a salt, to defend against dictionary attacks and rainbow table attacks. Passport.js npm module is used to handle authentication.
Routes for artwork and supporting documents
Routes for artwork ares used in various uses cases. Examples like Artwork officials to add new artwork to the system, users to view all owned artworks, agency to look up an artwork using its ID. Since artworks are associated with their supporting documents, some utility functions are implemented for client application to add or retrieve supporting documents after retrieving a artwork information from the system.
Routes for trade
An important feature of the Artbook system is to get and record consensus among various parties in a artwork sale process. The process of getting consent from each party is complex and critical, hence the middleware is carefully designed to handle the process and submit corresponding transactions to the blockchain component at different stage. 
A complete artwork sale process starts with an agency asks consent for sale from an artwork owner. The middleware expects a consent from the owner. If the owner agrees, the middleware will capture this and submit it to the blockchain component. When the artwork has an intended buyer, the agency will send request to the buyer via the client application, the middleware will then send this request to the buyer. If the buyer agrees with this sale, and deposits money on the 3rd-party payment solution provider, the middleware will submit this consent from buyer to the blockchain component. The last step is the owner receives notification about the sale. When the owner agrees with this sale, the sale is completed and recorded on blockchain. 
Back to Top