7 Decisions That Can Make or Break a Blockchain Implementation

There is considerable interest around blockchain these days and for good reason. The innovative characteristics of blockchain-like decentralization, immutability, transparency and automation are extremely useful for many industry verticals and will inspire the creation of a multitude of use cases. However, blockchain technology is still in its nascent phase. While cryptocurrency platforms like Bitcoin and Ethereum are gaining popularity, the adoption of blockchain into the mainstream software industry is still somewhat limited. But an increasing number of technology companies are making the decision to leverage the unique value of blockchain in their products.

I have worked on blockchain implementations for companies in many domains. If you are considering using blockchain, I've found there are seven key decisions necessary to successfully implement a blockchain in a product.

1. On-Chain or Off-Chain

One of the key architectural decisions while working on blockchain-based products is to understand where to go off-chain and where to go on-chain. This is an essential consideration when transaction data and business validation logic play a crucial role. The primary constraint is the network latency due to the data replication across the blockchain network. The degree of latency keeps increasing when the levels of data replication expand. To determine whether to on or off-blockchain, here are some general guidelines:

• Data that is either directly required for transaction validation or needs auditability should be stored on-chain. It is better to store referential data off-chain.

• If eventual consistency is good, it is possible to develop transactions off-chain and update only the first and last state 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 from an open and permissionless system to a private and controlled one. Public Blockchains are useful where the users are anonymous and 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. It is better to have some incentivization to carry out effective processing.

Permissioned Blockchain platforms control who can write/read on the blockchain. If you compare them with public chains, they are scalable. Permissioned Blockchains are suitable when controlled governance and compliance/regulations are important. Popular examples of a public permissionless chain are Ethereum, Bitcoin. An Insurance claim processing platform is a good use case to exemplify private permissioned blockchain.

3. Levels of Security

Tamper-resistance, resistance to double-spending attacks, and data consistency are some essential attributes of a secure distributed system. We can achieve the first two using cryptographic principles of blockchain technology. For consistency across the system, we need an appropriate consensus mechanism.

In public-facing systems where anyone can join the network, all the nodes are trust-less, with no node having more privilege than others. For such scenarios, the system should be Byzantine Fault Tolerant that can handle malicious node behavior. The blockchain with Proof of Work (POW) is better despite the over-consumption of network resources and limitations in 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 an appropriate governance model and consensuses like Practical Byzantine Fault Tolerance (PBFT) or Proof-of-stake (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 where documents are exchanged between multiple parties for approval, a system of later type can provide the required security and efficiency.

4. Data Privacy Needs

Sometimes data stored or transactions executed on the 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, transaction trend graphs may 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 in these types of situations. Although at times there are variations in real-world situations where these techniques can't fit directly and require the design of a new protocol using existing techniques.

5. Physical to Digital World Transition

Physical assets (i.e. land registry, paper contracts, or fiat currency) can be turned into digital assets on the blockchain. Leveraging from the decentralization of these documents will then become easier. However, this requires an inherent trust in the system. Therefore it is necessary to have 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. But choosing a bank with good technical infrastructure is essential to ensure easy Blockchain integration.

6. Data Protection (GDPR)

General Data Protection Regulation (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.

7. Ease of Development and Deployment

Last but not least, it is important to have tools that ease the 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.

In Conclusion

Before building a blockchain-based product, take a close look at the considerations mentioned above, which can make or break your efforts. Barring the hype and all the teething problems, blockchain technology has the potential to revolutionize many industries.

Author:

Pankaj Mendki is the Head of Emerging Technology at Talentica Software. Pankaj is an IIT Bombay alumnus and a researcher who explores and fast-tracks the adoption of evolving technologies for early and growth-stage startups. He has published and presented several research papers on blockchain, edge computing, and IoT in several IEEE and ACM conferences.