finished motivation
@@ -5,47 +5,3 @@
|
||||
This chapter introduces the Clan project, articulates its fundamental
|
||||
objectives, outlines the key components, and examines the driving
|
||||
factors motivating its development.
|
||||
|
||||
\section{Motivation}
|
||||
|
||||
Peer-to-peer (P2P) technologies and decentralization have undergone
|
||||
significant growth and evolution in recent years. These technologies
|
||||
form the backbone of various systems, including P2P Edge
|
||||
Computing—particularly in the context of the Internet of Things
|
||||
(IoT)—Content Delivery Networks (CDNs), and Blockchain platforms such
|
||||
as Ethereum. P2P architectures enable more democratic,
|
||||
censorship-resistant, and fault-tolerant systems by reducing reliance
|
||||
on single points of failure \cite{shukla_towards_2021}.
|
||||
|
||||
However, to fully realize these benefits, a P2P system must deploy
|
||||
its nodes across a diverse set of entities. Greater diversity in
|
||||
hosting increases the network’s resilience to censorship and systemic failures.
|
||||
|
||||
Despite this, recent trends in Ethereum node hosting reveal a
|
||||
significant reliance on centralized cloud providers. Notably, Amazon,
|
||||
Hetzner, and OVH collectively host 70\% of all Ethereum nodes, as
|
||||
illustrated in Figure \ref{fig:ethernodes_hosting}.
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=1\textwidth]{Figures/ethernodes_hosting.png}
|
||||
\caption{Distribution of Ethereum nodes hosted by various providers
|
||||
\cite{noauthor_isps_nodate}}
|
||||
\label{fig:ethernodes_hosting}
|
||||
\end{figure}
|
||||
|
||||
The centralized nature of these providers and their domicile within the
|
||||
same regulatory jurisdiction—the United States—introduces vulnerability.
|
||||
Such a configuration allows for possible governmental intervention,
|
||||
which could lead to network shutdowns or manipulation by leveraging
|
||||
control over these cloud services.
|
||||
|
||||
The reliance on cloud-based solutions is driven by their ease of use,
|
||||
reliability, and the significant technical barriers associated with
|
||||
self-hosting solutions. These barriers include the need for technical
|
||||
expertise and the often unreliable nature of personally managed
|
||||
hosting. Recognizing this gap, the Clan project is proposed to
|
||||
alleviate these barriers, making the process of self-hosting as
|
||||
straightforward and reliable as using a cloud provider. The goal is
|
||||
to democratize the hosting of P2P nodes, enhancing the overall
|
||||
robustness and autonomy of decentralized networks.
|
||||
|
||||
166
Chapters/Motivation.tex
Normal file
@@ -0,0 +1,166 @@
|
||||
\chapter{Motivation} % Main chapter title
|
||||
|
||||
\label{Motivation}
|
||||
|
||||
This chapter introduces the Clan project, articulates its fundamental
|
||||
objectives, outlines the key components, and examines the driving
|
||||
factors motivating its development.
|
||||
|
||||
Peer-to-peer (P2P) technologies and decentralization have undergone
|
||||
significant growth and evolution in recent years. These technologies
|
||||
form the backbone of various systems, including P2P Edge
|
||||
Computing—particularly in the context of the Internet of Things
|
||||
(IoT)—Content Delivery Networks (CDNs), and Blockchain platforms such
|
||||
as Ethereum. P2P architectures enable more democratic,
|
||||
censorship-resistant, and fault-tolerant systems by reducing reliance
|
||||
on single points of failure \cite{shukla_towards_2021}.
|
||||
|
||||
However, to fully realize these benefits, a P2P system must deploy
|
||||
its nodes across a diverse set of entities. Greater diversity in
|
||||
hosting increases the network’s resilience to censorship and systemic failures.
|
||||
|
||||
Despite this, recent trends in Ethereum node hosting reveal a
|
||||
significant reliance on centralized cloud providers. Notably, Amazon,
|
||||
Hetzner, and OVH collectively host 70\% of all Ethereum nodes, as
|
||||
illustrated in Figure \ref{fig:ethernodes_hosting}.
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=1\textwidth]{Figures/ethernodes_hosting.png}
|
||||
\caption{Distribution of Ethereum nodes hosted by various providers
|
||||
\cite{noauthor_isps_nodate}}
|
||||
\label{fig:ethernodes_hosting}
|
||||
\end{figure}
|
||||
|
||||
The centralized nature of these providers and their domicile within the
|
||||
same regulatory jurisdiction—the United States—introduces vulnerability.
|
||||
Such a configuration allows for possible governmental intervention,
|
||||
which could lead to network shutdowns or manipulation by leveraging
|
||||
control over these cloud services.
|
||||
|
||||
The reliance on cloud-based solutions is largely attributed to their
|
||||
ease of use and reliability, as self-hosting introduces several
|
||||
technical and operational challenges, which include:
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{NAT Traversal:} Establishing direct connections
|
||||
between peers located behind Network Address Translation (NAT)
|
||||
devices is complex and often requires workarounds such as port
|
||||
forwarding or relay servers.
|
||||
|
||||
\item \textbf{Dynamic IP Addresses:} Peers often have non-static
|
||||
(dynamic) IP addresses assigned by Internet Service Providers
|
||||
(ISPs), which makes maintaining stable connections difficult
|
||||
without additional solutions like Dynamic DNS services.
|
||||
|
||||
\item \textbf{Data Reliability:} Ensuring data durability and
|
||||
preventing loss due to hardware failures, system crashes, or
|
||||
insufficient backup mechanisms can be a challenge for individual
|
||||
users managing their own infrastructure.
|
||||
|
||||
\item \textbf{Security Concerns:} Self-hosted systems must be
|
||||
protected from malicious actors, including securing data in
|
||||
transit, authenticating connections, and mitigating attacks such
|
||||
as Distributed Denial of Service (DDoS).
|
||||
|
||||
\item \textbf{Maintenance Overhead:} Regular updates, hardware
|
||||
repairs, and troubleshooting require time and effort, which may
|
||||
discourage users unfamiliar with system administration.
|
||||
|
||||
\item \textbf{Steep Learning Curve:} Non-technical users face a
|
||||
high entry barrier, as hosting and configuring their own P2P
|
||||
nodes often involve understanding complex networking and software
|
||||
setup processes.
|
||||
|
||||
\item \textbf{High Network Churn:} In dynamic P2P environments
|
||||
where peers frequently join and leave, ensuring consistent
|
||||
availability of services and maintaining network stability
|
||||
present additional challenges.
|
||||
|
||||
\item \textbf{Uptime and Availability:} Keeping self-hosted systems
|
||||
online and operational 24/7 can be difficult, especially in
|
||||
situations of power outages, hardware failures, or limited
|
||||
internet connectivity.
|
||||
\end{itemize}
|
||||
|
||||
Recognizing this gap, the Clan project aims to address these
|
||||
challenges by simplifying the process of self-hosting, making it as
|
||||
straightforward, accessible, and reliable as using a cloud provider.
|
||||
The project's vision is to empower users to deploy and manage their
|
||||
own private P2P networks with minimal technical expertise,
|
||||
significantly lowering the barrier to entry.
|
||||
|
||||
As illustrated in Figure \ref{fig:vision-stages}, the proposed
|
||||
solution includes a user-friendly web interface. This interface
|
||||
allows users to design and customize their private P2P networks with
|
||||
just a few clicks. To further simplify the process, the inclusion of
|
||||
a Large Language Model (LLM) is envisioned to assist users throughout
|
||||
the network creation process. The LLM would provide contextual
|
||||
guidance, answer configuration-related queries, and help resolve
|
||||
potential issues, thus making the system approachable for a wider
|
||||
audience without requiring advanced technical skills.
|
||||
|
||||
\begin{figure}[h!]
|
||||
\centering
|
||||
|
||||
% Row 1
|
||||
\begin{subfigure}{0.45\textwidth}
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{Figures/vision/stage1.png}
|
||||
\caption{Stage 1}
|
||||
\end{subfigure}
|
||||
\hfill
|
||||
\begin{subfigure}{0.45\textwidth}
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{Figures/vision/stage2.png}
|
||||
\caption{Stage 2}
|
||||
\end{subfigure}
|
||||
|
||||
\vspace{1em} % Add spacing between rows
|
||||
|
||||
% Row 2
|
||||
\begin{subfigure}{0.45\textwidth}
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{Figures/vision/stage3.png}
|
||||
\caption{Stage 3}
|
||||
\end{subfigure}
|
||||
\hfill
|
||||
\begin{subfigure}{0.45\textwidth}
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{Figures/vision/stage4.png}
|
||||
\caption{Stage 4}
|
||||
\end{subfigure}
|
||||
|
||||
\vspace{1em} % Add spacing between rows
|
||||
|
||||
% Row 3
|
||||
\begin{subfigure}{0.45\textwidth}
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{Figures/vision/stage5.png}
|
||||
\caption{Stage 5}
|
||||
\end{subfigure}
|
||||
\hfill
|
||||
\begin{subfigure}{0.45\textwidth}
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{Figures/vision/stage6.png}
|
||||
\caption{Stage 6}
|
||||
\end{subfigure}
|
||||
|
||||
\vspace{1em} % Add spacing between rows
|
||||
|
||||
% Row 4
|
||||
\begin{subfigure}{0.45\textwidth}
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{Figures/vision/stage7.png}
|
||||
\caption{Stage 7}
|
||||
\end{subfigure}
|
||||
\hfill
|
||||
\begin{subfigure}{0.45\textwidth}
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{Figures/vision/stage8.png}
|
||||
\caption{Stage 8}
|
||||
\end{subfigure}
|
||||
|
||||
\caption{Visionary Webinterface to Setup a Clan Family Network}
|
||||
\label{fig:vision-stages}
|
||||
\end{figure}
|
||||
BIN
Figures/vision/stage1.png
Normal file
|
After Width: | Height: | Size: 1.0 MiB |
BIN
Figures/vision/stage2.png
Normal file
|
After Width: | Height: | Size: 1.0 MiB |
BIN
Figures/vision/stage3.png
Normal file
|
After Width: | Height: | Size: 1.0 MiB |
BIN
Figures/vision/stage4.png
Normal file
|
After Width: | Height: | Size: 1.3 MiB |
BIN
Figures/vision/stage5.png
Normal file
|
After Width: | Height: | Size: 1.3 MiB |
BIN
Figures/vision/stage6.png
Normal file
|
After Width: | Height: | Size: 105 KiB |
BIN
Figures/vision/stage7.png
Normal file
|
After Width: | Height: | Size: 1.1 MiB |
BIN
Figures/vision/stage8.png
Normal file
|
After Width: | Height: | Size: 1.1 MiB |
10
main.tex
@@ -53,6 +53,8 @@
|
||||
\usepackage{mathpazo} % Use the Palatino font by default
|
||||
\usepackage{svg}
|
||||
\usepackage{acronym}
|
||||
\usepackage{subcaption} % For subfigures
|
||||
|
||||
\usepackage[backend=bibtex,style=numeric,natbib=true]{biblatex} %
|
||||
% Use the bibtex backend with the authoryear citation style (which
|
||||
% resembles APA)
|
||||
@@ -244,8 +246,8 @@ and Management}} % Your department's name and URL, this is used in
|
||||
\addchaptertocentry{\acknowledgementname} % Add the
|
||||
% acknowledgements to the table of contents
|
||||
|
||||
I am very grateful to my team members Mic92, Lassulus, Hsjobeki,
|
||||
DavHau, Kenji and Timo with whom
|
||||
I am very grateful to my team members Mic92, Lassulus, W, Hsjobeki,
|
||||
DavHau, Kenji, Paul and Timo with whom
|
||||
I worked together with to create the Clan framework.
|
||||
As well as my supervisor, Ber Lorke, for his guidance and support
|
||||
during my research.
|
||||
@@ -333,9 +335,11 @@ and Management}} % Your department's name and URL, this is used in
|
||||
|
||||
% Include the chapters of the thesis as separate files from the Chapters folder
|
||||
% Uncomment the lines as you write the chapters
|
||||
\include{Chapters/Introduction}
|
||||
\include{Chapters/Motivation}
|
||||
\include{Chapters/Methodology}
|
||||
|
||||
\include{Chapters/Introduction}
|
||||
|
||||
%\include{Chapters/Chapter1}
|
||||
%\include{Chapters/Chapter2}
|
||||
%\include{Chapters/Chapter3}
|
||||
|
||||