Is blockchain right for your enterprise?

Yan Pritzker
Bitcoin, not Blockchain
9 min readMar 12, 2019
https://www.maxpixel.net/Cryptocurrency-Virtual-Blockchain-Currency-Network-3277335

This article is targeted toward CTOs, CIOs, and other decision makers in both enterprise and startup environments. Today we’re going to cut through all the hype and get to the bottom of whether you should be using “blockchain” in your business from the lens of tradeoffs, arguably the most important lens for a technology leader.

Why should you listen to me? In my experience as CTO of Reverb.com, I had a very strong belief that you should choose boring technology and only deviate from this when the tradeoffs of using a newer technology present an order of magnitude improvement. We built most of our website on Rails and Postgres, and we did just fine. The company now does about $600m in sales per year.

Don’t just listen to me though, Facebook was originally built on PHP and Mysql. Twitter was built on Rails and Mysql. You can get a lot done with these technologies, and you will have no shortage of expertise to choose from. But if you are dead set on blockchain, you must understand what you’re getting into. So let’s dive right in.

The Blockchain Hype Trap

The word blockchain itself is largely used as a broad concept rather than a specific bit of technology. It is commonly used to describe a distributed immutable ledger maintained by parties that don’t quite trust each other. A popular example of this appears to be companies involved in a supply chain where they want to share a common database for tracking the movement of an object through its lifecycle from production to consumption.

When it comes to specifics, people in the enterprise typically say “blockchain” to refer to:

  • (Rarely) the Bitcoin blockchain, the only blockchain that demonstrates actual immutability and censorship resistance, which is the only real feature blockchains are designed for.
  • (Sometimes) other public chains like Ethereum, or Stellar, which are perceived to have “better scalability” than Bitcoin, and also smart contracts, but still have nowhere near the scale needed for enterprise applications.
  • (Usually) a private system where multiple parties can write and audit data, based on something like Hyperledger Fabric, or a private Ethereum chain.

There appears to be a vicious cycle in enterprise blockchain, which goes something like this:

  • Consulting companies sell innovation services to enterprises by pitching them how they could integrate blockchain technology.
  • CIOs announce blockchain initiatives in order to appear relevant and with the times. The old adage is “nobody ever got fired for choosing IBM”. Today it seems “nobody ever got fired for researching blockchain”.
  • Other CIOs use the efforts of other companies as evidence that blockchain is worth exploring for their use case.
  • VCs start telling their portfolio companies that they should use blockchain because of the above.
  • Rinse, repeat.

Meanwhile, absolutely nobody has anything meaningful working at scale. It is incredibly important to shut out all this noise when making a technology decision, and evaluate a technology on its merits, usefulness to your business, and the costs and tradeoffs of implementation.

Understanding the Tradeoffs of Blockchain

Let’s examine why you would use any of these, and the tradeoffs you’re making when you build your business on them.

Bitcoin

Pros:

  • Bitcoin is the only blockchain which is actually immutable and has withstood a decade of attacks with aplomb. If your use case involves storing data in a truly immutable ledger that you will never be able to control, then Bitcoin is the blockchain for you.
  • Bitcoin use cases beyond money are limited, as the chain is not designed to store large amounts of data. One example would be existence proofs, where you can store a fingerprint of a document on Bitcoin to show that a document existed at a certain time.
  • The Lightning Network, a second layer on top of Bitcoin has the promise of nearly instant and nearly free transactions, and may be the foundation for further non-money applications, but it’s too early to tell.

Cons:

  • Bitcoin on-chain transactions are extremely slow. Blocks come at an unpredictable rate.
  • Before you decide to build your business on Bitcoin, you have to be aware that block space is scarce and comes at a premium. Expect the fees you pay for storing transactions to rise over time, and even become extremely high over the next few decades.
  • Given that Bitcoin is first and foremost financial in nature, consider the possibility that you will be priced out of your transactions by monetary use cases, which by virtue of moving large sums of money would be happy to pay for the block space that you will no longer afford.
  • Bitcoin developers are few and extremely expensive. They also tend to not want to work on enterprise technology. They’d much rather be changing the world by helping invent and propagate a new sound money.

Ethereum

Pros:

  • Ethereum has smart contracts. What that means is you can supposedly create immutable code that enables you to build things like banks in 100 lines of code.
  • Ethereum has the strongest marketing arm, and the most developer teams building something on it. Whether any of those use cases pan out, at least the developers exist, in theory.
  • The ethereum go client (geth), has 386 contributors on Github, though only about 20–30 have contributed meaningfully over the last year. This is a decent core developer pool, though still pretty risky for adoption in my opinion. You’d likely want to develop in-house expertise around the protocol.

