Enterprise Blockchain: Building a data exchange system

This is the second article in the series of enterprise blockchain. You can find the earlier article which talks about using IPFS storage with enterprise blockchain at
https://www.kavayahsolutions.com/kavayah-blog/enterprise-blockchain-using-ipfs-for-storage-with-hyperledger-fabric

In this article we will discuss about how to set up an enterprise blockchain between an organization and its partners/service providers. We will then discuss about onboarding a new partner/service provider into this network. We will discuss set up the network and the necessary technologies and steps. This will provide a well-rounded view of how a data exchange system can be built with enterprise blockchain.
 
For the sake of this article, let us consider a scenario in which a law firm which does business with other firms like process servers and lien resolution companies. All of them share information in the form of files, send status messages, generate/send invoices, payments and so on using email, portal uploads/downloads, secure form posts and so on.
​
One can estimate that there would be a lot of scattered data across systems and formats. System administrators would get nightmares thinking about back up and retrieval.
 
Let us consider using a sophisticated tool like EDI for our contrived scenario. EDI or Electronic Data Interchange systems are built for a specific purpose of one-to-one communication between organizations.
 
EDI exchanges data is in a standardized format –EDIFACT, GS1, etc.– and uses sftp, AS2 or VAN for transport. Consider that our law firm has a new partner, an accounting company and this new company does not use the EDI data standards nor the transport.
 
It will be a herculean task for the partner to get on to the EDI system. Since EDI works in a one-to-one paradigm when exchanging data, it may lead to stale and incorrect data when data across multiple organizations undergoes continuous and simultaneous change.
 
The solution to this problem lies in using tools which can make dissemination of information automatic, immutable and highly available. This makes organizations and its users accountable to the changes. Enterprise blockchain provides all those features out of the box. Storing large data sets on the enterprise blockchain ledger provides one challenge. Large files in a blockchain network create a lag. This will worsen as time progresses. Nobody like a slow network.
 
The solution for this is simple and considered. IPFS or Inter-Planetary File System can be used with enterprise blockchain, we can set up and use an IPFS network for file storage. You can read about in a previous article https://www.kavayahsolutions.com/kavayah-blog/enterprise-blockchain-using-ipfs-for-storage-with-hyperledger-fabric
 
Let’s say a decision has been made to use Fabric and IPFS for our data exchange system. Both Fabric and IPFS processes can be run in lightweight environments as docker instances. We will orchestrate the process of installing and running all the Fabric and IPFS nodes using docker images. These docker images are readily available from Hyperledger Fabric and IPFS software creators. We will create a network between all the participating entities.

Figure 1: Technology stack for setting up a blockchain network
​

​There are two types of organizations inside a Fabric network.

1. Orderer organization: This is a neutral organization and its role is to order/queue transactions on the blockchain
2. Peer organization: These type of organizations are the organizations that will conduct transactions.

 
Orderer organizations will have the orderer nodes running and whereas the peer organizations have peer nodes running. Let’s see what a peer node can do. Let say an organization makes a proposal –uploading files, updating status– the proposal will go to the peer node of that organization. From there, the proposal is then verified and build an object consisting all the changes to the resource and how the state of resource will look post-modifications. This is called a block.
 
The process of getting and setting the state of a resource and creating the corresponding blocks are done by chaincode. Chaincode is a program attached to the peer from where the response to a proposal is emitted in the form of block.

Each organization has their own set of client applications from where the proposals are built and sent to the organization’s own peer node on the blockchain network. Once the response/block reaches the client application with all the checks, this block is sent to orderer node to be added to the ledger. Every peer node has a ledger, so this new block will be added into each of those ledgers in the network. 
 
All the users/peers/clients belonging to an organization will be identified by the authorization keys they possess. For this purpose there is a certificate authority(CA) for each organization, both peer and orderer organizations.

Figure 2: A simple flow diagram for a transaction on blockchain
​

​The ledger shown in the above diagram is where the world state of all resources on the blockchain is stored. This world state is maintained in database, we will use CouchDB. Since all the peers possess the same ledger, they all possess the all information exchanged between them.
 
Let’s consider a sub-scenario, suppose the law firm has information that needs to be only shared with the process server and not with the lien resolution group. We will use collections in Hyperledger Fabric that will enable us to do exactly what we want here. While instantiating the chaincode we pass a collections config file in which we define the private rooms and organization-set for each room. Thus, when a proposal reaches the chaincode, we can set the data to be added into these private rooms where the only organizations allowed to view it will be allowed to access it.
 
This is a very useful feature where the organizations can come together in one channel and at the same time maintain privacy amongst a few. We are using an IPFS network for storage, this will minimize the infrastructure costs to great extent. Since we won’t be adding the files to the ledger but instead into the IPFS network.
 
The upside to using a programmable solution stack like this, is the atomic control we get and we can decide what to do next. What is next here, automation! Yes, chaincode has the facility to emit events inside. We can have an event listener which will do all miscellaneous actions otherwise done manually.
 
Note that automating work inside chaincode got it the name “smart contract”. When a proposal reaches chaincode informing it that a service rendered and verified, it will be automatically rewarded and hence upholding all the conditions in a contract.
​

​We will discuss in more detail how each of these components can be programmed and built in our coming articles.