There’s a scene in Angels and Demons where the Camerlengo asks Robert Langdon if he believes in God. Professor Langdon replies “faith is a gift I have yet to receive“. I found this interesting because, despite not being part of the church, Langdon has skills that are crucial to it’s survival.
I’m no Robert Langdon, but perhaps another reason why that scene resonated with me is because it kind of describes my relationship with blockchain technologies. On a technical level I could not be more enthusiastic about blockchain technology. A while back I even did some paid consulting work involving blockchains. The issues are all fascinating, from a high-level with the Byzantine General’s Problem, right down to lower level stuff like the bounded control-flow of the scripting language, and even to seemingly simple things like memory buffer eviction policies designed for resilience against abuse. It’s all fun stuff.
However, beyond the pleasure of intellectual pursuit, for now I am firmly a blockchain skeptic. It just doesn’t seem like blockchain is as widely applicable as people say it is. Some areas like syndicated loans may be ripe for blockchains, but that’s a very niche field with high barriers to entry, and very few projects actually operate at that level. And yes, I realise there’s plenty of institutional support even on the retail end of finance, but I really don’t know if there’s much more to it than FOMO – after all, if you’re in banking, spending a bit on blockchain projects is cheap insurance.
In real conversations the skepticism often manifests as point objections, such as:
- Full confirmation is too slow for most use cases.
- What do you mean bitcoin enables micro-transactions? Microtransactions have been powering the Internet for a long time. Sure with Bitcoin you don’t need a prepaid model, but prepaid hasn’t been that much of a problem thus far, so who cares? And anyway many microtransactions require low latencies which again are just fundamentally at odds with the blockchain model.
- Are you sure using a blockchain results in a cheaper solution, or is it just that more of the costs are kept off your books?
Each of the above will have pro-blockchain counter-arguments, such as SPV instead of full confirmation, but it just ends up going in circles.
These objection handling conversations can get a bit frustrating, so maybe we should stop starting from the premise that something should have a blockchain component, and then try to find flaws in the idea. What if we approached it from the other perspective: why should this thing have a blockchain?
The trouble is, in my experience, there is a tendency for people to argue that trust (or trustless-ness) is an intrinsic property of blockchain technology, and when they see a problem with some trust component they immediately think of incorporating blockchain as part of the solution. Is that reasoning really good enough? Or is trust merely a confusing straw man in this situation? We should be very clear on when and why a blockchain is needed, because it is expensive technology, and introduces major limitations on what users and operators can do.
Let’s start from first principles. What is a blockchain? And building on that, in what situations does one need a blockchain? For me, the penny dropped when I happened upon a gem in the a16z podcast. I feel Adam Ludwin really nails it about 30 minutes in, when he says (I’m paraphrasing for conciseness):
A blockchain is a database of assets that is shared with participants in the network, where a given asset is controlled by the participant who owns the asset, and not controlled by whoever controls the database.
The key thing is that whoever controls the database does not control the data. What does that mean? Let’s spell it out plainly.
If you take a copy of a database that is stored on some infrastructure that you control, e.g. the full blockchain that is downloaded by a Bitcoin client on your computer, you can go ahead and change the data as you like. It is your data. It lives on your computer. However, the data is structured in such a way that by making these arbitrary changes, you would have violated the integrity of the database, and consequently the database ceases to be valid, and is effectively no longer usable. It’s not a question of knowing how Bitcoin works – you can know everything there is about Bitcoin, but even armed with perfect understanding, you will never be able to make just the right edits to the data. The only way changes to your local copy of the database can be made without breaking the database is for the “owner” of the relevant entries within the database to make the required changes.
This the key property of blockchain technology: a copy of a dataset can exist anywhere, but to maintain the integrity of the dataset, individual items of data within the dataset can only be manipulated by a specific actor.
The word “only” in the above must be interpreted in the strictest technical sense, not “entrepreneur-level strictness”; there is no assumed database administrator with a secret key who can make the right binary-level edits or whatever. That’s the cryptographic magic of blockchain. It is absolute.
Do you need that magic? Are you sure you can’t just use a properly secured website with a normal database backend, to which you can make edits should customers screw up a request and need you to do a rollback? I mean if you’re building a solution for people to trade unused cellular hours, having Vodafone as an all-powerful database owner doesn’t seem so bad. The same could be said for a loyalty points trading platform.
It’s not a technical choice, it’s a business case choice. For your idea to work, do you need a database where there is no database owner who can make arbitrary updates?
If you answered yes, then congratulations, you indeed have a problem that may require a blockchain. Otherwise, you should default to a traditional database solution instead of needlessly accepting all the expense and loss of control that comes with a blockchain.
Maybe one day I will receive the gift of faith. But until then, I test every idea against the key requirement described above. Regardless, I’ll try to find some spare time to learn about things like lightning networks and segregated witness, just for the intellectual fun of it.