Blockchains are data structures, which should be used for applications that make the most of their unique attributes. As with all tools, we should use the right tool for the right job.

Gideon Greenspan has a nice presentation here on when blockchain should not be used. Here are some other examples:

Consider the notion of a smart bond—a bond based on a blockchain and enforced electronically. Is there a real advantage of having an issuer float a smart bond over a typical bond? If the debtor of the smart bond defaults, the issuer will still need to cover the losses of the bond, depending on the terms. In this instance, all you have is a buzzword compliant bond with additional infrastructure costs.

Another example is where a transaction cannot be electronically verified. Imagine that I want to track expensive bottles of Dom Perignon, so I make a blockchain app relying on RFID codes. What’s to stop me from emptying the bottles while keeping the RFID intact?

The physical world needs to interface with our nice blockchain-ized computers. This is why the notion of an oracle exists; oracles enable the physical world to interface with blockchains.

There are real bona fide reasons to use blockchains, but there are real bona fide reasons to use machine learning or microservices. Or the wheel. Or fire. Use blockchain when it’s the correct tool for the given scenario.

Anyone can put bad data into a data structure. Since blockchain is a data structure, anyone can put bad data into a blockchain.

Though application programmers will try to write code to prevent bad data, there is nothing inherent in a blockchain that prevents a bad data entry. Recall the term GIGO: garbage in garbage out.

Consider a scenario where there is a real application for blockchain that is full of bugs. All the blockchain does is enforce consensus, which means that we treat the wrong data in the blockchain as correct data.

We should take care not to conflate consensus with infallibility.

An example of a blockchain full of bugs was the forking of the Ethereum tree. There was a posting error, but some folks opted to go with the original tree, while others opted to go with the corrected tree. Both sets of users continued happily on, knowing full well that there was another tree that disagreed with theirs.

Indeed, consensus is not correct-ness.

Blockchains are a form of storing data called persistence. Traditional databases are also a form of persistence, but this does not mean that blockchains should be equated with traditional databases.

Some newbies want to eliminate centralized traditional databases completely, treating blockchains as a replacement. This fails to recognize the blockchain as a data structure with its own specific attributes, which are very different from traditional databases:

• Blockchains must propagate every change to all other participating computers. However, every field you include in the blockchain is a field that may change and therefore trigger consensus updates. Adding unnecessary fields to the blockchain is a recipe to increase network traffic.
• Blockchains are immutable, meaning once something is put into a blockchain it can’t be changed. While you can do offset records, users must be extra careful about what is put in a blockchain. The more you plan to input, the more error checks you need to implement and enforce.
• Blockchains are supposed to enforce radical transparency—everyone with access to the blockchain should be able to see the records. This can pose issues if the data includes personal information and medical records.

Most people I know take it for granted that a determined hacker can hack any account—regardless of cryptographic cybersecurity measures. However, some of those same people don’t consider the fact that blockchains can also be compromised.

If you realize that your online accounts can be hacked, then you must also acknowledge that your blockchain can be hacked, because the same encryption algorithms are used. It is unfortunately not an unbreachable solution.