Důkazy s nulovou znalostí pro anonymní směrování v dVPN

Problém s tradičním směrováním a proč nezbytně potřebujeme ZKP

Napadlo vás někdy, jestli je vaše „no-logs“ VPN skutečně tak soukromá, jak tvrdí marketing? Je to hořká pilulka, ale tradiční směrování – i to šifrované – je v základu nefunkční. Spoléhá se totiž na slepou důvěru v centrální autority a statické cesty, které lze překvapivě snadno zmanipulovat.

Většina lidí si představuje VPN jako magický tunel, ale pod kapotou jde jen o sérii „potřesení rukou“ (handshakes) se serverem poskytovatele. Problém je v tom, že tyto servery se stávají centrálními body selhání. I když poskytovatel tvrdí, že nic neukládá, stále sázíte své soukromí na jeho slovo a fyzické zabezpečení jeho datového centra.

• Paradox „žádných záznamů“ (No-Logs): Musíte věřit, že poskytovatel není pod tlakem státních orgánů nebo se nestal obětí tichého úniku dat. Pokud je centrální server kompromitován, vaše metadata – tedy informace o tom, kdo jste a kam přistupujete – jsou zcela odhalena.
• Nečestné uzly v P2P sítích: V decentralizovaných sítích se setkáváme s takzvaným „lhaním o směrování“. Uzel může tvrdit, že má nejrychlejší cestu k cíli, jen aby zachytil vaše pakety k analýze, což je klasický scénář útoku typu man-in-the-middle.
• Odklonění provozu: Výzkum Jacoba D. Whitea z Los Alamos National Laboratory (2023) upozorňuje na to, jak mohou routery „lhát“ o svých cestách, což vede k útokům typu blackholing nebo k odposlechu v rámci autonomních systémů. (White, J. D., "ZKPNet: Verifiable Routing," LA-UR-23-29806).

Potřebujeme způsob, jak dokázat, že je směrovací cesta platná, aniž bychom odhalili cestu samotnou nebo data uvnitř. A právě zde přicházejí na scénu důkazy s nulovým rozšířením znalostí (Zero-Knowledge Proofs – ZKP). Představte si to jako analogii s „Waldem“: mohu dokázat, že jsem našel Walda na mapě tak, že ho ukážu malým otvorem v obrovském kusu kartonu. Dokázal jsem, že vím, kde je, aniž bych vám ukázal zbytek mapy.

• Minimalizace dat: ZKP umožňuje uzlu prokázat, že dodržel protokol a pravidla, aniž by unikly jakékoli soukromé informace o schématu sítě.
• Ochrana metadat: Na rozdíl od běžného šifrování, které skryje obsah, ale zanechá „digitální stopu“ (IP adresy, časová razítka), dokáže ZKP skrýt identitu odesílatele i před samotnými uzly, které data přenášejí.
• Ověřování bez nutnosti důvěry (Trustless): Nemusíte věřit majiteli uzlu; věříte matematice. Pokud důkaz nesouhlasí, paket se nepohne.

Ve financích by banka mohla využít ZKP ke směrování transakcí přes síť třetí strany, aby maskovala původ, aniž by síť viděla detaily účtu. Ve zdravotnictví by nemocnice mohla sdílet záznamy pacientů přes P2P síť, kde směrovací uzly ani nevidí, která klinika o data žádá, což zajišťuje soulad s přísnými zákony o ochraně osobních údajů.

Upřímně řečeno, současný stav internetového směrování je chaos plný unikajících metadat a slibů typu „věřte mi“. Pokud se nám však podaří vyměnit tuto důvěru za matematickou jistotu, možná se konečně dočkáme soukromí, které nám bylo slibováno.

Jak ZKPNet a NIAR mění pravidla hry

Už jsme si ujasnili, že současné směrování na internetu je v podstatě jen série „čestných slov“ mezi servery. Pokud se chceme posunout dál, potřebujeme skutečnou matematiku, která nebude vyzrazovat naše interní data. Právě zde přichází na scénu ZKPNet a NIAR (Network Infrastructure for Anonymous Routing – Síťová infrastruktura pro anonymní směrování). NIAR je v podstatě framework, který nám umožňuje budovat tyto anonymní cesty bez existence centrálního správce.

