Zero-Knowledge Proofs for anonym trafikkruting i dVPN

Problemet med tradisjonell ruting og hvorfor vi trenger ZKP

Har du noen gang lurt på om din "loggfrie" VPN faktisk er så privat som markedsføringen påstår? Det er en bitter pille å svelge, men tradisjonell ruting – selv den krypterte varianten – er fundamentalt mangelfull. Årsaken er at den hviler på blind tillit til sentrale aktører og statiske ruter som er overraskende enkle å manipulere.

De fleste ser på en VPN som en magisk tunnel, men under panseret er det bare en serie "håndtrykk" med en leverandørs server. Problemet er at disse serverne blir sentrale sårbarhetspunkter (central points of failure). Selv om en leverandør lover at de ikke logger, satser du fortsatt privatlivet ditt på deres ord og den fysiske sikkerheten i deres datasenter.

• "Ingen logg"-paradokset: Du må stole på at leverandøren ikke blir presset av myndigheter eller rammet av et umerket datainnbrudd. Hvis den sentrale serveren blir kompromittert, ligger dine metadata – hvem du er og hvor du skal – vid åpne.
• Uærlige noder i P2P: I desentraliserte nettverk ser vi ofte "rutings-løgn". En node kan påstå at den har den raskeste veien til en destinasjon bare for å snappe opp pakkene dine for analyse – et klassisk "mannen-i-midten"-angrep.
• Trafikkavledning: Forskning utført av Jacob D. White ved Los Alamos National Laboratory (2023) belyser hvordan rutere kan "lyve" om rutevalgene sine, noe som fører til blackholing eller avlyttingsangrep innenfor autonome systemer (White, J. D., "ZKPNet: Verifiable Routing," LA-UR-23-29806).

Vi trenger en metode for å bevise at en rutingsvei er gyldig uten å faktisk avsløre selve ruten eller dataene som sendes. Det er her Zero-Knowledge Proofs (ZKP) kommer inn. Tenk på det som "Hvor er Willy"-analogien: Jeg kan bevise at jeg har funnet Willy på et kart ved å vise ham gjennom et lite hull i et gigantisk pappark. Jeg har bevist at jeg vet hvor han er, uten å vise deg resten av kartet.

• Dataminimering: ZKP gjør det mulig for en node å bevise at den har fulgt protokollen og gjeldende regler uten å lekke private nettverksskisser.
• Beskyttelse av metadata: I motsetning til enkel kryptering, som skjuler innholdet men etterlater "smuler" (IP-adresser, tidsstempler), kan ZKP skjule senderens identitet selv for nodene som flytter dataene.
• Tillitsløs verifisering: Du trenger ikke å stole på eieren av noden; du stoler på matematikken. Hvis beviset ikke stemmer, blir ikke pakken sendt videre.

Innen finans kan en bank bruke ZKP for å rute transaksjoner gjennom et tredjepartsnettverk for å skjule opprinnelsen, uten at nettverket ser kontodetaljene. Innen helsevesen kan et sykehus dele pasientjournaler over et P2P-nettverk der rutingsnodene ikke engang kan "se" hvilken klinikk som ber om dataene, noe som sikrer samsvar med strenge personvernlover.

Ærlig talt er dagens internettruting et kaos av lekkende metadata og "stol på meg"-avtaler. Men hvis vi kan bytte ut denne tilliten med matematisk sikkerhet, kan vi endelig få det personvernet vi ble lovet.

Hvordan ZKPNet og NIAR endrer spillereglene

Vi har nå fastslått at dagens internett-routing i bunn og grunn er basert på en serie "tillitserklæringer" mellom servere. Hvis vi skal komme oss videre fra dette, trenger vi matematikk som faktisk fungerer uten at forretningshemmelighetene våre lekker ut. Det er her ZKPNet og NIAR (Network Infrastructure for Anonymous Routing) kommer inn i bildet. NIAR er i praksis rammeverket som lar oss bygge disse anonyme stiene uten behov for en sentral autoritet.

Vanligvis, hvis en ruter skal bevise at den kan nå en destinasjon, må den vise frem rutingtabellen sin eller interne tekniske tegninger. Dette er et sikkerhetsmessig mareritt for en internettleverandør (ISP) eller et sykehusnettverk. Jacob D. White ved Los Alamos National Laboratory (2023) introduserte ZKPNet, et Rust-basert bibliotek som lager "gadgets" for disse bevisføringene.

