Finished cover page
This commit is contained in:
@@ -3,8 +3,10 @@
|
||||
\label{Motivation}
|
||||
|
||||
Peer-to-peer architectures promise censorship-resistant, fault-tolerant
|
||||
infrastructure by eliminating single points of failure \cite{shukla_towards_2021}.
|
||||
These architectures underpin a growing range of systems---from IoT edge computing
|
||||
infrastructure by eliminating single points of failure
|
||||
\cite{shukla_towards_2021}.
|
||||
These architectures underpin a growing range of systems---from IoT
|
||||
edge computing
|
||||
and content delivery networks to blockchain platforms like Ethereum.
|
||||
Yet realizing these benefits requires distributing nodes across
|
||||
genuinely diverse hosting entities.
|
||||
@@ -14,7 +16,8 @@ Amazon, Hetzner, and OVH collectively host 70\% of all Ethereum nodes
|
||||
(see Figure~\ref{fig:ethernodes_hosting}),
|
||||
concentrating nominally decentralized infrastructure
|
||||
within a handful of cloud providers.
|
||||
More concerning, these providers operate under overlapping regulatory jurisdictions,
|
||||
More concerning, these providers operate under overlapping regulatory
|
||||
jurisdictions,
|
||||
predominantly the United States and the European Union.
|
||||
This concentration undermines technical sovereignty:
|
||||
a single governmental action could compel service termination,
|
||||
@@ -28,7 +31,8 @@ data disclosure, or traffic manipulation across a majority of the network.
|
||||
\label{fig:ethernodes_hosting}
|
||||
\end{figure}
|
||||
|
||||
Why does this centralization persist despite the explicit goals of decentralization?
|
||||
Why does this centralization persist despite the explicit goals of
|
||||
decentralization?
|
||||
The answer lies in the practical barriers to self-hosting.
|
||||
Cloud providers offer static IP addresses and publicly routable endpoints,
|
||||
eliminating the networking complexity that plagues residential and
|
||||
@@ -36,8 +40,10 @@ small-office deployments.
|
||||
Most internet-connected devices sit behind Network Address Translation (NAT),
|
||||
which prevents incoming connections without explicit port forwarding
|
||||
or relay infrastructure.
|
||||
Combined with dynamic IP assignments from ISPs, maintaining stable peer connectivity
|
||||
from self-hosted infrastructure traditionally required significant technical expertise.
|
||||
Combined with dynamic IP assignments from ISPs, maintaining stable
|
||||
peer connectivity
|
||||
from self-hosted infrastructure traditionally required significant
|
||||
technical expertise.
|
||||
|
||||
Overlay VPNs offer a solution to this fundamental barrier.
|
||||
By establishing encrypted tunnels that traverse NAT boundaries,
|
||||
@@ -57,7 +63,8 @@ reducing operational overhead to a degree where a single administrator
|
||||
can reliably self-host complex distributed services.
|
||||
Overlay VPNs are central to Clan's architecture,
|
||||
providing the secure peer connectivity that enables nodes
|
||||
to form cohesive networks regardless of their physical location or NAT situation.
|
||||
to form cohesive networks regardless of their physical location or
|
||||
NAT situation.
|
||||
As illustrated in Figure~\ref{fig:vision-stages}, Clan envisions
|
||||
a web interface that enables users to design and deploy private P2P networks
|
||||
with minimal configuration, assisted by an integrated LLM
|
||||
@@ -79,7 +86,8 @@ benchmarks a subset of mesh VPNs but focuses primarily
|
||||
on solutions with a central point of failure.
|
||||
In contrast, this thesis evaluates more widely adopted mesh VPNs
|
||||
with an emphasis on fully decentralized architectures.
|
||||
Furthermore, that study relied exclusively on iperf3 for performance measurement,
|
||||
Furthermore, that study relied exclusively on iperf3 for performance
|
||||
measurement,
|
||||
whereas our benchmark suite includes real-world workloads
|
||||
to better reflect practical usage patterns.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user