Multi-Hop Onion Routing v dVPN: Průvodce

Multi-Hop Onion Routing Decentralized Architectures dVPN P2P Network Bandwidth Mining
D
Daniel Richter

Open-Source Security & Linux Privacy Specialist

 
18. března 2026 4 min čtení
Multi-Hop Onion Routing v dVPN: Průvodce

TL;DR

Tento článek popisuje, jak funguje multi-hop onion routing v nových decentralizovaných architekturách, jako jsou dVPN a DePIN sítě. Vysvětluje, jak vrstvené šifrování chrání vaše data při průchodu různými uzly a proč je to lepší pro svobodu internetu než staré VPN. Dozvíte se o těžbě šířky pásma a o tom, jak P2P sítě mění soukromí pro všechny.

Základy onion routingu v P2P světě

Přemýšleli jste někdy nad tím, proč se vaše "soukromá" VPN cítí jako skleněný dům? Pokud používáte pouze jeden server, poskytovatel vidí vše, co děláte – jedná se o masivní bod selhání. Multi-hop routing to řeší tak, že vaše data putují přes několik uzlů, takže nikdo nemá úplný obrázek.

Zjednodušeně řečeno, namísto přímé linky se váš provoz pohybuje klikatou cestou. To je běžné v mesh sítích, kde pokrytí přesahuje dosah jednoho uzlu.

  • Vrstvené šifrování: Každý uzel (nebo hop) oloupe pouze jednu vrstvu "cibule", přičemž ví pouze, odkud paket přišel a kam směřuje dál.
  • Žádná centrální důvěra: V P2P nastavení se nespoléháte na jedno firemní datové centrum, ale používáte distribuovanou síť uzlů.
  • Energie a efektivita: Není to jen pro utajení; někdy je skákání mezi bližšími rádiovými uzly ve skutečnosti energeticky úspornější než vysílání signálu do vzdálené věže.

Diagram 1

Viděl jsem lidi, kteří se to snažili udělat sami s pomocí vnořených kontejnerů, ale decentralizované architektury to umožňují nativně. Je mnohem těžší vás sledovat, když se cesta neustále mění. Zde vstupuje do hry DePIN (Decentralizované sítě fyzické infrastruktury), což v podstatě znamená, že lidé sdílejí svůj hardware k budování sítí v reálném světě.

Dále se podíváme na krypto stranu...

Vrstvené šifrování a decentralizovaná VPN

Představte si vrstvené šifrování jako ruské matrjošky, ale pro vaše datové pakety. Aby to fungovalo bez nutnosti komukoliv důvěřovat, systém používá asymetrické kryptografické handshake – obvykle něco jako výměnu klíčů Elliptic Curve Diffie-Hellman (ECDH). Před jakýmkoliv přenosem dat váš klient použije veřejné klíče každého uzlu k vyjednání unikátního "session key" pro každý skok (hop). Tímto způsobem váš počítač obalí data do tří vrstev šifrování ještě předtím, než opustí váš domov. První uzel dokáže odemknout pouze vnější vrstvu, aby zjistil, kam data poslat dál, ale nevidí samotnou zprávu ani konečný cíl.

  • Klíče specifické pro skok (Hop-Specific Keys): Váš klient vyjednává samostatné klíče s každým relay uzlem; vstupní uzel nevidí, co dělá výstupní uzel.
  • Anonymizační množiny (Anonymity Sets): Smícháním vašeho provozu s tisíci dalších toků se jednotlivé streamy stanou nerozeznatelné.
  • Diverzita uzlů (Node Diversity): Jelikož tyto uzly nevlastní jedna společnost, neexistuje žádný "hlavní vypínač", kterým by se dala zaznamenávat vaše historie.

Obvykle doporučuji používat WireGuard kvůli jeho rychlosti, i když je důležité si uvědomit, že WireGuard je protokol pro tunelování point-to-point. Sám o sobě nepodporuje multi-hop, jako to dělá Tor. Pro dosažení skutečné anonymity musí vývojáři WireGuard obalit do vlastního frameworku, který se stará o logiku onion-routingu. Pokud provozujete uzel na linuxovém serveru, můžete ve skutečnosti vidět šifrované "bloby" procházející skrz, aniž byste tušili, co je uvnitř.

Tento prostor se rychle vyvíjí, zejména s trhy s šířkou pásma založenými na blockchainu. Obvykle sleduji projekty, které open-sourcují své bezpečnostní audity, protože upřímně řečeno, pokud nemohu číst zdrojový kód, nevěřím tvrzením o soukromí.

Dále se ponoříme do toho, jak jsou tyto uzly vlastně placeny za svou námahu…

Motivace sítě tokenizovanou šířkou pásma

