Building it Better: A Simple Guide to Blockchain Use Cases
According to a recent study by Deloitte, 92% of the 26,000 blockchain-based projects that have been created over the last two years are now dead.
After first hearing of this, I had to ask myself: how did this number get so out of hand?
This article attempts to articulate exactly what caused this issue, aiming to help us passionate blockchain enthusiasts avoid starting a project that becomes a part of the 92%.
Building a Good Blockchain Use Case From the Ground Up
For those who are still unfamiliar on the basics of how blockchains function, I would highly recommend first reading the “Blockchains, Cryptocurrencies & the New Decentralized Economy: Part 1 — A Gentle Introduction” article written by Blockchain at Berkeley’s Ashley Lannquist last year.
For those with familiarity with the subject, we can begin to dive into core capabilities of blockchains that can be applied to create meaningful use cases.
With distributed ledger technology (like blockchain), users are able to create database environments where multiple mutually untrusting users can exchange value or append records without a central coordinator.
By combining concepts from cryptography and game theory, blockchains remove the need for trust in a system, ensuring that users are able to transparently interact with reduced reliance on third party authorities.
This inherent “decentralization” of blockchain systems is important, as it eliminates the negative effects of central points of failure: breaches in security, network downtime, or network outages. Additionally, as long as safety and liveness guarantees are intact, blockchains will rid networks of transaction censorship or malicious action from untrustworthy actors.
These distributed ledger systems have already been successfully implemented in fields like “Finance” or “Dispute Settlement”, where transacting parties historically have needed to trust a central authority to oversee transaction data and ensure that past agreements will be obeyed.
Companies like Hyperledger have created private enterprise blockchains designed to decentralize these transaction ecosystems, supporting the global business transactions of major technological, financial and supply chain companies. It is important to note that these implementations are exceptional — not ordinary — uses of blockchain technology, as evidenced by the fact that 92% of blockchain-based projects have failed to date.
Below is a flowchart that acts as a checklist for those who are looking to implement a blockchain solution, as well as an outline on what steps we should consider before making the jump towards Distributed Ledger Technology (DLT).
Criteria to Consider When Deciding on a Blockchain Use Case
1. Database
First off, when trying to establish a blockchain use case we must ask whether we possess a database that is fundamentally secure at all endpoints.
If we attempt to implement a blockchain on a system that is susceptible to tampering or alteration from the outside world we lose the ability to have things like trustlessness and decentralization in our system, resulting in a relatively limited blockchain use case.
An example of this type of issue can be seen in use cases like “Blood Diamond Tracking,” where companies utilize blockchains to track the flow of legal diamonds along a supply chain from producers to consumers. Although a blockchain may be a good solution for tracking the transactions associated with that diamond, the solution still places a great deal of trust in the employees or nodes that are entering these diamonds into the blockchain system. In this case the “database endpoint” is not secure, leading to trust issues that plague the blockchain use case.
2. Transactors
The next most important question to ask before utilizing a blockchain is whether or not there will be multiple parties coordinating action on our database.
If our database does not require coordination between a large number of stakeholders and can function with the usage of one key “writer” then we should be using a centralized database. Blockchains are, by nature, “Distributed Ledger Technology,” and if there is no need to “distribute” the ownership of the database then we should be using a different databasing structure.
This point, simple as it is, often gets forgotten in the process of constructing a quality blockchain use case. In reality, centralized software like Oracle Database or MySQL has far more robust transaction infrastructures than existing decentralized blockchain systems, meaning that we should only be using DLT if decentralization is absolutely necessary to our project.
A classic example of where centralization tends to make more sense is the use case of existing tech giants like Facebook or Google, who manage Exabytes of user data.
Although it would be nice for Google to be able to decentralize their users transactions, a blockchain use case doesn’t make sense. This is because it is much easier to track information in a centralized system, where all information goes through a single point.
Centralized systems fundamentally are able to have far more cohesive internal integration than decentralized systems, and as a result are far more likely to capitalize on things like economies of scale than DLTs. In fact, Google products like Gmail are only able to have features like “smart spam filters” because Google is able to easily see into almost everyone’s emails.
3. Trust
After determining whether or not centralization is important to your use case, it is crucial to ask who we need to trust in order for this system to operate and what would happen in the outcome where trust is breached.
In any centralized system, malicious action can take shape in a number of forms. Not only can a central authority try to edit existing transactions, but it can also withhold information, report inconsistent transactions across the network, or censor users from accessing specific transactions. If there is any incentive for a central authority to take these actions in our existing system we must at least consider implementing a security measure like blockchain into our use case.
If trust amongst users is not a significant issue, then one can simply utilize a distributed database, in which each user maintains a copy of the database and is free to edit and update the state of the database as they please. This is far easier to implement, as blockchain security features like “Byzantine Fault Tolerance” (resistance to tampering & inconsistency) will not need to be considered.
Special Case: Public vs Permissioned Blockchains
It is also important to note that there are ways to utilize blockchain systems that merge concepts from centralized databases, distributed databases, and distributed ledger technologies.
“Permissioned Blockchains” are one example of this marriage of concepts, combining centralized user authorization with a decentralized blockchain transaction ecosystem.
By having the ability to control the users allowed on the blockchain network, we are able to decrease the likelihood of malicious action and increase control over what the system is trying to manage — creating a system that does not require as much fault tolerance, security, and maintenance as a traditional “Public” blockchain.
The downside of this blockchain structure is that it is far less “trustless” than Public blockchains, as users still have to place trust in the authority granting permissions as well as the consensus mechanism being utilized by the system.
JP Morgan’s Quorum is a great example of a permissioned blockchain use case, as they have created a product that empowers the financial industry with high-speed transactions (dozens to hundreds per second) by taking advantage of the reduced need for BFT that transacting amongst a permissioned set of users allows (see QuorumChain).
4. Disintermediation
Before embarking on a blockchain use case it is additionally important to determine whether disintermediation is necessary to our transaction system.
If our pre-blockchain solution is subject to large middleman fees or confirmation time delays blockchains are a natural fit to expedite this process, cutting down on costs for all users.
If disintermediation is not essential to our transaction system, it is much easier to assign the task of verifying transactions to a middle man or central authority, removing the need for distributed validators on the blockchain network.
A great example of a use case that utilizes disintermediation at the moment is slock.it, who has built a digital business around the concept of creating smart contracts for individualized IOT devices, removing the need for human intervention or adjustment. With slock.it’s technology, any IOT device can have its own identity and can enter into complex agreements (including the agreement to receive payments) — all without using intermediaries.
5. Transaction Dependence
The final question to ask ourselves before implementing a blockchain use case is whether or not our transactions are dependent on one another.
Transaction dependance is a feature that can be seen in all kinds of database systems, particularly in multi-user systems involving numerous parties or systems involving the exchange of assets or goods (like real estate or retail for example).
If our transactions do not need to interact with one another it is much more effective to utilize a “master/slave” database structure, in which one “master” node acts as the champion of validation and approval for a certain subset of transactions which “slave” nodes do the work of carrying out.
If our transactions do rely on one another, determining how to distribute corresponding transactions amongst master nodes becomes quite difficult, resulting in the need for something like a blockchain to alter the collective state of the database.
Blockchains additionally offer atomicity (the ability to prevent partial updates to a database) to its users, ensuring that transactions that are contingent on each other will be executed immediately without the possibility for cancellation or tampering mid-trade. This ensures that no wealth will be created or destroyed as a result of any complicated transaction structures on the system.
Summary
Congratulations, we are now well on our way to building a proper use case! Despite the contrarian tone of this article, there are actually numerous applications of blockchain technologies that can greatly affect existing transaction systems for the better. Before becoming one of these applications, however, it is important to ask ourselves what our use case needs to function before deciding on blockchain as the proper solution.
If we are able to progress our way down the above-pictured flow chart we are well on our way to having a sound blockchain use case, increasing our likelihood of becoming one of the 8% of blockchain projects that will be able to withstand the test of time.
Addendum
In the spirit of the article I thought I would add some of my favourite blockchain use cases below — I encourage everyone to take them as an exercise to think about the factors that make use cases valuable!
i) Gnosis — Decentralized prediction market built on Ethereum platform
ii) Blocknotary — Decentralized Notary service with timestamp verification
iii) Zcash — Open, permissionless cryptocurrency that fully protects the privacy of transactions using zero-knowledge cryptography.
