Dapps are just trust-minimized cloud-computing
How not to waste $13 billion
Introduction
You could say that misunderstandings about the nature of dapps have resulted in the misappropriation of about $13 billion dollars between 2017 and 2018. While some of these ICOs may one day lead to something which merits the initial capital investment, it’s hard to argue that this will be the case for many (if any at all). The technology has been improperly leveraged and overcapitalized (unsuccessfully) in an effort to overcome fundamental limitations. Here I explain how the upsides and downsides of dapps compared to contemporary web services to show how to successfully leverage dapps.
Dapps offer a different architecture than scalable web services
The alternative architecture offered gives hope to dapps finding a use-case considering that dapps will have a hard time competing with web services.
Scalable web service architecture
Web services use the client-server architecture with centralized computing. The client-server architecture means that the end-user will make use of a remote computer to use the service. This is typically done for a number of reasons, but mainly because it’s scalable. This allows for a single entity to leverage economies of scale and share that computing power / data storage with users for free (usually in exchange for their data or to show them ads). Adding new users is easy because all that’s required to access the service is a lightweight, internet-connected computing device, and most people already own personal computers and cell phones. You could say this architecture exchanges security from hostile adversaries for better efficiency. Typically security is largely outsourced to government anyway (e.g. common law), so these architectures can focus strictly on efficiency.
Blockchain/dapp architecture
Blockchains use a peer-to-peer network and each user validates the entire blockchain. Validation typically requires downloading the entire blockchain and checking that every transaction conforms to the protocol to compute the final state. Adding new users is harder because it requires users owning hardware capable of validating the entire blockchain within a reasonable period of time. Owning personal computers is common, but requiring several hundred GB of data and days of syncing is a UX anti-pattern. The highly distributed blockchain data makes the network more resilient to attacks. You could say this architecture exchanges efficiency for better security. Unlike web services, blockchain networks do not outsource any of their security, even to governments. More often, governments are considered an adversary in the threat model.
More on the blockchain/dapp architecture
The blockchain is a cloud platform which can never be shut down
Cloud services are just server hardware rented out as a product. Basically web hosting. In today’s centralized cloud services, the service provider can revoke access at their discretion. In contrast, any code uploaded to the blockchain must stay there indefinitely. This is because the nature of blockchain validation requires that all data be present, so objectionable or politically sensitive data cannot be excised without preventing the ability to perform full validation. As long as full validation is a priority, data on the blockchain is censorship-resistant.
Full nodes are like servers
All full nodes contain the current state as well as the entire blockchain. This also means that they have a copy of each dapp and the contract code. If someone wanted to, they could offer access to blockchain data as a service. In other words, users have two options for accessing dapps:
- Run your own full node. The hardware requirements are high and the time to validate all state is high. This is a UX anti-pattern but allows anyone to run dapp code in a trust-minimized, private manner.
- Full node as a service. Here clients would request node data (e.g. all account information for a dapp associated with a given public key) and interact through a browser. To them, it would be as if they were running a full node, and the hardware requirements are pretty low. This is a somewhat trustful, less private way of accessing a dapp. It’s also scalable.
Inefficiency is a consequence of censorship-resistance
Blockchain networks are only censorship-resistant because copies of the blockchain are highly distributed. However, that high level of distribution means intensive on-chain computation or high-capacity data storage are prohibited. This is because the hardware requirements must be kept reasonably low for the full node count to stay reasonably high. The exact number of full nodes necessary for censorship-resistance is not well understood, but for the time being any service which wishes to retain this property should be conservative. Once a service is centralized there is no going back. This means:
- Transaction throughput must be limited. Transactions require data storage and computation to verify. If it takes you longer than the average block time to verify all transactions in a block, you are effectively prevented from full validation.
- Only the bare minimum should be persistently stored on-chain. Data is forever.
- A fee market is necessary to disincentivize spam, raising costs for any kind of operation. Microtransactions or applications without a minimum of economic value may not make sense.
Dapps offer a new balance of features to existing censorship-resistant services
Today’s censorship-resistant services offer this important feature in one of two ways:
- By hiding the location of a centralized service. (e.g. Tor hidden services)
- By keeping data highly distributed with no single point of failure. (Freenet, Bitmessage)
The unspoken reality of smart contract platforms is that they are a consequence of taking a highly distributed data store and adding scalable business logic capabilities. That is, if we embedded user-created APIs (smart contracts), a virtual machine, a formal means to triggering those API calls (transactions), and a way of ordering transactions in a highly distributed data store (a blockchain), we get a smart contract platform.
This is great news. It means that dapps offer something compelling and unique that both web services cannot offer and neither can existing censorship-resistant services.
The biggest feature difference offered by dapps is that they lack human and machine points of failure. The big question really comes down to how scalable they can be made. With the client-server model, this is a real possibility.
Why Ethereum’s “Unstoppable world computer” narrative failed
Dapps as censorship-resistant cloud-computing is more-or-less the same as its conception as an unstoppable (read: censorship-resistant) world computer (read: cloud computer) back in 2014. So if they had it right the first time, what happened?
They failed to target the correct markets
Gambling, adult classifieds, and anonymous markets are the three most profitable categories which require some degree of censorship resistance. Only in the first case was there any attempt made at pursuing products which could offer something on the Ethereum platform. It would be fair to say that the Ethereum team was composed of technologists without any clear sense of product-market fit.
Instead, the Ethereum community targeted inappropriate applications which rarely needed censorship-resistance at all. It seems that their primary target was services which used some trusted intermediary, and the reality is that the additional rent imposed by the trusted intermediary was nowhere near the additional costs that would be incurred by a decentralized architecture. The largest markups products usually see is something like 50x (e.g. pharmaceuticals), but the inefficiency of dapps (at least on Ethereum) is orders of magnitude larger on most (all?) metrics.
They never evaluated the costs
It was pretty clear from the start that blockchains wouldn’t offer anything cost-effective relative to conventional cloud computing platforms, such as Amazon web services. Given that they were targeting the wrong (or at best, suboptimal) markets, they really should have paid more attention to how cost-effective their solution was.
They put the technology ahead of the product-market fit
Ethereum was not a solution which started with a real-world problem. It was a generalization of a technology that itself was solving a very specialized problem (trust-minimized wealth transfer). Given this, they never optimized the architecture to solve any problem in particular, and were caught off guard when they found that Ethereum was too inefficient and costly for every problem domain they targeted.
Conclusion
Dapps are just code on an immutable cloud (the blockchain). The highly distributed blockchain data makes this code censorship-resistant. Dapps are absent both hardware and human points of failure which is a unique feature set that does not exist in other censorship-resistant technologies. Anything which doesn’t require this censorship-resistance may be better off using a completely centralized alternative. Ethereum was right when they called it an unstoppable world computer, but they failed to properly analyze the costs or target the correct markets.
