This post is co-authored with Alistair Pott. The views expressed are our own and do not necessarily represent the views of our employer.
This post explores the benefits and uses — real and perceived — of blockchain and related technologies. It is an attempt to get beyond the hype and cast a skeptical eye on some of the grandiose assertions of impending revolution in every imaginable industry, while remaining optimistic that real applications exist.
We attempt to develop a structured approach for how to evaluate blockchain use cases, explore some of the theoretical benefits of blockchains, and look at where they hold up in applied use. By doing so, we hope to come to a clearer perspective of which use cases we should be focused on and which we should expect to disappear once the current hype bubble pops.
While much blockchain discussion tends towards tribes of true believers and dismissive skeptics unable to engage in dialog, to get practical progress here we need to work from a foundation of informed realism. We’d love to hear your feedback.
A blockchain is a distributed, append-only database (ledger), maintained by a decentralized computing network running software that determines the consensus state of the database. That software may process transactions or run stored procedures (“smart contracts”), and it uses proof-of-work with monetary incentives, or some other similar mechanism, to protect against cheating (e.g. a Sybil attack). This is necessary since any number of unauthenticated participants may participate in the network.
For our purposes, it’s easiest just to think of a blockchain as a decentralized database, where there is no central administrator, but every computer in the network keeps a full copy of the database and processes every transaction.
To break this down a bit, a blockchain is:
- a database that
- is append-only (immutability)
- is readable by all parties involved (transparency)
- is not controlled by any one party (decentralization)
Note that other technologies have some of the same attributes. For example, we can build databases that are publicly readable or verifiably append-only. We can run procedures and store the results in databases. We have decentralized networks. And we have consensus mechanisms for systems with a known set of participants. We even have systems like Trillian that provide append-only, transparent, decentralized data storage for a known set of participants far more efficiently than blockchain (and we believe these are severely underappreciated and probably what 9 out of 10 people really need when they think they need a blockchain).
The primary blockchain differentiator is that it allows for fully decentralized databases — ones with arbitrary numbers of unknown participants.
Why is decentralization an interesting property? Because centralized systems have certain risks owing to their dependence on a central authority that could:
- Cheat: tamper with data, block access, change the rules, shut down completely, etc.
- Be forced to cheat: do the above due to pressure from a regulator or other entity
- Extract rent: scales to monopoly size and charge unreasonably high fees
Blockchains promise to mitigate these risks by removing the single central authority and decentralizing the network to some degree:
- A small number of known parties (even two companies)
- A large number of known parties (e.g. Certificate Transparency contemplates 10–1000)
- An unbounded number of known & unknown parties (e.g. the Bitcoin network)
The larger the number of participants, the less risk of triggering the risks cited above. Of course, other factors mitigate centralization risk as well, including more independent parties, more diversity among parties, better security, and easier detection and recovery from system compromise. But in terms of number of participants, the unbounded case — what we’ll call “full decentralization” — is what blockchain was invented to solve.
Of course, no level of decentralization comes for free, and in particular there are some significant disadvantages to full decentralization via blockchain, including:
- Massive scaling problems (transaction throughput)
- Data storage limitations (all data stored permanently, by every node)
- Painful development (all code is published to the blockchain permanently)
- Challenging privacy issues (these are public ledgers after all)
- No authority to appeal to when support is needed
The point is that decentralization needs to be worth the effort. For the sake of argument, let’s assume that these disadvantages are mitigated — and also that high quality user experiences can be delivered, which is unproven. Even so, blockchains are only useful when full decentralization is a critical feature. While there is a strong tendency in the blockchain community toward seeking decentralization in all cases, we think that this obsession is problematic. Instead, system designers and participants should be clear about the risks and mitigations of centralization in their system, and the costs and benefits of full decentralization.
Perceived benefits of decentralization
So what are the purported benefits of decentralization, and how do they hold up in practice? We’ll examine several of them generally, and then look at their application in practice in various examples.
The transfer of ownership of digital assets, or execution of stored procedures, can’t be stopped in a massively distributed, global network with no central choke points. However, censorship can still occur at the edges: exchanging digital goods for physical goods or services in the real world. We suspect the degree to which blockchain = uncensorable is overestimated, because real world uses can often still be censored. For example, while it’s hard to confiscate Bitcoin, a corrupt government may prevent it from being exchanged for fiat efficiently or used to purchase goods or services.
Still, decentralized systems are likely harder to censor than centralized systems, and the harder it is to find choke points, the harder to censor. Bitcoin is still harder to confiscate than gold or dollars in my bank account, and I can always access it if I’m able to leave the country.
It’s not clear how many use cases critically depend on censorship resistance (now or later) and can achieve that through full decentralization, but a blockchain is likely a good option in such cases.
Efficiency and automation
There is a hope that blockchains will let us take something that humans do today (e.g. execute legal contracts or business rules) and move it into algorithms, thereby reducing complexity, delays, and fees. These are often viewed as inefficiencies in the current systems. For example, bank transfers take multiple business days and can cost money, but if we just used a blockchain, they could be free and instant. If we could formalize contracts into algorithms, we could have unbreakable, self-executing contracts.
We think these opportunities are significantly overblown, for multiple reasons:
- It is generally underestimated how much the perceived inefficiencies are there by design, either for value-added services or regulations, and would eventually be added to a future blockchain implementation
- We ought not confuse the benefits of modernization/digitization of industries with the need for decentralization. Sure, lots of banks and other institutions use archaic processes, but they could upgrade to much more efficient processes without moving to a decentralized model.
- Decentralized databases are generally less efficient than centralized ones, except in cases where they counter the risk of significant rent extraction
In short, the world is full of inefficiencies, but decentralization should only be applied where it is actually necessary.
Sometimes it can be difficult to drive adoption of a centrally-controlled system, since parties wary of centralization risks may refuse to participate. While established rules, audit processes, and neutral third parties are often sufficient to create system trust and unlock adoption, in some cases the further step of introducing decentralization may be necessary.
We believe that this is a promising benefit of blockchains, although in many cases the full decentralization that calls for a blockchain is not required. Distributing the system across multiple parties, allowing for data transparency and auditability, and providing mechanisms to recover from badly behaving parties often will be enough to unlock adoption.
Incentives for participation
Another angle on system adoption is the oft-touted benefit of the built-in incentive model. In these systems, payments are executed with tokens and early adopters purchase those tokens at low prices. The idea is that as the system gains traction increased demand for those tokens will increase their value. Thus early adopters are incentivized to take part and to evangelize systems.
While there is potential for low friction digital payments to ease system adoption, we believe this should generally be built on a common token used as a store of value (BTC or ETH), rather than creating one-off tokens for each application.
We also believe the central assumption that the tokens will increase in value as application usage takes off is flawed. Tokens will only increase in value if people are incentivized to actually hold the tokens — otherwise you run into the velocity problem, where the same tokens are just spent repeatedly. For a more complete analysis, see An (Institutional) Investor’s Take on Cryptoassets.
Innovation and openness
Chris Dixon argues that centralization stifles competition and innovation: “Over time, the best entrepreneurs, developers, and investors have become wary of building on top of centralized platforms. We now have decades of evidence that doing so will end in disappointment.” (This evidence is not presented, and we believe there is plenty of evidence on the other side of the ledger.)
While we believe in the power of open platforms, open vs closed is not centralized vs decentralized, and we don’t see any evidence that decentralization specifically should produce more innovation, let alone the innovation that people want — except to the extent that openness is a nice side effect of decentralization. Decentralized systems must be open, and that may have some nice consequences. But it is openness and not decentralization that is useful.
How to evaluate potential blockchain use cases
So how do we evaluate when we need a decentralized database, or specifically a blockchain?
Decentralized databases are useful where we need to track a global state and centralized ways of doing that are problematic. There are two main factors that drive the need for decentralization:
- Censorship resistance — making it harder to stop the system
- System adoption — getting others to adopt a system
Whichever factors are at play, one should implement only the minimum level of decentralization required to meet those needs, because decentralization itself is expensive. For example, a fully decentralized system is probably necessary for censorship resistance but may be overkill for generating adoption. When a fully decentralized system is needed, a blockchain is the only known solution.
We suggest the following checklist for evaluating suggested use cases:
- Does the system require tracking a global state?
- Is decentralization being used for censorship resistance or system adoption, and does it makes a meaningful difference on those fronts?
- Is the minimum necessary level of decentralization being implemented?
Blockchain use cases
We can now apply this reasoning to some use cases where blockchains have been proposed. You can’t throw a stone these days without hitting someone with an “X on Blockchain” pitch: Kitties on Blockchain. Band names on Blockchain. Burger King loyalty program on Blockchain. We can’t possibly evaluate all proposed use cases, but let’s take a look at a few common ones.
Note that we aren’t experts in most of these fields, nor have we gone super deep on them. We include them primarily as examples of applying the evaluation framework above.
Money and other digital assets
Blockchains were invented specifically to solve for the problem of centralization in payments and digital value. Specifically, it wasn’t possible to achieve global trust without a fully decentralized database, and censorship by regulators and governments is common. Blockchains are an excellent technical tool for this application, though the right balance between scaling and full decentralization remains an open question.
Many blockchain-based identity solutions have been proposed. We see identity as an area where censorship resistance is critical and system adoption on a global scale is only possible in a fully decentralized system. That said, it’s not clear publishing global state is, in fact necessary, so whether blockchains have a role to play here is an open question.
It’s easy to imagine better credit systems — global, more secure, more complete, smarter, better privacy, etc. Many of these are achievable through modernizing the infrastructure, with or without a blockchain. However, credit systems would still benefit from greater decentralization. Censorship is a real risk in many countries, and global system adoption would likely require decentralization. Nevertheless, we think it’s unlikely that this case requires a fully decentralized database (i.e. a blockchain), since transparency, auditability, security, and privacy are achievable without a fully decentralized system (imagine a Certificate Transparency-like solution).
There is some excitement about building a DNS system on a decentralized database. The risks seem somewhat lower than those related to payments, but the solution would have some elegance by removing centralization risks and thereby driving adoption. However, given an existing system that has successfully achieved universal adoption and does not have significant censorship issues, we have to question the purpose.
Land title registries
Land titles are extremely important, and there is risk that corrupt governments (or others who can compromise data stores) will tamper with data. A decentralized database could avoid dependence on a corrupt government for ownership status. However, enforcement happens in the physical world, and if the enforcer (the government) doesn’t recognize your decentralized database, you haven’t achieved anything meaningful.
While you may want to store very important information in the cloud, there is not much risk of cheating in file storage, and rent extraction is difficult because the service is mostly commoditized. In general, centralized services work amazingly well. File storage is almost free, extremely fast, and robust. Censorship is not much of an issue, especially with storage systems available from many different countries. In addition there are already various p2p storage protocols (e.g. distributed hash tables as used in bittorrent) that offer censorship resistance without requiring blockchain based consensus.
Supply chain management
IBM is running ads talking about tomatoes “you can track from farm to pot.” There is a lot of cheating in supply chains (e.g. double selling inventory), so a decentralized database, especially one that is good at tracking provenance, feels like a good solution to that problem. But in all these cases, we think the participants could much more efficiently just agree on a central database to track information. For example, everyone writes transactions to a ledger on a cloud platform (probably from the same provider that would supply their blockchain solution!), which is made auditable and transparent, so everyone can be sure there’s no cheating going on. It is rare that there really is no way of agreeing on a central database.
It might be useful to write checkpoints to a decentralized database — digital proof that something was true as of a specific time. Since nobody controls that database and it is append-only, those checkpoints are therefore highly trustworthy. In such cases, it is specifically not possible to trust the claiming authority. A fully decentralized database is probably useful for this. But a lesser level of decentralization (say, a global network of 100 fully independent nodes) may be sufficient.
Accounting benefits from immutability, auditability, and some level of transparency. All of these can be achieved through centralized solutions, e.g. Trillian. There is no need for decentralization — least of all full decentralization with blockchain.
Decentralized autonomous organizations are all the rage among blockchain fanatics, but we believe this is based on the flawed efficiency assumptions discussed above. Organizations are social constructs and cannot be encoded into algorithms.
Blockchains are a fascinating new technology. They enable fully decentralized databases, resistant to censorship and potentially allowing for system adoption in critical applications like money and identity. We recommend using these attributes as the key criteria to use when evaluating blockchain use cases.
While there are important use cases that are useful applications of the technology, many blockchain applications are based on overhyped benefits or a misunderstanding of the degree of decentralization required. We believe that less decentralized (and less expensive) approaches to driving system adoption are underemphasized in the ecosystem today.
For further exploration of these alternatives, see our follow-up piece, Blockchain Alternatives.