The blockchain is a hot technology. Unfortunately, lots of drivers of blockchain technology have been for applications that haven’t really been a good fit for the technology, ones where traditional relational databases, such as MySQL, work just as well, and perhaps even better.
So how do you know if blockchain, which has been promoted for secure transactions, is a fit for your application project? The key to answering that question lies in understanding the fundamentals of Bitcoin and blockchain. Only when you understand the benefits and drawbacks can you address what criteria you might use to identify projects that are truly suitable for blockchain technology.
What is a blockchain?
A blockchain is the data structure that the Bitcoin cryptocurrency uses for its public ledger, where transactions are recorded. Somewhat curiously, the term “blockchain” does not appear in the original description of the Bitcoin protocol (neither does the term “blockchain”). The closest that it came was using the term “chain of blocks” in a comment in the source code for its implementation.
When most people talk about blockchains today, they mean a distributed database comprising a collection of blocks of data, each of which contains a timestamp and a cryptographic link to a previous block, in addition to the other data that it might store. And they often mean a database that is readable by many people, perhaps everyone, but cannot be easily updated by any single user. A peer-to-peer architecture instead of a client/server architecture may also be a key feature of a blockchain, which can let users carry out transactions without using a trusted third party.
The Bitcoin blockchain has these properties, but determining if blockchains are really suitable for your particular application will strongly depend on what definition of a blockchain you are using. In general, a good rule of thumb seems to be that the more like Bitcoin your application is, the greater chance of blockchains being a good fit for it, while applications that are less like Bitcoin tend to benefit less from its use.
So if you are thinking of using a blockchain, a good first step is to get a detailed understanding of how Bitcoin works so that you understand why Bitcoin’s blockchain works the way that it does. This is a non-trivial investment of time and will take more effort than reading a few web pages about Bitcoin. Once you do that, however, you will better understand the trade-offs that you must make if you implement a blockchain yourself.
Unless you are going to build a system that implements a peer-to-peer, pseudonymous electronic cash system, the chances are good that your requirements are very different from the requirements of Bitcoin, so there is no reason to expect that the design decisions that were made for Bitcoin will make sense for your application. Understand how Bitcoin works, but do not assume that just because Bitcoin does something in a particular way that it’s appropriate for your own use of blockchains.
Blockchain’s distributed database: Pros and cons
The fact that blockchains are a distributed database makes them useful in some ways. Distributed applications run on networked computers and coordinate their actions by either passing messages between instances of the application or through shared memory. Distributed databases can have a much higher level of availability than nondistributed applications, and they function better than nondistributed applications in the face of failures that isolate parts of a network from other parts of the network.
But these benefits come at a price. In particular, it can be tricky to keep data in a distributed database consistent because there is no guarantee that an update made in one place will eventually make it to the other parts of a distributed system.
In the case of Bitcoin, a possible lack of consistency means someone could spend the same Bitcoin more than once. The way that the Bitcoin blockchain records transactions are meant to solve this problem. The distributed nature of Bitcoin means that the Bitcoin blockchain is not necessarily consistent, but the way that the Bitcoin network operates means that it will be eventually.
At any point in time, Bitcoin users may not agree as to whether a specific transaction occurred, but they will probably eventually come to an agreement on this. Expect to make a similar compromise for consistency if you implement a blockchain yourself. (This sort of trade-off actually occurs in every database being used today, but unless you care about how databases work, you probably aren’t aware of it.)
Caveat: Building distributed applications is hard
Developing and testing distributed applications can be difficult. Testing and debugging software that runs on a single computer is hard enough; testing and debugging software that must coordinate with other software over a buggy network is even harder. The vagaries of how computers operate is why we have the term “heisenbug,” defined as a bug that changes its behavior when you try to test it. Be prepared to deal with heisenbugs when developing your distributed application.
In distributed applications, you can also expect to also see examples of “mandelbugs,” where the cause is so obscure and complex that the observed behavior appears to be a good example of chaos theory in action. You’ll also experience “schrödinbugs,” bugs that you don’t notice until someone using an application in a new or unconventional way discovers new and unexpected behavior that has been there all along.
These types of bugs are annoying in nondistributed applications, but they are even more annoying (and more common) in distributed applications. That’s why developing, testing, and supporting a distributed application can be harder — and more expensive — than you might expect.
The takeaway here is that if you are going to try to use blockchains in your application, set your expectations for cost and schedule to realistic values. If you have not dealt with distributed applications before, this can be an eye-opening exercise.
Conclusion of blockchain benefits
Blockchains can support the creation of new, more efficient business processes, but you’ll have to overcome a few challenges before you’ll see those benefits. The distributed nature of blockchains makes them surprisingly hard to work with. The definition of a blockchain is still very vague, so it is easy to call almost any useful distributed computing technology a blockchain without stretching the truth too much.
But the same flexibility may make it much harder to get the acceptance of business processes based on blockchains. Expect to see those issues worked out over the next few years. If you are brave enough, you can even be part of this process.
Now that you understand the fundamentals, you’ll need to decide whether blockchain fits your specific needs. In my next article, I’ll suggest some specific criteria you can use to identify projects that are truly suitable for blockchain technology. In the meantime, is there something I missed that you’d like me to address? I welcome your questions.
