Nollkunskapsbevis för anonym trafikdirigering | dVPN & DePIN

Problemet med traditionell routing och varför vi behöver ZKP

Har du någonsin funderat på om din "loggfria" VPN-tjänst verkligen är så privat som reklamen påstår? Det är en bister sanning, men traditionell routing – även den krypterade varianten – är i grunden bristfällig eftersom den bygger på blind tillit till centrala aktörer och statiska vägar som är förvånansvärt enkla att manipulera.

De flesta ser en VPN som en magisk tunnel, men under huven handlar det bara om en serie handskakningar med en leverantörs server. Problemet är att dessa servrar blir centrala sårbarhetspunkter (central points of failure). Även om en leverantör säger att de inte sparar loggar, satsar du fortfarande din integritet på deras ord och den fysiska säkerheten i deras datacenter.

• "No-Logs"-paradoxen: Du måste lita på att leverantören inte tvingas av myndigheter att lämna ut data eller drabbas av ett dolt dataintrång. Om den centrala servern komprometteras är din metadata – vem du är och vart din trafik går – helt oskyddad.
• Ohederliga noder i P2P-nätverk: I decentraliserade nätverk förekommer så kallad "routing-lögn". En nod kan hävda att den har den snabbaste vägen till en destination bara för att kunna fånga upp dina paket för analys – ett klassiskt man-in-the-middle-scenario.
• Trafikomdirigering: Forskning av Jacob D. White vid Los Alamos National Laboratory (2023) belyser hur routrar kan "ljuga" om sina vägval, vilket leder till blackholing eller avlyssningsattacker inom autonoma system. (White, J. D., "ZKPNet: Verifiable Routing," LA-UR-23-29806).

Vi behöver ett sätt att bevisa att en routing-väg är giltig utan att faktiskt avslöja själva vägen eller datan i den. Det är här Zero-Knowledge Proofs (ZKP) kommer in i bilden. Tänk på analogin med "Hitta Vilse": Jag kan bevisa att jag hittat Vilse på en karta genom att visa honom genom ett litet hål i ett gigantiskt pappark. Jag har bevisat att jag vet var han är utan att visa dig resten av kartan.

• Dataminimering: ZKP gör det möjligt för en nod att bevisa att den följt protokoll och policy utan att läcka några privata nätverksskisser.
• Metadatskydd: Till skillnad från enkel kryptering, som döljer innehåll men lämnar "brödsmulor" (IP-adresser, tidsstämplar), kan ZKP dölja avsändarens identitet även för de noder som faktiskt flyttar datan.
• Tillitslös verifiering (Trustless Verification): Du behöver inte lita på nodägaren; du litar på matematiken. Om beviset inte går ihop, flyttas inte paketet.

Inom finanssektorn kan en bank använda ZKP för att dirigera transaktioner genom ett tredjepartsnätverk för att maskera ursprunget, utan att nätverket kan se kontouppgifterna. Inom hälso- och sjukvård kan ett sjukhus dela patientjournaler över ett P2P-nätverk där routing-noderna inte ens kan se vilken klinik som begär datan, vilket säkerställer efterlevnad av strikta integritetslagar.

Ärligt talat är det nuvarande tillståndet för internet-routing en enda röra av läckande metadata och "lita på mig"-handskakningar. Men om vi kan byta ut den tilliten mot matematisk visshet, kan vi äntligen få den integritet vi faktiskt blivit lovade.

Hur ZKPNet och NIAR förändrar spelplanen

Vi har nu konstaterat att dagens internet-routing i princip bygger på en serie "hedersord" mellan servrar. Om vi ska kunna ta nästa steg behöver vi faktiskt matematik som inte läcker affärshemligheter. Det är här ZKPNet och NIAR (Network Infrastructure for Anonymous Routing) kommer in i bilden. NIAR är i grunden det ramverk som gör det möjligt att bygga dessa anonyma vägar utan en central instans.

I vanliga fall, om en router vill bevisa att den kan nå en viss destination, måste den visa upp sin routingtabell eller interna nätverksskisser. För en internetleverantör (ISP) eller ett sjukhusnätverk är detta en ren säkerhetsmardröm. Jacob D. White vid Los Alamos National Laboratory (2023) introducerade ZKPNet, ett Rust-baserat bibliotek som skapar så kallade "gadgets" för dessa intyganden.

