From Bitcoin to Ethereum: the Origins of DApps

On January 3, 2009, Satoshi Nakamoto mined the genesis block of Bitcoin on a small server in Helsinki, thereby creating a rapidly evolving crypto world. Bitcoin is based on “distributed ledger” technology, and the essence of bitcoin is actually the balance recorded on this “distributed ledger” (i.e., UXTO, unspent transaction expenses). Bitcoin is unquestionably a brilliant invention, but its application has some limitations. Because the UXTO-based scripting language can only support simple transactions, implementing more complex logic in the Bitcoin network is difficult. This has limited Bitcoin’s usage to “digital gold,” making it difficult to become more widely used.

Ethereum and Smart Contracts

Inspired by Bitcoin, Vitalik Buterin published “Ethereum: A Next-Generation Cryptocurrency and Decentralized Application Platform” in Bitcoin Magazine in 2014, in which he first proposed smart contracts in an attempt to create a more widely used blockchain system from a basic protocol, which is now known as Ethereum, the dominant smart public chain at the moment.

In the Ethereum white paper, Vitalik mentions the goals of the project: “What Ethereum intends to provide is a blockchain with a built-in fully fledged Turing-complete programming language that can be used to create “contracts” that can be used to encode arbitrary state transition functions, allowing users to create any of the systems described above, as well as many others that we have not yet imagined, simply by writing up the logic in a few lines of code.” Simply put, this is about creating a platform that can run smart contracts and decentralized applications (DApp).

A smart contract is similar to an “enforceable agreement” between a person and a machine that will carry out once a pre-defined condition is met. As a result, smart contracts can be regarded as a “trustworthy middleman.” Ethereum’s most significant innovation is smart contracts, which are also the foundation of its vast ecosystem. Unlike Bitcoin’s transaction scripts, Ethereum’s smart contracts are Turing-complete, which means it is theoretically capable of any possible computation and thus has limitless possibilities.

Ethereum Virtual Machine and DApp

If Bitcoin is essentially a “distributed ledger” with scripting functions, Ethereum is probably closer to a “distributed state machine.” Accounts in Ethereum are classified into two types: externally owned accounts, controlled by ordinary users using their private keys, and contract accounts, which have contract codes stored internally but no corresponding private keys and thus do not belong to anyone.

The state of the entire Ethereum network is a large data structure (Merkle-Patricia Tree) that contains the state of all accounts, their balances, as well as the rules for changing the state. The state of Ethereum is constantly changing as new blocks are added to the chain. Thus, you can think of Ethereum as a “distributed public computer” (a virtual machine) and the various DApps as software programs installed on this computer.

On Ethereum, a DApp is essentially a collection of smart contracts, each with its unique contract address. Once the contract code is complete, it must be started by an external transaction to the contract account. Developers can easily create DApps based on smart contracts and run them on Ethereum virtual machines using official tools. Because the Ethereum virtual machine has limited computing power, users must use ETH as “gas” to power the DApp and virtual machine.

DApp Ecology Expansion

Since the inception of Ethereum smart contracts, the number of DApps has grown, and the coverage area has expanded. Vitalik envisioned three types of Ethereum applications in the Ethereum white paper: non-financial, semi-financial, and financial. Non-financial applications include online voting, decentralized governance, and so on; semi-financial applications include smart reward payments, and so on; and financial applications (i.e., Defi) are the most influential, with Ethereum providing a flexible and reliable contractual approach to build protocol-native tokens, financial derivatives, hedging contracts, and other applications.

Although Ethereum is the most popular public chain with the most diverse DApp ecosystem, it also faces network congestion, poor efficiency, and high fees. Later, as a new generation of high-performance smart public chains such as EOS, Solana, and Flow emerged, they established their own DApp ecosystems. Currently, the most popular DApp categories are games, Defi, NFT collections, and Social-Fi. Game DApps have a significant advantage in terms of total number and UAW (number of unique active wallets), whereas Defi projects (such as Dex, lending, and so on) take a lead in terms of transaction volume.

You can check the active users, transaction volume, and other data of various DApps on major blockchains on data sites like DAppRadar and DAppReview. The number of DApps listed on DappRadar alone had surpassed 12,000 as of November 2022.

Source: DAppRadar

DApp Composition and Features

DApp have many similarities with App on traditional internet, and the relationship between DApp and blockchain is similar to that between App and operating systems such as IOS or Android. A DApp runs on blockchains, just as an App runs on various operating systems. Using a DApp in a browser may feel similar to using SaaS software for a user.

A typical DApp consists of three parts with similar functionality to a typical App’s three-tier structure of back-end (business module), database (storage module), and front-end (user interface).

Business module: Smart Contract

