By Chris DeRose
Immutability! It’s the buzzword that magically transforms a simple database into the next milliondollar VC fundraise. However, most of the projects that advertise this feature are not being entirely honest about just what kind of immutability they’re offering. And it’s becoming increasingly clear that nearly all of these claims are at best, hyperbolic.
Prior to blockchain, immutability existed in closed systems, through the benevolence of a custodian. After blockchain, or so the thinking goes, such immutability is simply a magical property of blockchains.
But, nothing could be further from the truth.
Defining immutability
For most in the bitcoin world, immutability is only available through proof of work. Outside the bitcoin space, others have little apprehension about claiming that their systems are similarly immutable.
But, arguments over energy consumption aside, the truth in the matter is that immutability is rare in all blockchains, bitcoin included.
Most blockchains promote a system whereby data is syndicated to all peers participating in the network in what could be called ‘folders’. These folders are cryptography signed by network participants and broadcast to all parties. The marketing literature in the industry would have its readers believe that because these folders are signed, somehow they are required to be kept by all peers thereafter.
However, such a mechanism is very analogous to how secure transactions are bundled in existing databases and message passing systems. Even the lowly protocol “SMTP”, by which we send our e-mail, supports the sending of multiple messages in a single, encrypted request, and such batch operations are common throughout most server inter-messaging protocols.
So what is it about blockchain that’s any different? Well, not much.
At first glance, bitcoin full nodes would seem to force upon its participants the need to store data. However, efforts are consistently being made by the Bitcoin Core team to reduce these storage requirements.
With ethereum, ‘pruning’ is a feature that is consistently promoted as a design goal. And to all of the coders in the blockchain space, immutability is starting to become regarded as a bug, and not a feature.
Space constraints
Why? The obvious reason is that this feature is inordinately expensive.
Mobile clients don’t have the disk space needed to retain all transactions in a network, nor do users want to bear the inordinate startup times required to spool up a node and download all the transactions that have occurred.
As a network grows, the bandwidth requirements become significant, and the response times that deal with having to track system state grow similarly.
This overhead becomes particularly pronounced with respect to low-overhead systems.
Should IoT become a mainstream goal of ‘blockchain’, it would be unreasonable to expect your toaster to include the resources needed to maintain the data of all toasters worldwide, for the entire history of IoT toasting.
So, how exactly does one force immutability in their blockchain? Either by actively paying for it, or conversely, by incurring cost-based risks in the network consensus for those that don’t store your data.
Available options
For those who store their data ‘immutably’ in bitcoin, there are currently two competing options for doing so: “OP_RETURN”, and ‘Transaction Output’ (TXO) encodings. OP_RETURN is a relatively recent invention designed to give programmers an easy way to encode their data into transactions without encumbering the function of the blockchain.
This mechanism is popular with such meta-protocols as Omni, Open Assets, Blockstack and Factom. “TXO” encoding is less popular, and is used by projects such as Counterparty and Drop Zone.
So what’s the difference?
TXO encodings disguise data as user addresses, making them indistinguishable from actual user addresses to relays. OP_RETURN encodings label the data simply as ‘data’, and make no pretense in disguising the encoded data as a network user’s value transfer.
So, why would anyone want to encode data as an address? Well, that’s what keeps the network from discarding that data.
For a blockchain, keeping track of outputs is essential to keeping in ‘sync’ with the network, and should a node discard an actual user’s outputs, that node stands to become a victim of a double spend in the case that this user subsequently spends money.
It is in this way that the nodes are incentivized to track this data – it will literally cost them money to not do so.
Further, it is very difficult (and currently impossible) for the network to discard data that is merely disguised as a blockchain user’s wallet. Unfortunately for blockchain designers, this is where the economic realities of immutability get particularly disconcerting.
Cost benefits
Immutability is expensive.
The bitcoin developers are constantly vigilant about trying to filter these ‘disguised’ users as much as possible. Depending on how they’re encoded, these transaction outputs (particularly the unspent outputs) often need to be kept in the most expensive memory of network nodes – RAM.
Placing the data in this location reduces the number of participants on the blockchain, and increases the time needed to process transactions. For any educated blockchain engineer, this feature is seen an enormous externality cost that creates a tragedy of the commons for all participants in the network.
It is probable that bitcoin will proceed in a manner whereby immutability is treated as a bug, and not a feature, and where ‘full nodes’ delete data more often than it is saved.
For non-bitcoin systems, these problems are even more compounded. Many of the systems being pitched as ‘immutable’ have no incentive structures for nodes to retain data that doesn’t concern them, and these data are often even more trivially discarded than are bitcoin’s “OP_RETURN”.
Much like SMTP (the technology behind email), nodes store only the messages that are relevant to themselves. This ‘feature’ of not storing irrelevant data is what allows the global email systems to process so many messages and scale to the needs and size of the entire human population.
For those that believe blockchains enable immutability, a reckoning will soon be in order.
Perpetual motion claim
Who will hold the world’s data, and what incentives will blockchain providers actually be able to provide their users to achieve this goal?
While many have been caught up in the hype behind immutability, most of these claims will at best regress to the basic signing mechanisms that have been in place for decades, with little to differentiate their systems from incumbent message passing solutions.
On paper, immutability sounds nice, it seems to be a dubious proposition that some magically benevolent server will show up to perform this service. And certainly, blockchain will not make that benevolence any easier than it is with incumbent HTTP systems.
Purchasers of blockchain systems should ask basic questions about how and why their competing institutions will store their data, as it’s becoming increasingly certain that should any of these systems actually achieve scale, that promise will quickly be broken.
As for bitcoin’s promises of immutability, it remains to be seen what actions will be taken to prune the TXO-based storage, but judging by recent activity in the bitcoin developers community, it would appear that benevolence is increasingly the favored opinion.
While the world searches for uses of blockchains outside the realm of monetary value transfer, it would seem that programmers will soon find that their solutions will regress to the economic realities that faced the original “decentralized” technology, the Internet itself.
Or, put more simply, the unlimited immutability of ‘blockchain’ may just end up being a perpetual motion claim, whose reality will soon catch up with the limited resources of the ‘decentralized’ Internet that we already know and love.