• Minimalt fotavtryck: Dessa bevis är extremt små, ibland bara 224 bytes med hjälp av Groth16. Du kan inkludera det i ett huvud (header) utan att spränga din MTU (Maximum Transmission Unit).
• Single-Hop Reachability: En nod kan bevisa att den har en giltig väg till "Router Y" utan att avslöja exakt hur många hopp som krävs eller hur de interna IP-adresserna ser ut.
• Prestandamässiga avvägningar: Latens i realtid är det stora hindret här. Benchmarks på en M1 Max visar att genereringen av bevis tar cirka 468 ms. Nu är 468 ms en evighet för ett enskilt paket, så vi använder det inte för varje bit data. Istället används ZKP för kontrollplans-operationer – som att sätta upp vägen – medan själva datan flödar fritt så snart "tilliten" har etablerats.

Sedan har vi sPAR (Somewhat Practical Anonymous Router), som försöker lösa kravet på "ärliga noder" som finns i system likt Tor. Som diskuterats av Debajyoti Das och Jeongeun Park (2025), använder sPAR multi-party fully homomorphic encryption (FHE) så att inte ens routern vet vart den skickar informationen.

Den riktigt smarta delen är hur systemet undviker "kollisionsproblem". Om många försöker använda samma bandbreddsslot samtidigt, förstörs datan. sPAR använder en "choice-of-three"-strategi – ett matematiskt "ball-and-bins"-trick – där en klient väljer tre slumpmässiga index och meddelandet hamnar i den första lediga platsen.

• Homomorfisk placering: Servern placerar ditt paket i en "hink" (bucket) utan att någonsin se vilket index du valt. Allt sker medan datan fortfarande är krypterad.
• Skalbarhetsbegränsningar: Just nu kommer sPAR inte att ersätta det globala webbnätverket. Det stödjer cirka 128 användare med några sekunders latens, vilket gör det perfekt för nischade användningsområden som att "mixa" kryptotransaktioner eller för privat meddelandehantering inom ett LAN.

Föreställ dig en detaljhandelskedja som behöver synkronisera sitt lager. Genom att använda routing i sPAR-stil kan den centrala servern inte kartlägga vilken butik som skickar vilken uppdatering. Detta förhindrar konkurrenter från att analysera trafikvolymer för att lista ut vilka platser som är mest lönsamma.

Bandwidth-mining och den tokeniserade nätverksekonomin

Har du någonsin reflekterat över att din internetuppkoppling hemma bara står och tickar utan nytta när du är på jobbet eller sover? Det är i praktiken en outnyttjad tillgång, precis som att ha ett extra sovrum som aldrig hyrs ut.

Hela DePIN-rörelsen (Decentralized Physical Infrastructure Networks) håller på att förändra detta genom att skapa ett "Airbnb för bandbredd". Istället för att bara betala din internetleverantör varje månad, kan du faktiskt tjäna kryptovaluta genom att dela din outnyttjade anslutning med ett globalt P2P-nätverk.

Att bygga en decentraliserad VPN (dVPN) eller ett proxy-nätverk kräver tusentals noder för att vara praktiskt användbart. För att motivera människor att driva dessa noder använder projekt tokeniserade incitament. Du tillhandahåller infrastrukturen, och nätverket betalar dig i utility-tokens.

Men det finns ett betydande tekniskt hinder: hur vet nätverket att du faktiskt levererar bandbredd av hög kvalitet utan att spionera på den trafik du vidarebefordrar? Om en nod börjar logga användardata för att "bevisa" sin aktivitet, går hela integritetsaspekten med en Web3-VPN förlorad.

• Bandwidth Mining: Användare installerar en lättviktig nod-klient som bidrar med uppströmskapacitet till nätverkets gemensamma pool. Belöningar beräknas vanligtvis baserat på drifttid (uptime), genomströmning och geografisk efterfrågan.
• Integritetsbevarande bevis: Det är här ZKP (Zero-Knowledge Proofs) blir en räddare i nöden. Du kan bevisa nåbarhet och protokollefterlevnad utan att avslöja det faktiska innehållet i datapaketen eller interna nätverkskartor.
• Quality of Service (QoS): Noder kan tillhandahålla ett "Proof of Bandwidth" som använder matematiska intyg för att verifiera att de inte stryper trafiken eller skapar "svarta hål" för datapaket.

Om du vill hålla dig uppdaterad om hur dessa specifika VPN-protokoll utvecklas, är SquirrelVPN en utmärkt resurs för de senaste nyheterna inom VPN-teknik och säkerhetsuppdateringar. De bevakar noga skiftet från centraliserade datacenter till dessa distribuerade nod-modeller.

Själva "ekonomin" i detta system sker on-chain. Smarta kontrakt fungerar som automatiserade mellanhänder som hanterar utbytet mellan användare i behov av integritet och nod-operatörer med överskottsbandbredd.

