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 blockchain. This includes Microsoft, IBM, and AWS. Each of those companies offers a public blockchain as a service.

Blockchain 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 blockchain 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 blockchain 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 blockchain technology, what it solves, and the issues involved.

What is a blockchain?

The simplest explanation is a blockchain serves as a ledger. This ledger is a long series of transactions. And it uses cryptography to verify each transaction in the chain. Put another way, think of 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, blockchain 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 of blockchain believe it solves the issue of data validation and trust. For systems needing to verify transactions between two parties, you would consider blockchain. Supply chain logistics is one problem people believe solved by blockchain technology. Food sourcing and traceability are good examples.

Other examples include Walmart requiring food suppliers to use a blockchain provided by IBM starting in 2019. Another is Albert Heijn using blockchain 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 should make your system more trustworthy, but it does the opposite.

Blockchain pushes the burden of trust onto 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 with blockchain.

[Warrants mentioning – many cryptocurrencies rely on trusted third parties to handle payouts. So, they use blockchain to generate coins, but don’t use blockchain to handle payouts. Because of the issues involved around trust. Let that sink in for a moment.]

Here’s another 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, blockchain will not do anything to validate that the data is correct. Blockchain 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.

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. Blockchain could show the point of contamination, 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 yes, 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. A blockchain 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 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 you.

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. If we can trust each other, then we would be able to trust a central clearinghouse, too.

Don’t buy a blockchain solution unless you know for certain you need one.

[This article first appeared on Orange Matter. Head over there and check out the great content.]

11 thoughts on “No, You Don’t Need a Blockchain”

  1. I think you have a few inaccuracies:

    “This ledger is a long series of transactions…Put another way, blockchain is a database—one that is never backed up” : it is actually a long series of IMMUTABLE transactions. The transactions can never be changed. They are there for the world to see in the open. This is what generates trust. If you do something stupid, it can’t be removed. There are lots of funny things in ethereum where you can see stupid things users have done. And it doesn’t need to be backed up b/c in order to add a transaction (as a miner) you MUST have the entire chain. Therefore it is akin to a p2p network where all participants are essentially the backup.

    “Blockchain pushes the burden of trust onto individuals adding transactions to the blockchain. ” Not true in all cases. Different blockchains can be created to solve different use cases. In cases like Walmart food sourcing, it is permissioned blockchain where you must be trusted to write to the blockchain (vs bitcoin which uses proof-of-work and block verification to prove you are a trusted actor). This fosters excellent trust. Let’s say Walmart has a food sourcing system in sql server, Will consumers TRUST that the data has not be modified to hide bad behaviors? I wouldn’t. But if it’s in blockchain and open for the world to READ, I have confidence that the data was not fraudulently modified.

    “The burden of trust goes from a central entity to all participants. And this is the inherent problem with blockchain.” Again, not true. Look at Azure blockchain as an example. It is really tough to do user authentication in blockchain and it isn’t needed in many cases. So Azure says, “hey, just use AAD in those cases”. It works great. You are right as far as cryptocurrencies using trusted 3rd parties…but it’s a different use case. I want to remain anonymous on the blockchain so I can buy my illicit drugs, yet the payment eventually needs to be done in dollars via a trusted clearninghouse.

    “blockchain will not do anything to validate that the data is correct.” Not exactly true. In ethereum and others you can write function code that executes and you put your logic there. But remember, part of the goal of a blockchain is to show the honest transactions. If you do bad data entry on your food sourcing…well, I trust you even less.

    You are quite correct that for most use cases a database is a better solution than blockchain. But I can give you many examples, generally around TRUST, where a blockchain is a far better solution.

    These are not interchangeable technologies. One is not better than the other. This is analogous to “SQL Server vs Mongo” rather than “SQL Server vs Oracle”. The former serves distinct use cases.

    Reply
  2. While many (maybe most) projects do not need ‘blockchain’, your article has so many inaccuracies that you devalue the discussion, imho. For example,

    “Do you need a [new] database?” — Better to start out with what problem you are trying to solve and then consider the best solution, blockchain or not.

    ‘Are all the entities involved known, and trust each other? If the answer is no, then you don’t need a blockchain.’ This is particularly inaccurate — just consider the use of bitcoin and the trustless solution to limiting inflation

    Reply
  3. Yes, unfortunately this post does seem to have many errors. The suggestions about when to use a blockchain appear to be a misreading of the flowchart in this paper or something derived from it: https://eprint.iacr.org/2017/375.pdf

    I am actually more pessimistic than the author about the scope of valid use cases for blockchain other than cryptocurrency . Regarding supply chain management, a blockchain appears to meet one useful criterion in that field (auditability) while sacrificing much of the functionality relational databases have developed over decades. Auditability requirements can be met with existing databases such as SQL Server or Postgres with features such as system-period data versioning. You could also do something as simple as providing a web API that issues insert but not delete or update statements.

    Immutability doesn’t seem like a useful requirement to me as long as the audit trail is maintained, as without infallible data entry, there will need to be some means of publishing corrections, either as an update to an existing record or a newer record containing the revision, and a party could as easily publish an incorrect correction as they could incorrectly update a non-immutable record.

    Maybe my opinion will change as I learn more.

    We saw a similar pattern with the NoSQL databases, which sacrificed functionality such as transaction management, causing developers to re-implement database features in their applications.

    Others have suggested that blockchain will drive innovation, but implementing a blockchain will be the excuse for getting the project done, not the reason why it succeeds.

    Reply

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.