For the last few years, I have been a blockchain skeptic. Well, that’s not entirely fair — I should say, I think cryptocurrencies and tokens are the killer app for blockchains, and we’re still looking around for that second great use case.
My skepticism came down to my computer science training — public permissionless blockchains with some form of consensus based proof (proof of work, proof of stake, etc) are designed to address a serious computer science problem called the Byzantine Generals Problems. The problem essentially asks how do you trust a whole system that relies on un-trustworthy components and actors? Contrary to the proliferation of blockchain applications and startups, there are really only certain situations where this is applicable, and as soon as you make your blockchain permissioned and start centrally granting trust, you’ve essentially fixed the very problem blockchains are supposed to solve.
It’s with that lense I’ve viewed most non-crypto blockchain projects over the past few years, and have generally been unconvinced that a distributed ledger is the right solution for most of them. Add in the fact that I always get nervous about a technology when IBM starts making ads for it (I’m still waiting for Watson to show up at my doctor’s office…) and you can see some of the issues I’m worried about.
I’ve come to realize that enterprise blockchains are less about a technical solution to a complex algorithmic problem, and more about a simple solution to a complex organizational problem
Recently, my thinking has started to shift. Not entirely, I still believe cryptocurrencies are the killer app for public blockchains, but I’m starting to see a new use for private blockchains that raise above theoretical computer science problems.
I’ve come to realize that enterprise blockchains are less about a technical solution to a complex algorithmic problem, and more about a simple solution to a complex organizational problem. Put simply, when multiple organizations are involved in any endeavor, there are only so many ways that they can interact to complete large technical projects, and all of those mechanisms are flawed. Maybe blockchains are the least flawed of them all.
The US banking industry has a long history of technical collaboration at scale, and a great example is how they reconcile checks. It’s a long story that starts with bags of checks being exchanged by banking officials 100 years ago, and ends in the 1970’s with a system of mailing magnetics tapes around. The banking industry has essentially built and maintained a fully open API that any of the 2000+ members can use for paying out checks for many years. And, to their credit, they did this without computers, with computers the size of rooms, and finally now with the internet. If you’re interested in going deeper on the subject, Planet Money did an excellent podcast on it.
I call this problem the Byzantine Organizational Problem — anytime more than one company or group has to collaboratively build software, the overhead of managing and designing the processes, API’s, and deciding on programming languages, databases, and protocols vastly outweighs the difficulty of any technical solutions
This system took 10 years to build and now, almost 50 years on, no major modernization has happened. It still takes 5 days for money to move from point A to point B in the system even though we have the internet, better databases, better API layers, etc. This is the problem I’m referring to, it is incredibly difficult for a whole industry to outsource core business functions to a third party and stay nimble and efficient.
I call this problem the Byzantine Organizational Problem — anytime more than one company or group has to collaboratively build software, the overhead of managing and designing the processes, API’s, and deciding on programming languages, databases, and protocols vastly outweighs the difficulty of any technical solutions. The technical trust issues of the Byzantine Generals Problem almost pale in comparison to the human trust issues of the Byzantine Organizational Problem.
And, that’s where enterprise blockchains come in — if you stop thinking about a blockchain as a distributed data storage algorithm (of which there are hundreds, many that are better than a blockchain) and start thinking about it as a consensus driven API and cross-system translation layer, you can suddenly see a different level of value.
This shift in thinking was big for me.
An example I’ve heard several times now for private blockchains is supply chain management, specifically around ocean shipping and ports. The baseline is that no one really trusts anyone in the ecosystem — the shippers don’t trust the ports, the ports don’t trust the customs agents, the customs agents don’t trust anyone. NOTE — I’m not talking about computer security trust, they don’t have a problem with cryptographic identity. They don’t trust each other on a human / organizational level. They don’t trust each other to make decisions that are mutually beneficial, or even design functioning systems that won’t try to cheat each other.
In this type of trustless environment, getting everyone together to form a third party working group to develop inter-organizational APIs and systems is going to be difficult (hence why it hasn’t happened in the shipping industry). It’s not just about who pays for the initial development work, but who supports it in the long term? Who pays the AWS hosting bills? Who handles 4am outages? Who is managing upgrades to protocols and tooling, and libraries as security patches are released? When everyone already has an internal system, whose API structure do you use? What does the federation and interop even look like, REST, SOAP, or gRPC?
Blockchain, and specifically platforms like Hyperledger, can offer a solution to this problem. Because Hyperledger already has a well defined API, the primary development issues in our above example becomes one of schema design, and the collaboration group that is needed can be the biggest 10 ports, shippers, and customs agencies in the world in an open-source style working group (with RFCs and everything). The normal holy wars of what language and database to use become a non-issue since Hyperledger provides both, and hosting is a very basic IT exercise for each interested company to undertake (1 or 2 machines configured correctly and some certificate distribution).
At this point, you almost don’t care about the blockchain. As weird as it is to say, the magic here is having an easy to use platform with clean APIs, easy to setup replication, and pre-configured security rules that everyone agrees to use. The product then becomes the well designed API that any of these companies can read from, write from, and integrate with their internal systems as they see fit. This point must be emphasized: instead of building 10 connections to 10 different systems at 10 different companies (and hoping they work, even with a common protocol), each company builds a single integration to the blockchain layer, and everything else just works.
This may all seem theoretical, but solving organization issues is incredibly valuable.
I’ve worked in software long enough to know organizational problems almost always trump technical problems. Sure, we don’t have general AI yet, so order your engineers to build Jarvis and they’ll fail. That said, cat herding hundreds of companies and thousands of developers can turn a simple project like building a sandcastle into the equivalent of building the great pyramids. Communication issues come up, IP issues arise, personality conflicts, and money problems are all infinitely more complex than most of the technical work we engineers have to do.
And that’s how I moved from a blockchain skeptic to blockchain agnostic — when I realized blockchains are good for solving the Byzantine Generals Problem AND the Byzantine Organizational Problem.
Disclaimer: The information provided in this blog post is for general informational purposes only and should not be construed as tax, accounting, or financial advice. The content is not intended to address the specific needs of any individual or organization, and readers are encouraged to consult with a qualified tax, accounting, or financial professional before making any decisions based on the information provided. The author and the publisher of this blog post disclaim any liability, loss, or risk incurred as a consequence, directly or indirectly, of the use or application of any of the contents herein.