Proč by někdo nechával zapnutý počítač celou noc jen proto, aby směroval cizí provoz? Dříve se to dělalo "pro věc", ale dnes používáme tokenizovanou šířku pásma, aby se to vyplatilo. Je to v podstatě model Airbnb pro vaše internetové připojení.

  • Těžba šířky pásma (Bandwidth Mining): Provozujete uzel a síť vám platí v kryptoměnách v závislosti na tom, kolik dat úspěšně přenesete.
  • Důkaz šířky pásma (Proof of Bandwidth): Protokoly používají kryptografické výzvy k prokázání, že nefalšujete rychlosti. To je zásadní pro zastavení Sybil útoků, kdy se jeden člověk pokusí vytvořit 1 000 falešných uzlů, aby ovládl síť. Požadováním "vkladu" nebo důkazu o práci (proof of work) se pro hackera stane příliš drahé, aby falšoval spoustu identit.
  • Dynamické ceny: V decentralizované burze, pokud uzel v oblasti s vysokou cenzurou vypadne, odměny pro nové uzly v této oblasti prudce vzrostou.

Diagram 2

Vídal jsem lidi z maloobchodu a financí, jak to používají ke stahování dat, aniž by byli zablokováni. Dále se podíváme na kompromisy a reálné aplikace.

Kompromisy a aplikace v DePIN sítích

Poslouchejte, multi-hop není žádný zázračný lék; pokud posíláte provoz přes tři uzly po celém světě, odezva (ping) tím utrpí. Je to klasický kompromis, kde obětujete surovou rychlost za skutečnou digitální suverenitu.

Každý další "hop" přidává milisekundová zpoždění kvůli režii šifrování a fyzické vzdálenosti. I když je WireGuard rychlý, nebyl původně navržen pro směrování typu onion. Pro nápravu tohoto problému projekty DePIN nové generace optimalizují výběr uzlů na základě blízkosti nebo používají protokoly jako Sphinx, aby udržely jednotnou velikost paketů, takže nikdo nemůže odhadnout, co je uvnitř, na základě časování.

Reálné aplikace:

  • Zdravotnictví: Bezpečné sdílení záznamů o pacientech mezi klinikami bez úniku z centrální databáze.
  • Maloobchod: Zabránění konkurentům ve sledování stahování inventáře pomocí distribuované rotace IP adres.
  • Finance: High-frequency tradeři používají mesh sítě, aby se vyhnuli úzkým hrdlům centralizovaných burz.

Skutečným vítězstvím je, že síť je nemožné zničit. Protože neexistuje žádný centrální ředitel ani API, které by bylo možné předvolat, decentralizovaná alternativa ISP zůstane funkční, i když se ji vlády pokusí odpojit.

Diagram 3

Upřímně řečeno, budujeme odolnější web. Je to sice chaotické, ale je náš.

D
Daniel Richter

Open-Source Security & Linux Privacy Specialist

 

Daniel Richter is an open-source software advocate and Linux security specialist who has contributed to several privacy-focused projects including Tor, Tails, and various open-source VPN clients. With over 15 years of experience in systems administration and a deep commitment to software freedom, Daniel brings a community-driven perspective to cybersecurity writing. He maintains a personal blog on hardening Linux systems and has mentored dozens of contributors to privacy-focused open-source projects.

Související články

Zero-Knowledge Proofs for Anonymous Node Validation
Zero-Knowledge Proofs

Zero-Knowledge Proofs for Anonymous Node Validation

Learn how Zero-Knowledge Proofs (ZKPs) enable anonymous node validation in decentralized VPNs (dVPN) and DePIN networks to protect provider privacy.

Od Marcus Chen 19. března 2026 7 min čtení
common.read_full_article
Sybil Attack Resistance in DePIN Architectures
Sybil Attack Resistance

Sybil Attack Resistance in DePIN Architectures

Learn how DePIN and dVPN networks stop Sybil attacks. Explore Proof-of-Physical-Work, hardware attestation, and tokenized bandwidth security trends.

Od Viktor Sokolov 19. března 2026 9 min čtení
common.read_full_article
Sybil Attack Mitigation in Tokenized Mesh Networks
Sybil attack mitigation

Sybil Attack Mitigation in Tokenized Mesh Networks

Learn how DePIN and dVPN projects fight Sybil attacks in tokenized mesh networks using blockchain and proof-of-bandwidth protocols.

Od Viktor Sokolov 18. března 2026 8 min čtení
common.read_full_article
Tokenized Bandwidth Liquidity Pools
Tokenized Bandwidth

Tokenized Bandwidth Liquidity Pools

Learn how Tokenized Bandwidth Liquidity Pools enable P2P bandwidth sharing and crypto rewards in the DePIN ecosystem. Explore the future of decentralized internet.

Od Marcus Chen 18. března 2026 8 min čtení
common.read_full_article