What is Blockchain’s place in solving Real-World problems?
This article is the first in a series presented as a discussion of applied blockchain technology. The following is an overview of both blockchain as a general tool and its fit within application development. Stay tuned for follow-up discussions of specific problem domains and their applicability for blockchain solutions.
Blockchain apps have taken off in the public eye. Cryptocurrencies currently reign king, and for most, these are the only known application of blockchains, and are often considered one and the same. Despite this, some new categories of blockchain applications are beginning to gain traction beyond blockchain enthusiasts, most notably with the rise of Cryptokitties. With this traction has come a fair amount of hype, as well as plenty of examples of what could be considered blockchain for blockchain’s sake.
Because blockchain technology is still not widely understood, it can be difficult to distinguish the valuable use cases of blockchains from the questionable ones. To address this problem, this article will attempt to lay out a simple mental model for understanding the fit for real-world applications and blockchain technology.
But before evaluating that fit, it’s important to first understand who actually stands to benefit from the introduction of blockchain to a product.
Only the Developer Cares if it’s “Blockchain”
Ignore the technophiles for a moment. Most real-world users of applications at the end of the day are only interested in what an application does and does not do.
Blockchain, then, is only important in the way it helps or hinders an application in achieving its intended functionality. An app shouldn’t advertise that it was built on a blockchain any more than it would advertise it was written in Python.
Recognizing that blockchains are a tool and not a feature, we can start constructing a framework for evaluating blockchain fit.
Constructing A Framework for Evaluating Blockchain Fit
If blockchains are just a means to an end, then it follows that a simple pros-and-cons chart should suffice. The features and drawbacks of blockchains can be weighed against those of other candidate solutions for the problem and the best option will fall out naturally.
While this should seem obvious, it’s important to note that the applicability of blockchains can’t be judged by walking through a simple flow-chart. Consider these example criteria:
“Do latency and throughput matter? If yes: don’t use blockchain.”
“Does decentralization matter? If no: don’t use blockchain.”
Technical design decisions are seldom so clear-cut. As with any problem worth discussing, the answer is usually fuzzy and only found when considering the options in terms of trade-offs.
“How important is low latency?”
“How valuable are the other benefits outside of low latency?”
“Can we shim in a low-latency solution on the side and still reap the other benefits?”
As such, a better model can be expressed as a simple four-step process:
- List blockchains’ features and evaluate their meaningfulness to the problem
- List blockchains’ drawbacks and evaluate their harm
- List alternative solutions for each feature and evaluate their fit independently
- Choose a blockchain or one or more of its alternatives based on each fit
Features of Blockchains
The first step, then, is to list the features of blockchains. Note that these are not presented as features unique to blockchains — most of these can be found from at least one viable alternative.
Decentralization
No single party can affect the availability of an application or the integrity of its behavior.
This is the bread-winner for blockchains. Decentralized storage solutions are in great supply, but decentralized execution environments are not.
For application users, decentralization provides near guarantees against censorship, denial of service, and foul play. For the developer, it removes the need to harden some centralized infrastructure against attackers, and allows the developer to operate anonymously if needed.
A good fit for decentralization is public-key distribution, where the most prominent solution — trusted certificate authorities — is prone to both malfeasance by the central party and to attack from outside entities.
Deterministic Behavior
Each user can know precisely how an application will behave in response to any event.
Users of open-source blockchain applications can verify the source of the app against the published code on the blockchain. Because each participant in the blockchain’s network will execute that code independently and will attempt to reach a consensus with their peers, it becomes prohibitively expensive for a single party to force unexpected behavior from the application. Note that closed-source applications do not benefit from this feature.
Deterministic behavior is meaningful in situations where a centralized party would be reasonably motivated to mislead its users, or to outright go against its word, in a way that would harm the user.
Insurance, for example, is a strong use case for deterministic behavior. Insurance is purchased precisely for the purpose of protecting the purchaser from unexpected outcomes. What’s more, an insurer may have every reason to avoid paying out an expensive claim if it can — through misinformation, by dragging its feet, or by defrauding the claimant entirely.
Anonymity and Pseudonymity
Users may interact with applications without divulging their true identities.
Blockchain apps allow users to operate anonymously or, in situations where reputation is important, pseudonymously. Of course this appeals to those who would act illicitly, but it also brings benefits to legitimate users in situations where sensitive information is involved, or where users are simply averse to sharing information that is irrelevant to the task at hand.
A person’s voting habits, for example, may be incriminating if released, and need not be tied directly to the individual voter as they communicate their vote.
Immutability and Durability
Information stored in a blockchain will persist, unchanged, for the lifetime of that blockchain.
By itself, this feature is useful to the end user only in the case where an application is expected to store data on the user’s behalf — landownership registries as a simple example.
Note, though, that immutability and durability are also useful as underlying components of the features Deterministic Behavior and Auditability and Non-Repudiation.
Auditability and Non-Repudiation
Any claim made about the state of an application may be indisputably checked by anyone for validity.
Because every input of every blockchain app is stored in the public blockchain forever, disputes over past events are impossible. Entrance into legal contracts, for example, has traditionally been backed by witness testimony of the entrants’ signatures to the contract. Blockchain-backed “smart contracts” are an alternative implementation that completely obviates the need for witness testimony.
Drawbacks of Blockchains
Next, a list of blockchains’ drawbacks as they apply to application development.
Slow
Blockchain applications will always execute more slowly than a traditional centralized solution, if for no other reason than for the need for events to be broadcast to the blockchain’s network and for the consensus algorithm to converge. At present, these consensus implementations are slow enough as to noticeably degrade performance for applications. Note, though, that this issue only affects applications which need to regularly change the blockchain state. Apps that can tolerate slow writes are unaffected.
Expensive
To support a decentralized architecture, participants must be incentivized to commit their own resources to storing and executing data, and miscreants must be disincentivized from abusing those resources and driving participants away. This means it costs users money to store and execute data on blockchains. For general-purpose blockchains like Ethereum, resource utilization is quite poor compared to a traditional general-purpose computer, and consequently, operations which are negligibly expensive for a classical computer can skyrocket in price on a blockchain. One megabyte of storage, for example, is prohibitively costly on a blockchain like Ethereum.
Unconventional
Blockchain tech is still relatively new. The blockchain app developer doesn’t benefit from the wealth of third-party libraries or the large pool of knowledgeable developers that traditional software platforms enjoy.
What’s worse, the end user of a blockchain app must make an unfortunate choice: learn to use new and unfamiliar tools to interact with the blockchain’s network, or confer trust in a centrally hosted server to communicate with the blockchain’s network on their behalf.
In the first case, the user can quickly lose their patience. They must purchase a strange digital currency and install dubiously legitimate software on their device to talk to the blockchain network — a process that they may barely understand and which can seem unnecessary, considering how they’ve gotten by without this overhead for countless applications they’ve used before.
In the latter case, the user can have same experience that they’ve known for traditional applications. The tradeoff, though, is that all the benefits of decentralization are lost. That hosted server is now a central party that may manipulate events or fall victim to attack.
No Peripherals
Current blockchain implementations operate within the abstraction of a virtual machine without external interfaces. Naturally, then, they have a difficult time interacting with anything outside their virtual machine, including other blockchains.
If a blockchain app were to communicate with a real-world device, that device must be configured as a full participant of the blockchain’s network. It must be able to speak the network’s protocol, must be connected to the internet, and must have enough storage and processing capacity to keep up with the protocol.
External data sources are even harder to work with, as they can’t be accessed from without the blockchain’s execution environment, and porting them to the blockchain itself can incur a huge expense. There are workarounds for integrating with external data sources, but they can quickly complicate development.
Mistakes are Easy
For blockchains with specific use cases, such as Bitcoin and Namecoin, this is not the case. But for Ethereum, the leading player in general-purpose blockchains, mistakes are far too easy.
Some design decisions chosen for Ethereum’s virtual machine have resulted in some novel and unintuitive pitfalls for application developers. It’s very easy to end up with a bullet in the foot when writing in Solidity, the programming language of Ethereum.
For simple applications, or applications with low-stakes, this is not an issue. But complex applications with high stakes stand to suffer greatly from this drawback. This can be mitigated by things like thorough testing and through formal verification methods, but the burden on the developer remains.
Everything is Public
Blockchains like Monero and Zcash have achieved privacy for a specific real-world use case: digital currency. A general-purpose execution environment with privacy, however, is not yet feasible. The consequence for applications built on blockchains is that any input it might request from a user must be suitable for full public release.
In Search of Alternatives
Most of blockchains’ features are not offered by blockchains exclusively. It can be easy to over-engineer a solution just because the technology being used is exciting, when a simpler and equally viable alternative was readily available.
Consider a brief list of alternatives for each feature of blockchains:
Decentralization: Classic peer-to-peer protocols like BitTorrent provide decentralized data storage easily without the need for blockchains. Decentralized computation, as mentioned above, is rare.
Deterministic Behavior: For applications run on a user’s own device, the developer can achieve the same guarantee by publishing the source and allowing the client to build their own copy of the application from the source (assuming the user can trust their compiler). Applications run outside the user’s device cannot provide the same strength of guarantee that a decentralized app can.
Anonymity / Pseudonymity: Onion routing (Tor) is the most available alternative for anonymous communication between applications and their users, without the need to trust a single central party. VPNs can also provide anonymity, but require the user to trust the VPN provider itself.
Immutability and Durability: Traditional long-term data storage solutions are available in abundant supply. For that reason, this might be considered the least valuable feature of blockchains as an application platform.
Auditability and Non-Repudiation: The latter is easily achievable with the use of digital signatures and a public-key infrastructure, and digital signatures are indeed becoming the standard solution in practice. Auditability is trickier, as an application must publish to an append-only log all events subject to audit, as they occur, and must be trusted not to omit events. Certificate Transparency logs are a recent example of auditability achieved through a blockchain alternative.
So What, Then?
To sum it all up, we know:
- The applicability of blockchain to a problem is decided by the degree to which its pros and cons help or burden the developer.
- Not every feature of blockchains is relevant to a given problem.
Unfortunately, there is no simple answer as to whether a blockchain is the right tool for the job. Each problem has its own set of needs and constraints, and should be considered independently.
Stay tuned for further discussion on individual problem domains, and the value of blockchains for each.
