Why is blockchain the way it is? Why should any storage system ― no matter how distributed it is, or “immutable” ― need to consume such a lot of the world’s electricity? The answer is more political than technological.
I don't mean party-political, but more basically blockchain is always about power. Blockchain is rooted in the rejection of fiat currency and centralised administration. Cryptocurrency advocates generally oppose the way that traditional money is organised, and favor an unorthodox and expensive way of organising electronic cash. And most other blockchain applications seek essentially to change the way that shared data is managed; that is, they want to alter power structures.
By better understanding its unusual objectives and starting assumptions, you’ll improve the chances of success when planning new blockchain applications (experience shows at least 90% of blockchain pilots are failing to proceed to production). The reality is that most proposed extensions of blockchain beyond cryptocurrency are not good ideas, as I hope to show.
Can we generalise from cryptocurrency to data management?
The Bitcoin blockchain takes an exorbitant approach to solve the well-understood Double Spend problem in cryptocurrency. Bitcoin started from a desire to remove some of the management structures of conventional money systems (structures which happen to simplify transactions and save costs). When considering non-currency applications for blockchain platforms, we have to first check whether the same approach is warranted, and whether the same assumptions are even sensible. Most real-life data management is much more complex than the rarefied world of cryptocurrency.
Thousands of nodes are needed to support Bitcoin’s blockchain and the like ― not because storage of transaction logs really needs to be distributed, nor because account holders don’t trust other computers ― but in order to crowd-source a special decision-making process which could be done by a single system administrator if it were trusted to do so. The goal of the original blockchain was to arrive at a chronological order of accepted transactions, as a means to stop Double Spend.
The importance of order
A core feature of all practical cryptocurrency systems is cryptographic private keys, possessed by account holders. Private keys are used to digitally sign transactions, to prove that someone is in control of an account and that they consent to move some of their balance to another account. The Double Spend problem arises simply because using the same private key to sign the same transaction (e.g. “Transfer 10 Clams from A to B”) results in the same cryptogram. So if we see the same transaction more than once, how can we tell if it’s real before anyone takes advantage of a bogus balance? There needs to be a mechanism for watching each transaction and deciding if it’s legitimate or an attempted Double Spend.
For decades it had been assumed that the oversight of cryptocurrency movements would have to be done centrally, by a digital reserve bank or some scheme operator (akin to the private credit card systems). The idea of a non-fiat cryptocurrency seemed a fantasy ― until Satoshi Nakamoto invented Bitcoin and the blockchain.
Arguably the most ingenious aspect of Nakamoto’s blockchain is the way it crowdsources the oversight. The outcome of the blockchain algorithm is a public history of accepted transactions, which is updated periodically and shared across many nodes. The famous “consensus” process underlying the blockchain delivers agreement about just one thing: the time order of transactions ― for that is enough to detect and reject attempted Double Spends.
Cryptographic security systems usually require key lifecycle management to ensure certain private keys are in the hands of certain registered users. But blockchain was designed on the basis that no authority registers the account holders. And yet it pretty much guarantees that Bitcoin will move from one account to another, with nobody knowing anything about who is in control of the essential private keys. Blockchain is the only cryptographic system I know of that provides such certainty without centrally organised key management. It literally produces order out of chaos.
Is there anything (else) like cryptocurrency?
So there’s really only one question to ask before qualifying a potential application for most blockchains: Is your use case truly devoid of key lifecycle management? Do you want a situation where nobody knows which private keys go with which user accounts?
Foregoing key lifecycle management is highly unusual, which explains why beneficially generalising blockchain to regular data management is so rare. Most business systems have an intrinsic order: there’s a scheme by which users, accounts and/or devices all go together. Strangely, some of the strongest interest in blockchain lies in environments that are otherwise highly organised, such as supply chain, asset management, and the Internet of Things, yet in these settings, key management and user or device registration are normal.
If Key Lifecycle Management is necessary, rethink blockchain
If there are other reasons for needing key lifecycle management, then you should rethink blockchain or crowdsourcing consensus. IoT and supply chain are widely touted blockchain use cases, which fall into this problematic category.
Some futurists envisage swarms of autonomous robots self-organising to achieve some sort of outcome, but all industrial IoT today is far more orderly. Devices come with serial numbers and IP addresses! There is no uncertainty whatsoever where any given cryptographic keys are located.
Likewise, there’s no crypto-chaos in any supply chain. Growers, makers, distributers, agents, warehouse personnel and couriers are all employees or contractors; they’re all formally registered, and they interact with supply chain records via specific accounts and terminal equipment. There’s nothing about this sort of environment that requires you crowd-source consensus as to the order in which transactions take place.
Encryption for confidentiality also creates erodes the blockchain proposition. Almost everybody agrees that personal information should never be held on a public blockchain, but many pundits presume that encryption will make it OK. But encryption for confidentiality requires key lifecycle management: you need assurance of which key pair goes with which intended recipient of the encrypted data, so it doesn't fall into the wrong hands. And if you can organise that, then decentralizing any other aspect of the ledger is futile.
Blockchain brings a heady basket of benefits: extreme tamper resistance, decentralisation, synchronisation, and ultra-high availability. But none of these are unique to blockchain. Blockchain’s only special trick is it delivers security in the absence of key lifecycle management, and that’s the explanation for its weird and wonderful and inefficient architecture. In the real world, most use cases require user registration, and then blockchain loses its reason for being.