• Minimalt fotavtrykk: Disse bevisene er bittesmå, noen ganger bare 224 bytes ved bruk av groth16. Du kan legge dette i en header uten at det går utover MTU-størrelsen (Maximum Transmission Unit).
• Enkelt-hopp-tilgjengelighet: En node kan bevise at den har en gyldig sti til "Ruter Y" uten å avsløre nøyaktig hvor mange hopp det er, eller hvordan de interne IP-adressene ser ut.
• Ytelsesavveininger: Forsinkelse (latency) i sanntid er den største utfordringen her. Ytelsestester på en M1 Max viser at bevisføringen tar rundt 468 ms. Nå er 468 ms en evighet for en enkelt pakke, så vi bruker det ikke for hver eneste bit med data. I stedet brukes ZKP for kontrollplan-operasjoner – som å sette opp stien – mens selve dataene flyter fritt når "tilliten" først er etablert.

I tillegg har vi sPAR (Somewhat Practical Anonymous Router), som prøver å løse kravet om "ærlige noder" i systemer som Tor. Som diskutert av Debajyoti Das og Jeongeun Park (2025), bruker sPAR multi-party fullstendig homomorfisk kryptering (FHE), slik at selv ikke ruteren vet hvor den sender dataene.

Det geniale er hvordan systemet unngår "kollisjonsproblemet". Hvis mange prøver å bruke samme båndbredde-spor samtidig, blir dataene ødelagt. sPAR bruker en "valg-av-tre"-strategi – et matematisk triks kjent som "balls-and-bins" – der en klient velger tre tilfeldige indekser, og meldingen havner i den første ledige plassen.

• Homomorfisk plassering: Serveren plasserer pakken din i en "bøtte" uten noen gang å se hvilken indeks du valgte. Alt dette skjer mens dataene fortsatt er kryptert.
• Skaleringsbegrensninger: Foreløpig kommer ikke sPAR til å erstatte det globale nettet. Det støtter rundt 128 brukere med noen sekunders forsinkelse, noe som gjør det perfekt for nisjeområder som miksing av kryptotransaksjoner eller privat meldingsutveksling i et lokalnett (LAN).

Se for deg en butikkjede som må synkronisere varelageret sitt. Ved å bruke ruting i sPAR-stil, kan ikke den sentrale serveren kartlegge hvilken butikk som sender hvilken oppdatering. Dette hindrer konkurrenter i å snuse opp hvilke lokasjoner som er mest lønnsomme basert på trafikkmengden.

Båndbredde-mining og den tokeniserte nettverksøkonomien

Har du noen gang tenkt over at internettforbindelsen din bare står der ubrukt mens du er på jobb eller sover? Det er i praksis en uutnyttet ressurs, akkurat som å ha et gjesterom som står tomt uten at du leier det ut.

Hele DePIN-bevegelsen (desentraliserte fysiske infrastrukturnettverk) snur nå opp-ned på dette ved å skape et slags "Airbnb for båndbredde". I stedet for å bare betale nettleverandøren din hver måned, kan du faktisk tjene krypto ved å dele den ubrukte kapasiteten din med et globalt P2P-nettverk.

For å bygge en desentralisert VPN (dVPN) eller et proxy-nettverk som faktisk fungerer, kreves det tusenvis av noder. For å få folk til å drifte disse nodene, bruker prosjektene tokeniserte insentiver. Du stiller med "rørene", og nettverket betaler deg i utility-tokens.

Men det finnes en massiv teknisk utfordring: Hvordan kan nettverket vite at du faktisk leverer båndbredde av høy kvalitet uten å spionere på trafikken du ruter? Hvis en node begynner å logge brukerdata for å "bevise" at den fungerer, forsvinner hele personvernaspektet ved en Web3-VPN.

• Båndbredde-mining: Brukere installerer en lettvekts node-klient som bidrar med oppstrømskapasitet til nettverkets fellesressurser. Belønninger beregnes vanligvis basert på oppetid, gjennomstrømming og geografisk etterspørsel.
• Personvernsbevarende bevis: Det er her Zero-Knowledge Proofs (ZKP) blir en livredder. Du kan bevise tilgjengelighet og protokoll-etterlevelse uten å avsløre det faktiske innholdet i pakkene eller interne nettverkskart.
• Tjenestekvalitet (QoS): Noder kan levere et "Proof of Bandwidth" som bruker matematiske attesteringer for å verifisere at de ikke struper trafikken eller "blackholer" datapakker.

Hvis du vil holde deg oppdatert på hvordan disse spesifikke VPN-protokollene utvikler seg, er det en god idé å sjekke ut SquirrelVPN for de nyeste nyhetene innen VPN-teknologi og sikkerhetsoppdateringer. De følger tett med på skiftet fra sentraliserte datasentre til disse distribuerte nodemodellene.

Selve "økonomien" i dette foregår on-chain. Smarte kontrakter fungerer som automatiserte mellomledn som håndterer utvekslingen mellom brukere som trenger personvern, og nodetilbydere som har overskytende båndbredde.

