One of the puzzles of the blockchain world is the gap between the enterprise cheerleaders, who want to see a blockchain in anything, and people from the bitcoin world, who frequently don’t see applications of blockchains outside of currency. It’s hardly surprising that there’s a feeding frenzy around any new and cool technology. And it’s to be expected that those who already understand the new technology are more cautious about how it’s applied. But for blockchains, that caution is extreme. Jimmy Song’s recent articles, “Alternatives to Blockchain” and “Why Blockchain Is Hard,” are good examples.
I know Song, who’s writing a book on bitcoin programming for O’Reilly, and I agree on many of his specific points. Even where I disagree, Song knows a lot more about blockchains than I do. And blockchain advocates need to learn a lot from people who have actually made a blockchain work: there’s a lot of fantasy and unreality at large. Song’s articles should be required reading for anyone considering a blockchain deployment.
What surprises me is the “it’s our toy and you can’t play with it” attitude that I see coming from much of the bitcoin world. To the extent that there are loads of businesses getting all excited about blockchains when they should just be installing a traditional database, they’re completely right. But to the extent that there are applications for blockchains that we’re only starting to invent, they’re wrong.
The two blockchain applications that look most interesting to me are Maersk’s container shipping application, and Walmart’s Food Safety Alliance. I’ve actually pooh-poohed the use of blockchains for tracking groceries: tracking every leaf of artisanally grown lettuce as it makes its way to your farmers’ market is the ultimate first-world problem. But when I read about Walmart, I realized that they have a genuine problem managing their supply chains, and it’s a blockchain problem. They’re doing deals with farms all over the world, they have limited ways of tracking what the farms are actually doing or shipping, they don’t know where those products are in the supply chain, and these issues add up to big problems—not just keeping the shelves stocked, but serious health and safety problems.
It’s probably not a coincidence that the Maersk and Walmart projects are being done in collaboration with IBM and Hyperledger. IBM knows a bit about building large IT projects. Hyperledger Fabric isn’t based on proof-of-work; it is permissioned, significantly increasing transaction throughput and reducing the computational resources required. Many bitcoin purists don’t consider a “permissioned” blockchain a legitimate blockchain. That’s fine with me. I don’t care a whole lot about splitting these semantic hairs. Whatever role enterprise blockchains play in the future, I don’t think they will be based on anything as energy intensive as proof-of-work.
I am wary of blockchains that don’t cross organizational boundaries. It seems to me that the most important feature of a blockchain is the ability to do trusted computing with untrusted participants. So the first question I’d ask of any blockchain developer is “who don’t you trust?” If the answer is “we trust everyone who is allowed to use our application,” then it’s time to head back to MySQL. In the Maersk and Walmart applications, it’s pretty clear who isn’t trusted. There are plenty of incentives for shippers to forge or falsify paperwork. There are plenty of produce suppliers who might be willing to way “trust me, this lettuce really isn’t from Arizona.”
I am also wary of re-centralizing something that wants to be decentralized. But I think we have to reconsider what “centralized” means. Let’s imagine an HR blockchain for a large corporation, with tens of thousands of employees. I’m tempted to say that this fails a few of my tests: it’s centralized (probably owned by whoever runs global HR), and there isn’t “distrust”: we have a happy company, working toward common goals, and one big HR group that keeps the paychecks coming. Just use a traditional database and get over your blockchain fascination.
But that’s not true. I’ve never worked for a large corporation, but even small companies are rarely happy families. They are collections of fiefdoms, many of which don’t trust each other, some of which would gladly stab another group in the back. So maybe an HR blockchain that runs entirely within one company isn’t out of place. It would be an immutable distributed database for performance evaluations, hiring decisions, and other administrative records. A blockchain might make it impossible for HR to say that a harassment complaint against a powerful senior manager was never filed. Maybe such a blockchain would make it possible to distribute control to local working groups, blunting some of the inter-group rivalry. Maybe smart contracts could be developed to manage compliance without requiring a central authority. And in a setting like this, maybe many of the issues that make blockchains hard fall away: you can do updates, you can tolerate relatively slow writes (on some applications), you don’t need a huge number of nodes, and so on. Incentives are less of a problem when they’re derived from real-world situations, like knowing that your employees will be paid fairly, or that Walmart will accept your next shipment of tomatoes.
It’s certainly possible that enthusiasm for blockchains has prevented developers from investigating simpler, but less trendy, solutions. In an email exchange, Jimmy Song suggests that all three of the applications I’ve mentioned (Maersk, Walmart, and the hypothetical HR application) could be solved more simply with a triple cryptographic signature (two participants plus an auditor). He may be right. But I’m still puzzled: Why not a blockchain? A blockchain is a ledger, but a ledger does more than simply record transactions. A ledger tracks resource flows—for traditional accounting, that resource is cash, but other resources can be tracked, too. And flows are exactly what you care about if you’re dealing with produce supply chains or shipping containers. Until we try both solutions, we won’t know which will work better.
Most criticisms of enterprise blockchains are making important points. Developers need to understand those criticisms and think seriously about how they apply to their projects. You have to think about the rate at which transactions can be processed, and you have to think about the computing power required. You can’t wish these problems away, or assume that someone else will solve them for you. It’s also important to think about other solutions, and not to be blinded by the blockchain hype.
But it’s also important not to let criticism limit our imagination. When we finally find the best use cases for blockchains, they may look strange and different, like nothing we would have expected. To discover those applications, we may have to stumble through many poorly thought out experiments and discard lots of poor ideas.
That’s how technology makes progress.
Related:
Learning Path: Introduction to Blockchain Applications — Dr. Jonathan Reichental helps you fully understand the scope of blockchain technology and how it can be used across a variety of applications and industries.
