ZKP for P2P-metadata i dVPN: Sikker båndbreddedeling

Metadataproblemet i desentraliserte nettverk

Har du noen gang lurt på hvorfor din "loggfrie" VPN-tjeneste fremdeles vet nøyaktig når du maraton-så på den serien i går kveld? Det er fordi selv om de ikke ser på selve trafikken din, så vil metadataene – de digitale smulene som viser når og hvor du kobler deg til – fortsatt rope ut identiteten din til alle som følger med.

I et tradisjonelt oppsett stoler du på ett enkelt selskap. Men i en desentralisert VPN (dVPN) ruter du i praksis pakkene dine gjennom internettforbindelsen i hjemmet til en fremmed. Selv om dette fjerner problemet med et "sentralt sårbarhetspunkt" (single point of failure), skaper det en ny utfordring: hver eneste node i dette P2P-nettverket er en potensiell snoker.

Hvis jeg drifter en node, kan jeg se din IP-adresse og nøyaktig hvor mye data du flytter. Enda verre er det at jeg ser tidsstemplene. Hvis du er en varsler i en høyrisikoregion, er selve det faktum at du koblet deg til en spesifikk node klokken 02:00 nok til at du blir flagget av internettleverandørens (ISP) overvåking.

Metadataproblemet er i bunn og grunn et kart over ditt digitale liv. Som Zero-knowledge proof forklarer, er målet med en ZKP å bevise at en påstand er sann uten å avsløre selve hemmeligheten – noe som er nøyaktig det som mangler i dagens P2P-nettverk.

Dette blir spesielt komplisert når vi introduserer "båndbredde-utvinning" (bandwidth mining). I et DePIN (desentralisert fysisk infrastrukturnettverk) får folk betalt i tokens for å dele internettet sitt. For å få betalt, må noden bevise at de faktisk har utført jobben.

Vanligvis betyr bevis på utført tjeneste at man viser en "kvittering" for økten. "Hei, bruker X brukte 5 GB av min båndbredde fra kl. 16:00 til 17:00." Pang – der røk personvernet. Nettverket trenger dataene for å forhindre svindel, men brukeren trenger at disse dataene forblir skjulte for å være anonym.

• Helse: Hovedproblemet her er lekkasje av øktens varighet. Hvis en node ser at en pasient er koblet til en medisinsk portal i tre timer, antyder det en alvorlig konsultasjon selv om selve dataene er kryptert.
• Finans: Her er utfordringen koblingen mellom en IP-adresse og en kryptolommebok. Hvis en node ser en spesifikk IP flytte data under en handel med store verdier, blir den brukeren et mål for såkalte "dusting"-angrep.

Bransjen står fast. Vi ønsker oss et desentralisert internett, men vi bygger det på et fundament av synlige metadata. I følge kilder om Zero-knowledge proof viste forskere som Goldwasser og Micali allerede i 1985 at vi kan bevise at "kunnskapskompleksiteten" er null. Vi har bare ikke brukt dette effektivt nok på P2P-ruting ennå.

Og ærlig talt, før vi løser hvordan vi kan betale en node uten at noden vet hvem den betjener, bytter vi bare ut én stor utleier med tusen små.

Neste gang skal vi se nærmere på hvordan zk-SNARKs faktisk løser dette ved å la oss verifisere disse øktene uten å avsløre verken "hvem" eller "når".

Slik redder Zero-Knowledge-bevis personvernet

Har du noen gang følt deg overvåket mens du bare prøver å surfe på nettet? Selv med en VPN kan nettleverandøren din eller en nysgjerrig node-eier se "formen" på dataene dine. Dette er et gigantisk hull i skroget på personvernskipet vårt.

Tenk på et zero-knowledge-bevis (ZKP) som en måte å bevise at du har nøkkelen til en dør, uten å faktisk vise frem nøkkelen eller åpne døren slik at alle kan se inn. En klassisk måte å visualisere dette på er "Hvor er Willy?"-analogien. Se for deg et massivt brett med et bilde av Willy. For å bevise at du har funnet ham uten å avsløre koordinatene hans, legger du et gigantisk ark med gråpapir over kartet med bare ett lite hull klippet ut. Du skyver kartet under papiret helt til Willy dukker opp i hullet. Personen som ser på ser Willy, og vet dermed at du har funnet ham, men de har ingen anelse om hvor han befinner seg på det faktiske kartet.

I en verden av P2P-nettverk er dette en livredder. Vanligvis må en node fremvise en kvittering for utført arbeid for å få betalt for "båndbredde-mining". Men denne kvitteringen inneholder ofte IP-adressen din, tidspunktet du var tilkoblet og hvor mye du lastet ned. Det er et mareritt for personvernet.

