Where are the Blockchain Killer Apps?

It assumes a basic understanding of what blockchains/distributed ledgers/whatever-your-marketing-person-came-up-with-as-a-technically-true-but-practically-less-important-diversifier are and what they can do technically and politically. If not, there is tons of information out there, from every consultancy, finance blogger, technologist, bank, and government think tank

This focus of this post is not theory but the current state of play of this technology in order to divine what we might see as killer apps in the future. This is based on my work in the blockchain trenches and talks with scores of people that are actually working on building stuff both within incumbent regulated institutions and in anarchocryptointernet land.

For clarity, for me a killer app should have a few characteristics. It will be a public, production app running “real” data. It will be able to show that it is replacing a non-distributed process. It will be widely used and depended upon. It will be something that could be used by someone with the technical skills of my mother — i.e., something that will continue to scale. As of this writing, there are no distributed apps that I am aware of that fit the killer app criteria (besides, maybe, Bitcoin). So, what will it take to get there?

Hurdles to adoption

Unproved tech scalability

No public project has proven the ability to scale at production beyond Bitcoin — but even Bitcoin has recently been going through governance growing pains. Outside of Bitcoin, there have been many proof of concept white papers that have shown theoretical data throughput, but hard data around the ability for blockchains to serve real world needs is not extant. This is scary for institutions like banks that are looking to actually replace their existing systems with this new technology. That said, as far as theoretical results, Hyperledger (as a logic layer) and BigchainDB (as a distributed datastore) seem to have made great progress in scalable performance. For my company Ohalo, we have been running on the Eris stack and, given enough computing resources, have yet to run into any large scaling issues with a long-running (2.5 months+) Tendermint consensus algorithm running the Ethereum Virtual Machine. That said, we are still doing further testing before making absolute promises.

Immaturity of blockchain stack

We are still at a point in time where there is not clear consensus about what software stack should be used for what particular application. Clarity will come from experimentation. However in the meantime there is a diversity of opinion around what stack is best for which application. Moreover traditional hired gun tech firms that are consulting for the big fish (banks, insurance companies, etc.) do not always provide the best advice. A cynical view would be that this is because blockchain applications are often winner-take-all network plays, which in turn means that what is essentially a technical question of using the most mature technology to get a particular job done, gets muddied by internal and external political interests. A more gracious view would be that such firms simply do not have the resources to sufficiently evaluate and handle multiple technologies at once and therefore just default to the technology that has the most internal momentum. In either case, the issue is that there is not yet a strong internalisation of the technology to provide off-the-shelf solutions for any particular business problem that a large corporation may have. For my part, I build on the Eris stack and appreciate that the marmots there are constantly curating the newest production-ready technologies in the field, which should make it easy to mix and match the best software stack as the industry matures. (disclosure: my company Ohalo and Eris both work with Anthemis).

Adversarial behaviour in consortium plays

Control is the default behaviour for large corporates today. Blockchains will require a fundamental rethink in how companies interface with their data and financial assets, divorcing control of the network from control of the data and logic. It has always been control of the data and logic that is important for large corporates, which has traditionally meant control of the network. However blockchains allow governance of how data behaves on any computer in a network through smart contracts. This has important implications since the network will be free from control and will act as a way to integrate corporates for value creation without having to pre-agree on network ownership. In effect, it allows creation of iterative consortia that can be run on software without necessarily a third party “in control” and setting standards. Blockchains enable scaling of small use cases that can be iteratively joined in a very fluid manner. Corporates have not yet grasped this on a large scale. We see friction arising from current thinking even in very successful consortium-first plays like R3, where internal issues persist that prevent a large scale adoption of the technology in production.

Geeks in banks syndrome

Companies that have the resources to gain the most value from this technology mainly interface startups with their innovation teams. With some notable exceptions (with whom we are working), these teams may have some small budget for proof of concept work but do not necessarily have a big voice in enterprise-wide decision making at banks. That in turn means that it is a long sales process to get the ear of the people that have the resources to create value and need to hear about how decentralised apps could help/hurt them. Strong internal champions with intellectual momentum around blockchain applications are few and distributed applications have not enough experience under their belt to reach the ear of executives. Geeks in banks are good. But for ecosystem plays, geeks in boardrooms are better. Lack of talent: There is a bottleneck of people able to build this stuff out. Even if some individual organisation wants to try something out, the learning curve is steep for devs and incumbent corporates simply cannot source the people they need to try things out. It is unfortunate that the talent that is out there focuses on developing stuff like the DAO that has questionable value beyond the “isn’t-it-cool-that-we-can-create-this” type of thinking (and unfortunate consequences for those investing in it without fully understanding first). This also holds true with business people at blockchain startups in this space. Among these folks, there is not a lot of knowledge about where corporates actually suffer or want to change. The regulated sector is regulated for a reason and will actually be very happy to pay for security and speed no matter what technology if it helps their profit margin on a risk-adjusted basis. The argument for cutting costs with new technology is extremely nuanced and depends upon the specific product/regulatory/market mix that a particular division within a particular corporate may face. Some of the problems that blockchain companies seek to address are in areas of the financial system that just aren’t broken enough to fix.

Realising the potential of smart contracts

While the attractiveness of a distributed and replicated datastore is elegantly done on a blockchain, it is not necessarily something that is impossible to do with regular datastores for many use cases. A large portion of the promise of blockchain tech lies in the ability to run distributed code that several entities can interact with and that results in a determined outcome — these are often called “smart contracts”. There is a divide between blockchain apps that run smart contracts to do useful things and blockchain apps that simply use a blockchain like Bitcoin to store the results of logic run on a secondary software stack. I get that the latter type of implementation is easier since there is less heavy lifting in smart contract development, but many such applications to date fail to realise the potential and power of distributed applications for creating deterministic logic across a network. This may seem like a picky point, but it has important implications in creating trust in and maturing the technology.

Use case taxonomy

So where does this leave us? For killer use cases, I propose a few below, but would love to hear about others. I suggest the following three categories:

Enterprise led use cases

These are use cases where there is a large cost issue or a heretofore locked revenue centres. These are areas of the regulated system that will be assisted by the distributed applications. Blockchain companies focusing on these use cases need to maximize/growth hack enterprise use. The end user probably won’t even know that a decentralised app is running it. I would consider identity plays, like Ohalo, and legal tech to be in this category.

Developer/user led use cases

These are use cases where banks/insurance/regulated companies have some sort of arbitrage over a perfectly frictionless world. These are also those areas of the regulated system that will be most disrupted by distributed applications. These need to maximize user use first. The user probably is aware that it is a decentralised app. Think remittances, online market places, real estate agents, etc. Bitcoin or Openbazaar are the most vivid examples of this.

Hybrid use cases

These are totally new forms of businesses where entrenched interests have yet to firm. These will have diverse and volatile impacts on existing players depending on the use case in question. IoT is one that I would think of.

Just code

To my mind, there is very little value being added by further building ideas and “thought work” around blockchain. We have the concepts we need at this point in time and need to build stuff to test out what churns and what burns.

So with an exhortation to code done in a blog post that is decidedly not that, I’ll end with saying that the best thing we can do to answer the questions of the future is to make that future by coding, developing political will in incumbents, and building out products that will start to test out these assumptions at scale.

If anyone is in London and would like to talk more about my own work or about blockchains in general please feel free to get in touch.