Smart contracts serve as the programmatic foundation for implementing a DApp’s business logic. Smart contracts are stored on the blockchain in contract addresses, and input data is passed between contract addresses to realize the functions of the DApp according to predefined logic and trigger the state transformation of the entire virtual machine. Unlike a traditional App, however, the smart contract also stores the current state of the DApp, which is also the nature of the blockchain itself.

Storage module: data storage

The data flow process is at the heart of any App or DApp. Data is transferred from the storage module to the business module for processing so users can interact with the front end. App data is typically stored in a centralized server, whereas DApp data can be stored entirely on the chain; however, for efficiency and cost reasons, many DApps store most data off-chain, on services such as IPFS, and only storing important business module data on the blockchain.

User interface: front-end interaction

The front-end is where general users can easily access to use smart contract code even without detailed programming knowledge. There is little difference in front-end development between DApp and App; both are built with general technologies such as HTML and JavaScript. However, because using a DApp requires interaction with smart contracts, the front end must provide a programmatic interface that allows wallet applications (such as Metamask).

Source: Ethereum DApp Architecture Source: The Architecture of a Web3 Application

DApps have the following features when compared to traditional apps:

DApps do not rely on centralized servers but on blockchains, running on decentralized virtual machines. These are the essential features of DApps, but they also have some significant advantages and disadvantages:

Advantages

Zero Downtime

If the centralized server fails, the program will be completely unavailable; however, for a DApp, a single node going down has no effect on the program’s operation on the blockchain. DApps frequently have lower operating costs than traditional Apps because smart contracts never stop running once they go on the chain. DApps often have lower operating costs than traditional apps.

No license is required

Interacting with DApps is done solely through the wallet address without the need to provide complete personal information when you are applying for a general financial account. This not only eliminates the need to reveal personal privacy but also significantly lowers the threshold so that anyone with a crypto wallet can easily access most DApps.

Code is Law

Because of the tamper-evident feature of blockchain, DApps rely on the code logic of smart contracts to operate, so once it is uploaded to the chain, it is impossible to be modified unless the developer retains the permission to change it; and once the application is deployed it will exist forever, and it is theoretically impossible to restrict the access of anyone in the world.

Disadvantages

Limited by scalability, DApp efficiency is low

DApps generally operate less efficiently than traditional apps due to decentralization and may even be temporarily unavailable due to blockchain congestion.

Theoretically, all actions on the chain require gas fees

Due to the limited processing capacity of the blockchain virtual machine, users need to pay a certain amount of gas fee to the network for interacting with Dapp, which is difficult for users who are used to traditional free Apps.

High difficulty of smart contract maintenance

Once the smart contract code is on the chain, it is difficult to modify, which makes the development and maintenance of DApp more complex. It is also difficult to fix the code in time once it goes wrong.

DApp’s code is usually open sourced

Since the blockchain is decentralized, the code of the DApp needs to be publicly accessible to all community members. This also allows users to do their code analysis and predict the project’s potential.

Token economic system

The functions of DApps are often implemented through various tokens, either the token of the corresponding blockchain (e.g., ETH) or the token issued by the DApp itself (e.g., UNI).

Bottlenecks in DApp Development

Although the DApp ecosystem is in rapid development, the overall influence of DApps remains limited compared to world-class applications in Web2. The following bottlenecks may arise during the DApp eco-implementation.

1.User scale and learning threshold:

In terms of UAW, only about 100 DApps’ data exceed 10,000. Even the most popular DApps only receive hundreds of thousands of independent addresses per day, which definitely pales in comparison to the Web2 space.

Users must learn basic knowledge such as wallets and blockchains to use DApps. So switching from Web2 apps to DApps will incur learning costs. For the time being, the promised anti-censorship and privacy features of DApps have not demonstrated their actual value, causing DApps to remain a niche product among crypto geeks.

2.Product Iteration and Security Risks

To get users first and improve product quality in operation, products in Web2 frequently follow the development rule of “small steps, fast iteration.” However, it is difficult to change the contract code of a DApp once it goes online. If there are major bugs in the code after the launch, it will bring serious consequences. As a result, the project owner must perform a complete product design and code audit before the DApp goes online to avoid all possible problems.

3.Public Blockchain Infrastructure

Ethereum, the current number one smart public chain, suffers from low efficiency and high cost. Compared to VISA’s 24,000 TPS, Ethereum’s TPS of around 15 is insufficient to meet its vision of becoming a “global settlement layer.” Time will tell whether the future blockchain can break through the impossible triangle and strike a balance between efficiency, security, and decentralization.

Conclusion

DApps are crucial to the next generation of the Internet, known as Web3, and may usher in a new business model for the information industry. Regarding usability, DApps are very similar to Web2 applications, but DApps have distinct features of anti-censorship and privacy.

Furthermore, using DApps requires a connection to a wallet, making it closely related to the user’s personal property. To avoid property loss, you should carefully evaluate the security of the DApp before connecting your wallet to it. It is best to choose a DApp with a reliable agency code audit.