In an industry that thrives on hyping buzzwords, blockchain has been one of the biggest, most hyped buzzwords of them all. Despite this amount of hype, few killer blockchain applications (outside of cryptocurrency) have emerged. Perhaps, this is because few people have a deep enough understanding of what blockchain is to dream about the problems it could solve for them? In that case, hopefully this article, which attempts to explain blockchains to a non-technical audience, will spur on discussion about solid applications built upon blockchains.
(Please note – this discussion will gloss over implementation details in favour of big picture design considerations. It is not intended to serve as a quote, or a guide to technical complexity – just a high level primer into what the technology is capable of.)
At its core, a blockchain is a set of interlocking transaction ledgers. A transaction ledger is ultimately a list of transactions. In a blockchain, these lists of transactions are recorded in blocks, then when a block is written to the blockchain, it is linked to the block that came before it. Therefore, a blockchain is a chain of blocks. Each block is filled with transactions. Once written, transactions are immutable, meaning that they can’t be changed. If you make a mistake, you can reverse the entry, but you cannot simply delete it. On its own, that wouldn’t be that revolutionary, but blockchain adds one more special trait. Blockchains are fully decentralized, meaning that each ‘node’ that works with the blockchain gets a full copy of the blockchain. If any one node is damaged, the rest have full, working copies of the blockchain, such that little to no data is ever lost and business can carry on as usual.
Ultimately, a blockchain is a decentralized way to store transactions. Since it is decentralized, any party with access can choose to audit transactions at any point – they can follow the flow of goods, either financial, digital or real and close to real time. The downside to this is that whenever a party wants to work with the blockchain, even in the most simple ways, they usually have to download the entire blockchain first.
Now we have a working definition for a blockchain. A blockchain is an immutable ledger in which transactions are stored in blocks, then each subsequent block is linked to the block immediately preceding it. Or, in other words, a blockchain is a ledger in which records can never be deleted or overwritten. Transactions are stored in blocks and when you write a new block, it is linked to the previous block. That definition illuminates blockchain’s biggest strength. Because all transactions are stored in blocks and each block is joined to the block before, a blockchain contains a record of every single transaction to ever take place in a system. This means that is is strongly auditable – every party can audit every single transaction in a blockchain. Ultimately, a blockchain is a way to guarantee trust – if every single transaction is shown, every single party can audit and verify that the others’ claims are true.
With that definition in mind, what kinds of things are blockchains good for? To figure out if your idea would be a good application for blockchain, go through this thought exercise.
1. Does your application require a shared, consistent place to store data?
This is the critical blockchain question. Do you need to store and share data? Do you need to be able to guarantee its consistency?
This question is critical because at their core, blockchains provide distributed storage. If you don’t need to store and share data while guaranteeing historical consistency, there is no reason to use a blockchain. Instead, there are far cheaper ways to provide similar function!
2. Do many people/groups/organizations need to contribute data to the data store?
This question (and #3) will help you figure out whether you even need a highly auditable system. This question asks about how many separate entities would contribute date to your system. If multiple entities contribute data, it is useful if every transaction can be audited. On the other hand, if only one entity is contributing data, you likely won’t
3. Can the entities that need to contribute data agree on who should be in control of it?
This question illuminates a dangerous part of blockchain, that often dooms blockchain projects. Because blockchains are so auditable, they work best in situations where the stakeholders have lots of trust and control issues between them. They throw blockchain at a data siloing problem without realizing that technology can’t solve an issue where people just don’t want to share.
Those sorts of territorial issues aside, blockchain shines when the entities who write data don’t particularly trust each other. Blockchain is strongly auditable, so each party can verify the other’s claims and audit their transactions.
4. Do you often need to delete data?
If you often delete data, you should avoid a blockchain. Blockchains are immutable, which means that once you write data to a blockchain, that data can never be deleted or changed. You can do a reversing entry, but you cannot delete the offending record. In some cases, for example, where you need a strong audit trail, this is highly desirable. In other cases, it can be extremely inconvenient and can result in storing large amounts of useless, housekeeping data.
5. Do you need a trustworthy log of all the transactions that go into the data store?
A blockchain is a distributed ledger. In other words, it is a trustworthy log of all the transactions that go into a data store! If you don’t need this level of detail, a blockchain will only get in your way.
Hopefully, these questions have given you a chance to evaluate what sorts of applications would work well if paired with a blockchain. And hopefully, they’ve helped give you a broader sense of what a blockchain is, and what it can do. In general, I argue that an application is a good fit for blockchain if it fits the following four criteria:
1. Many entities (who don’t have much trust in each other) all want to contribute and use aggregate data.
2. This data should be retained indefinitely – it will never be deleted.
3. This data must include a log of all transactions.
4. It solves a lucrative problem significantly better than non-blockchain alternatives.
The first three will be familiar, but the fourth one is brand new. However, it’s important to understand that, at this point, blockchain apps are more expensive. Good blockchain developers are relatively rare and can command premium rates. Tooling is not very advanced, so development can be slow and costly. And when you add in often inconsistent documentation and a tendency for troubleshooting to end off in an IRC channel, you end up with an often frustrating development cycle. These problems are not insurmountable, but most of all, they need either enthusiast effort, or a considerable appetite for expense.
Blockchains may not be the future of everything, as the media once seemed to predict, but they are definitey interesting for certain applications, particularly in financial fields where audit is important, and in legal fields, where dates and ownership are important. It’s important to understand the exact capabilities and drawbacks of blockchain before committing resources to developing an application in it.
Most importantly though, be aware that blockchains cannot solve all of your problems. It is a solution to a very narrow set of problems. And, within that narrow set of problems lies considerable room for interpersonal problems. Blockchain doesn’t work if people won’t share.