Glamorize your problem domain (2022)
Glamorize your problem domain<p>by ftxbro - March 27, 2023<p>I gave a conference talk last year, tldr: “we build apps. Here are all the lessons we’ve learned from framing this as a blockchain problem.”<p>My introductory joke was “how to become a blockchain expert in three easy steps”.<p><pre><code>    Work in software
    Work on a project
    Decide that whatever you’re working on is a blockchain
</code></pre>
But was I truly joking? I genuinely believe teams should try really really hard to draw analogies between what they are building and “classic”, well-understood, formally studied systems and ideas in computing. Is your web API a blockchain if you squint? Is your authentication system really a smart contract if you squint? Squint, I tell you, squint!<p>The reason is not so you will somehow be able to apply advanced techniques from research journals to your web apps. You won’t. But there are other advantages.<p>First, you get a vocabulary for free. If you pretend your app is actually a blockchain, you can talk about “blocks” and “transactions” and “smart contracts” and “consensus algorithms” – things that you would otherwise have to invent bespoke names for, or be unable to talk about at all.<p>Second, analogies can be a good source of interesting ideas. If your web app is a blockchain, HTTP is your transaction protocol, and user authentication is your smart contract, could you build a “mining pool”? What would that mean? Could you attribute the performance issues in your app to particular parts of the blockchain? Also what are your consensus algorithms? Is it worth introducing a new one? Should your app be a proof of work blockchain or a proof of stake blockchain? Does that distinction even make sense? These won’t all be good ideas, it is plain to see. But you might strike gold.<p>Third, morale. It’s fun to be able to think of yourself as a blockchain* expert, even if the asterisk is big and the analogy is a little hazy.<p>Last, I’ll observe it’s quite within the realm of possibility you’ll encounter a problem that truly belongs to the domain of e.g. blockchain development, no squinting required. Satoshi Nakamoto wrote<p><pre><code>    The root problem with conventional currency is all the trust that&#x27;s required to make it work. The central bank must be trusted not to debase the currency, but the history of fiat currencies is full of breaches of that trust. Banks must be trusted to hold our money and transfer it electronically, but they lend it out in waves of credit bubbles with barely a fraction in reserve. We have to trust them with our privacy, trust them not to let identity thieves drain our accounts.
</code></pre>
I agree something seems to be awry with the financial industry’s popular “fiat currencies”. You can hardly spit without hitting a currency that, frankly, deserves it. Cryptocurrency these days is “blockchain heaven”. I was on a team years ago that sunk weeks into debugging our app’s flaky payment system, entirely thanks to the traditional banking system’s poor transparency and terrible security. In theory, cryptocurrencies that are based on blockchain technology – i.e. Bitcoin, Ethereum, and others – should be better than fiat currencies. In practice, though, the blockchains of these cryptocurrencies fail to inherit most of the UX benefits of traditional currencies, i.e. it is not natural to use them for everyday transactions, they are not widely accepted, and they are subject to extreme volatility. (Searching the Internet indicates that some of this is possible, I have never seen it done.)<p>Nakamoto, a blockchain developer, unsurprisingly prescribes blockchain theory as a remedy. Our cryptocurrencies would be better if their authors knew how to write smart contracts, formally define their blockchain’s consensus algorithms, etc.<p>Maybe so, but I’ll settle for far less than formal semantics. I just want the authors of cryptocurrencies to think of themselves more glamorously. Don’t be a payment system designer - your job isn’t just to facilitate transactions in a rigid way. Be a blockchain developer - your job is to give your users a way to express themselves, to send and receive money, elegantly, in a decentralized way - to guide them interactively, help them discover what is possible, and steer them away from scams. Provide the trappings that you would demand of a modern, widely accepted currency – a user-friendly wallet, fast transaction times, low fees, and so on – or at least as many as you can afford.<p>Doing this correctly without reinventing the wheel (please don’t reinvent the wheel) almost always involves building your cryptocurrency on a larger, established blockchain. I find the “Ethereum” blockchain by Vitalik Buterin to be an excellent example of what I think is a great UX for a cryptocurrency. Ethereum is just a blockchain, and so you can use all the features that the blockchain ecosystem provides without any fuss. The Dogecoin blockchain by Billy Markus is a less stellar example. It is based on the “Litecoin” blockchain, and so gains the security of that blockchain – however it obscures the entry point and execution path from the user, and so has a poor user experience. (It’s a similar story for many other cryptocurrencies.) Of course, still miles better than traditional banking.<p>Even if you don’t work on a finance-related product, the internal tools and systems of a large-ish organization probably have a “blockchain” or two that would benefit from being recognized as such. I often think about a talk I saw that describes IBM’s approach to supply chain management and “Hyperledger Fabric”, a blockchain IBM invented for describing supply chain transactions and cross-organization requests. I can’t speak personally to how effective their tool is, but I’m comfortable predicting that it is better than the counterfactual where developers just do everything in traditional databases.<p>Go forth, the blog post is ended.