Blockchain is a hot technology right now. Unfortunately, lots of pilots 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 “block chain”). The closest that it came was using the term “chain of blocks” in a comment in the source code for its implementation.
Because of this fuzzy origin, there is no clear definition of exactly what a blockchain is and is not. And while few people would dispute that Bitcoin uses a blockchain, opinions on other uses of the same technology are more divided. Some even argue that the only appropriate use for the term is for Bitcoin’s public ledger.
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 be 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 is 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.
Blockchain: Transaction accuracy and legal considerations
Transactions of any significance can be complicated and need a robust legal framework to make them useful. That is why important data, such as that associated with bank accounts, is either heavily regulated or operated by government organizations. Blockchains, on the other hand, particularly in the way that they are implemented by Bitcoin, do not currently have that same level of legal backing.
It took lawyers a while to work out a reasonable way to provide a legal framework for the business use of public-key infrastructure (PKI). This was eventually defined in the American Bar Association’s Digital Signature Guidelines, the now-obsolete EU Directive 1999/93/EC, and similar rules. And the necessary controls are typically described in documents such as a Certificate Policy and a Certificate Practices Statement. It will probably take a while for lawyers to work out a reasonable legal framework for transactions involving blockchains, especially because it is not yet clear at this point exactly what a blockchain is.
And the fact that data appears in a blockchain does not mean that the data is necessarily accurate. In the case of Bitcoin, it is relatively easy to verify that transactions are valid. IT uses public-key cryptography to authenticate transfers of Bitcoins from one owner to another, and the validity of Bitcoin transactions is checked before they are added to the Bitcoin blockchain. But in other applications, how to validate data is less clear.
There are two hard problems to solve when you want to give the use of blockchains the necessary soundness to make them a reasonable way of resolving disputes in the business world. First, you need a good way to validate that the data that will be written to a blockchain is accurate. Second, once that's done, you need a way to write the validated data to the blockchain.
Making these processes as sound as the underlying technology may turn out to be at least as tricky as debugging a distributed application. A distributed application only needs to get buggy computer hardware and software to work together. Getting a new business process accepted can require getting people, including your auditors, to agree on exactly what the output of a distributed system means, which may be even more difficult.
Reaping the benefits of blockchain
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.
Keep learning
Get up to speed on unstructured data security with TechBeacon's Guide. Plus: Get the Forrester Wave for Unstructured Data Security Flatforms, Q2 2021.
Join this discussion about how to break the Ground Hog Day repetition with better data management capabilities.
Learn how to accelerate your analytics securely into the cloud in this Webinar.
Find out more about cloud security and privacy, and selecting the right encryption and key management in TechBeacon's Guide.
Learn to appreciate the art of data protection and go behind the privacy shield in this Webinar.
Dive into the new laws with TechBeacon's guide to GDPR and CCPA.