• Automatiserade P2P-betalningar: Istället för en månadsabonnemang hos ett gigantiskt företag betalar du exakt för det du använder. Det smarta kontraktet frigör mikrobetalningar till nod-leverantörerna i realtid.
• Skydd mot Sybil-attacker: Om en enskild aktör kör 1 000 falska noder från en och samma server skulle nätverkets decentralisering rasera. Proof-of-bandwidth-protokoll – ofta kombinerat med krav på staking – gör det ekonomiskt ohållbart att "ljuga" om sina resurser.

I vårt tidigare exempel med sjukvården skulle en klinik kunna betala för bandbredd i detta nätverk med tokens. Tack vare att nätverket använder sPAR-logik får kliniken anonymitet, samtidigt som nod-operatörerna får betalt – allt utan att internetleverantören kan se trafikmönstren mellan kliniken och sjukhuset.

Djupdykning i det tekniska protokollagret

Nu lämnar vi den ekonomiska modellen och går in på det faktiska tekniska protokollagret. Det är här vi går ner på detaljnivå för att förstå hur vi faktiskt bäddar in dessa bevis i ett datapaket.

Det verkliga genombrottet här är elimineringen av "single point of failure" (en sårbar punkt). I en traditionell konfiguration är det en enskild part som sitter på alla nycklar. Men med hjälp av distribuerad, helt homomorfisk kryptering (multi-party Fully Homomorphic Encryption, FHE), kan vi generera en gemensam publik nyckel där bokstavligen ingen känner till den övergripande hemligheten.

• Gemensam nyckelgenerering (Joint Key Generation): Under konfigurationen skapar varje deltagare sin egen hemliga nyckel. Dessa kombineras till en enda publik nyckel ($pk$). Som Debajyoti Das och Jeongeun Park (2025) beskriver i sitt arbete om sPAR, är den övergripande hemliga nyckeln helt enkelt summan av alla individuella nycklar. Men eftersom ingen delar med sig av sin del, existerar den "fullständiga" nyckeln aldrig på en enskild plats.
• RLWE (Ring Learning With Errors): Detta utgör den matematiska grunden. Enkelt uttryckt är RLWE som ett komplext pussel där man lägger till en gnutta "brus" i datan. Det är extremt svårt för en dator att lösa detta baklänges, vilket ger oss ind-cpa-säkerhet (vilket innebär att en angripare inte kan skilja mellan två olika krypterade meddelanden, även om de gissar vad innehållet är).

Paketstrukturen: Här lever beviset

Var tar då det här 224-byte stora ZKP-beviset (Zero-Knowledge Proof) vägen? I en modern IPv6-miljö använder vi Extension Headers (tilläggshuvuden). Specifikt använder vi ett anpassat "Destination Options"-huvud.

Genom att placera beviset i tilläggshuvudet kan routrar som inte har stöd för ZKPNet helt enkelt skicka paketet vidare, medan "ZKP-medvetna" noder pausar, verifierar beviset på 2,7 ms och sedan skickar det vidare. Om beviset är falskt kastas paketet omedelbart.

• Skydd mot ekvivokation (Equivocation Protection): Vi kan förhindra att noder ljuger genom att baka in konversationshistoriken i nycklarna. Genom att använda en hash av kommunikationshistoriken för att uppdatera den publika nyckeln i varje runda, bryts matematiken om servern försöker visa en annan "verklighet" för Alice än för Bob.
• Verifierbar FHE: Istället för att bara lita på att en nod utför de matematiska beräkningarna korrekt, använder vi verifierbar FHE. Det fungerar som ett digitalt kvitto som bevisar att servern har följt protokollet exakt enligt specifikationen.

I vårt användningsfall för detaljhandeln är det detta tekniska lager som gör det möjligt för 100 butiker att synkronisera data. Strategin med "val-av-tre-fack" (choice-of-three bin strategy) säkerställer att även om en angripare fångar upp paketet och granskar IPv6-huvudet, kan de inte avgöra vilken butik datan kom ifrån, eftersom ZKP bevisar att vägen är giltig utan att avslöja källan.

Framtiden för DePIN och ett censurresistent internet

Om vi ska vara ärliga är dagens internet i princip en samling inhägnade trädgårdar som utger sig för att vara en global allmänning. Vi har i de föregående avsnitten diskuterat hur nollkunskapsbevis (ZKP) och P2P-bandbredd kan åtgärda de tekniska grundproblemen, men den stora frågan är hur detta ska kunna skalas upp när miljontals människor vill strömma video samtidigt.

Att skala upp dessa protokoll är en enorm utmaning på grund av det så kallade "anonymitetstrilemmat". Generellt sett tvingas man välja två av tre: stark integritet, låg latens eller låg bandbreddsbelastning. Genom att analysera komplexa system som Tor ser vi att även med "perfekt" kryptografi kvarstår sårbarheter för attacker på systemnivå, såsom trafikkorellering, om nätverket inte är tillräckligt tätt.

