HOSN-app/thesis/content/02-background/dapps.tex

The term Web 1.0 refers to the beginnings of the Internet, which consisted of simple static web pages. The central idea was to present or consume content. The characteristic of Web 2.0 is the user's participation in the creation process. Thus, a series of platforms (blogs, social networks) was launched on which users can provide content and connect. Typically, Web 2.0 platforms have a centralized structure, which entails the problems mentioned in the previous chapter. On the occasion of the 30th anniversary of the World Wide Web in March 2019, the initiator Tim Berners-Lee summed up that the Internet was misused - partly due to the system design \cite{berners-lee2019web30}.

With the next version 3.0 of the web, more transparency, security, and fairness should be created. However, while there is broad agreement on what is meant by terms Web 1.0 and Web 2.0, there is no uniform definition of Web 3.0 that has prevailed to date. There are many ideas, but no final solution yet.

An interpretation of what Web 3.0 is, is all about decentralization, hence it is also called the \acf{dWeb}. In this context, Web 3.0 is considered an umbrella term for a group of emerging technologies such as blockchain, crypto currencies, and distributed systems which are interconnected to create novel applications, so-called \acf{dApp}. Although decentralized applications have existed for a long time (e.g., BitTorrent), these applications do not meet the criteria of a \ac{dApp}.

\subsection{Characteristics of a \ac{dApp}}
\label{sec:dapp-characterisitics}
As with client-server applications, a \ac{dApp} is divided into front and back end. The main difference is that the back end is not represented by a centralized server and thus a single point of failure, but by code that is executed in a decentralized \ac{P2P} network. In the back end so-called smart contracts are used to perform logical operations, and instead of a database, a blockchain is used. The front end can be created either as an app or website, but it is necessary that calls can be executed from the front end to the back end.

Johnston et al. and Siraj Raval name the following four criteria for a \ac{dApp} \cite{johnston2015dapp,raval2016decentralized}:

\begin{itemize}
	\item \textbf{Open Source}: Trust and transparency are created by the disclosure of the source code. This also enables improvement through contributions from other developers.
	\item \textbf{Blockchain based}: The data of the application are stored cryptographically in a public, decentralized blockchain. The immutability of the blockchain can be used in conjunction with smart contracts to build consensus and trust.
	\item \textbf{Cryptographic token}: Certain actions in the network can only be performed by paying with a token. This token can either be purchased or given to the user in exchange for data, storage space or similar. Especially as a reward for positive actions, users should be rewarded with tokens. However, no entity should have control over the majority of the tokens.
	\item \textbf{Token generation}: The application must generate tokens according to a standard cryptographic algorithm (e.g., Proof of Work and Proof of Stake Algorithm) or distribute them among the users at the beginning of its operation.
\end{itemize}

In addition to the criteria of a \ac{dApp}, Johnston et al. also describe a classification system for \acp{dApp} considering if they have their own blockchain or they use another \ac{dApp}'s blockchain \cite{johnston2015dapp}:

\begin{itemize}
	\item \textbf{Type 1}: Use their own blockchain (e.g. Bitcoin, Ethereum, EOS).
	\item \textbf{Type 2}: Protocols, to use another blockchain of type 1 with own tokens (e.g. Omni Protocol).
	\item \textbf{Type 3}: Protocols with own tokens, which in turn use protocols of a \ac{dApp} of type 2.
\end{itemize}

Over 1900 dApps use the Ethereum platform \cite{dappsXXXXstats} and in terms of market capitalization, 94 of the top 100 tokens base on Ethereum \cite{dappsXXXXtokens}. Ethereum is a public, decentralized blockchain and at the same time a system for the execution of smart contracts. The associated token is called \ac{ETH} and is required to execute the smart contracts on the \ac{EVM}.

Since the storage of large amounts of data in the blockchain is expensive, the data are often stored elsewhere, and only one reference is written into the blockchain. \ac{IPFS} has become the preferred decentralized storage location.

Examples of \acp{dApp} that use the Ethereum - \ac{IPFS} combination are the social networks Peepeth and AKASHA, which are introduced in the following chapter.

Among the disadvantages of \acp{dApp} are the costs associated with actions and the handling of tokens. The tokens are stored in a wallet, and this wallet has to be accessible by the \ac{dApp}. Therefore, a special web browser or an extra browser add-on is required. Before the first usage, the user has to obtain the token somehow. The acquisition is usually complex and therefore represents a barrier for some users to use the application. Because of this, unfortunately, only experienced users can fulfill the prerequisites to use a \ac{dApp}.

The advantages of a \ac{dApp} include not only reliability but also the avoidance of censorship and manipulation by design. Furthermore, there are no dependencies towards a service provider. However, the creation of a \ac{dApp} is complex and it is difficult to install updates and bugfixes. Currently, there are still very few \acp{dApp}, so interactions between different \acp{dApp} are not able to create synergy effects.