Nollatietotodistukset ja anonyymi reititys | dVPN & DePIN

Perinteisen reitityksen ongelmat ja miksi tarvitsemme nollatietotodistuksia (ZKP)

Oletko koskaan miettinyt, onko "lokitiedoton" VPN-palvelusi todella niin yksityinen kuin markkinointipuheet antavat ymmärtää? Totuus on karu: perinteinen reititys – jopa salattu sellainen – on perustavanlaatuisesti rikki. Se nojaa sokeaan luottamukseen keskkitettyjä toimijoita kohtaan sekä staattisiin reitteihin, joita on yllättävän helppo manipuloida.

Monet mieltävät VPN:n taikatunneliksi, mutta konepellin alla se on vain sarja kättelyitä palveluntarjoajan palvelimen kanssa. Ongelmana on, että näistä palvelimista tulee keskitettyjä haavoittuvuuspisteitä (single point of failure). Vaikka palveluntarjoaja väittäisi, ettei se kerää lokeja, asetat silti yksityisyytesi heidän sanansa ja heidän konesaliensa fyysisen turvallisuuden varaan.

• "Ei lokeja" -paradoksi: Sinun on luotettava siihen, ettei viranomainen painosta palveluntarjoajaa tai ettei järjestelmään ole tehty huomaamatonta tietomurtoa. Jos keskitetty palvelin vaarantuu, metatietosi – kuka olet ja minne olet menossa – ovat täysin avoimia.
• Solmujen epärehellisyys P2P-verkoissa: Hajautetuissa verkoissa törmätään usein "reititysväleihin". Solmu saattaa väittää, että sillä on nopein reitti kohteeseen vain voidakseen kaapata pakettisi analysoitavaksi – tämä on klassinen "man-in-the-middle" -asetelma.
• Liikenteen harhauttaminen: Jacob D. Whiten tutkimus Los Alamosin kansallisessa laboratoriossa (2023) korostaa, kuinka reitittimet voivat "valehdella" reitityksestään, mikä johtaa blackholing-ilmiöön tai tietoliikenteen kaappauksiin autonomisten järjestelmien sisällä. (White, J. D., "ZKPNet: Verifiable Routing," LA-UR-23-29806).

Tarvitsemme tavan todistaa reitityspolun oikeellisuus paljastamatta itse polkua tai sen sisältämää dataa. Tässä kohtaa kuvaan astuvat nollatietotodistukset (Zero-Knowledge Proofs, ZKP). Tätä voi verrata "Missä Vallu?" -analogiaan: voin todistaa löytäneeni Vallun kartalta näyttämällä hänet pienen reiän läpi valtavan pahviarkin takaa. Olen todistanut tietäväni hänen sijaintinsa näyttämättä sinulle muuta osaa kartasta.

• Datan minimointi: ZKP mahdollistaa sen, että solmu voi todistaa noudattaneensa protokollaa ja sääntöjä vuotamatta mitään yksityisiä verkkorakenteita.
• Metatietojen suojaus: Toisin kuin pelkkä salaus, joka kätkee sisällön mutta jättää "murusia" (IP-osoitteita, aikaleimoja), ZKP voi piilottaa lähettäjän identiteetin jopa niiltä solmuilta, jotka siirtävät dataa.
• Luottamukseton varmennus (Trustless Verification): Sinun ei tarvitse luottaa solmun omistajaan, vaan matematiikkaan. Jos todistus ei täsmää, paketti ei liiku.

Finanssialalla pankki voisi käyttää nollatietotodistuksia reitittääkseen transaktioita kolmannen osapuolen verkon kautta peittääkseen alkuperän ilman, että verkko näkee tilitietoja. Terveydenhuollossa sairaala voisi jakaa potilastietoja P2P-verkossa niin, etteivät reitittävät solmut näe edes sitä, mikä klinikka dataa pyytää. Näin varmistetaan tiukkojen tietosuojalakien noudattaminen.

