In this series of blog posts, I will take you through each of the steps involved in designing, architecting and implementing a fully functional Enterprise Blockchain Application. At the end of this series of posts, we will share the entire code base of the application along with docker containers containing the app to ensure you have a better understanding of how to build a blockchain application.
The app will be built on IBM Blockchain Platform 2.0 Beta. Please check out my previous post — IBM Blockchain Platform 2.0 Beta: Run your blockchain N/W in 10 Simple Steps
The Objective of our app
The objective is to develop a DApp that explores potential business benefits of using Blockchain like
- Improved process efficiency
- Economy of scale
- Privacy when you need it
- Transparency and trust
- Decentralized data yet logically centralized view
- Record payments on to Blockchain
Use case and Actors
The use case we picked up to meet our objectives is a Loan Origination and Payment application. The use case doesn’t cover all intricacies and regulatory aspects of the loan origination and payments but will be a good indicator of what are the design aspects to consider while building a DApp on Blockchain The actors in the app are
- The Credit Reporting Agency — publishes the credit report of the citizens of demo universe to the Blockchain N/W. Controls access to the reports through smart contracts.
- The Property Title Search Organization — publishes the title report of the properties in the demo universe to the Blockchain N/W. Controls access to the reports through smart contracts.
- The Borrower (Applicant) — applies for a loan → receives proposals of various T&C from lenders → buys the loan → makes the monthly payment, all on the blockchain
- Lender 1 — who fully utilizes all that blockchain has to offer and hence fully automated business process behind the proposal response to the applicant
- Lender 2 — who still follows some traditional business process slowly embracing blockchain
- Consortium — which facilitates onboarding organizations and establishes governing principles of the business network.
Blockchain Business Network
The Blockchain business network of the application looks like this
Technical Design and Architecture
IBM Blockchain Platform Business Network Architecture
- Every organization in the network has a CA and a peer node.
- A private channel is established between the consortium orchestrator and lenders to securely share proposals, terms, and conditions of the loan with the applicant.
- The chain code to create and process the loans will be deployed to the peers of Lender 1, Lender 2 and consortium orchestrator. We will review the Chaincode in detail in another post.
The design of the Blockchain network is just one piece of the puzzle the Application design and architecture is equally important. Consider the following as you design your application
- The blockchain is not a transactional database, so don’t expect throughputs like a traditional centralized database. IBM Blockchain Platform with Hyperledger Fabric at its heart scales well when compared to the public blockchain platforms but the throughput still cannot be compared with traditional centralized databases
- Use the blockchain for what it has to offer — trust, transparency, and immutability. Decide what you store in your blockchain based on that
- Embrace asynchronous event-driven programming — the blockchain nodes are only eventually consistent. The consensus process is not instantaneous.
- The data in the blockchain is secured by design through encryption and various governing principles of the network, but the security stops at the blockchain network level. You should still address the application security with your design
- Think about GDPR like regulations before you store PII onto blockchain
We followed a modular microservices architecture. The complexity of interaction with the blockchain itself is abstracted out to a generic component that knows how to invoke Chaincode to read/write data from/to blockchain. This helps to keep the other services lightweight and flexible.
Service API Definitions
Borrower (Applicant) Services
I hope you are able to follow up until now we will catch up on the design and development of the Chaincode in our next post.
About the Author
Ganeshram Ramamurthy is ObjectFrontier’s technical director and heads technology for presales. For many years, Ganesh has been designing and developing enterprise applications across various domains. He has a keen interest in emerging technologies and is now spearheading blockchain initiatives at OFS.