Med ZKP bruker vi det som kalles kompletthet (completeness) og sunnhet (soundness). Kompletthet betyr at hvis en økt faktisk fant sted, kan den ærlige noden bevise det. Sunnhet sikrer at en uærlig node ikke kan forfalske en økt for å stjele tokens. I tråd med prinsippene for zero-knowledge-bevis lar dette oss bekrefte at en påstand er sann uten å formidle annen informasjon enn selve sannheten.

En systematisering av angrep utført av forskere hos Trail of Bits i 2024 viste at 96 % av feilene i SNARK-baserte systemer skyldes "under-constrained" kretser. Det betyr at matematikken ikke var stram nok til å forhindre juks.

Vi driver altså ikke med matematikk bare for moro skyld. Vi bygger en mur der mursteinene består av logikk. Hvis logikken er solid, mottar noden sine krypto-belønninger, mens du beholder dine surfevaner for deg selv.

Når vi bruker dette på en P2P-tunnel, "blinder" vi i praksis metadataene. I stedet for at noden rapporterer at "Bruker A brukte 500 MB klokken 22:00", genererer den en zk-SNARK (Succinct Non-Interactive ARgument of Knowledge). Dette er en ørliten databit som sier: "Jeg har tilrettelagt for en gyldig økt på nøyaktig 500 MB", og nettverket kan verifisere dette uten å vite at det var deg.

• Varehandel: Den teoretiske løsningen er å bevise at en forsendelsesoppdatering ble mottatt uten å lekke det nøyaktige tidsstempelet. Dette hindrer konkurrenter i å overvåke hastigheten på en butikks forsyningskjede.
• Helsevesen: En klinikk kan bevise at data ble overført for faktureringsformål via en ZKP. Noden ser aldri filstørrelsen, noe som hindrer utenforstående i å gjette hvilken type spesialist som blir konsultert basert på datavolumet.
• Finans: Tradere kan bruke tokeniserte nettverk der beviset validerer brukt båndbredde uten å koble en spesifikk lommebokadresse til en privat IP-adresse.

Å bruke disse bevisene på mobile noder – som når telefonen din deler litt 5G-kapasitet – er krevende fordi matematikken er tung. Men nyere protokoller som Halo eller Virgo gjør dette lett nok til å kjøre uten å tømme batteriet.

Ærlig talt er dette den eneste måten et P2P-nettverk kan overleve på lang sikt. Hvis vi ikke skjuler metadataene, bygger vi bare en større og mer distribuert overvåkningsmaskin. Vi er avhengige av at systemet er "zero-knowledge" som standard, ikke som en ettertanke.

Neste steg er å se på hvordan disse zk-SNARK-bevisene faktisk implementeres i koden, og hvordan det ser ut når en node prøver å verifisere et bevis i sanntid.

Implementering av ZKP i dVPN-økosystemet

Har du noen gang tenkt over hvor absurd det er at vi prøver å bygge et "privat" internett, samtidig som vi etterlater oss digitale spor som enhver nettleverandør (ISP) og node-eier kan følge? Det er som å gå med maske, men legge igjen visittkortet ditt ved hver eneste dør du passerer.

Hvis du er opptatt av detaljene i nettverkssikkerhet, vet du at det er en fulltidsjobb å holde tritt med hvordan disse protokollene faktisk endrer seg. Jeg bruker mye tid på tekniske rapporter om sårbarheter i tunelleringsprotokoller; det er én ting å snakke om en pakke-header, men noe helt annet å forklare hvorfor den headeren i praksis fungerer som et sporingslys for statlig overvåking.

Modellen "Airbnb for båndbredde" er kul i teorien, men et mareritt for personvernet. For å få betalt, må en node bevise at de faktisk har flyttet dataene dine. I et standardoppsett betyr dette at en relay-node viser en kvittering: "Jeg håndterte 2 GB for denne spesifikke lommebokadressen." Dermed er koblingen mellom din krypto-identitet og trafikken din hugget i stein.

Vi bruker smarte kontrakter for å bygge bro over dette gapet, men de trenger en måte å verifisere arbeidet på uten å se "hvem" som utfører det. Det er her ZKP (Zero-Knowledge Proofs) kommer inn for å håndtere det vi kaller Proof of Relay (bevis på videresending). Den smarte kontrakten fungerer som en dommer – den sjekker et matematisk bevis i stedet for en rå loggfil.

