To recap, we have so far discussed the three key concepts of the Blockchain which are decentralization, consensus and trustless. Which in my humble opinion is what made the Blockchain technology so exciting to geeks the world over.
But at its core, the Blockchain is just another database. When talking about storing and processing data, there is nothing that the Blockchain can do that any other conventional database cannot do (MySQL, MSSQL, No SQL or what not).
Let's look at the core applications of the Blockchain today: Cryptocurrency and Smart Contracts. We discussed about how Bitcoin removes the need for a middle man to approve financial and trading transactions, and that in the Ethereum Virtual Machine architecture, the smart contract exists within the Blockchain itself without the need to deploy any additional servers.
Purpose built for a specific reason and usage.
So do you think that you should be scrambling to replace your projects and move their data architecture on the Blockchain just for the sake of saying that you are running on a (perceived to be) trendy architecture?
I think not good sir!
There are a few considerations that you should ask yourself before thinking about rebuilding your data architecture into the Blockchain.
What is the value of the data?
Are you involved in a high value asset transaction? Do you need to ensure an asset transfer is verifiable and traceable?
An example of a high value asset implementation of the Blockchain would be an experiment done by the Swedish Lantmäteriet (land registration office) to move the whole land ownership, sale and transfer process into the Blockchain and facilitate the process of ownership and transfer through use of Smart Contracts. You can read more about their research HERE.
By moving the land ownership process into the Blockchain, they are trying to address several issues that have been persistent in their current environment:
- Authenticity of the original source - too many cases we have heard of land titles being forged, duplicated, lost and stolen with no way to know and verify the true ownership of the land. Moving ownership information and transfer history into the Blockchain would be a process of registering a set of data as an on-chain asset and linking to the physical land titles as an off-chain asset. This would ensure that the off-chain and on-chain relationship would secure the process in its entirety within the Blockchain architecture
- Improvement of ownership and transfer process - a land transfer involves multiple different parties including the buyer, the seller, a bunch of lawyers, government officers, document runners and the list goes on. Placing ownership and transfer verification on a smart contract with clearly defined entities to verify and co-sign the transaction would eliminate redundancy and speed up the entire process
- Saving the taxpayer money - a projected savings of over 100 million EURO a year by eliminating paperwork, reducing mistakes, fraud and increasing speed of transactions
So if your data has no apparent value to anyone but yourself... better stick to SQL.
Is there a need for automation and regulation?
Smart contract facilitates the autonomous execution and self-regulation of an asset ownership or transfer.
An example of implementing smart contracts to execute or regulate a process would be in a study conducted by Deloitte's Center for Health Solutions and Financial Services. They were focusing on applying the Blockchain into a term life insurance product recorded in a smart contract.
Insurance is a logical fit for self-executing smart contracts since the conditions that do or do not lead to a payout can be clearly defined in the insurance policy. You can read more about their research HERE.
Imagine a day when you don't have to wait for your insurance claim when visiting your physician or waylaid by a series of unfortunate events. Your claim automatically gets deposited into your account. Visits from your friendly neighbourhood adjuster will be a thing of the past.
So if you are not really transacting anything of real value, and there is not any need for self-execution and self-regulation... better stick to SQL.
And lastly,
Is it feasible for you to deploy a network large enough to secure your transactions and data?
So how many nodes are enough?
Backtrack a little.... A node is generally referred to as a Blockchain client that has a copy of the full block, performs validations and shares the transaction load across the network.
I am not entirely sure of how to answer this question. I'm definitely not smart enough to formulate a calculation and proof to you that mathematically it should be x amount of nodes, distributed across y amount of area.
However there is the looming 51% threat... By definition: "51% attack refers to an attack on a Blockchain – usually Bitcoin's, for which such an attack is still hypothetical – by a group of miners controlling more than 50% of the network's mining hashrate, or computing power. "
So hypothetically speaking, owning 51% of the Bitcoin network would technically cost you USD 50 billion (at the currency market cap) to execute... Hmmmm, not feeling it.
But logically the amount of nodes that you deploy should be able to uphold the principles of a Blockchain network. Consensus, decentralized and trustless. If you deploy two, or even ten nodes and if it would take a hacker five minutes to take over half of the nodes, then your Blockchain would be rendered useless and your client accounts taken over... better to stick to SQL.
Either work on an established network, like Etherium or Bitcoin itself; or deploy your network in a closed private cloud. You should also develop your own applications and processes to empower entities within your network to deploy their own nodes and clients to facilitate your network growth. If you think your network would never need to grow beyond 20 nodes... better stick to SQL.
But that does not mean that a small Blockchain network should never be deployed, or you should never dream of deploying your own potentially yuge Blockchain project. Just approach your project with eyes wide open and consider all possibilities.
I will leave you with a bit more reading ->
No comments:
Post a Comment