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 the cost. The rest of the application needs to be architected to address the below questions.
Critical Questions
1. Data Privacy — What data to store on 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 shall 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. Blockchain — Which blockchain to build an application on?
The performance of software directly depends on the performance of its dependencies and their host environments. The 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 below areas and their varied implementations.
a) Consensus
A blockchain relies on the distributed consensus of the participant nodes. The PoW (Proof of Work) consensus takes more time to achieve a consensus across the system based on the finality gadget watermark compare to any PoS (Proof of Stake) systems. Similarly, other variant consensus algorithms impact transaction confirmation time which the application needs to deal with without sacrificing the response time.
b) Smart contract
Public blockchain smarts contract methods are open and can be invoked by any good or bad users, thus, 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 long process of security audit with an external organization.
c) 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.
d) 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, but difficult to manage (especially maintenance and upgrades) and is not cost-effective. If you choose a 3rd party service, it introduces an additional dependency with its inner workings of their delivering transactions to the blockchain, transaction pool management, retrying strategies, and resetting policies.
e) 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 and using it for storage refunds is a good thing to consider.
e) Tools and support
Last but not least is to consider 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 and work with. Some of these issues can be addressed, however, the application still needs to deal with the challenges coming from blockchain intricacies.
1) Experiencing more transactions than the blockchain can handle
Many applications produce tons of microtransactions these days to record every little detail. The blockchains are yet to achieve scalability at this scale, however, it shouldn’t stop one 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.
2) Failure to execute a transaction
A blockchain may fail to pick up a transaction submitted by the application, either this could be an issue with the transaction itself or related to decentralized network issues i.e., reorganization of the chain in blockchain, hard forks, transaction pool failure, etc. The application shall retry in all cases by remembering what has been committed to the blockchain and did not go through. In case of failure resulted from the lower gas price, the application shall re-submit the transaction with a higher gas price, otherwise, retry. This is essential to synchronize the blockchain state and the application’s internal state.
3) 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.
4) Inconsistency between blockchain and internal application state
If an application is built around blockchain tokenomics, the non-blockchain part of the application shall remember the state of the system which has not been confirmed or committed to the blockchain yet.
These pending transactions can be accounted for in the calculation when the 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 is to implement overdraft protection of the balance in the application and allowing to execute transactions when they have balances to a certain extent. The second approach is implementing 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 brace with new challenges and unanswered questions to solve at this scale, however, following this guideline will set steps 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 in another article.
