After building Ethereum contracts for the last three months, I have briefly stepped away to build a small centralized system again. Working with the tools that had been my forte for years is familiar, but my perspective on them has also changed in important ways.
Specifically, I am building a central database for Dharma Protocol events that are emitted on the Ethereum blockchain. My thoughts while building this central database are: Why would anyone ever trust me that these events are correct? We could clearly never use this in an external production context! But the ironic thing is, for many years I built systems just like this that were used and trusted by millions of people. The systems look the same, but my understanding what what is secure and robust has fundamentally changed since I started blockchain work.
Seeing something familiar with new eyes can yield surprising realizations, as reported by many people who experience “reverse culture shock” after travelling - and I would say that, in way, I experienced something similar returning to the world of centralized engineering. Although I haven’t completely imbibed the tokenize-the-world flavored kool-aid, I submit that the world-computer vision of blockchains now seems firmly superior in my mind.
Centralized solutions are fragile and insecure in numerous ways. Even as the developer or developing team, it’s not trivial to know that a centralized system is uncorrupted. If the EC2 instance running your code gets compromised, it’s possible that it will run for a long time without the team being aware of any problem. Blockchain projects don’t have this insecurity due to their consensus mechanisms and the immutability of contracts once deployed.
Contract bugs and vulnerabilities are still possible, sure, but it’s nothing like the anxiety I experience now with centralized systems — the sense that I cannot trust even the output of well-tested code. Let alone convince other people that it is trustable and I haven’t tampered with the data to inflate growth numbers, like Wells Fargo, Snapchat, and many others have done.
This leads me to the feeling that blockchain replacements for many common projects are inevitable. Once trust has been established in blockchain-based solutions, reverting to centralized projects for anything with high value will seem unconscionable. Sure, blockchains are currently inefficient - but this is infinitely better than something you cannot trust.
Some applications such as Amazon are trustable because we have a mental or paper trail for what we expect to happen. If those systems yield something that conflicts with our expectations, we can dispute it formally. These disputes are time-consuming and expensive but possible. However, there are many applications where there is little-to-no ability to dispute a computation. For example, I am listening to music using Spotify now and trusting that somewhere in the gigantic complexity of that system there is nothing preventing the musician from receiving fair payment for my entertainment. There is no trail backing this kind of trust. We assume that Spotify’s private code is correctly logging each track played, accounting the monetary payments correctly, and that they have no compromised server meddling with that process. Compared to the transparency inherent in blockchain projects, a system like Spotify will seem ridiculously untrustable to anyone from the blockchain world. The more people become experienced with blockchain solutions, the less support centralized solutions will inevitably receive.
I’m sitting in NYC during Blockchain in Finance Week, hacking on decentralized Solidity in one tab and centralized Node.js in another. The contrast is clearer than ever. I can only imagine that there will be a sweeping revolution in software development, that many of our most important services will be replaced with decentralized solutions, and our notions of what it means for services to be secure will be completely revised. It might not be in the current wave of Ethereum dApps. But it’s coming.