Why is blockchain the way it is? Why should any storage system — no matter how distributed or “immutable” it is — need to consume so much of the world’s electricity?
The answer is more political than technological. I don’t mean party-political, but in the sense that politics is 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 favour 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.
When planning new blockchain applications, you’ll improve the chances of success by better understanding the technology’s unusual objectives and starting assumptions. Because 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 to crowdsource a special decision-making process which could be done by a single trusted system administrator.
The importance of order
All practical cryptocurrency systems rely on the 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, for example “Transfer 10 Clams from Alice to Bob”, results in the same piece of coded text, or “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 by some system operator akin to the private credit card systems. The idea of a non-fiat cryptocurrency seemed a fantasy — until Satoshi Nakamoto invented Bitcoin and its specific style of 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. That’s 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?
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? That is to say, 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 (IoT), 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, but on my analysis they fall into this problematic category.
Some futurists envisage swarms of autonomous robots self-organising to achieve various sorts of clever emergent outcomes, but all industrial IoT today is really quite orderly. Devices come with serial numbers and network addresses! There is no uncertainty whatsoever about where any device’s 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 crowdsource consensus.
Encryption for confidentiality also 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. And yet encryption for confidentiality requires key lifecycle management and end user registration. We need assurance of which key pair goes with which intended recipient of the encrypted data, so that it doesn’t fall into the wrong hands. And if we can organise that, then decentralising any other aspect of the record keeping 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 that it delivers security in the absence of centralised key lifecycle management, and that’s why it has such a weird and wonderful and inefficient architecture.
In the real world, most use cases require user registration, and in those cases blockchain loses its reason for being.
This is an edited version of a post originally published at Constellation Research, Order out of chaos. Photo by Christian Lue.