|
|
@@ -16,10 +16,10 @@ Johnston et al. and Siraj Raval name the following four criteria for a \ac{dApp}
|
|
|
\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)
|
|
|
+ \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} \cite{johnston2015dapp}:
|
|
|
+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).
|
|
|
@@ -27,10 +27,12 @@ In addition to the criteria of a \ac{dApp}, Johnston et al. also describe a clas
|
|
|
\item \textbf{Type 3}: Protocols with own tokens, which in turn use protocols of a \ac{dApp} of type 2.
|
|
|
\end{itemize}
|
|
|
|
|
|
-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.
|
|
|
+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.
|
|
|
|
|
|
-\subsection{Ethereum}
|
|
|
-\label{sec:ethereum}
|
|
|
+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.
|
|
|
|
|
|
-\subsection{InterPlanetary File System (IPFS)}
|
|
|
-\label{sec:ipfs}
|
|
|
+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.
|
