In this article, I will share a context on how the properties of Hyperledger Fabric can be applied in real life scenarios.
Let’s start with really simple scenario. Imagine that we have 2 companies or 2 parties — A and B, that have some business process between each other. They do a lot of transactions & exchange a lot of information — documents, digital assets, currency, tokens etc.
So where does the shared information get stored? Now considering that both the parties do not trust each other, as is the general case, they store all their records inside their servers along with their software & so does Party B. But as they have to do business transactions together, at some point in time, the 2 companies stop and start matching the records. The probability of the records tallying with each other is often bleak but if they match, the process continues. But in reality this never happens & there is always some mismatch. So at that point the companies start the tedious & long settlement process which can take several days to weeks to months to even years in some situations. And to top it up, the worst part of the settlement process is that neither of them is paying the other as neither knows how much has to be paid. So this process has serious pitfalls. Although there are techniques that can optimize it but they still don’t scale much.
Now imagine that you have to manage a supply chain with ten parties that communicate to each other in a really complex way. With the above scenario, it is evident that it becomes tedious, challenging and close to impossible scenario to manage. So what do the companies do? They hire a third party and channelize all their transactions through it.
The third party or a verification authority is made responsible for almost everything ranging from data integrity to transactional security. So, while all the parties begin to communicate with this verification authority in a bid to resolve a lot of their problems, the very approach invariably introduces a few more.
1. First, it costs a lot of money.
2. Second, all the parties have to ensure that everyone else also trusts the third party. This challenge grows manifolds especially if some of the parties are international.
3. The third and most critical problem with this approach is that the verification party is also, to a certain degree, dependent upon humans to manage their clients transactions. This increases the probability of human induced errors, misconception, improper data handling & fraud.
Imagine what would happen if someone somehow changes some of the data that resides within this verification authority. With perhaps no easy way for any of the parties to realise that the information may have changed, it further escalates into additional problems. Even with the best of software and multiple checks & balances, the reality is that these things do happen and that there are no bullet proof approach to prevent them. The verification authority or party can apply thousands of procedural measures by employing specialized hardware access control, security software and background checking of the personal but it is still not fool proof.
Although traditionally, we have been following similar approaches in our businesses, but we must now realise that there are gaps & hence may not be the ideal approach. It’s time that we make a radical shift towards ‘Smart Contracts’.
Let’s imagine a similar scenario like we discussed earlier, but with a new perspective. We have 3 parties which work together and all of them have setup Hyperledger in their servers. The parties agree on a particular business process and actually create the Smart Contracts which enforces the agreed business process. Each of their Hyperledger is connected to the other parties. Thus, all of them have the access to the same information which is enforced by the Smart Contract.
Say if someone is to alter the data in his Hyperledger, all of the other parties will almost instantly realise this change. Remember that this information is not based on any assumption and that there is a deterministic way to ascertain this.
Let’s assume that some real good hacker is somehow able to update all the data shared between the parties at the same instant. This also will not cause problems because the data will then fail the cryptographic verification. It’s just not possible for any party, internal or external, to sneak through and modify any data. All the companies share the same data which is automatically synchronized in real time. When the process decides to update the ledger, it has to pass through the Smart Contract. In the context of Hyperledger, a Smart Contact is called ‘Chaincode’.
Chaincode is a program that runs on top of the blockchain and implements the business rules of how any application interacts with the ledger. It is triggered when a transaction is proposed and it decides the change of state to be applied to the ledger. The business rules within the Chaincode can permit or deny a transaction or an operation. The business rules can be as simple as ‘before transferring the money, check that the transferor has that amount of money’ or can be complex ones like setting up the rules to allow or disallow a user from any activity or particular organization from any operation, create dependent rules like ‘allow an organization to accept payment if they meet certain criteria’. The business rules can be really creative as the Smart Contracts are written using Google Go or Node.js or Java where one can use any external library, data structure or algorithm.
The need of the hour is to stop for a moment and contemplate on how well Hyperledger can change the way business is conducted between multiple parties with a focus on enforcement of trust between parties that fundamentally don’t trust each other.