Blockchain spine

The project designed, developed, and deployed a fully functioning blockchain network dealing with deep leasing and Vehicle-as-a-Service business model.

The project can mainly be divided into two main tasks producing two things. The first involved design, specification, and deployment of the blockchain network, the second writing smart contracts using the Go programming language to implement business transactions.

Blockchain Network

After careful evaluation of different blockchain solutions, we have determined that Hyperledger Fabric is the most suitable choice for our specific use case. This decision is based on several key factors, primarily its private and permissioned nature. As an enterprise solution, it is crucial for our platform to ensure robust security and privacy, granting access exclusively to approved participants. Public access is strictly prohibited, and we require a network that can accommodate only pre-approved organizations for participating in business application transactions.

Hyperledger Fabric

Hyperledger Fabric effectively addresses the specific requirements of our business needs. Its design caters specifically to enterprise demands, making it the obvious choice for our project, aligning perfectly with our security, privacy, and participation criteria.

Design and definition of blockchain network

When designing a Hyperledger Fabric blockchain network, it is important to consider several key parameters and scenarios. These parameters include the level of redundancy required and the degree of separation between Certificate Authorities and other participating nodes (like peers and orderers) within an organization.

Channels and governance

In Hyperledger Fabric, data privacy and accessibility of data is implemented in the form of channels. For more granular, finer control, private data collections help achieve it. In our network, we have two channels. All three organisations participate in ‘journeydata’ channel. For the second channel, only Riversimple and org1 participate. Apart from these two channels, we have two test channels named ‘tch12’ and ‘tch13’ where Riversimple and org1 are participants and all three organisations are participants, respectively.

Channel participants are decided based on both conveniency and governance considerations. A channel participant can read the data stored on the channel except if the data is in private data and an organisation is not part of the private data collection.

Deployment of network

The deployment of the network was automated to a great extent using Ansible playbooks. The network consists of seven servers running on the Swansea University network.

Ansible Playbook

Ansible playbooks were developed to help in deploying the network nodes in an easier, human errors free, repeatable and idempotent way of execution. The playbooks also serve as a documentation of what is being done with what inputs and which certificate files are used. Idempotency of Ansible helps to reduce time and resources consumed by the playbooks. One can run the playbook repeatedly without executing the same step again and again.

Chaincode

Hyperledger Fabric (HLF) provides a few options in relation to chaincode. The business logic is implemented as smart contracts with form chaincode in HFL. Smart contracts can be written in either in go, java, or javascript. We chose the go programming language as it is statically typed, compiled, and comparatively faster with good developer community support for HLF chaincode. Chaincode, data structures and function definitions and implementations are defined to match the data sent from client app.

Defining data structures and functions

We designed and developed a list of business transaction logics as chaincode functions. Before implementing any functions, we had to come up with a set of data structures representing data units to be stored on the blockchain. These data structures store details used in retrieving and using data in the process of generating billing and payments.

Business transaction flow diagrams

During the designing phase we have developed several transaction diagrams to have a better understanding and visualisation of what is going to be implemented.

Future works

Onboarding a supplier to the blockchain will serve multiple purposes, including the implementation of requirements specific to the supplier's use case and the enhancement of the existing system.
By integrating the supplier onto the blockchain, we can address their unique needs and gather valuable insights and feedback from their perspective, which can be used to identify areas for improvement within our current system.
End to end implementation of bill of materials will improve overall functionality of the system.

Lessons Learnt

Blockchain systems are quite complex, especially when we require more freedom in defining and using them. From the available Blockchain frameworks, HLF is one of the most mature open-source frameworks, being modular and flexible. These characteristics also increases the complexity significantly especially during the starting phase. One of the main outcomes is that the Ansible playbooks addresses the issue and reduced the complexity to a great extent. When the system grows further these playbooks will help reduce the time and effort needed to bring up the blockchain network nodes a lot.

Blockchain Spine