Cons:

  • Ethereum undergoes planned hard-forks on a regular basis. You may want to consider whether a mission critical business can be built on software that is changing so rapidly. Furthermore, the fact that hard forks are planned and called off within hours indicates that this chain isn’t actually immutable.
  • Smart contracts have proven incredibly hard to write securely.
  • Although you won’t get “real” immutability, you will introduce incredible friction as your business needs will change, but your smart contracts will be “immutable.”
  • In order to make your contracts not immutable, you will implement complex upgradeable architectures which will destroy the very premise that things are supposed to be unchangeable and kind of eliminate the point of doing the smart contracts on chain in the first place.
  • Hiring Ethereum developers comes at a premium, and because the technology is nascent, they will likely produce code full of security bugs.
  • Ethereum is still not scalable for high throughput use cases, and the plans to scale it sound more like science fiction than computer science.
  • Ethereum 2.0 will be a completely different chain, not backwards compatible with the current one. So, if after reading the above, you’re thinking “this sounds like what I need”, maybe wait 3–5 years first.
  • Consider the costs of acquiring the tokens required for your use case. For example, you need ETH to pay gas costs on Ethereum, but the value of this token has been subject to extreme fluctuation due to speculation.
  • Due to the above, you’ll probably want to run your own private chain. But even that will be subject to scalability issues if you have to cross international borders and deal with latency, or communicate between a large number of nodes.

Stellar

Pros:

  • A lot of big name companies are running nodes, if the Stellar website is to be believed. Stellar uses a system where every node decides which other nodes to trust. This is the list they recommend you start with, which may be a decent proxy for understanding who’s really in charge on this network.
  • Its transactional speed, if you believe reddit, is in the thousands per second, which is a lot faster than eth/bitcoin, though again, if you plan to build enterprise scale applications on the public chain, consider being priced out of capacity by other usecases.

Cons:

  • Stellar core only has something like 4 recent contributors on github. Personally that would instantly disqualify it for me, but you may be ok running with alpha software or developing in house expertise around a private fork of this technology. Remember, though, if you have a bug that can only be fixed at the blockchain level, this is the approximate number of total experts that exist.
  • I have no idea where you would hire Stellar developers. Assume a giant premium and lack of talent.

Hyperledger

Pros:

  • Hyperledger was built for the enterprise rather than as a cryptocurrency, and thus may at least be closer in functionality to what you’re looking for. There is no native “currency” token, and it’s designed with a permission-based system in mind.
  • Hyperledger has something like 15 recent contributors within the last year on github. It’s a pro compared to some other systems like Stellar, though still way too small for my comfort.

Cons:

  • It’s unclear if anyone is using it in production, though there are many proof of concept systems being built on it.
  • It has complex “choose your own adventure” consensus mechanisms and backend database (LevelDB, CouchDB) options. You might want to consider hiring a few computer science PhD’s to help you figure this out.
  • Getting scalability numbers for this system is quite hard, but one paper using a network of 4 orgs with 8 peer nodes and 2 “endorsing peers” backed by a kafka cluster for consensus running on ultra beefy nodes achieved something like a few thousand tps. Again, due to the complexity of the system, your mileage will vary significantly, and I doubt they tested in real world conditions with e.g. intercontinental latency involved (“While network characteristics are important, we assume a datacenter or high bandwidth network with very low latency for this study”).
https://www.hyperledger.org/wp-content/uploads/2017/08/Hyperledger_Arch_WG_Paper_1_Consensus.pdf

Recapping the problems of Enterprise Blockchain

Let’s recap why blockchains may not make sense for you.

  • Blockchains are designed to coordinate untrusted parties. If you’ve ever run an in-house distributed database like Elasticsearch, you’ll know they’re not that easy to keep highly available and highly performant. Now imagine trying to coordinate a bunch of organizations where you don’t actually have full control of all the nodes, their hardware, networking connections, and operator errors. Blockchains are not designed for scale, so you should consider how much scale you will need in production.
  • Developers are very hard to come by. Make sure you’re ready to build in house expertise around something that may not be your core competency. For startups, this is a serious anti-pattern, but may be affordable for certain large enterprises.
  • Distributed consensus systems are really complicated. Very few people actually understand them or how to debug them at scale. Be prepared to build in house expertise.
  • The technologies evaluated are all of early/alpha quality and have a relatively small number of experts worldwide. There is also the risk that any or all of these are technological dead ends that will end up not supported five years from now.

I’m still convinced I need a blockchain, what would you suggest?

If you’re ok with all of the above and still think this technology is right for you, then I would consider going with a hosted option to delegate the running of the chain to someone who will at least not screw it up.

Let’s face it, you’re not really looking for a permisionless system, so you might as well trade in some centralization for operational stability. AWS continues to be the leader in cloud hosting, and they have recently announced hosted permissioned Ethereum and Hyperledger systems, as well as a system called QLDB which is an append-only database ledger.

As long as you trust that AWS won’t muck with your data (they generally won’t, because that would destroy their business), then you should let them be the central operator of your “blockchain”.

The choice between Ethereum and Hyperledger is left to the reader. The main tradeoff would be that Ethereum has more people building on top, and Hyperledger is likely more suited to permission-based systems.

Choose boring technology

Please consider choosing boring technology to build whatever you’re building. You’ll get to market faster, your developer cost will be lower, and your company will be focused around your core competency rather than forced into developing in-house expertise in very complex technology that no one really understands.

The end.

--

--