• Forhindring av "Double Spending": I et tokenisert nettverk sørger en ZKP for at hver økt-ID (session ID) er unik og kun "brukes" én gang på blokkjeden, uten at hovedboken noen gang får vite hvilken bruker som faktisk sendte dataene.
• Belønning av ærlige noder: Siden Zero-knowledge-beviset er basert på soundness (sannferdighet), kan ikke en node generere et gyldig bevis for en økt som aldri fant sted. Hvis matematikken ikke stemmer, utbetaler ikke den smarte kontrakten midlene.
• Blinding av metadata: Ved å bruke et ikke-interaktivt bevis, sender noden en enkelt "blob" med data til kjeden. Som nevnt tidligere i artikkelen, betyr dette at verifikatoren (blokkjeden) ikke lærer noe annet enn det faktum at arbeidet faktisk ble utført.

Dette handler ikke bare om å skjule Netflix-vanene dine; det handler om infrastruktur. Ta detaljhandel som et eksempel. På implementeringssiden kan en butikks lokale gateway generere en ZKP for hver lagersynkronisering. P2P-noden flytter dataene og får betalt av den smarte kontrakten, men noden ser aldri de tidsmessige mønstrene som kunne avslørt forretningshemmeligheter i forsyningskjeden.

Innen finans bruker høyfrekvente tradere ZKP-er for å skjule sin fysiske lokasjon. Den smarte kontrakten verifiserer at båndbredden ble levert, men fordi beviset er "blindet", kan ikke noden koble trafikken til en spesifikk lommebok for å drive med "front-running" av en handel.

Selv i helsesektoren, hvor klinikker deler journaler, håndterer den smarte kontrakten faktureringsbeviset. Implementeringen sikrer at "beviset" ikke avslører om en fil var 10 KB eller 10 GB, noe som holder pasientens potensielle tilstand skjult for node-operatøren.

Det reelle problemet jeg ser, er "beregningsskatten". Å generere en zk-SNARK er ikke gratis – det krever CPU-sykluser. Hvis du kjører en node på en Raspberry Pi eller en telefon, vil du ikke at 50 % av strømmen skal gå med til bare å bevise at du har gjort jobben.

En studie fra 2024 utført av forskere hos Trail of Bits (som nevnt tidligere) fant at nesten alle feil i disse systemene skyldes "under-constrained" kretser. Hvis matematikken ikke er streng nok, kan en node "lure" systemet ved å lage et bevis for arbeid de aldri faktisk utførte.

Vi ser nå et skifte mot teknologier som Halo eller Virgo for å gjøre dette raskere. Disse protokollene krever ikke et "trusted setup", som er en fin måte å si at vi ikke trenger å stole på at utviklerne ikke etterlot seg en bakdør i de opprinnelige matematiske konstantene. Det gjør hele P2P-økosystemet langt mer transparent og sikkert.

Uansett, å implementere dette i en dVPN er ikke bare noe som er "kjekt å ha". Hvis vi ikke får kontroll på metadataene, bygger vi bare en større og mer effektiv overvåkningsmaskin og kaller den "Web3".

Neste punkt på agendaen er de faktiske kodestrukturene – spesifikt hvordan disse kretsene er bygget opp, og hvorfor det er så lett for utviklere å ved et uhell etterlate seg disse "under-constrained" hullene i logikken.

Tekniske hindringer og fremtiden for DePIN

Vi har snakket om hvordan disse bevisene fungerer som ren magi for personvernet, men la oss være ærlige et øyeblikk – ingenting i nettverksverdenen er gratis. Hvis du prøver å drive et desentralisert fysisk infrastrukturnettverk (DePIN) der hver node i praksis er en mini-ISP, møter du en massiv vegg: matematikken er rett og slett blytung.

Den største barrieren for fremtidens DePIN er den beregningsmessige kostnaden. Å generere en zk-SNARK er ikke som å hashe et passord; det ligner mer på å løse et komplekst puslespill mens noen overvåker hvert eneste trekk du gjør. Tidligere var genereringen av disse bevisene så treg at det var nærmest umulig å bruke dem i en VPN-økt i sanntid. Du måtte ha ventet i flere sekunder bare for å verifisere en enkelt pakke – forsinkelsen (latency) ville minnet om en oppringt internettlinje fra 1995.

Men ting er i endring. Nye protokoller gjør dette endelig levedyktig for båndbredde-mining. Som tidligere nevnt, endrer systemer som Bulletproofs og STARKs spillereglene fordi de ikke krever et "trusted setup", noe som ofte skaper usikkerhet. Enda viktigere er det at de blir stadig raskere.