Běžně platí, že pokud chce router prokázat, že se dokáže spojit s cílovým bodem, musí odhalit svou směrovací tabulku nebo interní schémata. Pro poskytovatele internetového připojení (ISP) nebo nemocniční síť to představuje bezpečnostní noční můru. Jacob D. White z Národní laboratoře Los Alamos (2023) proto představil ZKPNet, knihovnu postavenou na jazyku Rust, která vytváří takzvané „gadgety“ pro tato potvrzení.

• Minimální datová stopa: Tyto důkazy jsou drobné, při použití protokolu Groth16 mají někdy pouhých 224 bajtů. To lze snadno vložit do hlavičky, aniž by došlo k překročení limitu MTU.
• Dosažitelnost na jeden skok (Single-Hop): Uzel může prokázat, že má platnou cestu k „Routeru Y“, aniž by ukázal přesný počet skoků nebo podobu interních IP adres.
• Výkonnostní kompromisy: Hlavní překážkou je zde latence v reálném čase. Benchmarky na procesoru M1 Max ukazují, že vytvoření důkazu trvá přibližně 468 ms. Pro jeden paket je 468 ms věčnost, proto se ZKP nepoužívá pro každý jednotlivý bit dat. Místo toho se využívá pro operace v řídicí rovině (control-plane) – například pro sestavení cesty – zatímco samotná data proudí vysokou rychlostí, jakmile je „důvěra“ jednou navázána.

Dále zde máme sPAR (Somewhat Practical Anonymous Router – Částečně praktický anonymní router), který se snaží vyřešit požadavek na „poctivý uzel“, jenž je slabinou systémů jako Tor. Jak uvádějí Debajyoti Das a Jeongeun Park (2025), sPAR využívá vícestranné plně homomorfní šifrování (FHE), díky němuž ani samotný router neví, kam data odesílá.

Fascinující je způsob, jakým sPAR řeší „problém kolizí“. Pokud se více uživatelů pokusí využít stejný slot šířky pásma, data se znehodnotí. sPAR využívá strategii volby ze tří – matematický trik založený na teorii pravděpodobnosti (balls-and-bins) – kdy si klient vybere tři náhodné indexy a zpráva se uloží do prvního volného.

• Homomorfní umístění: Server umístí váš paket do „koše“, aniž by kdy viděl index, který jste si vybrali. Vše probíhá v momentě, kdy jsou data stále zašifrovaná.
• Limity škálování: V současné době sPAR nenahradí globální web. Podporuje přibližně 128 uživatelů s latencí v řádu několika sekund, což je ideální pro specifické účely, jako je mixování krypto transakcí nebo soukromá komunikace v rámci LAN.

Představte si maloobchodní řetězec, který potřebuje synchronizovat skladové zásoby. Díky směrování ve stylu sPAR nemůže centrální server zmapovat, která prodejna odesílá konkrétní aktualizaci. To brání konkurentům v tom, aby na základě objemu síťového provozu odhalili, které pobočky jsou nejziskovější.

Těžba šířky pásma a ekonomika tokenizovaných sítí

Napadlo vás někdy, že vaše domácí internetové připojení jen tak nečinně zahálí, zatímco jste v práci nebo spíte? V podstatě jde o nevyužité aktivum – podobně jako kdybyste měli volný pokoj pro hosty, který nikdy nepronajímáte.

Celé hnutí DePIN (decentralizované sítě fyzické infrastruktury) tento přístup mění a vytváří jakési „Airbnb pro šířku pásma“. Místo toho, abyste každý měsíc jen platili svému poskytovateli internetu (ISP), můžete nyní vydělávat kryptoměny sdílením svého nevyužitého připojení v globální P2P síti.

Vybudování decentralizované VPN nebo proxy sítě vyžaduje tisíce uzlů, aby byla služba skutečně použitelná. Aby projekty motivovaly uživatele k provozování těchto uzlů, využívají tokenizované pobídky. Vy poskytnete „potrubí“ a síť vám zaplatí v užitkových tokenech.

