A Blockchain is (probably) not what you need

You will usually find two kinds of articles when it comes to development of blockchain based apps, the overly optimistic “it’s a paradigm shift” kind, and the “it’s really bad, don’t ever use it” kind. Having worked with blockchain based technologies for the better part of a year, I found these articles mostly impractical. So here’s my (hopefully practical) take on when you should consider using a blockchain for your app.

What does a blockchain give you?

The only thing that a blockchain based application gives you (if you are using it correctly) is decentralized consensus. Every other “feature” can generally be implemented for far cheaper using traditional technologies.

Here are some of the proposed advantages a blockchain gives you:

  • Immutability
  • Traceability
  • Notarization
  • Transparency
  • Anonymity
  • Privacy
  • Failure tolerance
  • Verified ownership

Applications needing these properties are not new and many of these problems have already been well-studied and solved using centralized technologies. Heck, even git (or a slightly modified version of it) can solve most of these problems easily. Or if you want to make Jeff Bezos even richer take a look at Amazon’s QLDB (which is basically repackaged git and gpg over a database).

Thus, if some combination of these parameters are your only criteria without needing decentralized consensus, you don’t need a blockchain.

But wait, there’s more!

When you use a central trusted server, you also get a few more things for free which are impossible to do with today’s state of the art blockchains:

  • Speed:
    Bitcoin has a max throughput of 7 transactions per second. Even permissioned blockchains like Hyperledger have a transaction limit of 150 to 300 tps. Centralized technologies will give you speeds at least two orders of magnitude more.

  • Scalability:
    In a decentralized system, adding more nodes slows the system down as each node has to wait for the entire system to synchronize first. This is not a problem in centralized systems.

  • Agility and Regulation:
    The only way to change the underlying software of a blockchain after deployment is a “hard fork”, which is usually difficult to perform correctly and cumbersome if your application requirements change constantly. Also it is difficult to create a distinction between the “developers” and the “users” without introducing too much centralization. Simply marking a few nodes as more powerful than others undermines the core idea of decentralization.

Decentralized consensus

Applications needing decentralized consensus are generally of two types:

  1. Your use case consists of multiple parties keeping their own separate copies of data and they don’t want to compromise by keeping the data on a single server.
  2. You data store is so sensitive you don’t trust the server operator not to mess with it.

These are valid concerns which can be solved by decentralized consensus however it is crucial to determine if it is worth sacrificing speed, scalability and agility for this.

No tokens required

For any situation where the blockchain is used simply to verify and maintain an immutable ledger (without using tokens), you can use a simple algorithm to determine if you need a blockchain:

  1. Determine how valuable agility, speed, scalability are for your application.
  2. Determine how valuable a decentralized consensus mechanism is for your application.
  3. If the value obtained in step 1 < step 2, congratulations! You have found a successful use-case for a blockchain!
  4. Else, you can build your application faster and better without using a blockchain.

What if I need tokens?

Tokens are used as a placeholder for value that your system creates. This is usually fine unless you want to “map” the value to a real world entity. When a token is mapped to a real world entity or commodity let’s say the USD, fluctuations in the supply of the real world entity as well as other real world phenomenon must also reflect on the value token inside your system. This is generally impossible to do in a decentralized manner. In absence of such a mechanism, your token will fluctuate in value very heavily and this is not useful in many applications, especially which rely on currency.

The Nakamoto consensus algorithm is only useful if the mechanism for consensus itself it decentralized, i.e. every user in the pool has a chance to publish a block. Regulation of real world entities is usually done by a select few which are then agreed upon by the rest of the population. The notion of a “select few” in a decentralized system defeats the whole purpose of such a system.

You get the following features when using a “traditional” currency:

  • Guarantee of “value” i.e. the tokens you have are actually worth something. (For example, due to a central bank.)
  • Guarantee of stability and low volatility.
  • Other (potentially) solvable technological problems discussed above like stability and speed.

If your use-case values “decentralization” and “freedom from regulation” more than the above features, you might have found a valid use-case for a blockchain!

Future proof

Advances in blockchain technology may render the above heuristic obsolete. Some very smart people are working really hard to solve these problems, especially those of scalability and speed. But these algorithms are a good estimate, at least for the foreseeable future.