This is the first of a two-part article where we critique two major claimed applications for Bitcoin and decentralised public ledgers (DPLs) more generally. (Though instead of the acronym, we shall simply say ‘Bitcoin’, which was the first and remains the archetypal example of a DPL.)
The first of these supposed applications — that Bitcoin can serve as a tamper-resistant database — is examined below. The second — that Bitcoin has utility as a sort of next-generation internet with enhanced privacy — is the subject of our first podcast.
The chance of a stray bullet at a formal dance is never precisely zero
Extreme features come with extreme trade-offs. In other words, if you desire the most extreme performance with respect to some property of a thing, then, as a rule, you’ll have to put up with some very poor performance for some of the ‘other’ properties of that thing. Consider a bulletproof ball gown; the gown features, as the name suggests, extreme resistance to penetration by fast-moving projectiles. It is extreme in the sense that the degree of resistance far exceeds that of almost all other varieties of ball gown (and, indeed, evening wear more generally).
It is hard to imagine a realistic scenario in which such extreme clothing would be the rational choice, and where the associated trade-offs (high cost, discomfort, limited breathability, etc) would make sense. However, as we all know, technology is always moving forward — it follows that the various downsides will inevitably grow less over time. Bulletproof fabrics will become cheaper, thinner, more flexible, lighter in weight, and so on. Does it follow, then, that one day all ball gowns will be bulletproof? After all, why not? We may never say that the probability of a stray bullet finding its way into a formal dance event is precisely zero. One day, will it be a no-brainer to select evening wear with this property, since it is only a matter of time before the trade-offs fade into irrelevance?
Remarkably, the answer is ‘no’. Bullet-resistance will never be a routine property of ball gowns. Although it is likely that materials technology will continue to advance so that (eventually) those “other” properties of ball gowns will be close what is considered acceptable today, by the time this occurs, the standard for these properties will also have moved on. At that point in the future, a regular (non-bulletproof) ball gown will be lighter, brighter, more flowing and flexible than anything currently available, meaning that reversion to the ‘old’ set of qualities would still amount to a considerable trade-off, by the standards of the time.
Although the above view could be regarded as pessimistic (ball gowns will never be bulletproof!), it really shouldn’t disappoint us in the slightest. When all is said and done, a dress only needs to be robust enough. So long as it doesn’t tear when the wearer sits down, or disintegrate if stepped on, that is and probably always will be fine, as far as durability is concerned.
Let’s talk Bitcoin
The relevance of this mildly surreal example to Bitcoin is the following: what applies to “extreme” ball gowns is a very general principle, and even holds for decentralised ledgers! To understand this, consider the celebrated property of Bitcoin that it is extremely resistant to tampering (such as improper alteration of data). This property forms the basis of a great many proposals for applications of Bitcoin (and Bitcoin-like networks) each of which requires a tamper resistant append-only database. These include the most talked-about ‘decentralised applications’ of recent times: NFTs (e.g. representing digital art or intellectual property), decentralised exchanges, fractional real estate ownership, and many more.
As it turns out, the argument which has been advanced for using Bitcoin as a database maps precisely into the claim that, one day, all evening wear will be bulletproof: “We know that Bitcoin has this amazing property, now we just need to advance the other aspects of the technology to the point where the trade-offs are acceptable”, so the story goes. This day, however, will never come. Like the bulletproof ball gown, such an extreme level of resistance to tampering will never be appropriate for the overwhelming majority of applications because the trade-off this entails will always be too great.
The line of reasoning followed above is quite straightforward, so why has this been missed by crypto industry creatives and investors alike? It is difficult to say with certainty, and there are likely to be several reasons. For example, it is regularly asserted that Bitcoin (or some similarly decentralised network) is the only way to provide a standardised and neutral platform, on which competing businesses are willing to build. However, although the first such network (with a strong claim to neutrality) was a decentralised public ledger (Bitcoin), there is a more down-to-earth approach to providing such a thing: simply utilise the familiar concept of a centralised service provider, operating within a free market.
In praise of centralisation
In a free market, a centralised service provider is disciplined to behave correctly because, if they do not, customers will go to one of their competitors. Similarly, a public ledger protocol may be run by a central entity (a ‘central node’), while other nodes check that the central node is executing the protocol correctly. If the central node is identified as faulty, these other nodes can vote to replace it. The result is an append-only public database, robust enough for almost any application in practice. Most importantly, its centralised architecture means it can be blazingly fast and scalable.
Notably, this approach is already being followed by the Solana protocol. Although Solana is still comparatively new, its rate of adoption by both users and businesses has been stunning. At the time of writing Solana is the 6th largest coin by market capitalisation, its token (SOL) having appreciated 400x in price since launch just over a year ago. Criticisms of the approach which Solana embodies typically amount to “but it’s not decentralised!” — but of course — decentralisation can never be an end in itself, since the ‘pay-offs’ from increased tamper resistance are diminishing, while the trade-offs are immense. At least for the applications being deployed on Solana, the conjecture that decentralisation is required, is well on the way to being refuted, experimentally.
Solana’s missing piece and Bitcoin’s killer-app
As is the case from most ‘crypto tokens’, Solana’s token plays a dual role: as payment to use the network and for voting — specifically — on matter of governance such as protocol upgrades or replacing the central node. And here we find that something is amiss: Though governance is a fine application for the token, it would be much better if network fees are payable in something which we might call money, such as the local currency. This is standard in the non-crypto world — after all — it would be very inconvenient if subscriptions to Microsoft products were only payable in Microsoft stock! Put differently, the roles of ‘governance token’ and ‘medium of exchange’ should not be conflated, because keeping them separate confers a competitive advantage.
In summary, when it comes to decentralisation and extreme tamper resistance, of the variety embodied by Bitcoin, we make the following claims:
- most applications are strongly disadvantaged by it,
- governance tokens may derive mild benefits from it (though do not generally require it),
- but the killer-application (that justifies the trade-offs) is money itself.
In our next post, we will elaborate on this last claim. As we will explain, the appropriate money in this context is a peer-to-peer CBDC, which requires the generating protocol to be decentralised and justifies the highest degree of tamper resistance. We will argue that, although a centralised protocol like Solana can (and must) use money, it cannot generate it.
This points to a unifying vision for the future of blockchains: with a decentralised protocol as the ‘base’ layer where the money is generated, and all other protocols (boasting features which may not currently be available on the base layer directly) being nested into the base layer in order to use the money.