Existuje však obrovská technická překážka: jak může síť vědět, že skutečně poskytujete kvalitní šířku pásma, aniž by špehovala provoz, který přes vás proudí? Pokud by uzel začal protokolovat uživatelská data, aby „dokázal“, že pracuje, celý aspekt soukromí Web3 VPN by se okamžitě rozplynul.

• Těžba šířky pásma (Bandwidth Mining): Uživatelé si nainstalují lehkého klienta (uzel), který přispívá odchozí kapacitou do síťového poolu. Odměny se obvykle počítají na základě doby provozu (uptime), propustnosti a geografické poptávky.
• Důkazy zachovávající soukromí: Zde přichází na pomoc technologie ZKP (důkazy s nulovým rozšířením znalostí). Můžete prokázat dostupnost a soulad s protokolem, aniž byste odhalili skutečný obsah paketů nebo vnitřní mapy sítě.
• Kvalita služeb (QoS): Uzly mohou poskytovat „Proof of Bandwidth“ (důkaz o šířce pásma), což jsou matematická potvrzení ověřující, že uzel neomezuje provoz ani „nepohlcuje“ pakety (tzv. blackholing).

Pokud chcete sledovat, jak se tyto specifické VPN protokoly vyvíjejí, doporučujeme navštívit SquirrelVPN, kde najdete nejnovější zprávy o technologiích VPN a aktualizace v oblasti bezpečnosti. Sledují totiž aktuální posun od centralizovaných datových center k těmto distribuovaným modelům založeným na uzlech.

Samotná „ekonomická“ část probíhá přímo na blockchainu (on-chain). Chytré kontrakty fungují jako automatizovaní zprostředkovatelé, kteří řeší směnu mezi uživateli vyžadujícími soukromí a provozovateli uzlů s přebytečnou kapacitou.

• Automated P2P Payments: Namísto měsíčního předplatného u obří korporace platíte přesně za to, co spotřebujete. Chytrý kontrakt uvolňuje mikroplatby poskytovatelům uzlů v reálném čase.
• Odolnost proti Sybil útokům: Kdyby jeden člověk spustil 1 000 falešných uzlů z jediného serveru, zničil by decentralizaci sítě. Protokoly Proof-of-Bandwidth – často podpořené požadavky na staking – způsobují, že „lhát“ o vašich zdrojích je ekonomicky příliš nákladné.

V našem příkladu ze zdravotnictví by klinika mohla za šířku pásma v této síti platit pomocí tokenů. Protože síť využívá logiku sPAR (o které jsme mluvili dříve), klinika získá anonymitu a provozovatelé uzlů dostanou zaplaceno – to vše, aniž by poskytovatel internetu viděl vzorce provozu mezi klinikou a nemocnicí.

Detailní vhled do vrstvy technického protokolu

Nyní se přesuneme od ekonomického modelu k samotné vrstvě technického protokolu. Zde se podíváme pod kapotu toho, jak tyto důkazy skutečně vkládáme do datových paketů.

Skutečným průlomem je zde eliminace jediného bodu selhání (single point of failure). V běžném nastavení drží klíče od hradu jedna osoba. Avšak díky multi-party plně homomorfnímu šifrování (FHE) dokážeme vygenerovat společný veřejný klíč, u něhož doslova nikdo nezná hlavní tajný klíč (master secret).

• Společné generování klíčů (Joint Key Generation): Během fáze nastavení si každý účastník vytvoří svůj vlastní tajný klíč. Ty jsou následně zkombinovány do jediného veřejného klíče ($pk$). Jak uvádějí Debajyoti Das a Jeongeun Park (2025) ve své práci o sPAR, hlavní tajný klíč je prostým součtem všech jednotlivých klíčů. Jelikož ale nikdo svůj klíč nesdílí, „celistvý“ klíč v jeden okamžik na žádném místě neexistuje.
• RLWE (Ring Learning With Errors): Toto je matematický základ celého systému. Laicky řečeno, RLWE je jako složitý hlavolam, kde k datům přidáte malé množství „šumu“. Pro počítač je extrémně náročné tento proces zvrátit, což nám poskytuje ind-cpa bezpečnost (to znamená, že útočník nedokáže rozlišit dvě různé zašifrované zprávy, i kdyby hádal jejich obsah).