Suoraan sanottuna nykyinen internet-reititys on vuotavien metatietojen ja "luota minuun" -kättelyiden sekasotku. Mutta jos voimme vaihtaa tämän luottamuksen matemaattiseen varmuuteen, saatamme vihdoinkin saavuttaa sen yksityisyyden tason, joka meille on luvattu.

Kuinka ZKPNet ja NIAR muuttavat pelikenttää

Olemme jo todenneet, että nykyinen internet-reititys perustuu pitkälti palvelinten välisiin "herrasmiessopimuksiin". Jos haluamme siirtyä tästä eteenpäin, tarvitsemme todellista matematiikkaa, joka ei paljasta liikesalaisuuksiamme. Tässä kohtaa kuvaan astuvat ZKPNet ja NIAR (Network Infrastructure for Anonymous Routing). NIAR on käytännössä viitekehys, jonka avulla voimme rakentaa näitä anonyymeja polkuja ilman keskitettyä hallintoa.

Yleensä, jos reititin haluaa todistaa pystyvänsä tavoittamaan tietyn kohteen, sen on näytettävä reititystaulunsa tai sisäisiä kaavioitaan. Tämä on tietoturvapainajainen niin internet-palveluntarjoajille (ISP) kuin sairaalaverkoillekin. Jacob D. White Los Alamos National Laboratorysta (2023) esitteli ZKPNetin, Rust-pohjaisen kirjaston, joka luo "gadgeteja" eli työkaluja näitä todisteita varten.

• Minimaalinen tilantarve: Nämä todisteet ovat pikkuruisia – Groth16-algoritmia käytettäessä vain noin 224 tavua. Ne voidaan lisätä paketin otsikkotietoihin (header) ilman, että MTU-koko (Maximum Transmission Unit) ylittyy.
• Yhden hypyn saavutettavuus: Solmu voi todistaa, että sillä on voimassa oleva polku "reitittimeen Y" paljastamatta tarkkaa hyppyjen määrää tai sisäisiä IP-osoitteita.
• Suorituskyvyn kompromissit: Reaaliaikainen viive (latency) on suurin haaste. M1 Max -prosessorilla tehdyt mittaukset osoittavat, että todisteen luominen kestää noin 468 ms. Yksittäiselle paketille 468 ms on ikuisuus, joten emme käytä sitä jokaiseen databittiin. Sen sijaan nollatiedon todistusta (ZKP) käytetään ohjaustason (control-plane) toiminnoissa – kuten polun muodostamisessa – kun taas varsinainen data liikkuu vauhdilla heti, kun "luottamus" on vahvistettu.

Sitten on sPAR (Somewhat Practical Anonymous Router), joka pyrkii ratkaisemaan Tor-verkon kaltaisten järjestelmien vaatimuksen "rehellisistä solmuista". Kuten Debajyoti Das ja Jeongeun Park (2025) ovat esittäneet, sPAR hyödyntää monen osapuolen täysin homomorfista salausta (FHE), jolloin edes reititin ei tiedä, mihin se on lähettämässä tietoa.

Mielenkiintoinen osa on "törmäysongelman" (collision problem) välttäminen. Jos useat käyttäjät yrittävät käyttää samaa kaistanleveyspaikkaa, data korruptoituu. sPAR käyttää kolmen valinnan strategiaa (choice-of-three strategy) – "pallot ja laatikot" -matematiikkaan perustuvaa kikkaa – jossa asiakas valitsee kolme satunnaista indeksiä ja viesti päätyy ensimmäiseen vapaaseen paikkaan.