Den största flaskhalsen för ett decentraliserat fysiskt infrastrukturnätverk (DePIN) är avvägningen mellan "bevisstorlek" och "bevistid". Om varje enskilt paket i ett Web3-VPN kräver ett Groth16-bevis skulle din router bokstavligen smälta. För att lösa detta rör vi oss mot rekursiva bevis.

• Rekursiva SNARKs: Istället för att verifiera 1 000 individuella paketbevis kan en nod "rolla upp" dessa bevis till ett enda metabevis. Det fungerar som en rysk matrusjka-docka, där det yttersta lagret bevisar giltigheten för allt som finns inuti.
• Krympning av tillståndet (State Shrinking): Detta håller blockkedjans storlek hanterbar. Istället för att varje nod behöver känna till nätverkets hela historik, behöver de bara verifiera det senaste rekursiva beviset för att veta att routingtabellen är korrekt och ärlig.

Företag börjar nu inse att centraliserade VPN-tjänster utgör en riskfaktor för datasäkerheten. Distribuerade noder gör måltavlan betydligt svårare att träffa för angripare.

• AI-baserad routing: Vi ser ett skifte mot mjukvarudefinierade nätverk (SDN) där AI-agenter i realtid väljer den mest censurresistenta vägen för trafiken.
• Förbi internetleverantörer (ISP Bypass): Genom att tokenisera konnektivitet bygger vi i praktiken ett parallellt internet. Det handlar inte längre bara om att dölja sin IP-adress; det handlar om att äga infrastrukturen så att en internetleverantör inte bara kan trycka på en knapp och bryta din åtkomst.

Implementeringsguide för nodoperatörer

Du har nu läst om matematiken och teorin, men du undrar förmodligen hur du faktiskt sätter igång en nod i praktiken. Ärligt talat är installationen av en ZKP-aktiverad nod ett perfekt helgprojekt, men det är också det enda sättet att gå från att "lita på en VPN-leverantör" till att "lita på fysikens lagar".

Hårdvarukrav och konfiguration

Du behöver ingen serverhall, men du kan inte direkt köra det på en brödrost heller.

• Minimikrav: Sikta på minst 8 GB RAM och en modern fyrkärnig processor.
• Nätverk: En symmetrisk fiberanslutning är drömmen, men minst 20 Mbps i uppladdningshastighet (upstream) krävs.

Initiering av en Proof Gadget

De flesta moderna dVPN-projekt använder bibliotek som arkworks eller bellman. Här är ett exempel i pseudokod på hur en nod kan initiera en "path-validation gadget" med hjälp av logik från ZKPNet:

// Pseudokod för att initiera en ZKP-routing-gadget
use zkpnet_lib::{Prover, PathCircuit};

fn prove_path(secret_path: Vec<u8>, public_root: [u8; 32]) {
    // 1. Initiera kretsen (circuit) med den dolda routing-vägen
    let circuit = PathCircuit {
        path: secret_path,
        root: public_root,
    };

    // 2. Generera ett Groth16-bevis (tar ca 468ms)
    let proof = Prover::prove(circuit, &params).expect("Proving failed");

    // 3. Bifoga beviset på 224 byte till IPv6 Extension Header
    packet.attach_header(0xZK, proof.to_bytes());
}

När du konfigurerar din backend, kom ihåg att själva bevistiden (proving time) är den kritiska flaskhalsen – nästan en halv sekund. Om du sätter upp detta, se till att din nod inte försöker bevisa varje enskilt paket. Använd istället probabilistiska bevis eller batch-bearbetning. Du bevisar att du hanterat ett visst fönster av trafik korrekt under själva setup-fasen för routing-vägen.

Vanliga fallgropar att undvika:

1. Dubbla NAT-problem: Om din nod sitter bakom två routrar kommer P2P-identifieringen (discovery) att misslyckas. Använd UPnP eller manuell port forwarding.
2. Klockavvikelse (Clock Skew): ZKP- och blockchain-protokoll är extremt tidskänsliga. Kör en lokal NTP-daemon.
3. IPv6-läckor: Många konfigurerar sin VPN-nod för IPv4 men glömmer att deras internetleverantör (ISP) även delar ut IPv6-adresser.

Övergången från ett centraliserat internet till ett decentraliserat, ZKP-drivet nätverk kommer att vara utmanande. Vi kämpar fortfarande med latensproblem och det så kallade "anonymitetstrilemmat". Men framstegen är på riktigt. Oavsett om du kör en nod för att tjäna tokens eller för att du är trött på ISP-övervakning, så är du med och bygger en mer motståndskraftig infrastruktur. Kom bara ihåg: håll din firmware uppdaterad, håll koll på processortemperaturen och för allt i världen – tappa inte bort dina privata nycklar.