Struktura paketu: Kde se nachází důkaz?

Kam se tedy onen 224bajtový důkaz s nulovou znalostí (ZKP) vlastně ukládá? V moderním nastavení protokolu IPv6 využíváme rozšiřující hlavičky (Extension Headers). Konkrétně používáme vlastní hlavičku typu „Destination Options“.

Umístěním důkazu do rozšiřující hlavičky zajistíme, že směrovače, které ZKPNet nepodporují, paket jednoduše předají dál. Avšak uzly, které „rozumí ZKP“, se zastaví, během 2,7 ms důkaz ověří a teprve poté jej pošlou dál. Pokud je důkaz podvržený, paket je okamžitě zahozen.

• Ochrana proti ekvivokaci (Equivocation Protection): Uzlům můžeme zabránit ve lhaní tím, že historii konverzace včleníme přímo do klíčů. Použitím hashe historie komunikace k aktualizaci veřejného klíče v každém kole zajistíme, že pokud se server pokusí ukázat Alici jinou „realitu“ než Bobovi, matematické výpočty přestanou sedět.
• Verifikovatelné FHE: Namísto pouhé důvěry, že uzel provede výpočty správně, používáme verifikovatelné FHE. Funguje to jako digitální stvrzenka, která dokazuje, že server postupoval přesně podle protokolu.

V našem scénáři pro maloobchodní sektor je to právě tato technická vrstva, která umožňuje synchronizaci dat mezi 100 prodejnami. Strategie „výběru ze tří košů“ (choice-of-three bin) zajišťuje, že i když útočník zachytí paket a prohlédne si IPv6 hlavičku, nedokáže určit, ze které prodejny data pocházejí. ZKP totiž prokazuje platnost cesty, aniž by odhalilo identitu zdroje.

Budoucnost DePIN a internetu odolného vůči cenzuře

Pokud si budeme nalévat čistého vína, současný internet je v podstatě jen soubor uzavřených platforem, které se tváří jako globální veřejný statek. V předchozích částech jsme rozebírali, jak mohou technologie důkazů s nulovou znalostí (ZKP) a peer-to-peer (P2P) sdílení šířky pásma opravit tyto „prorezlé trubky“, ale zásadní otázkou zůstává: jak to všechno škálovat, když se miliony lidí pokusí streamovat video najednou?

Škálování těchto protokolů je nesmírně náročné kvůli takzvanému „trilematu anonymity“. Zpravidla si musíte vybrat pouze dvě ze tří vlastností: silné soukromí, nízkou latenci nebo nízkou režii šířky pásma. Analýza komplexních systémů, jako je Tor, ukazuje, že i při „dokonalé“ kryptografii stále čelíte útokům na úrovni systému, například korelaci provozu, pokud síť není dostatečně hustá.

Největším úzkým hrdlem pro decentralizované sítě fyzické infrastruktury (DePIN) je poměr mezi „velikostí důkazu“ a „časem pro jeho vygenerování“. Pokud by každý paket ve Web3 VPN vyžadoval důkaz Groth16, váš router by se pravděpodobně roztavil. Řešením, na které se nyní zaměřujeme, jsou rekurzivní důkazy.

• Rekurzivní SNARKy: Namísto ověřování 1 000 jednotlivých důkazů paketů může uzel tyto důkazy „zabalit“ (roll up) do jediného meta-důkazu. Je to jako ruská matrioška, kde vnější vrstva potvrzuje platnost všeho, co je uvnitř.
• Zmenšování stavu (State Shrinking): To udržuje velikost blockchainu v rozumných mezích. Uzly nemusí znát celou historii sítě; stačí jim ověřit poslední rekurzivní důkaz, aby měly jistotu, že směrovací tabulka je legitimní.

