|
|
@@ -0,0 +1,36 @@
|
|
|
+The term Web 1.0 refers to the beginnings of the Internet, which consisted of simple static web pages. The central idea was to simply present or consume content. Characteristic for 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 with each other. Typically, Web 2.0 platforms have a centralized structure, which entails the problems mentioned in the previous chapter. This led the founder of the World Wide Web, Tim Berners-Lee, to say that the Internet was being misused - partly because of 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 decentralized Web (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 dApps (decentralized Apps). Although decentralized applications have existed for a long time (e.g. BitTorrent), these applications do not meet the criteria of a dApp (see next section).
|
|
|
+
|
|
|
+In the following, the characteristics of a dApp are described and individual, essential components are examined in more detail.
|
|
|
+
|
|
|
+\subsection{Characteristics of a dApp}
|
|
|
+\label{sec:dapp-characterisitics}
|
|
|
+Just as with client-server applications, a 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 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 Algorithm in Bitcoin)
|
|
|
+\end{itemize}
|
|
|
+
|
|
|
+In addition to the criteria of a dApp, Johnston et al. also describe a classification system for dApps \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 dApp of type 2.
|
|
|
+\end{itemize}
|
|
|
+
|
|
|
+The advantages of a 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 dApp is complex and it is difficult to install updates and bugfixes. Currently there are still very few dApps, so interactions between different dApps are not able to create synergy effects.
|
|
|
+
|
|
|
+\subsection{Ethereum}
|
|
|
+\label{sec:ethereum}
|
|
|
+
|
|
|
+\subsection{InterPlanetary File System (IPFS)}
|
|
|
+\label{sec:ipfs}
|