• Automatiserte P2P-betalinger: I stedet for et månedlig abonnement hos et gigantisk selskap, betaler du nøyaktig for det du bruker. Den smarte kontrakten utbetaler mikrobetalinger til nodetilbyderne i sanntid.
• Beskyttelse mot Sybil-angrep: Hvis én person drifter 1 000 falske noder fra en enkelt server, kan det ødelegge nettverkets desentralisering. Proof-of-bandwidth-protokoller – ofte støttet av krav om staking – gjør det altfor dyrt å "lyve" om ressursene man har tilgjengelig.

I eksempelet vårt fra helsesektoren kan en klinikk betale for båndbredde på dette nettverket ved hjelp av tokens. Fordi nettverket bruker sPAR-logikken vi diskuterte tidligere, får klinikken anonymitet, og nodetilbyderne får betalt – alt uten at nettleverandøren (ISP) kan se trafikkmønstrene mellom klinikken og sykehuset.

Et dypdykk i det tekniske protokollaget

Nå som vi har sett på den økonomiske modellen, skal vi bevege oss over i det faktiske tekniske protokollaget. Det er her vi går i detalj på hvordan vi faktisk implementerer disse bevisene direkte i datapakken.

Det store gjennombruddet her er overgangen bort fra "single point of failure" – ett sårbart punkt. I et typisk oppsett er det én aktør som sitter med alle nøklene. Men ved å bruke flerparts fullstendig homomorf kryptering (FHE), kan vi generere en felles offentlig nøkkel der bokstavelig talt ingen kjenner den overordnede hemmeligheten (master secret).

• Felles nøkkelgenerering (Joint Key Generation): Under oppsettet genererer hver deltaker sin egen private nøkkel. Disse kombineres til én enkelt offentlig nøkkel ($pk$). Som beskrevet av Debajyoti Das og Jeongeun Park (2025) i deres arbeid med sPAR, er den overordnede hemmelige nøkkelen summen av alle individuelle nøkler. Siden ingen deler sin private del, eksisterer aldri den "komplette" nøkkelen på ett enkelt sted.
• RLWE (Ring Learning With Errors): Dette er det matematiske fundamentet. Enkelt forklart er RLWE som et komplekst puslespill der man legger til en liten mengde "støy" i dataene. Det er ekstremt vanskelig for en datamaskin å løse dette baklengs, noe som gir oss IND-CPA-sikkerhet (dette betyr at en angriper ikke kan skille mellom to ulike krypterte meldinger, selv om de prøver å gjette innholdet).

Pakkestrukturen: Her lever beviset

Hvor blir det egentlig av dette 224-byte store nullkunnskapsbeviset (ZKP)? I et moderne IPv6-oppsett benytter vi oss av Extension Headers (utvidelseshoder). Mer spesifikt bruker vi et tilpasset "Destination Options"-hode.

Ved å plassere beviset i utvidelseshodet, kan rutere som ikke støtter ZKPNet bare sende pakken videre uten problemer. "ZKP-bevisste" noder vil derimot stoppe opp, verifisere beviset på ca. 2,7 ms, og deretter videresende den. Hvis beviset er falskt, blir pakken forkastet umiddelbart.

• Beskyttelse mot tvetydighet (Equivocation Protection): Vi kan forhindre at noder lyver ved å bake samtalens historikk direkte inn i nøklene. Ved å bruke en hash av kommunikasjonshistorikken til å oppdatere den offentlige nøkkelen for hver runde, vil matematikken "knekke" dersom serveren prøver å vise Alice en annen virkelighet enn den viser Bob.
• Verifiserbar FHE: I stedet for å bare stole på at en node utfører beregningene riktig, bruker vi verifiserbar FHE. Det fungerer som en digital kvittering som beviser at serveren har fulgt protokollen nøyaktig slik den er programmert.

I vårt brukstilfelle for detaljhandel, er det dette tekniske laget som gjør at 100 butikker kan synkronisere data sømløst. Strategien med "valg-av-tre"-beholdere sikrer at selv om en angriper fanger opp pakken og analyserer IPv6-hodet, kan de ikke se hvilken butikk dataene stammer fra, fordi ZKP-beviset bekrefter at ruten er gyldig uten å avsløre kilden.

Fremtiden for DePIN og et sensurbestandig internett

Skal vi være helt ærlige, er dagens internett i bunn og grunn en samling inngjerdede hager som utgir seg for å være et globalt felleseie. Vi har brukt de foregående avsnittene på å snakke om hvordan zkp (nullkunnskapsbevis) og p2p-båndbredde kan utbedre selve rørleggerarbeidet i systemet, men det virkelige spørsmålet er hvordan dette skal skalere når millioner av mennesker forsøker å strømme video samtidig.

Skalering av disse protokollene er der ting virkelig blir komplisert på grunn av "anonymitets-trilemmaet". Som regel må du velge to av tre: sterk personvernsskydd, lav forsinkelse (latency) eller lav overhead på båndbredden. Analyse av komplekse systemer som Tor viser at selv med "perfekt" kryptografi, må man fortsatt håndtere angrep på systemnivå, som trafikkorrelasjon, dersom nettverket ikke er tett nok.

