7 questions to ask before you launch an enterprise blockchain project
Successful projects will think seriously about what blockchains mean, and how to use them effectively.
Blockstream (source: Gentlejack35 on Wikimedia Commons)
We’re only at the beginning of the blockchain story, not the middle or the end. There’s no shortage of activity and ferment. If the Bitcoin blockchain is the first-generation proof-of-concept, and the Ethereum blockchain is the second, we’re now starting to see third-generation blockchains. Those blockchains include projects like Hyperledger, Cardano, and EOS. They focus on the obvious shortcomings of the existing blockchains–most notably, transaction throughput and a user interface that can fairly be described as “savage.”
Enterprise blockchain projects will only be successful if they take advantage of a blockchain’s unique properties. I’ve written elsewhere that a blockchain is a distributed ledger, shared by untrusted participants, with strong guarantees about accuracy and consistency. With that in mind, here are some questions to ask if you’re considering an enterprise blockchain project.
Learn faster. Dig deeper. See farther.
What exactly are you trying to accomplish?
Look carefully at your requirements, and ask yourself whether you really need a blockchain. Do you need the additional guarantees about agreement that a blockchain provides, or would a distributed database suffice?
How much do you trust your partners?
Untrusted business partners point you in the direction of blockchains. And they may also point toward proof-of-work or proof-of-stake, rather than simpler (and faster) permissioned blockchains.
How public or open do you need to be?
Who needs to participate in your blockchain? There is a continuum between a public blockchain like bitcoin or Ethereum and the smallest, most carefully controlled, private blockchain. I can imagine special-purpose public blockchains for applications like power microgrids (or, for that matter, locavore farming). I can imagine blockchains in financial services that only serve a small number of partners, and are essentially private. A blockchain that only serves a single organization is probably a cargo cult. It may look like a blockchain, but it doesn’t add any value.
What are your data integration issues?
The biggest problem facing enterprise blockchains might not be an agreement protocol, but integrating all the legacy data formats and structures that blockchain participants use. Health care blockchains are a good example of this problem. There are hundreds of medical records formats in use, and any medical blockchain will have to do something to reconcile those formats. Any blockchain that crosses enterprise boundaries (and even blockchains that live within corporate boundaries) will need to deal with data integration, and solving those problems may well be harder than building the blockchain itself.
If you need “miners,” who will they be, and how will you compensate them?
On most current blockchains, including bitcoin and Ethereum, “miners” do the job of validating the blockchain’s consistency and adding blocks. They don’t do this work for free. ICOs (initial coin offerings) are all the rage, and it’s easy to imagine paying miners with cryptocurrency (after all, that’s what bitcoin and Ethereum do), but it’s hard to imagine established enterprises issuing their own currencies. Are there alternate forms of compensation (for example, data or CryptoKitties) that might work?
What are your performance requirements, and how will you meet them?
The bitcoin and Ethereum blockchains currently handle about a dozen transactions per second. For many enterprise applications, that is too slow, by several orders of magnitude. You need to think about what kind of performance you need, and how you’ll get it. There are a number of possible solutions, including the bitcoin lightning network; replacing the compute-intensive “proof of work” that miners perform to add blocks; and permissioned blockchains, such as Hyperledger’s Fabric.
What are the legal ramifications?
Recently, I’ve seen several people ask whether blockchain applications can comply with GDPR and other regulations. That is certainly uncharted territory. It’s very difficult to see how a “right to be forgotten” could be implemented on a ledger that doesn’t allow previous entries to be deleted. I don’t think the answer is that blockchains can’t comply; the answer will depend on exactly what data you’re storing in the blockchain, how that data is used, and how private or public your blockchain is.
Many cryptocurrency advocates are critical of enterprise blockchains, and these questions are largely drawn from those criticisms. Those criticisms don’t mean that enterprise blockchains don’t work, but they do raise issues that need to be addressed. You don’t want to build a blockchain just to discover that you’ve really created a very slow distributed database, or that nobody wants to verify your blockchain’s consistency because you haven’t thought through compensation.
This is a great time to be experimenting with blockchain technologies. Aside from bitcoin itself, we haven’t seen many projects emerge from the tire-kicking stage yet. I’m confident that, in the next few years, we will see many enterprise blockchains in production. The ones that survive won’t be the “me too” projects; they’ll be the projects that have thought seriously about what blockchains mean, and how to use them effectively.
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.