Data On Blockchain
Last week I had a very interesting talk with a Silicon Valley fintech startup. The business process was a 3 party process where the 3rd party needs to reliably verify the actions of the 1st party who is only interacting with the 2nd party. We thought through this scenario and how it can be solved with a blockchain and in the process came up with a 4 to 6 party solution that completely provides transparency among all these parties. The reason I mention 4 to 6 party is that the role of the remaining 3 parties could be done by a single party or outsource it to other specialized players. The important thing is that when there are so many parties involved in a business process, trust becomes important and blockchains designed to store data on them can help such use cases.
As we are working with enterprise application partners, it was clear that they need to visualize beyond a “send tokens” transaction. So, as part of our global testnet rollout we also upgraded our demo block explorer. The block explorer now allows submitting data transactions. While the format can be anything, we are showcasing plain text and JSON formats in our blockchain explorer.
Below is a video showing submitting of tokens but also sending data. The use cases selected are fintech and ITOM CMDB. As a platform our blockchain has a lot of configurable options. The testnet is setup to accept payloads of up to 32KB (but it’s possible to go higher by changing this option for a specific blockchain deployment).
If you are an enterprise IT developer or executive thinking whether blockchain is right for you, there are many reasons you want to use a blockchain. High availability, scalability, reliability, immutability are the main reasons. However, do note that a blockchain data doesn’t replace a traditional relational database or even a NoSQL database which offer much richer data query and reporting capabilities.
A blockchain can be thought of as a decentralized database of key/value pairs where the key is the transaction hash and the value is the transaction payload. When doing 1000 txns per second, it results in about 32 billion transactions per year. So, unless massive infrastructure with high operational cost is involved, it is not possible to support such high volume data patterns. Blockchains can solve this problem but most existing blockchains have problem scaling to such volumes. Not only is the issue with the finality timing but also the way the data is stored and retrieved. 0chain is in the process of designing a specialized block storage that makes use of the blockchain properties to provide a simple yet highly scalable key/value blockchain database. This will be discussed in a future blog post.
While blockchains are not meant for doing regular database tasks like ad-hoc querying, it is possible for a specialized client to read data off of the blockchain and do post processing. We may even look at the possibility of providing pluggable component into our sharder code, the node that stores the blocks, so that the post-processing becomes part of the blockchain itself and suitable for private enterprise blockchain deployments.
