Building an enterprise blockchain application (part 1): design and architecture

Hesitation about blockchain is on the wane and we are seeing increased business adoption across industries. Blockchain, having many potential applications beyond the originally focused financial services industry, has the potential to revolutionize logistics, supply chain, manufacturing, healthcare, government, title registry, and content distribution. With benefits such as increased trust, transparency, and security of data, as well as the ability to introduce cost savings and new efficiencies, organizations should be preparing to take advantage.

To help you get your feet wet, we will take you through the steps involved in the design, architecture, and implementation of a fully functional enterprise blockchain application in a series of blog posts. We will do that by sharing content from the various development stages of a sample application that we (Relevantz) built for loan origination and payment on blockchain. If you follow through the end of this series, you will have a better understanding of the internal workings of a blockchain application.

We built this application using the IBM Blockchain Platform 2.0 beta. To get started with the latest version of the IBM Blockchain Platform, you can read this blog by IBM for download instructions, which include how to get a 30-day trial.

Visit our exclusive microsite on asset tokenization

Table of Contents

Objective

The objective is to develop a decentralized application (DApp) that explores the potential business benefits of using blockchain, such as:

1. Improved process efficiency

2. Economy of scale

3. Privacy when you need it

4. Transparency and trust

5. Decentralized data with a logically centralized view

6. Recording of payments onto a blockchain

Use Case and Actors

The use case we picked to meet our objectives is a loan origination and payment application. The actual implementation of the use case doesn’t cover all intricacies and regulatory aspects of the loan origination and payments process, but it will be a good indicator of the design aspects to consider while building a DApp on the blockchain. The actors in the app include:

The Credit Reporting Agency — publishes the credit report of the citizens of the demo universe to the blockchain network. 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 network. Controls access to the reports through smart contracts.
The Borrower (Applicant) — applies for a loan → receives proposals of various terms and conditions from lenders → obtains the loan → makes the monthly payment, all on the blockchain.
Lender 1 — fully utilizes all that blockchain has to offer, hence the fully automated business process behind the proposal response to the applicant.
Lender 2 — still follows some traditional business process, slowly embracing blockchain.
Consortium — facilitates onboarding organizations and establishes the 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 Certificate Authority 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 chaincode to create and process the loans will be deployed to the peers of Lender 1, Lender 2, and the 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. Application design and architecture are equally important. Consider the following as you design your application:

Although the IBM Blockchain Platform with Hyperledger Fabric at its heart scales well when compared to the public blockchain platforms, it is not a transactional database, so don’t expect throughputs like that of 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 personally identifiable information onto the blockchain.

Design

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 the blockchain. This helps to keep the other services lightweight and flexible.

As you can see, we are expanding the IBM Blockchain Platform network to include a node running in AWS, showing the multi-cloud ability of IBM Blockchain Platform.

Data flow

The microservices expose REST APIs for the presentation layer to consume.
The services delegate calls to the Hyperledger Gateway for blockchain invocations.
The blockchain calls are asynchronous. Once the transactions are added to the blockchain, the Event Hub pushes the signal to all interested subscribers through a callback endpoint.
We use WebSockets for the presentation layer to react to the events from the Event Hub.

Data flow diagram with synchronous (red) and asynchronous (black) calls