• Homomorfinen sijoittelu: Palvelin sijoittaa pakettisi "sankoon" näkemättä koskaan valitsemaasi indeksiä. Kaikki tapahtuu datan ollessa vielä salattuna.
• Skaalautuvuuden rajat: Tällä hetkellä sPAR ei ole korvaamassa maailmanlaajuista verkkoa. Se tukee noin 128 käyttäjää muutaman sekunnin viiveellä, mikä tekee siitä täydellisen erikoistarkoituksiin, kuten kryptovaluuttatapahtumien sekoittamiseen (mixing) tai yksityiseen viestintään lähiverkossa (LAN).

Kuvitellaanpa vähittäiskauppaketju, jonka on synkronoitava varastotilanteensa. Käyttämällä sPAR-tyyppistä reititystä keskuspalvelin ei pysty päättelemään, mikä myymälä lähettää minkäkin päivityksen. Tämä estää kilpailijoita analysoimasta liikennemäärien perusteella, mitkä toimipisteet ovat kaikkein tuottavimpia.

Kaistanlouhinta ja tokenisoitu verkkotalous

Oletko koskaan miettinyt, kuinka kotisi internetyhteys seisoo täysin joutilaana ollessasi töissä tai nukkumassa? Se on periaatteessa hukkaan heitetty resurssi – aivan kuten tyhjä vierashuone, jota et koskaan vuokraa eteenpäin.

DePIN-liike (Decentralized Physical Infrastructure Networks) on muuttamassa tämän luomalla "kaistanleveyden Airbnb:n". Sen sijaan, että vain maksaisit kuukausimaksuja operaattorillesi, voit ansaita kryptoa jakamalla käyttämättömän yhteytesi maailmanlaajuiseen vertaisverkkoon (P2P).

Hajautetun VPN-palvelun (dVPN) tai välityspalvelinverkon rakentaminen vaatii tuhansia solmuja ollakseen todella hyödyllinen. Jotta ihmiset saadaan ylläpitämään näitä solmuja, projektit hyödyntävät tokenisoituja kannustimia. Sinä tarjoat putken, ja verkko maksaa sinulle hyötytokeneilla.

Tähän liittyy kuitenkin valtava tekninen haaste: miten verkko voi tietää, että tarjoat todella korkealaatuista kaistaa, ilman että se vakoilee reitittämääsi liikennettä? Jos solmu alkaa lokittaa käyttäjädataa "todistaakseen" toimintansa, Web3-VPN-palvelun koko tietosuoja-ajatus romuttuu.

• Kaistanlouhinta (Bandwidth Mining): Käyttäjät asentavat kevyen solmuohjelmiston, joka luovuttaa lähetyskapasiteettia verkon yhteiseen pooliin. Palkkiot lasketaan yleensä käytettävyysajan, läpimenon ja maantieteellisen kysynnän perusteella.
• Yksityisyyttä suojaavat todisteet: Tässä nollatietotodistukset (ZKP) ovat pelastus. Voit todistaa saavutettavuuden ja protokollan noudattamisen paljastamatta pakettien todellista sisältöä tai sisäisiä verkkokarttoja.
• Palvelun laatu (QoS): Solmut voivat tarjota "Proof of Bandwidth" -todisteen, joka käyttää matemaattisia vahvistuksia varmistaakseen, ettei liikennettä kuristeta tai paketteja hävitetä ("blackholing").

Jos haluat pysyä kärryillä näiden VPN-protokollien kehityksestä, SquirrelVPN on erinomainen lähde uusimmille VPN-teknologian ja tietoturvan päivityksille. He seuraavat tiiviisti siirtymää keskitetyistä konesaleista kohti näitä hajautettuja solmumalleja.

Tämän järjestelmän "talousosuus" tapahtuu lohkoketjussa (on-chain). Älysopimukset toimivat automatisoituina välittäjinä, jotka hoitavat vaihdannan yksityisyyttä tarvitsevien käyttäjien ja ylimääräistä kaistaa tarjoavien solmunylläpitäjien välillä.