• Forsinkelse vs. Personvern: Dette er den klassiske avveiningen. Hvis noden din bruker for mye tid på å tygge tall for å bevise at den har flyttet 10 MB med data, blir brukeropplevelsen elendig. Vi ser nå en trend mot "batching", der en node beviser 1 000 økter samtidig for å spare CPU-sykluser.
• Maskinvarebegrensninger: De fleste DePIN-noder er ikke kraftige servere; det er snakk om Raspberry Pi-enheter eller gamle laptoper. Hvis ZKP-protokollen er for ressurskrevende, vil den enten brenne ut maskinvaren eller rett og slett krasje.
• Mobile noder: Drømmen er å dele telefonens 5G-forbindelse via et P2P-nettverk, men zk-bevis kan være en skikkelig batterisluker. Protokoller som Virgo (som vi nevnte tidligere) er spesifikt designet for å være mer skånsomme mot prosessoren.

For å forstå hvorfor dette er vanskelig, må man se på hva koden faktisk gjør. Vi skriver ikke bare et skript; vi bygger en aritmetisk krets. I praksis blir høynivåkode, som Python-eksempelet nedenfor, kompilert til R1CS (Rank-1 Constraint System) eller aritmetiske kretser. Disse kretsene består av "porter" som håndhever logikken. Hvis du lar en port være "under-constrained" (mangelfullt begrenset), slik en studie fra 2024 av forskere hos Trail of Bits påpekte, kan en ondsinnet node forfalske hele økten.

Her er et konseptuelt blikk på hvordan en krets kan sjekke om en node faktisk holdt seg innenfor de lovede båndbreddegrensene, uten å avsløre det nøyaktige antall bytes til den offentlige blokkjeden:

# Merk: Denne høynivå-logikken blir kompilert til en aritmetisk krets 
# (R1CS) for at ZK-SNARK faktisk skal fungere.

def verify_bandwidth_usage(claimed_usage, secret_session_log, limit):
    # 'secret_session_log' er den private inngangsverdien (the witness)
    # 'limit' og 'claimed_usage' er offentlige data
    
    # 1. Sjekk om loggen samsvarer med det påståtte forbruket
    is_match = (hash(secret_session_log) == claimed_usage_hash)
    
    # 2. Forsikre at forbruket er under den fastsatte grensen
    is_under_limit = (secret_session_log <= limit)
    
    # Kretsen returnerer 'True' kun hvis begge betingelsene er oppfylt
    # Verifikatoren (blokkjeden) ser kun 'True/False' og selve beviset
    return is_match and is_under_limit

I et reelt DePIN-miljø sender noden (beviseren) en "commitment" til blokkjeden. Dette er i bunn og grunn et kryptografisk løfte. Senere, når det er tid for utbetaling, leverer de en ZKP. Smartkontrakten fungerer som verifikator og kjører en logikk som tar millisekunder å sjekke, selv om det tok noden et helt sekund å generere beviset.

Fremtiden for DePIN avhenger av å få denne matematikken i bakgrunnen. Innen detaljhandel, for eksempel, hvis en butikk bruker et P2P-nettverk for å synkronisere salgsdata, kan de ikke ha kasser som fryser i tre sekunder mens de genererer et bevis for dataoverføring. Det må være sømløst.

I finanssektoren ser vi lignende utfordringer med høyfrekvent handel. Hvis en trader bruker et tokenisert nettverk for å forbli anonym, kan enhver ustabilitet (jitter) forårsaket av bevisgenerering koste dem tusenvis av kroner i et "front-running"-scenario. Målet er å få tiden for bevisgenerering ned til et punkt der det er raskere enn selve nettverkets responstid (ping).

Helt ærlig er problemet med "under-constrained" kretser det som holder meg våken om natten. Hvis 96 % av sårbarhetene i disse systemene skyldes feil i den matematiske logikken, bygger vi i praksis en bank med en hvelvdør som ser tung ut, men som ikke er boltet fast i veggen. Utviklere har derfor begynt å bruke verktøy for "formell verifisering" av kretsene sine, som i praksis betyr å bruke en annen AI eller en matematisk motor for å bevise at selve beviset faktisk er vanntett.

Neste steg er å oppsummere det hele og se på hvordan den endelige "personvernstakken" ser ut når man kombinerer P2P-ruting, tokeniserte belønninger og zero-knowledge metadata.

Konklusjon: Et genuint anonymt internett

Etter å ha dykket ned i både matematikk og protokoller – hvor står vi egentlig nå? Hvis du har fulgt med så langt, er det tydelig at den gamle måten å gjøre ting på – der man bare håper at leverandøren ikke misbruker tilliten – er i ferd med å dø ut.

