An Honest Criticism of Smart Contract Platforms
We Wanted Decentralized Cars but All We Got Is Speculation
With the launch of Ethereum and other smart contract platforms like EOS, Neo, Cosmos, and Tezos, we were promised decentralized Uber, decentralized AirBnb, and many other “decentralized apps” (aka “DApps”) as part of a broad shift to “web 3.0” — yet almost none of these promises ever materialized. Instead, all we have to show for billions of dollars of investment into the cryptocurrency space is a massive ecosystem built around one thing, and one thing only: speculation. But why is that?
A common argument is that the major smart contract platforms don’t have “scale” yet in terms of throughput (e.g. transactions per second), but when they do there will be a “gold rush” of useful new platforms that can be built on them. This doesn’t make sense because if it were true, one would expect to see nascent attempts at things like decentralized Uber clogging up the Ethereum network, struggling to meet user demand, and we haven’t actually seen this.
Another common argument is that blockchains and cryptocurrencies don’t create any value for users compared to centralized platforms like (actual) Uber or Airbnb, and that this is the true reason why the promises around a “decentralized internet” haven’t materialized. I think there is a lot of truth to this for most applications people would want to use, including Uber and Airbnb, and indeed my position until recently was that there were precisely zero major platforms that cryptocurrencies could create value for (when compared to centralized platforms).
However, after much consideration, I came to the conclusion that I argue in this post, which is that there is actually a pretty big wedge for cryptocurrency technology to redefine certain types of platforms, but that smart contract platforms like Ethereum are ill-suited to the task of effecting this shift. Moreover, I argue that an unwarranted focus on smart contract platforms has been preventing the space from actually delivering non-speculative value to users, and that dropping this hang-up on them could open the space up to a real platform shift for certain types of applications.
The Wedge for Cryptocurrencies Broadly
When I talk about cryptocurrency technology, I’m referring broadly to anything that runs on a “public” blockchain (also known as an “unpermissioned” blockchain), whereby anyone can participate in the network by running a node. In contrast, most platforms run on a centralized array of servers that is meticulously managed by a single entity (e.g. Google’s servers are managed exclusively by Google’s engineers). Defining cryptocurrency tech in this way, the natural question arises: What can cryptocurrencies do well that centralized server architectures can’t?
My conclusion to the above, which I will likely elaborate on in a future post, is that they do precisely two things very well: privacy and censorship-resistance (i.e. they’re good at keeping users’ identities from being tied to their activity and they’re good at not being shut down in the face of political turmoil). For example, I would argue that Bitcoin’s initial success came precisely from the fact that it offered a more private and more censorship-resistant digital store of value than anything that existed on the market before it. Before Bitcoin there was literally no way you could transact online without your transactions being tied to your identity but Bitcoin singularly changed that. Moreover, if Bitcoin were not censorship-resistant, it seems clear that it would have been shut down due to how disruptive it was at the time, and how big of a threat it posed (and still poses for that matter) to the status quo. As such, when considering the question, “why couldn’t you launch Bitcoin on a centralized server architecture,” I think the need for privacy and censorship-resistance provides a sufficient and reasonable answer.
The natural next question, if we agree that privacy and censorship-resistance are two things that cryptocurrencies can do better than centralized alternatives, is, “what other applications could create value for users by increasing privacy and censorship-resistance?” While the space of applications is obviously not huge since the subset of users who care deeply about privacy and censorship-resistance for most applications is correspondingly not huge, I believe a serious wedge exists for creating a suite of applications that provide this pair of properties at the core of their value propositions. In particular, I think communication platforms like Twitter and Messenger could be re-imagined as cryptocurrencies/blockchains, and that if they were then they would offer features you would not be able to get anywhere else (namely an unprecedented level of privacy and censorship-resistance). Indeed, in many countries around the world, a crypto-based Twitter and Messenger app would likely be the only way to communicate freely.
Why Smart Contract Platforms Fail
If we agree that a wedge exists for cryptocurrency tech to deliver a superior level of privacy and censorship-resistance to users, the natural next question becomes whether or not smart contract platforms are well-suited to delivering this value. My conclusion, after deeply considering smart contract platforms, is that smart contract platforms are not only ill-suited to launching competitive products, but that the focus on them by the crypto community has been holding it back from being able to deliver compelling products that create non-speculative value for users.
Below, I summarize the core issues that I think smart contracts have when it comes to developing a product that can create value for users. Note that a lot of this comes from personal experience while developing the Ultranet, the first truly decentralized private marketplace, which I ultimately determined could not be built as a smart contract due to the shortcomings below.
Native Storage Issues
Interestingly, all smart contract platforms, not just Ethereum, have a serious feature gap when it comes to the basic storage requirements most apps have (I had to solve this with the Ultranet by rolling a new chain and introducing a “block pool” concept). In particular, if one wants to store basic user data such as images directly on a smart contract platform, then every image the user ever uploads must be stored in the blockchain forever. This is in contrast to traditional apps, whereby updates wipe out whatever was stored previously, which is what is generally expected and required in order to make storing user data feasible.
Some discussions I found during my research suggested using IPFS as the storage layer for the application. While this seems interesting in theory, in practice IPFS (and Filecoin, the successor to IPFS) is highly ill-suited to serving files to users in real-time, instead servicing a use-case more like Amazon Glacier, where latency is sacrificed in favor of storing larger amounts of data. This is not even considering the complexity one would face around compensating users for storing and replicating all of the data in a censorship-resistant way, which seems like a currently-unsolved problem for smart contract and decentralized file storage platforms (the “block pool” concept I mentioned earlier solves this in a domain-specific way, which is generally sufficient for many use-cases, but not in a general way).
Suprisingly, this feature gap, which seems to preclude any actually interesting user application from being implementable on a smart contract platform, seems to not even be on the roadmap for Ethereum and other smart contract platforms.
Transaction Fees Require a Separate Currency
On a platform like Ethereum all transactions require paying transaction fees in the native currency. As such, if one were to launch a new platform as a smart contract on Ethereum, users would have to maintain two currencies for all of their interactions, which poses an untenable compromise in the user experience in our view.
A common argument is that one should just use Ethereum as the native currency for their new platform, but doing so would result in the total loss of all of the adoption advantages that come with associating a new currency with each new platform, namely making it much harder to overcome the “platform chicken and egg problem” initially. This blog post by Coinbase founder Fred Ehrsam does a great job explaining the value of introducing a new currency on a new platform, but the basic idea is that having widely-distributed ownership of a system’s currency early on that’s biased toward early adopters provides a large advantage over a more random distribution like that of Ethereum in terms of bootstrapping an initial user-base and motivating early adopters not only to use the system but also to onboard new users.
Interestingly, there have been proposals to allow Ethereum miners to take other cryptocurrencies as a transaction fee rather than insisting on taking Ethereum only. This would likely solve this issue if it were implemented, but it seems the complexity of implementing such a system combined with the fact that it would likely have a negative effect on the price of Ethereum have prevented a viable implementation from surfacing.
Centralized Updates
Generally-speaking, a smart contract on a platform like Ethereum generally needs an owner; that is, someone who owns the private keys with the unilateral authority to update the smart contract. While this may be fine for applications that do not require censorship-resistance, we think it presents an untenable compromise for those that do. Even if one were to launch something requiring censorship-resistance on a particular smart contract platform anonymously, for example, questions would eventually arise with regard to who holds the one and only pair of keys, then making that person a choke-point for censorship.
While alternative approaches to updating smart contracts have been proposed, such as holding votes among the token-holders, we are not aware of any project actually making this work without needing to have a centralized entity with ultimate control of the system (e.g. using a so-called “proxy contract” or other means). Among other issues, it seems that requiring the people who hold tokens to constantly be voting would be an untenable compromise to the user experience.
The above issues create a stark contrast with the update mechanism for things that are built as new from-scratch blockchains. In particular, updating these merely requires those running the software to update to the latest version in order to remain compatible with the rest of the network, which works well even if they are all running software produced by different groups of people. This not only eliminates the single choke-point of censorship that smart contracts face, but it also avoids the issues of token-based governance, since requiring people who are running the software to update is much less cumbersome than requiring all token holders to make informed votes. Moreover, Bitcoin, and even Ethereum itself, have demonstrated that the processes that govern an independent blockchain work well while maintaining the highest bar for censorship-resistance in a way that we have yet to see implemented in any smart contract.
Conclusion
While smart contract platforms are ill-suited to the task of creating non-speculative value for users, this fact should not lead one to dismiss the potential of cryptocurrency technology more broadly. In particular, platforms built directly on cryptocurrency technology without using smart contracts, for example platforms built on their own from-scratch blockchains, have the potential to create highly-differentiated value for users in the form of unprecedented levels of privacy and censorship-resistance. Moreover, while this wedge is not huge, it seems there are enough people in the world who care deeply about privacy and censorship-resistance that we should expect to see at least a few serious attempts at new platforms, particularly in the area of communication, that are built on new from-scratch blockchains (with the Ultranet being one such example).
If you liked this post, it would mean a lot to me if you could share it on Twitter.