• Automatisoidut P2P-maksut: Suurelle suuryritykselle maksettavan kiinteän kuukausimaksun sijaan maksat vain siitä, mitä käytät. Älysopimus vapauttaa mikromaksuja solmun tarjoajille reaaliajassa.
• Sybil-hyökkäysten esto: Jos yksi henkilö pyörittäisi tuhatta valesolmua yhdeltä palvelimelta, verkon hajautus vaarantuisi. Kaistanleveyden todistamiseen perustuvat protokollat – joihin usein liittyy steikkausvaatimus – tekevät resurssien vääristelystä taloudellisesti kannattamatonta.

Terveydenhuoltoesimerkkiämme ajatellen: klinikka voisi maksaa verkon kaistanleveydestä tokeneilla. Koska verkko hyödyntää aiemmin mainittua sPAR-logiikkaa, klinikka saa anonyymiuden ja solmun ylläpitäjät saavat maksunsa – ilman, että internet-palveluntarjoaja näkee klinikan ja sairaalan välisiä liikennerytmejä.

Syväsukellus tekniseen protokollakerrokseen

Nyt siirrymme taloudellisesta mallista varsinaiseen tekniseen protokollakerrokseen. Tässä osiossa pureudumme siihen, miten nämä todisteet käytännössä upotetaan tietoliikennepaketteihin.

Todellinen läpimurto on luopuminen keskitetyistä haavoittuvuuspisteistä (single point of failure). Perinteisissä malleissa yhdellä taholla on hallussaan järjestelmän avaimet. Hyödyntämällä monen osapuolen täysin homomorfista salausta (multi-party fully homomorphic encryption, FHE), voimme luoda yhteisen julkisen avaimen siten, ettei kukaan tiedä varsinaista pääsalaisuutta (master secret).

• Yhteinen avaimenmuodostus (Joint Key Generation): Käyttöönottovaiheessa jokainen osallistuja luo oman salaisen avaimensa. Nämä yhdistetään yhdeksi julkiseksi avaimeksi ($pk$). Kuten Debajyoti Das ja Jeongeun Park (2025) sPAR-työssään esittävät, pääsalaisuus on kaikkien yksittäisten avaimien summa. Koska kukaan ei jaa omaa avaintaan, "kokonaista" avainta ei ole olemassa missään yksittäisessä paikassa.
• RLWE (Ring Learning With Errors): Tämä on matemaattinen peruskivi. Yksinkertaistettuna RLWE on kuin monimutkainen palapeli, jossa tietoon lisätään pieni määrä "kohinaa". Tietokoneen on äärimmäisen vaikea ratkaista tätä takaperoisesti, mikä takaa ind-cpa-tietoturvan (hyökkääjä ei pysty erottamaan kahta eri salattua viestiä toisistaan, vaikka hän arvaisi niiden sisällön).

Pakettirakenne: Missä todiste sijaitsee?

Mihin se 224 tavun nollatietotodiste (ZKP) sitten sijoitetaan? Nykyaikaisessa IPv6-ympäristössä hyödynnämme lisäotsakkeita (Extension Headers). Tarkemmin sanottuna käytämme räätälöityä "Destination Options" -otsaketta.

Sijoittamalla todisteen lisäotsakkeeseen reitittimet, jotka eivät tue ZKPNet-protokollaa, voivat vain välittää paketin eteenpäin. Sen sijaan "ZKP-tietoiset" solmut pysäyttävät paketin, todentavat todisteen 2,7 millisekunnissa ja välittävät sen vasta sitten eteenpäin. Jos todiste on väärennetty, paketti hylätään välittömästi.

• Harhautussuojaus (Equivocation Protection): Estämme solmuja valehtelemasta sitomalla viestintähistorian osaksi avaimia. Kun julkinen avain päivitetään jokaisella kierroksella viestintähistorian tiivisteellä (hash), matematiikka pettää heti, jos palvelin yrittää esittää Alicelle eri "todellisuutta" kuin Bobille.
• Todennettava FHE (Verifiable FHE): Sen sijaan, että luottaisimme solmun suorittavan laskennan oikein, käytämme todennettavaa FHE:tä. Se toimii kuin digitaalinen kuitti, joka todistaa palvelimen noudattaneen protokollaa täsmälleen ohjeiden mukaan.

