Topics In Demand
Notification
New

No notification found.

Blog
Top Considerations while Implementing Blockchain

July 27, 2020

412

0

If you are seeing technology making a difference in the startup ecosystem, you might have seen a lot of hype around Blockchain. Innovative characteristics of Blockchain- decentralization, immutability, transparency, and automation- can be applied to various industry verticals, thereby creating a multitude of use cases.

Blockchain technology is still in its nascent phase and, while cryptocurrency platforms like Bitcoin and Ethereum have been in use since long, its adoption into the mainstream software industry has been limited. Having worked on Blockchain implementation for startups from various domains, I have tried to list down the top seven considerations while implementing a Blockchain in a product.

On-Chain or Off-Chain

One of the key architectural decisions while working on Blockchain-based products is- which part of the functionality should be implemented on the Blockchain and which is to be considered off-chain (i.e. on the centralized servers), both in terms of the transaction data and business validation logic.

The primary constraint is the network latency due to the data replication across the Blockchain network. The degree of latency keeps increasing with increasing levels of data replication. For the same reason, Ethereum charges a reasonable fee to store data on the chain.

Some general guidelines-

  1. Data that is either directly required for transaction validation or need auditability should be stored on-chain. All other types of data that are referential should be stored off-chain.
  2. In cases wherein eventual consistency is good enough, transactions can be carried out off-Chain, with only the first and last state being updated on-chain. This will increase overall throughput without utilizing additional network resources.

Public or Private Permissioned

Another important decision is the scope/access of the Blockchain itself, ranging between open & permissionless system to a private & controlled one. Public Blockchains are useful, wherein the users are to be kept anonymous and treated equally. Public chains require a community around them to ensure that no one person has the authority to change rules. They need to be community-driven, and a single user cannot change the rules of the entire network. However, a large number of nodes may limit the throughput of the transactions, and some incentivization is required to carry out effective processing.

Permissioned Blockchain platforms, on the other hand, control who can write/read on the Blockchain and are scalable when compared to public chains. They could be suitable where controlled governance is required, and compliance/regulations need to be followed.

An example of a public permissionless chain is Libra, a global payment system by Facebook, which can be used by anyone for value exchange. On the other hand, an Insurance claim processing platform is a good use case to exemplify private permissioned Blockchain. This categorization must be thought in the initial stages itself, as both the categories require different kinds of consensus and identity management solutions.

Levels of Security

Tamper-resistant, resistance to double-spending attacks, and data consistency are some of the desired attributes of a secure distributed system. While the first two can be achieved using cryptographic principles of Blockchain technology, an appropriate consensus mechanism is required to achieve consistency across the system.

In public-facing systems where anyone can join the network, all the nodes are trust-less with no one node having more privilege than others. In these scenarios, security is required against any malicious node, and a Blockchain with POW like the consensus is better suited despite the over-consumption of network resources and limitations in terms of transaction throughput.

In consortium like systems, multiple parties interact and share information. In these systems, although node identities are well known, only some nodes are fully trusted for processing the transactions, and security is required against the semi-trusted nodes or external users not directly participating in the network. A Blockchain, with appropriate governance model and consensuses like PBFT or POS, will not only provide the desired security attributes to the system but also increase the operational efficiency because of high trust levels.

In a document workflow-based application, for example, where documents are exchanged between multiple parties for approval, a system of later type can provide the required security and efficiency.

Data Privacy Needs

Sometimes, data stored or transactions executed on Blockchain need protection on account of confidentiality or compliance rules, and herein privacy comes into the picture. For instance- in the case of financial trades and medical-records based applications, transactions may need to be hidden with data visibility for selected stakeholders. Even in the case of bitcoin wherein transactions are done by anonymous users, transaction trend graphs may provide insights that can reveal the user’s true identity. These users may want to hide the beneficiary or amounts involved in these transactions.

Techniques like transaction mixing and zero-knowledge proof have been proposed to support that. Sometimes, there are variations in real-life situations where these techniques can’t fit directly and require the design of a new protocol using existing techniques.

Physical to Digital World Transition

Physical assets (like a land registry, physical objects, paper contracts, or fiat currency) can be represented into digital assets on the Blockchain and can benefit from decentralization. However, this requires an inherent trust in the system. We would either need a trusted third party providing this guarantee or a physical legal agreement between the parties that cannot be repudiated in the court of law.

In the case of fiat currency based applications, this trusted third party is a bank.  In that case, choosing a bank with good technical infrastructure is essential so that the Blockchain platform can be integrated with the bank easily.

Data Protection (GDPR)

GDPR compliance requires that a user can selectively reveal personal data to others and can exercise his/her right to the erasure of this data. As it is not possible to delete any data from the Blockchain, we should either keep such personal data Off-Chain (in centralized servers) or provide end-to-end encryption of his/her records so that it can be viewed only by that user.

Ease of Development & Deployment

Last but not least, we should have tools that ease out processes of development and deployment. A better smart contract framework means fewer bugs and more trust. A good container orchestration tool like Kubernetes is a must-have for upgrading the product on all the validator nodes.

Conclusion

Before building a real Blockchain-based product, you got to take a close look at the considerations mentioned above that can make or break your efforts. Stripping away all the hype and covering all the teething problems, I believe that blockchain technology is meant to revolutionize industries in a similar fashion of Big Data or any other emerging technology. Happy Blockchaining!


That the contents of third-party articles/blogs published here on the website, and the interpretation of all information in the article/blogs such as data, maps, numbers, opinions etc. displayed in the article/blogs and views or the opinions expressed within the content are solely of the author's; and do not reflect the opinions and beliefs of NASSCOM or its affiliates in any manner. NASSCOM does not take any liability w.r.t. content in any manner and will not be liable in any manner whatsoever for any kind of liability arising out of any act, error or omission. The contents of third-party article/blogs published, are provided solely as convenience; and the presence of these articles/blogs should not, under any circumstances, be considered as an endorsement of the contents by NASSCOM in any manner; and if you chose to access these articles/blogs , you do so at your own risk.


images
Prem Baranwal
Principal Software Engineer

prem-baranwal

© Copyright nasscom. All Rights Reserved.