Den største flaskehalsen for et desentralisert fysisk infrastrukturnettverk (DePIN) er forholdet mellom "bevisstørrelse" og "bevistid". Hvis hver eneste pakke i en Web3-VPN krever et Groth16-bevis, kommer ruteren din til å smelte. For å løse dette ser vi nå på rekursive bevis.

• Rekursive SNARKs: I stedet for å verifisere 1 000 individuelle pakkebevis, kan en node "rulle opp" (roll up) disse bevisene til ett enkelt metabevis. Det fungerer som en russisk matrosjka-dukke, der det ytterste laget beviser gyldigheten av alt som er inni.
• Krymping av tilstanden (State): Dette holder størrelsen på blokkjeden håndterbar. I stedet for at hver node må kjenne til hele nettverkets historikk, trenger de bare å verifisere det nyeste rekursive beviset for å vite at rutingtabellen er ærlig og korrekt.

Næringslivet begynner nå å innse at sentraliserte VPN-tjenester utgjør en sikkerhetsrisiko for dataene deres. Distribuerte noder gjør angrepsflaten betydelig vanskeligere å treffe.

• AI-basert ruting: Vi ser et skifte mot programvaredefinert nettverk (SDN) der AI-agenter velger den mest sensurbestandige stien i sanntid.
• Omgåelse av nettleverandører (ISP Bypass): Ved å tokenisere konnektivitet bygger vi i praksis et parallelt internett. Det handler ikke lenger bare om å skjule IP-adressen din; det handler om å eie infrastrukturen slik at en nettleverandør ikke bare kan trykke på en bryter og kutte tilgangen din.

Implementeringsguide for node-operatører

Du har nå lest om matematikken og teorien bak, og du lurer sikkert på hvordan du faktisk får opp en node. Ærlig talt, å sette opp en zkp-aktivert node er et lite helgeprosjekt, men det er den eneste måten å gå fra å "stole på en VPN-leverandør" til å "stole på fysikkens lover."

Maskinvarekrav og oppsett

Du trenger ikke en hel serverpark, men du kan heller ikke kjøre dette på en brødrister.

• Minimumskrav: Jeg vil anbefale minst 8 GB RAM og en moderne prosessor med 4 kjerner.
• Nettverk: En symmetrisk fiberlinje er drømmen, men du trenger minst 20 Mbps opplastingshastighet.

Initialisering av en Proof Gadget

De fleste moderne dVPN-prosjekter bruker biblioteker som arkworks eller bellman. Her er et eksempel i pseudokode på hvordan en node kan initialisere en "path-validation gadget" ved hjelp av ZKPNet-logikk:

// Pseudokode for initialisering av en ZKP-rutingsgadget
use zkpnet_lib::{Prover, PathCircuit};

fn prove_path(secret_path: Vec<u8>, public_root: [u8; 32]) {
    // 1. Initialiser kretsen med den skjulte rutingsstien
    let circuit = PathCircuit {
        path: secret_path,
        root: public_root,
    };

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

    // 3. Legg ved det 224-byte store beviset i IPv6 Extension Header
    packet.attach_header(0xZK, proof.to_bytes());
}

Når du setter opp backend-systemet, må du huske at bevis-tiden (proving time) er den kritiske faktoren – det tar nesten et halvt sekund. Hvis du setter opp dette, må du sørge for at noden din ikke prøver å bevise hver eneste pakke. Bruk heller probabilistiske bevis eller batch-prosessering. Du beviser at du håndterte et bestemt vindu av trafikk korrekt under selve oppsettfasen av stien.

1. Double NAT-problemer: Hvis noden din står bak to rutere, vil P2P-oppdagelsen (discovery) feile. Bruk UPnP eller manuell portviderekobling (port forwarding).
2. Klokkeavvik (Clock Skew): ZKP- og blokkjedeprotokoller er svært tidssensitive. Kjør en lokal NTP-daemon.
3. IPv6-lekkasjer: Mange konfigurerer VPN-noden sin for IPv4, men glemmer at nettleverandøren (ISP) også deler ut IPv6-adresser.

Overgangen fra et sentralisert internett til et desentralisert, ZKP-drevet nettverk kommer til å bli utfordrende. Vi kjemper fortsatt mot forsinkelser (latency) og det såkalte "anonymitetstrilemmaet". Men fremgangen er reell. Enten du kjører en node for å tjene tokens (bandwidth mining) eller fordi du er lei av overvåking fra nettleverandører, er du med på å bygge en mer robust infrastruktur. Bare husk: hold fastvaren (firmware) oppdatert, følg med på CPU-temperaturen, og for alt i verden – ikke mist de private nøklene dine.