Meidän vähittäiskaupan käyttötapauksessamme tämä tekninen kerros mahdollistaa sadan myymälän välisen datan synkronoinnin. "Choice-of-three" -lokeroistrategia varmistaa, että vaikka hyökkääjä kaappaisi paketin ja tarkastelisi IPv6-otsaketta, hän ei pysty päättelemään, mistä myymälästä data on peräisin. ZKP nimittäin todistaa polun kelvollisuuden paljastamatta sen lähdettä.

DePINin tulevaisuus ja sensuurinkestävä internet

Jos olemme rehellisiä, nykyinen internet on käytännössä joukko aidattuja puutarhoja, jotka teeskentelevät olevansa globaalia yhteisomaisuutta. Olemme aiemmin käsitelleet sitä, miten nollatietotodistukset (ZKP) ja vertaisverkkoon (P2P) perustuva kaistanleveys voivat korjata infrastruktuurin perusrakenteet, mutta todellinen kysymys kuuluu: miten tämä skaalautuu, kun miljoonat ihmiset yrittävät striimata videota samanaikaisesti?

Näiden protokollien skaalaaminen on haastavaa niin kutsutun "anonymiteettitrililemman" vuoksi. Yleensä on valittava kaksi kolmesta: vahva yksityisyydensuoja, alhainen viive tai vähäinen kaistanleveyden lisäkuormitus. Monimutkaisten järjestelmien, kuten Tor-verkon, analysointi osoittaa, että vaikka kryptografia olisi "täydellistä", verkko on silti altis järjestelmätason hyökkäyksille, kuten liikenteen korrelaatioanalyysille, jos verkon solmutiheys ei ole riittävä.

Hajautetun fyysisen infrastruktuurin verkkojen (DePIN) suurin pullonkaula on "todisteen koon" ja "todistamiseen kuluvan ajan" välinen suhde. Jos jokainen Web3-VPN-verkon paketti vaatisi Groth16-todisteen, reitittimesi ylikuumentuisi välittömästi. Tämän ratkaisemiseksi katseemme kääntyy rekursiivisiin todisteisiin.

• Rekursiiviset SNARK-todisteet: Sen sijaan, että solmu varmentaisi 1 000 yksittäistä pakettitodistetta, se voi "kääriä" (roll up) todisteet yhdeksi metatodisteeksi. Se on kuin venäläinen maatuska-nukke, jossa uloin kerros todistaa kaikkien sisällä olevien kerrosten oikeellisuuden.
• Tilan supistaminen (State Shrinking): Tämä pitää lohkoketjun koon hallittavana. Jokaisen solmun ei tarvitse tuntea verkon koko historiaa; riittää, että ne varmentavat uusimman rekursiivisen todisteen varmistuakseen reititystaulukon rehellisyydestä.

Yritykset ovat alkaneet ymmärtää, että keskitetyt VPN-palvelut ovat tietoturvariski. Hajautetut solmut tekevät hyökkäyspinta-alasta huomattavasti vaikeamman kohteen.

• Tekoälypohjainen reititys: Olemme siirtymässä kohti ohjelmistopohjaisia verkkoja (SDN), joissa tekoälyagentit valitsevat reaaliajassa sensuurinkestävimmän polun datalle.
• Internet-palveluntarjoajien (ISP) ohittaminen: Tokenisoimalla yhteydet rakennamme käytännössä rinnakkaista internetiä. Kyse ei ole enää vain IP-osoitteen piilottamisesta, vaan infrastruktuurin omistamisesta siten, ettei yksittäinen palveluntarjoaja voi vain katkaista yhteyttäsi kytkintä kääntämällä.