Firmy si začínají uvědomovat, že centralizované VPN představují pro bezpečnost dat značné riziko. Distribuované uzly dělají z infrastruktury mnohem obtížnější cíl pro případné útočníky.

• Směrování založené na AI: Sledujeme posun k softwarově definovaným sítím (SDN), kde agenti umělé inteligence v reálném čase vybírají cestu, která je nejvíce odolná vůči cenzuře.
• Obcházení ISP: Tokenizací konektivity v podstatě budujeme paralelní internet. Už nejde jen o skrytí vaší IP adresy; jde o to vlastnit infrastrukturu tak, aby poskytovatel internetu (ISP) nemohl jednoduše „přepnout vypínač“ a odříznout vás od přístupu.

Implementační příručka pro operátory uzlů

Teorii a matematické základy už znáte, ale teď vás pravděpodobně zajímá, jak uzel skutečně zprovoznit. Upřímně řečeno, nastavení uzlu s podporou ZKP (Zero-Knowledge Proofs) je projekt tak na víkend, ale je to jediná cesta, jak přejít od „důvěry v poskytovatele VPN“ k „důvěře ve fyzikální zákony“.

Specifikace uzlu a nastavení

Nepotřebujete sice serverovou farmu, ale na toustovači to také nerozjedete.

• Minimální specifikace: Doporučuji cílit alespoň na 8 GB RAM a moderní čtyřjádrový procesor.
• Síť: Symetrické optické připojení je ideál, ale nezbytným minimem je alespoň 20 Mbps pro upload (upstream).

Inicializace proof gadgetu

Většina moderních dVPN projektů využívá knihovny jako arkworks nebo bellman. Zde je ukázka pseudokódu, jak by uzel mohl inicializovat gadget pro validaci cesty pomocí logiky ZKPNet:

// Pseudokód pro inicializaci ZKP směrovacího gadgetu
use zkpnet_lib::{Prover, PathCircuit};

fn prove_path(secret_path: Vec<u8>, public_root: [u8; 32]) {
    // 1. Inicializace okruhu (circuit) s tajnou směrovací cestou
    let circuit = PathCircuit {
        path: secret_path,
        root: public_root,
    };

    // 2. Generování Groth16 důkazu (trvá cca 468 ms)
    let proof = Prover::prove(circuit, &params).expect("Generování důkazu selhalo");

    // 3. Připojení 224bajtového důkazu k IPv6 Extension Headeru
    packet.attach_header(0xZK, proof.to_bytes());
}

Při nastavování backendu mějte na paměti, že největším úskalím je čas generování důkazu (proving time) – trvá to téměř půl sekundy. Pokud uzel konfigurujete, zajistěte, aby se nepokoušel prokazovat každý jednotlivý paket. Místo toho využijte pravděpodobnostní důkazy nebo dávkování (batching). Prokazujete, že jste správně odbavili určité okno provozu během fáze ustavování cesty.

1. Problémy s Double NAT: Pokud je váš uzel za dvěma routery, P2P vyhledávání (discovery) selže. Použijte UPnP nebo manuální přesměrování portů (port forwarding).
2. Odchylka hodin (Clock Skew): ZKP a blockchainové protokoly jsou citlivé na přesný čas. Spusťte si lokálního NTP démona.
3. Úniky přes IPv6: Mnoho lidí si nakonfiguruje VPN uzel pro IPv4, ale zapomene, že jejich poskytovatel (ISP) přiděluje i IPv6 adresy.

Přechod od centralizovaného internetu k decentralizovanému, poháněnému pomocí ZKP, bude náročný. Stále bojujeme s latencí a „trilematem anonymity“. Pokrok je však hmatatelný. Ať už uzel provozujete kvůli tokenovým odměnám, nebo proto, že už máte dost sledování ze strany ISP, stáváte se součástí budování odolnější infrastruktury. Jen nezapomeňte: udržujte firmware aktualizovaný, hlídejte si teploty procesoru a proboha, neztraťte své privátní klíče.