Vi beveger oss fra en "stol på meg"-modell til en "kan ikke røre dette"-modell. Tidligere koblet du deg til en VPN og ba en stille bønn om at de ikke førte logger, selv når forretningsmodellen deres eller en rettslig utleveringsbegjæring tydet på det motsatte.

Men med et P2P-nettverk drevet av nullkunnskapsbevis (Zero-Knowledge Proofs - ZKP), kan noden bokstavelig talt ikke tyste på deg, fordi den aldri hadde tilgang til dataene i utgangspunktet. Dette er et fundamentalt skifte i nettverksarkitektur.

• Sensurbestandighet: I land med omfattende overvåking fra internettleverandører (ISP), er ZKP-baserte dVPN-er en total "game changer". Siden metadataene er skjulte ("blinded"), kan ikke statlig Deep Packet Inspection (DPI) enkelt koble en spesifikk bruker til en "forbudt" utgangsnode.
• Økonomisk rettferdighet: Utvinning av båndbredde (Bandwidth Mining) blir en legitim jobb. Du får betalt for arbeidet du faktisk utfører, bevist gjennom matematikk, uten at du trenger å bygge en database over kundenes vaner for å tilfredsstille en belønningsalgoritme.
• Slutten på digitale spor: Som vi har sett, er det enkelt å skjule selve innholdet (payload); den virkelige utfordringen er å skjule det faktum at du sendte det. ZKP-er lar oss endelig slette disse digitale fotavtrykkene i sanntid.

Dette er ikke bare for personvernentusiaster eller folk som prøver å skjule torrent-bruk. Implikasjonene for industriell infrastruktur er enorme.

Innen helsevesenet kan en sykehuskjede som bruker et desentralisert nettverk for å synkronisere pasientdata, nå bevise overfor tilsynsmyndigheter at de har flyttet journalene uten at relénodene noen gang har sett "formen" på disse dataene. Dette forhindrer at noen kan gjette seg til pasientvolum eller type nødssituasjoner basert på datapakkenes mønster.

For detaljhandelsgiganter betyr det synkronisering av varelager på tvers av tusenvis av P2P-tilkoblede butikker, uten at en konkurrent kan kartlegge logistikken og leverandørkjeden deres. De får hastigheten til et distribuert nettverk med personvernet til et lokalt nettverk.

Og innen finans handler alt om forsprang. Høyfrekvente tradere kan bruke disse tokeniserte nettverkene til å maskere sin fysiske lokasjon. Hvis en node ikke kan se sesjonsvarigheten eller lommebokadressen via en ZKP, kan de heller ikke drive med "front-running" av handlene.

Jeg skal ikke lyve for deg – vi er ikke helt ved det "perfekte" internett ennå. Den beregningsmessige kostnaden er fremdeles en faktor. Hvis du kjører en node på en billig ruter, kan ressursbruken for å generere disse bevisene fremdeles påvirke gjennomstrømmingen din noe.

Men som jeg nevnte tidligere, løser overgangen til protokoller som Halo og Virgo dette. Vi nærmer oss et punkt der logikken er så effektiv at "personverk-skatten" i praksis er umerkelig for sluttbrukeren.

I følge dokumentasjonen for Zero-knowledge proofs har konseptet eksistert siden 80-tallet, men det er først nå vi har maskinvaren og koden (som zk-SNARKs) som kreves for å få det til å fungere i stor skala i P2P-nettverk.

Helt ærlig, hvis du er en teknologi-entusiast eller bryr deg om hvor internett er på vei, bør du følge nøye med på DePIN-prosjekter (Decentralized Physical Infrastructure Networks). Modellen med "Airbnb for båndbredde" fungerer bare hvis gjestene forblir anonyme og vertene får rettferdig betalt.

Fremtidens internett handler ikke bare om desentralisering; det handler om verifiserbart personvern. Vi bygger en teknologistabel der P2P-ruting håndterer "hvor", kryptering håndterer "hva", og nullkunnskapsbevis håndterer "hvem" og "når".

Når du kombinerer disse, får du et internett som ikke tilhører et enkelt selskap eller en stat. Det er et nettverk som eksisterer på grunn av brukerne sine, beskyttet av matematikkens lover snarere enn en administrerende direktørs luner.

Uansett, det har vært en lang reise gjennom disse protokollene. Enten du bare leter etter en bedre måte å surfe på, eller du ønsker å bygge den neste store desentraliserte appen, husk dette: Hvis du ikke verifiserer, så gjetter du bare. Hold kretsene tette og metadataene dine skjult.