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 understanding of what Web 3.0 is, is all about decentralization, which is why 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 that 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} (see next section).

In the following, the characteristics of a \ac{dApp} are described and individual, essential components are examined in more detail.

\subsection{Characteristics of a \ac{dApp}}
\label{sec:dapp-characterisitics}
Just as with client-server applications, a \ac{dApp} is also 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 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. There are no special requirements for the front end so that it can be displayed as an app or website. It must only be possible to execute calls 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 is 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 is 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 development 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.