Considerations when using a Blockchain in an Enterprise
In essence, a Blockchain can be used across a consortium of participants to provide a single immutable shared view of the current and past state of any type of asset, whether this asset is a digital, physical, or cryptocurrency asset. All this can be done without the need of a trusted third party.
If you decide to use a Blockchain (more on that later) there are several things to consider. The list below is not meant to be an exhaustive list but highlights some of the more relevant ones, specifically within an enterprise context.
Consortium
A benefit of Blockchain is as a single source of truth that is shared between multiple parties (consortium). To benefit from the immutability aspect of Blockchain, the nodes need to be hosted by a sufficient number of consortium members.
One of the challenges of a consortium is getting agreement on a common data model, smart contracts and any future changes that might be needed. A proper governance model is therefore important. As we all know, it is not always easy to get consensus within consortia’s, especially if it is a large consortium. If, however, there is one member or a few members that have considerable weight within the consortium it typically becomes easier to reach consensus.
For example, a company building products might carry significant weight in a consortium consisting of all its suppliers that are looking at streamlining supply chain management. Not aligning with the wishes of that company might mean not being able to do business for the supplier.
Data Security and Consistency
The quality of the data on a Blockchain depends on what data is being stored. If the data being stored is not consistent with the state it should represent, the value of Blockchain diminishes greatly other than that it highlights the weaknesses in the data gathering process.
For example, if you ship goods and the state of the goods (where they are, who is handling it,…) is not accurate registered in a Blockchain ledger, the value of Blockchain will be low. When you have sensors (e.g. GPS, temperature, …) monitoring your physical assets, you want to be sure that the data recorded by these sensors cannot be tampered with before it is written into the Blockchain. Blockchain itself does not solve these security and consistency aspects.
Data Access
Blockchain represents a single source of truth for a consortium. But that does not mean that all data stored in the Blockchain needs to be accessible to all the consortium members all the time. Consortia’s can change over time as members leave and new members join. So do the relationships between members and thus the data they can and want to share. Policies governing data visibility are therefore important. Sometimes you want to expose certain information without divulging all the information. This is where zero-knowledge proofs can play a role.
For example, a Blockchain could store personal information like age. In order to know if somebody can drink or drive you do not need their age but proof that they are older than a certain age (16,18, or 21).
Data Storage (on or off chain)
Copies of a ledger are stored in the different nodes that are hosted/managed by different consortium members. Storing everything on a Blockchain (on chain) means that the size of Blockchain will grow much faster on all the nodes, and by virtue of Blockchain any data stored on chain cannot be deleted, which could pose a problem if that data is subject to GDPR for example. Instead, you can store some of the meta-data on chain with a reference to the actual data which can be off chain and does not have to be duplicated in every node but is still managed by the Blockchain system.
For example, a Blockchain could store some meta-data of medical images like the hospital the images were taken, the date, and the state of the image. The images themselves which are large in size, together with personal information could be stored off chain and can if needed be deleted, setting the state of the image in the Blockchain to “deleted”. An alternative for sensitive data could be to store it encrypted on a Blockchain but the key to decrypt is stored off chain. Deleting the key (assuming nobody has copies) would render the sensitive data inaccessible. However, this last approach might be legally challenged. The data has not been removed, just encrypted.
Immutability and Trust
Immutability is often touted as one of the strong selling points of Blockchain. You get immutability of data in a Blockchain ledger only under certain conditions: the nodes representing the distributed ledger need to be hosted/managed by a sufficient number of consortium members and you need to assume (trust) that these consortium members will not collude, or that the risk of collision is very low.
Even if you address immutability on a consortium level there could still be other risks. If the consortium uses a Blockchain as a Service hosted/managed by a single provider do you sufficiently trust the provider to run an actual Blockchain in the back-end of the APIs it exposes? If you trust the provider, might that provider not be the trusted third party for your consortium, and do you still need a Blockchain? One way to address the provider trust issue is by managing several nodes within the consortium. But you can even go a step further: can you trust the source code of the Blockchain ledger to warrant immutability and risks?
The immutability and trust risks can be addressed to give sufficient peace of mind but are sometimes glanced over when the immutability aspect of Blockchain is mentioned. The (lack of) trust scenarios described are not unique to Blockchain, but applicable to many applications. In many cases, we tend to implicitly trust the vendors or providers of the software. Vendors and providers from their side have a stake in not violating that trust as this would harm their reputation (brand) and will threaten their revenue.
Business case
Perhaps the most important thing to consider (as with any new technology being introduced): what is the value? What costs are saved by introducing this new technology or what opportunity can it address? How do these saved costs compare to the cost of deploying this technology?
This is not always trivial to calculate. If we look at the shipping container case in the previous post for example. You would need to get an estimation of the overhead of exchanging data. How much can this overhead be reduced by using Blockchain? What other gains will Blockchain bring?
The big question is perhaps should you use a Blockchain? There are several different decision graphs you can find on the Internet that can give some insight in deciding if you really need a Blockchain (below one of these decision graphs)
There are many other considerations that were not discussed in this post. Things like for example the performance of the system (e.g. how many transactions /seconds), interoperability with other systems and Blockchains, consensus protocols, data migration… Some of these are not only relevant for Blockchain. For any new system that you want to deploy in an enterprise, it is important to do a proper due diligence.
* A trusted third party is a company that could host the data that you would share between participants of a consortium and that would not manipulate the data on purpose or by accident (for example: deleting data, altering data, ….)
This is the third post in a three-part series that tries to give, as much as possible, a non-technical introduction on Blockchain. These posts are a cumulation of questions from, and discussions with people, that had various levels of understanding about Blockchain. These posts are not meant to be an exhaustive overview but should help you in getting a grasp on what Blockchain is about.
Website: https://cwinex.io/
