Blockchains Are Not About Decentralization
Decentralization is not a useful feature of blockchains, it’s a necessary limitation to enable the real one — security.
In the rubble of the dotcom boom at the turn of the century, O’Reilly launched a book and series of conferences which were to morph into Web 2.0. The first of these was called O’Reilly Peer-to-Peer and it revolved around a group of technologies that often had decentralized, shared databases, from Napster to Gnutella, Jabber, Freenet, Free Haven and Groove.
These decentralized services also decentralized revenue potential, so the alternative, very, very centralized versions of their same use cases (the ‘platform’ companies), became the largest corporations on earth. A centralized technology architecture allowed for a centralized business model and operating as a trusted third party, in the middle, allowed for capturing money from information flows. This is how a platform business works. Ironically, the co-founder of the most famous decentralized product, Napster, later became the president of the largest centralized platform of all — Facebook.
The 2001 wave of decentralization led to the platform era of today.
Today there is another wave of decentralized software driven by Bitcoin and, more generally, blockchains. It has also lead to an assumption that decentralization is a trend with inherent advantage. This would be a wonderful thing, if true. We could create mutualized versions of everything from Uber to Facebook, where the providers and/or users would be the owners. However, the early signs that this will happen for these kinds of use case are not good. Just like before, the decentralized nature of this software, which is largely based on innovative protocols, has lead to a tragedy of the commons as more money is to be made speculating on top of the protocol rather than tending to it.
The two graphs below, taken from this excellent article on the problem of funding the evolution of blockchains, demonstrate the lack of growth in people working on supporting the core public chain protocols.
This doesn’t mean that this wave of decentralization will be replaced by platforms, however, as this time there is a byproduct of decentralization that makes it a necessary evil, in terms of its business model. That byproduct is security. Blockchains are slow, inefficient databases that have little advantage over other means, even in terms of accuracy — but they have one fantastic advantage, in their purest form they are unhackable.
What we mean by unhackable, here, is not that nobody can see inside — that blockchain databases are secret — they are the opposite, very public. And they are public because they are replicated all over the place.
The usefulness of blockchain unhackability can be illutrated with a real world example that has nothing to do with technology. If you knew a secret truth that someone would silence you for, to protect a lie, the best thing you could do to protect the truth would be to sacrifice secrecy — ie tell everyone, so that the person trying to protect a lie would have to silence an impossible number of people. In essence, that’s what a blockchain does, and it makes it hard to fake things like bank balances, by making the balances very public. You can keep ownership secret but only if you keep not just the keys to spend money very secret, but the fact that an account number is owned by you.
By unhackable, in the context of blockchains, we mean untamperable, all the replicated systems are the same and to tamper with the truth, you’d have to hack the majority of them.
Blockchain systems are about preventing lies, not protecting secrets. While one person’s benign privacy is another person’s conspiratorial secrecy, in today’s networked world there is a choice between privacy and security. More truth means less secrecy. More privacy means less security.
This time, decentralization may be here to stay, but as a necessary inefficiency for secure, untamperable, networks.
We know blockchains are unhackable in theory (those based on proof of work), from their mathematical construct. In practice, a public database based on this technology that is literally money, that has managed to survive being successfully hacked for several years, is nothing short of miraculous.
The obvious use case for resilient databases is ones that store information that has value itself, like simple transactions of value or more complex contractual transactions, ie where the contents of the database itself has intrinsic value. But there is another use case — where the database is connected to something in the real world and where there would be a large cost if it is compromised, such as a hardware controller in a nuclear power plant.
Two things make the latter use case a very important addition to the financial one, for blockchains:
1. we are now connecting hardware infrastructure to the Internet or other networks that costs money and potentially lives if it is compromised.
2. The existing software running over these networks consists of layer upon layer of software modules, created for ease of development rather than understandability, where it costs more to debug or ensure security than create in the first place.
Today, software that costs more to debug than to produce, results in massive unnecessary overhead due to complexity.
We have reached the ludicrous situation where the amount of code to render a single web page is roughly the equivalent of an entire banking system’s core ledger from the 1970s. This has created an enormous problem where we have traded low capital expenditure (software development costs) in exchange for higher future operational costs (making things secure).
This problem is sometimes referred to as technological debt and there is a point where building new software on top of old, in an era where everything is connected to the Internet, will lead to ‘default’ on that debt, through its vulnerability to malicious attack.
A web of blockchains is emerging as speedier but less cryptographically secure, proprietary private chains, peg to the bulletproof public ones such as Bitcoin or Ethereum. Unlike the web which was a protocol suitable for hyperlinked information this will be a protocol for things like contracts or connections to hardware controllers that need to be really secure. It will be important for things where the tradeoff from speed and decentralized replication is outweighed by security — such as IoT devices that control physical infrastructure and utilities to financial contracts and transactions.
The web is essentially a protocol based on one-way links and these are good for content publishing (I can link to you without permission) the essence of blockchains, however, is a new alternative protocol to the web, and one way of looking at it is that it’s based on secure, two-way links.
A transaction on a balance sheet has to link from one place to another, with the other being aware of the link (ie bi-directional and not like a web link), for the numbers to add up and for the system to maintain state (settled transactions and account balances). This is why blockchain protocols and the databases they imply are the opposite of fast, inaccurate, cache based, full text ones that the web is built on.
A blockchain based web will be slow and inefficient to update and its decentralized nature will increase that latency and inefficiency.
But the cost will be worth it for things which require security.
