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.

​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.

​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.

Introduction

Suppose you are building a data exchange system between a consortium of organizations using an enterprise blockchain network. Documents of large file-size will need to be stored and retrieved routinely. A decision is made to use Hyperledger Fabric as the framework by the powers that be.

Hyperledger Fabric is an excellent framework to run an enterprise blockchain network and can work for a lot of use cases. However, it is not advisable storing large data sets on the ledger. This is a common issue across all blockchain frameworks.

​Many industries that use enterprise blockchain technologies, use it for features like security, high-availability, data-immutability and decentralized network. Any blockchain framework is suitable only for small data sets. The dissemination of large data will create a lag on network. This lag may not be acceptable in a production system. We need a solution to this problem.

Enter IPFS, the Inter Planetary File System. IPFS helps solving the problem of file storage. Large files can be easily stored and efficiently managed on the IPFS.
 
In the remainder of this article we will discuss 3 different setups in increasing order of security measures.
​

• Setup of a parallel IPFS network and simple storage and retrieval of a file
• Setup of encrypted storage and retrieval of a file
• Setup of authorization scheme with encrypted storage and retrieval of a file. 

Simple storage and retrieval on IPFS

​The idea is to create an IPFS network parallel to the Fabric network. In a multi-organization blockchain network, we can install and run the IPFS processes on the fabric peers. But, segregating the fabric peer and IPFS processes will give better performance.
acceptable in a production system. We need a solution to this problem.

​The app will be communicating with both the networks. The step one in this process will be sending the files to be uploaded to the IPFS network. If the App belongs to Org1 then they will send the file to be uploaded through one of its nodes in the IPFS network. After a successful response from IPFS API application, which will contain the hash-code for the uploaded file. This hash-code will be the content to be stored on the Fabric ledger. A further breakdown of the whole process is shown as below. 
​

Encrypted storage and retrieval

To secure our file, we will encrypt the file with a key. Behind the each of the IPFS and Fabric API applications sit their respective networks, the infrastructure setup for each network may also be in different geographies. 

As a bonus, the redundancy of large files when stored on a ledger can be avoided by using IPFS.

Authorization scheme with encrypted storage and retrieval

How about access to a subset of organizations within a larger set of organizations within a Fabric channel?
Data can still be privately stored on ledger while sharing it to an arbitrary number of organizations. A set of organizations may be organized in sets, called collections in Fabric.
 
Therefore, on the IPFS network the access to file data should be determined based on whether a node from an organization is permitted to see the hash-code of file on the ledger.
 
To achieve this, we devised a process where the files are encrypted using a symmetric key stored on the ledger along with the file hash-code.
 
Let’s say, for a successfully uploaded file, the IPFS API will send a response with hash-code of the file and encryption key. Now this data is delivered to the Fabric API through which the chaincode is invoked and stored on the ledger.
​

​The above diagram shows how the hash-code+key is stored to the ledger, now when the user needs to view a file, she will need to fetch both the hash-code and the key. Organizations with the encryption key are the only ones that will be able to view the content of the file. This ensures the rules imposed inside the fabric collection configuration are also applicable on the IPFS network. We will try to go into more detail about Hyperledger Fabric and IPFS in upcoming articles.