Käyttöönotto-opas solmun ylläpitäjille

Olet nyt perehtynyt matematiikkaan ja teoriaan, mutta mietit todennäköisesti, miten solmu saadaan käytännössä pystyyn. Rehellisesti sanottuna ZKP-yhteensopivan (nollatietotodistus) solmun pystyttäminen on mainio viikonloppuprojekti, mutta se on ainoa tapa siirtyä "VPN-palveluntarjoajaan luottamisesta" suoraan "fysiikan lakeihin luottamiseen".

Solmun tekniset vaatimukset ja asennus

Et tarvitse palvelinfarmia, mutta aivan leivänpaahtimellakaan homma ei onnistu.

• Vähimmäisvaatimukset: Suosittelen vähintään 8 Gt RAM-muistia ja nykyaikaista neliydinprosessoria.
• Verkkoyhteys: Symmetrinen kuituyhteys on ihanteellinen, mutta vähintään 20 Mbps lähtönopeus (upload) on välttämätön.

Todistusmekanismin (Proof Gadget) alustus

Useimmat nykyaikaiset dVPN-projektit hyödyntävät kirjastoja, kuten arkworks tai bellman. Tässä on pseudokoodiesimerkki siitä, miten solmu alustaa reitin varmistusmekanismin ZKPNet-logiikkaa käyttäen:

// Pseudokoodi ZKP-reititysmekanismin alustamiseksi
use zkpnet_lib::{Prover, PathCircuit};

fn prove_path(secret_path: Vec<u8>, public_root: [u8; 32]) {
    // 1. Alustetaan piiri (circuit) salaisella reitityspolulla
    let circuit = PathCircuit {
        path: secret_path,
        root: public_root,
    };

    // 2. Luodaan Groth16-todistus (kestää noin 468 ms)
    let proof = Prover::prove(circuit, &params).expect("Todistuksen luominen epäonnistui");

    // 3. Liitetään 224-tavuinen todistus IPv6-lisäotsakkeeseen (Extension Header)
    packet.attach_header(0xZK, proof.to_bytes());
}

Kun määrität taustajärjestelmää, muista, että todistusaika (proving time) on kriittinen tekijä – lähes puoli sekuntia on pitkä aika. Jos pystytät tätä, varmista, ettei solmusi yritä luoda todistusta jokaiselle yksittäiselle paketille. Sen sijaan kannattaa käyttää probabilistisia todistuksia tai eräajoa (batching). Todistat käsitelleesi tietyn liikenneikkunan oikein reitin muodostusvaiheessa.

1. Tupla-NAT-ongelmat: Jos solmusi on kahden reitittimen takana, P2P-löydettävyys epäonnistuu. Käytä UPnP-toimintoa tai manuaalista porttiohjausta.
2. Kellon poikkeama (Clock Skew): ZKP- ja lohkoketjuprotokollat ovat herkkiä ajalle. Pidä paikallinen NTP-palvelu (Network Time Protocol) käynnissä.
3. IPv6-vuodot: Monet konfiguroivat VPN-solmunsa IPv4-liikenteelle, mutta unohtavat, että palveluntarjoaja jakaa myös IPv6-osoitteita.

Siirtyminen keskitetystä internetistä hajautettuun, ZKP-pohjaiseen verkkoon on väistämättä monimutkaista. Taistelemme edelleen viiveongelmien ja "anonymiteetin trilemman" kanssa. Kehitys on kuitenkin todellista. Olitpa ylläpitämässä solmua ansaitaksesi tokeneita tai siksi, että olet kyllästynyt operaattorien suorittamaan valvontaan, olet mukana rakentamassa kestävämpää infrastruktuuria. Muista vain: pidä laiteohjelmistot päivitettyinä, tarkkaile prosessorin lämpötiloja ja – mikä tärkeintä – älä koskaan kadota yksityisiä avaimiasi.