Database

No, You Don’t Need a Blockchain

No, You Don’t Need a Blockchain

The hype around blockchain technology is reaching a fever pitch these days. Visit any tech conference and you’ll find more than a handful of vendors offering it in one form or another. This includes Microsoft, IBM, and AWS. Each of those companies offers a public blockchain as a service.

It is also the driving force behind cryptocurrencies, allowing Bitcoin owners to purchase drugs on the internet without the hassle of showing their identity. So, if that sounds like you, then yes, you should consider using blockchain. A private one, too.

Or, if you’re running a large logistics company with one or more supply chains made up of many different vendors, and need to identify, track, trace, or source the items in the supply chain, then it may be the solution for you as well.

Not every company has such needs. In fact, there’s a good chance you are being persuaded to use it as a solution to a current logistics problem. It wouldn’t be the first time someone has tried to sell you a piece of technology software you don’t need.

Before we can answer the question if you need a blockchain, let’s take a step back and make certain we understand the technology, what it solves, and the issues involved.

What is a blockchain?

The simplest explanation is a blockchain serves as a ledger, a series of transactions using cryptography to verify each transaction in the chain. Think of it as a very long sequence of small files, each file based upon a hash value of the previous file combined with new bits of data and the answer to a math problem.

Put another way, it is a database—one that is never backed up, grows forever, and takes minutes or hours to update a record. Sounds amazing!

What does blockchain solve?

Proponents believe it solves the issue of data validation and trust. For systems needing to verify transactions between two parties, you would consider blockchain. The leading problem it is applied towards is supply chain logistics. Specifically, food sourcing and traceability.

Examples include Walmart requiring food suppliers to use a blockchain provided by IBM starting in 2019. Another is Albert Heijn using the technology along with the use of QR codes to solve issues with orange juice. Don’t get me started on the use of QR codes; we can save it for a future post.

The problem with blockchain

Blockchain is supposed to make your system more trustworthy, but it does the opposite. It pushes the burden of trust down to the individuals adding transactions to the blockchain. This is how all distributed systems work. The burden of trust goes from a central entity to all participants. And this is the inherent problem. What’s worth mentioning here is how many cryptocurrencies rely on trusted third parties to handle payouts. So, they use blockchain to generate coins, but don’t use it to handle payouts because of the issues involved around trust.

Here’s another example of an issue with blockchain: data entry. In 2006, Walmart launched a system to help track bananas and mangoes from field to store, only to abandon the system a few years later. The reason? Because it was difficult to get everyone to enter their data. Even when data is entered, it will not do anything to validate that the data is correct. It will validate the transaction took place but does nothing to validate the actions of the entities involved. For example, a farmer could spray pesticides on oranges but still call it organic. It’s no different than how I refuse to put my correct cell phone number into any form on the internet which requires a number be given.

In other words, blockchain, like any other database, is only as good as the data entered. Each point in the ledger is a point of failure. Your orange, or your ground beef, may be locally sourced, but that doesn’t mean it’s safe. It may help determine the point of contamination faster, but it won’t stop it from happening.

Do you need a blockchain?

Maybe. All we need to do is ask ourselves a few questions.

Do you need a [new] database? If you need a new database, then you might need a blockchain. If an existing database or database technology would solve your issue, then no, you don’t.

Let’s assume you need a database. The next question: Do you have multiple entities needing to update the database? If no, then you don’t need a blockchain.

OK, let’s assume we need a new database and we have many entities needing to write to the database. Are all the entities involved known, and trust each other? If the answer is no, then you don’t need a blockchain. If the entities have a third party everyone can trust, then you also don’t need a blockchain. It should remove the use of a third party.

OK, let’s assume we know we need a database, with multiple entities updating it, all trusting each other. The final question: Do you need this database to be distributed in a peer-to-peer network? If the answer is no, then you don’t need a blockchain.

If you have different answers, then a private or public blockchain may be the right solution for your needs.

Summary

No, you don’t need a blockchain. Unless you do need one, but that’s not likely. And it won’t solve basic issues of data validation and trust between entities.


Thomas LaRock is a Head Geek at SolarWinds and a Microsoft® Certified Master, Microsoft Data Platform MVP, VMware® vExpert, and former Microsoft Certified Trainer. He has over 20 years’ experience in the IT industry as a programmer, developer, analyst, and database administrator. LaRock has spent much of his career focused on data and database administration, which led to his being chosen as a Technical Evangelist for Confio Software in 2010, where his research and experience helped to create the initial versions of the software now known as SolarWinds® Database Performance Analyzer. LaRock has served on the board of directors for the Professional Association for SQL Server® (PASS), and is an avid blogger, author, and technical reviewer for numerous books about SQL Server management. He now focuses on working with customers to help resolve problems and answer questions regarding database performance tuning and virtualization for SQL Server, Oracle®, MySQL®, SAP®, and DB2®. He’s made it his mission to give IT and data professionals longer weekends.