It feels like a day doesn’t go by without a mention of blockchain in the news. After the huge rise of Bitcoin in 2017, and tales of people who managed to get-rich-quick off the cryptocurrency bubble, it is hardly surprising to see it so frequently mentioned. But what exactly is a blockchain? And is it useful to you? Let’s take a look.
What is a blockchain?
A blockchain is somewhere where records are stored.
At the simplest level, that’s it.
To give a bit more background, imagine some transaction. For example, you’ve gone to a local coffee shop and bought a drink for £2.40. You’ve given £2.40 to the coffee shop in return for some goods and services. It was a really important transaction, so you want to keep it safe somewhere.
Well, one standard method of storing this data is to store it in a traditional-style database. The database probably has some rules defining what information is required, in what format, and who can review and adjust the data later.
Another way of storing the same data would be using a blockchain. At a mile-high view, it works in a very similar way. It will have some defined rules, instructing us on what information can be stored in each ‘block’ (a place where we can store data), and some extra regulations on how the record might be updated.
From that description the two sound similar, right?
Well, not entirely.
One of the key differences here that I haven’t mentioned so far is that a blockchain has more focus on enforcing that historic data hasn’t been altered, making it tamperproof.
As mentioned above, in a database data can be altered by an administrator (or someone with adequate privileges) quickly and with relative ease. Sometimes this is necessary, or a system might want this ability for some convenience.
A blockchain, conversely, does not allow this. Instead, it runs on a set of ‘nodes’, each of which may be under the control of separate companies or individuals.
The set of nodes are all densely interconnected so that no single company or individual is responsible for control, and removes a central point of failure. These nodes are responsible for generating and signing the transactions in our ‘database’, or more correctly, ‘ledger’, before propagating this transaction to other nodes in the network. The other nodes then each independently verify the transaction’s validity by a handful of defined rules. These most often consist of checks against compliance with the particular blockchain’s rules, digital signatures, and conflicts seen with previous transactions (e.g. you couldn’t have given that £2.40 to the coffee shop, you’d already spent it in the bakery). Assuming you really did spend that money at the coffee shop and everyone can agree that, the transaction propagates forward until it is eventually written in a block on the blockchain, which also needs to be generally approved and confirmed.
It’s a complicated way of ensuring that multiple entities (our nodes) can create something singular (a blockchain) to accurately record history and make sure it isn’t being overwritten. Previously, this would typically be done by a single entity (for example, a bank), but could be costly because our one arbiter is entirely in control, and painful if two parties used different arbiters. Having a pool of nodes to verify transactions avoids this and means we can believe that the records are an accurate reflection of the world.
So why would I ever want to use a traditional database?
The above is an oversimplification to say the least. In reality the two are quite distinct and have very different use cases.
Blockchain has a very specific niche that it caters to, and by employing the use of it when it isn’t absolutely necessary you could be hit by all kinds of issues (the same as any unnecessary technology, really). In the case of Blockchain, it can be slow (transactions take more time to complete than in traditional systems), wasteful (very energy intensive and slow computationally), and huge (nodes eventually will not be able to carry full copies of the blockchain, which can cause issues with consensus).
However, when used correctly, the benefits of a trustless, immutable, distributed and decentralised database can be invaluable.
Not sure where your system fits?
Typically, software that can effectively use blockchain would be where there’s a need for a common database that multiple participants need to write to and there is currently some lack of trust between the involved groups. Your system should also not be reliant on confidential decision making, as the results will end up as public knowledge. Further, there should be a documented need for an objective and immutable history of all records for the involved’s reference.
On the other hand, if your system involves large or confidential data, does not require an immutable history of the world, isn’t cross-party or is not governed by strict static rulesets, blockchain might not be for you.
Need more information?
Black Pepper Software collaborate with you to deliver not just the best software, but the right software. If you need more help understanding the blockchain and your project’s requirements, contact us.