Why it is harder to DApp than to CRApp!

Decentralized applications (Decentralized Applications, or DApps) on the blockchain (“web3”) are more challenging to build than traditional centralized applications (CentRalized Applications, or CRApps) on cloud infrastructure (“web2”). There are primarily three reasons for this: lower fault tolerance, low-level programming models, and asynchronous & distributed computations. This article reviews CRApp structure, relates it to DApp structure and discusses these three causes of difficulty. Finally, we point to the solution to these challenges and a path forward for producing competent web3 engineers.

CRApp Structure

Typical centralized applications today are designed to have a lightweight client, a backend business logic server, and a high-availability database. Of course, this basic structure may be extended to have a variety of different databases and microservices, but to a first approximation, this is a sufficient analysis.

Clients are lightweight because they are not responsible for fully implementing all the application’s behavior but merely to render a user interface and reflect state changes to and from the cloud-provisioned database. For example, when you upload a video to YouTube, the processing to analyze sound levels and look for copyright violations does not happen in your browser but on YouTube’s servers. Lightweight clients help facilitate low-power usage by mobile phones and smart televisions, among other things.

Clients typically cannot directly access the data store but rely on the business logic server to implement their requests and feed them the data they need for a specific user.

Centralized applications are typified by the phrase “trusted cloud”: the client does very little, and all the work happens “over there” in the cloud, which is fully trusted.

DApp Structure

In contrast, DApps empower users to directly interact with the blockchain, which serves as a database for the application and tends to remove the presence of business logic servers by either moving them into the shared blockchain, distributing them across clients or by having dedicated trusted participants in DApps that look like peer clients to end users. Furthermore, since blockchains are computation-scarce, computations are pushed to the clients, and the blockchain serves as a database and enforcement mechanism that ensures all clients follow the shared rules of the DApp.

It is plausible that a blockchain application could work like a centralized application by interacting with a traditional business logic server that uses a blockchain as its database. However, this defeats one of the value propositions of DApps: users have complete control and authority over their resources and data, so the business logic server cannot interact with the blockchain on their behalf.

Decentralized applications are typified by the phrase “untrusted edge”: the client does all the work but is untrusted, so lightweight verification happens on the chain.

Problem 1: asynchronous & distributed computations

The first reason that DApps are more complex than CRApps is that the clients are not sequentialized by a single central bottleneck server like the business logic server provides for CRApps. For example, when you make a payment on PayPal, any asynchrony is hidden from clients by PayPal’s servers which can delay responding to clients until the work they’ve requested is finalized. In contrast, DApps directly communicate with the blockchain, which may delay their request or fail and need to be retried with new information. This sort of programming challenge is present in some CRApps on the business logic side, but databases typically mediate these difficulties as well.

Programming of this nature is generally regarded as the most challenging kind of programming by software engineers. This is because analyzing an asynchronous and distributed program requires thinking about all of the possible interleavings of events that may occur. For example, Alice may go first and then Bob, or maybe Bob goes first and then Alice. In a two-party, one-step interaction, there are two possibilities. If we introduce Claire, there are now 6 possibilities (ABC, ACB, BAC, BCA, CAB, CBA). (In fact, there are more because any party may refuse to participate.) Each new party increases the complexity exponentially: a problem called “combinatorial explosion” in the literature.

DApp structure imposes this on programs because clients must be exposed directly to the blockchain, which has asynchronous writes that may fail because of changing states.

Problem 2: low-level programming models

CRApps are developed and deployed in a highly advanced environment where decades of innovation and performance optimization has produced programming languages like JavaScript on the front end and TypeScript/Go/Rust/Haskell/Racket/etc on the backend. Furthermore, since a single centralized party controls backend business logic servers, they can be highly optimized and scaled for the predicted workload of the single application.

In contrast, blockchains are a nascent technology with underdeveloped programming languages and severe performance constraints that incentivize “bare metal” programming. For example, the most popular blockchain programming language in 2022, Solidity, does not provide arbitrary numbers of variables or function arguments to programmers; in contrast, FORTRAN provided this in the 1950s. Furthermore, it is typical for blockchain programmers to feel that they must scrutinize every single assembly instruction generated for performance optimization or because the meaning of each instruction is so subtle.

Software engineers generally regard programming of this nature as the most complex kind of programming. This is because programming requires so much understanding, knowledge, and experience without abstractions. Blockchain programming of this style feels more like building “embedded systems” or “device drivers,” which are the typical forte of elite software engineers, rather than building the simple “CRUD” systems that first-semester software engineers can easily manage (but are still viable and essential CRApps!)

Problem 3: lower fault tolerance

Since CRApps are centrally controlled, they can be easily changed or taken offline whenever there are problems. Furthermore, they only loosely manage critical resources, like financial accounts, because they do not typically have authority over funds. Thus, if an engineer makes a mistake, they can not accidentally lose $325 million overnight, as Wormhole did in February 2022.

In contrast, DApps have complete authority over financial accounts and are committed to an immutable blockchain where they cannot be changed. Unfortunately, this means that failures are catastrophic and typically lead to complete losses. (The interested reader should refer to the fantastic public-service blog, “Web3 is going just great” — https://web3isgoinggreat.com/?theme=bug.)

Programming of this nature is generally regarded as the most challenging kind of programming by software engineers. This is because it requires a considerable amount of upfront investment and effort to ensure that faults never enter the system. In addition, it calls upon the most advanced and expensive kinds of software checking and verification, like formal verification, model checking, audits, and so on.

Problem Summary

DApp design pushes developers to their limit by requiring them to solve the most complex and dangerous problems while providing them with the least-developed and most expensive programming tools. Despite this difficulty, the vast returns available on the blockchain has incentivized many developers to try their hand, often with disappointing results.

Solution: The future of blockchain is in Reach

We believe that the CRApp time is ending, as users will demand control over their resources and data. We think that web3 is a plausible means by which the decentralized and self-sovereign ownership hoped for by the Web’s founders can be realized.

But, we believe that the main bottleneck for this transition is the difficulty of bringing developers into the web3 development world. The few thousand developers in web3 today have failed to deliver a killer DApp that engages with the mass market. We believe that the next ten thousand web3 developers will be web2 engineers that transition to web3 with the creativity and courage to find that first killer-DApp and create the decentralized dream.

We believe that our development platform, Reach, is the means to overcome this bottleneck. First, it abstracts the design of DApps away from some of the most challenging parts of asynchronous design. It provides a high-level programming language akin to JavaScript that insulates developers from low-level details without overly sacrificing performance. Finally, it provides an integrated and automatic verification environment to derisk deployment and increase confidence in DApps. If you’re interested in learning more about Reach, check out our site — reach.sh — and join one of our upcoming bootcamps.

We believe the future of blockchain is within Reach.

Join our community!

Discord: https://discord.gg/enXXM8xfG7
Twitter: https://twitter.com/reachlang

And if you want to start your blockchain-building journey, we have the docs for you! Learn Reach here and become a bear builder!