{{announcement.body}}
{{announcement.title}}

Two Critical Questions for your Enterprise Blockchain Application

DZone 's Guide to

Two Critical Questions for your Enterprise Blockchain Application

In this article, we discuss critical questions (related to data privacy and blockchain type) architects need to consider before using blockchain.

· Security Zone ·
Free Resource

question-mark-graffiti

Introduction

A public blockchain orchestrates a trust layer by providing transparency, integrity, traceability, and authenticity of data. It records all transactional activities in the world state. These unique properties attract many to develop applications that record transparent activities among the stakeholders, ownership details to provide traceability to the origin, timestamps for the digital content to prove the existence, and more. Matt Spoke, the CEO of Aion Foundation, has highlighted why a public blockchain is a good way forward.

Though blockchain storage is open and accessible, it incurs a cost for every write-operations executed in this world state. Thus, it’s imperative to host only an essential portion of the application on the blockchain to minimize cost. The rest of the application needs to be built to address the following questions.

You may also like:  How Blockchain Could Contain Customer Data Breaches.

Critical Questions

1. Data Privacy  —  What Data to Store in a Blockchain

Any data going on a public chain are open, accessible, and irrevocable. Thus, public blockchain is not GDPR (and CCPA from next year) compliant, unless the data has been encoded with quantum-resistant algorithms and stored.

Personally Identifiable Information (PII) or sensitive data compromising user privacy should not be stored on a blockchain. However, blockchain still needs account aka wallet addresses to individually link them with their real users (can be pseudo-anonymous on the blockchain).

2. Which Blockchain to Build an Application on

The performance of software directly depends on the performance of its dependencies and their host environments. Blockchain brings a new paradigm of decentralization architecture, where every node on the chain constantly updates its states to maintain the world state. In addition to that, a blockchain application also needs to deal with the following issues and their varied implementations.

Consensus

A blockchain relies on the distributed consensus of participant nodes. The PoW (Proof of Work) consensus takes more time to achieve a consensus across the system based on the finality gadget watermark compared to any PoS (Proof of Stake) system. Similarly, other variant consensus algorithms impact transaction confirmation time, which the application needs to deal with without sacrificing response time.

Smart Contract

Public blockchain smarts contract methods are open and can be invoked by any good or bad user. As a result, smart contracts need to ensure the non-corruptibility of their data and protect against the misuse of their business logic. Developing a secure and efficient smart contract requires high skill-sets and a lot of effort for pen-testing. Moreover, based on the complexity and monitory impact of such a smart contract, it needs to go through a security audit with an external organization.

Block Time and Number of Transactions

Block production time and a maximum number of transactions that can be incorporated in a block decide the throughput of the system. The application can theoretically generate these many transactions, but those transactions still need to complete with the other applications on the chain. For example, Ethereum currently processes 15 transactions per second.

Accessing the Blockchain

Though blockchains are open and consumable, a reliable connection is required to communicate with it using a full node or options like 3rd party (e.g., Infura, Blockdaemon, Nodesmith, etc.). A full node guarantees an up to date blockchain state. However, it is difficult to manage (especially in relation to maintenance and upgrades) and is not cost-effective.

If you choose a third-party service, it introduces an additional dependency with its inner workings of delivering transactions to the blockchain, transaction pool management, retrying strategies, and resetting policies.

Gas Cost and Price

The gas cost associated to execute a transaction on blockchain fluctuates based on the demand and supply of the network. The underlying network cryptocurrency price also influences it. Based on application usage patterns, it’s wise to estimate the budget gas cost to run the system for the next three to five years. Purchasing gas in advanced when the prices are lower will help lower costs; using it for storage refunds is a good thing to consider.

Tools and Support

Last but not least to consider is the tooling support for the blockchain ecosystem, as it plays a crucial role while developing, deploying, debugging, and monitoring smart contracts. Getting technical support in the time of need makes a lot more difference.

Dealing With Blockchain Intricacies

Murphy’s law is nullified in the ideal world, but in reality, things go wrong, and we need to plan for potential worst-case scenarios. Some of these issues can be addressed, however, the application still needs to deal with the challenges coming from blockchain intricacies.

More Transactions Than the Blockchain Can Handle

Many applications produce tons of microtransactions these days to record every little detail. Blockchains have yet to achieve scalability at this level, however, it shouldn’t stop one from building applications on top of it. This can be addressed using aggregating transactions (if it’s possible logically) and making fewer transaction commits on the blockchain.

The other option to high throughput is to use a sidechain network if available. This ensures the public blockchain benefits are still available to the application while offloading some of the work to the sidechain.

Failure to Execute a Transaction

A blockchain may fail to pick up a transaction submitted by the application. This could either be an issue with the transaction itself, or it could be related to decentralized network issues (i.e., reorganization of the chain in blockchain, hard forks, transaction pool failure, etc.). The application will retry in all cases by remembering what has been committed to the blockchain and did not go through.

In case the failure resulted from the lower gas price, the application will re-submit the transaction with a higher gas price. Otherwise, it will retry. This is essential to synchronize the blockchain's state and the application’s internal state.

Congestion on the Network

The application shall have a provision for reacting and adapting to the congestion in the network. If increasing gas prices do not work, the application shall retry periodically or exponentially.

The good thing about network congestion is that it may not be immediately possible to commit transactions to the network by other means. This will reduce the risk of a double spend. The application can continue functioning using its internal state and commit the transactions later at a higher gas price on availability.

Inconsistency Between Blockchain and Internal Application State

If an application is built around blockchain tokenomics, the non-blockchain part of the application will remember the state of the system, which has not been confirmed or committed to the blockchain yet.

These pending transactions can be accounted for when users access the application. However, if they directly access the blockchain explorer, the balances or state could be off. If users are smart and have access to their private keys, they can send transactions directly to the blockchain outside of the application and deplete the balances or change the state.

One way to address this is to implement overdraft protection of the balance in the application and allow to execute transactions when they have balances to a certain extent. The second approach is to implement a house account for the application to perform state changes on behalf of users.

To conclude, building enterprise blockchain applications that have millions of users and transactions may not fit into regular software architecture. Therefore, architects need to prepare for new challenges and unanswered questions to solve at this scale; following this guide will set you up in the right direction.

An important aspect that has not been covered here is managing keys that are used to execute transactions on the blockchain. We shall dive deep into this topic in another article.


Further Reading

Topics:
blockchain ,smart contract ,software architecture ,dapp ,dapp developers ,security

Published at DZone with permission of Rakesh Gohel . See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}