Zero-Knowledge Proofs für anonymes Routing | dVPN & DePIN

Das Problem mit herkömmlichem Routing und warum wir ZKPs benötigen

Haben Sie sich jemals gefragt, ob Ihr „No-Logs“-VPN tatsächlich so privat ist, wie es das Marketing verspricht? Es ist eine bittere Pille, aber das traditionelle Routing – selbst in verschlüsselter Form – ist grundlegend fehlerhaft. Der Grund: Es basiert auf blindem Vertrauen gegenüber zentralen Instanzen und statischen Pfaden, die überraschend einfach manipuliert werden können.

Die meisten Nutzer betrachten ein VPN als eine Art magischen Tunnel. Unter der Haube ist es jedoch lediglich eine Abfolge von Handshakes mit dem Server eines Anbieters. Das Problem dabei ist, dass diese Server zu zentralen Schwachstellen (Single Points of Failure) werden. Selbst wenn ein Provider versichert, keine Protokolle zu führen, setzen Sie Ihre Privatsphäre letztlich auf sein Wort und die physische Sicherheit seines Rechenzentrums.

• Das „No-Logs“-Paradoxon: Sie müssen darauf vertrauen, dass der Anbieter nicht von Regierungen unter Druck gesetzt wird oder Opfer einer unbemerkten Datenpanne geworden ist. Wenn der zentrale Server kompromittiert wird, liegen Ihre Metadaten – wer Sie sind und wohin Ihr Datenverkehr fließt – offen.
• Unehrliche Knoten in P2P-Netzwerken: In dezentralen Netzwerken erleben wir oft „Routing-Lügen“. Ein Node könnte behaupten, den schnellsten Pfad zu einem Ziel zu haben, nur um Ihre Pakete für eine Analyse abzufangen – ein klassisches Man-in-the-Middle-Szenario.
• Traffic-Umleitung: Untersuchungen von Jacob D. White am Los Alamos National Laboratory (2023) zeigen auf, wie Router über ihre Pfadführung „lügen“ können, was zu Blackholing oder Interzeptions-Angriffen innerhalb autonomer Systeme führt. (White, J. D., „ZKPNet: Verifiable Routing“, LA-UR-23-29806).

Wir benötigen eine Methode, um die Validität eines Routing-Pfades zu beweisen, ohne den Pfad selbst oder die darin enthaltenen Daten preiszugeben. Hier kommen Zero-Knowledge Proofs (ZKP) ins Spiel. Denken Sie an die „Wo ist Walter?“-Analogie: Ich kann beweisen, dass ich Walter auf einer Karte gefunden habe, indem ich ihn durch ein winziges Loch in einem riesigen Stück Karton zeige. Ich habe bewiesen, dass ich weiß, wo er ist, ohne Ihnen den Rest der Karte zu offenbaren.

• Datenminimierung: ZKPs ermöglichen es einem Node zu beweisen, dass er Protokolle und Richtlinien eingehalten hat, ohne private Netzwerkschemata preiszugeben.
• Schutz von Metadaten: Im Gegensatz zur einfachen Verschlüsselung, die zwar den Inhalt verbirgt, aber „Brotkrumen“ (IP-Adressen, Zeitstempel) hinterlässt, können ZKPs die Identität des Senders sogar vor den Nodes verbergen, die die Daten transportieren.
• Trustless Verification (Vertrauenslose Verifizierung): Sie müssen dem Node-Betreiber nicht vertrauen; Sie vertrauen der Mathematik. Wenn der kryptografische Beweis nicht aufgeht, wird das Paket nicht weitergeleitet.

Im Finanzsektor könnte eine Bank ZKPs nutzen, um Transaktionen über ein Drittanbieternetzwerk zu routen und so den Ursprung zu verschleiern, ohne dass das Netzwerk Kontodetails einsehen kann. Im Gesundheitswesen könnte ein Krankenhaus Patientenakten über ein P2P-Netzwerk teilen, wobei die Routing-Knoten nicht einmal „sehen“ können, welche Klinik die Daten anfordert – dies gewährleistet die Einhaltung strengster Datenschutzgesetze.

Ehrlich gesagt ist der aktuelle Zustand des Internet-Routings ein Desaster aus lückenhaften Metadaten und „Vertrau-mir“-Handshakes. Aber wenn wir dieses Vertrauen durch mathematische Gewissheit ersetzen können, erhalten wir vielleicht endlich die Privatsphäre, die uns von Anfang an versprochen wurde.

Wie ZKPNet und NIAR die Spielregeln verändern

Wir haben bereits festgestellt, dass das aktuelle Internet-Routing im Grunde auf einer Reihe von „Ehrenworten“ zwischen Servern basiert. Wenn wir darüber hinausgehen wollen, benötigen wir echte Mathematik, die unsere Geschäftsgeheimnisse nicht preisgibt. Genau hier kommen ZKPNet und NIAR (Network Infrastructure for Anonymous Routing) ins Spiel. NIAR ist im Grunde das Framework, das es uns ermöglicht, diese anonymen Pfade ohne eine zentrale Kontrollinstanz aufzubauen.

Normalerweise muss ein Router, wenn er beweisen will, dass er ein Ziel erreichen kann, seine Routing-Tabelle oder interne Schaltpläne offenlegen. Für einen ISP oder ein Krankenhausnetzwerk ist das ein Albtraum für die Netzwerksicherheit. Jacob D. White vom Los Alamos National Laboratory (2023) stellte ZKPNet vor, eine auf Rust basierende Bibliothek, die „Gadgets“ für diese Attestierungen erstellt.

• Minimale Datenlast: Diese Beweise sind winzig – bei Verwendung von groth16 teilweise nur 224 Bytes groß. Das lässt sich problemlos in einen Header integrieren, ohne die MTU (Maximum Transmission Unit) zu sprengen.
• Single-Hop-Erreichbarkeit: Ein Knoten kann beweisen, dass er einen gültigen Pfad zu „Router Y“ besitzt, ohne genau offenzulegen, wie viele Hops dazwischen liegen oder wie die internen IP-Adressen aussehen.
• Performance-Abwägungen: Die Echtzeit-Latenz ist hier die größte Hürde. Benchmarks auf einem M1 Max zeigen, dass die Erstellung des Beweises etwa 468 ms dauert. Nun sind 468 ms für ein einzelnes Paket eine Ewigkeit, weshalb wir dies nicht für jedes Datenbit verwenden. Stattdessen wird ZKP für Control-Plane-Operationen eingesetzt – also für den Aufbau des Pfades –, während die eigentlichen Daten fließen, sobald das „Vertrauen“ etabliert ist.

Zusätzlich gibt es sPAR (Somewhat Practical Anonymous Router), das versucht, die Anforderung an „ehrliche Knoten“ (honest nodes) zu lösen, wie man sie von Tor kennt. Wie von Debajyoti Das und Jeongeun Park (2025) erörtert, nutzt sPAR Multi-Party Fully Homomorphic Encryption (FHE), sodass selbst der Router nicht weiß, wohin er die Daten sendet.

Der Clou dabei ist, wie das „Kollisionsproblem“ vermieden wird. Wenn mehrere Nutzer versuchen, denselben Bandbreiten-Slot zu belegen, werden die Daten unbrauchbar. sPAR nutzt eine „Choice-of-Three“-Strategie – ein mathematischer Trick aus dem Bereich „Balls-and-Bins“ –, bei dem ein Client drei zufällige Indizes wählt und die Nachricht im ersten verfügbaren Slot landet.

• Homomorphe Platzierung: Der Server platziert Ihr Paket in einen „Bucket“, ohne jemals den von Ihnen gewählten Index zu sehen. Das Ganze geschieht, während die Daten noch verschlüsselt sind.
• Skalierungsgrenzen: Aktuell wird sPAR das globale Web nicht ersetzen. Es unterstützt etwa 128 Nutzer mit einer Latenz von wenigen Sekunden. Damit ist es perfekt für Nischenanwendungen wie das Mixen von Krypto-Transaktionen oder privates Messaging in einem LAN (Local Area Network).

Stellen Sie sich eine Einzelhandelskette vor, die ihre Bestände synchronisieren muss. Durch den Einsatz von Routing im sPAR-Stil kann der zentrale Server nicht zuordnen, welche Filiale welches Update sendet. Dies verhindert, dass Wettbewerber anhand des Traffic-Volumens analysieren können, welche Standorte am profitabelsten sind.

Bandwidth-Mining und die Wirtschaft der tokenisierten Netzwerke

Haben Sie schon einmal darüber nachgedacht, dass Ihr heimischer Internetanschluss ungenutzt bleibt, während Sie bei der Arbeit sind oder schlafen? Im Grunde ist das eine brachliegende Ressource – vergleichbar mit einem Gästezimmer, das Sie niemals vermieten.

Die DePIN-Bewegung (Decentralized Physical Infrastructure Networks) ändert das grundlegend, indem sie ein „Airbnb für Bandbreite“ schafft. Anstatt monatlich nur Gebühren an Ihren Internetprovider zu zahlen, können Sie Kryptowährungen verdienen, indem Sie Ihre ungenutzte Verbindung mit einem globalen P2P-Netzwerk teilen.

Der Aufbau eines dezentralen VPN (dVPN) oder eines Proxy-Netzwerks erfordert tausende von Knotenpunkten (Nodes), um wirklich effektiv zu sein. Um Menschen dazu zu bewegen, diese Nodes zu betreiben, setzen Projekte auf tokenisierte Anreize. Sie stellen die Leitung bereit, und das Netzwerk entlohnt Sie mit Utility-Token.

Dabei gibt es jedoch eine enorme technische Hürde: Wie kann das Netzwerk sicherstellen, dass Sie tatsächlich qualitativ hochwertige Bandbreite liefern, ohne den von Ihnen weitergeleiteten Datenverkehr auszuspionieren? Wenn ein Node damit begänne, Nutzerdaten zu protokollieren, um seine „Arbeit“ nachzuweisen, wäre der gesamte Privatsphäre-Aspekt eines Web3-VPN hinfällig.

• Bandwidth Mining: Nutzer installieren einen schlanken Node-Client, der Upstream-Kapazitäten in den Netzwerk-Pool einspeist. Die Belohnungen werden in der Regel auf Basis von Uptime (Betriebszeit), Durchsatz und geografischer Nachfrage berechnet.
• Privacy-Preserving Proofs: Hier erweisen sich Zero-Knowledge Proofs (ZKP) als Lebensretter. Sie ermöglichen es, Erreichbarkeit und Protokollkonformität nachzuweisen, ohne den eigentlichen Paketinhalt oder interne Netzwerkkarten offenzulegen.
• Quality of Service (QoS): Nodes können einen „Proof of Bandwidth“ erbringen, der mathematische Attestierungen nutzt, um zu verifizieren, dass sie den Datenverkehr nicht drosseln oder Pakete in ein „Blackhole“ laufen lassen.

Wenn Sie verfolgen möchten, wie sich diese spezifischen VPN-Protokolle weiterentwickeln, ist ein Blick auf SquirrelVPN für aktuelle Nachrichten zu VPN-Technologien und Sicherheits-Updates sehr empfehlenswert. Dort wird der Wandel von zentralisierten Rechenzentren hin zu diesen verteilten Node-Modellen genau beobachtet.

Der wirtschaftliche Teil dieses Ökosystems findet On-Chain statt. Smart Contracts fungieren als automatisierte Vermittler und wickeln den Austausch zwischen Nutzern, die Privatsphäre benötigen, und Node-Betreibern, die überschüssige Bandbreite besitzen, ab.

• Automatisierte P2P-Zahlungen: Anstatt ein monatliches Abonnement bei einem Großkonzern abzuschließen, zahlen Sie exakt für das, was Sie verbrauchen. Der Smart Contract gibt Mikrozahlungen in Echtzeit an die Node-Provider frei.
• Resistenz gegen Sybil-Angriffe: Würde eine einzelne Person tausende gefälschte Nodes von einem einzigen Server aus betreiben, wäre die Dezentralisierung des Netzwerks gefährdet. Proof-of-Bandwidth-Protokolle – oft kombiniert mit Staking-Anforderungen – machen es wirtschaftlich unattraktiv, falsche Angaben über die bereitgestellten Ressourcen zu machen.

In unserem Beispiel aus dem Gesundheitswesen könnte eine Klinik für Bandbreite in diesem Netzwerk mit Token bezahlen. Da das Netzwerk die zuvor beschriebene sPAR-Logik nutzt, erhält die Klinik Anonymität, während die Node-Betreiber entlohnt werden – und das alles, ohne dass der Internetprovider die Traffic-Muster zwischen Klinik und Krankenhaus einsehen kann.

Tiefer Einblick in die technische Protokollschicht

Nachdem wir das ökonomische Modell beleuchtet haben, widmen wir uns nun der eigentlichen technischen Protokollschicht. Hier gehen wir ins Detail und schauen uns an, wie wir diese kryptografischen Beweise (Proofs) tatsächlich in ein Datenpaket integrieren.

Der entscheidende Durchbruch besteht darin, den „Single Point of Failure“ zu eliminieren. In einem herkömmlichen Setup hält eine einzige Instanz die Schlüssel zum System. Durch den Einsatz von Multi-Party Fully Homomorphic Encryption (FHE) können wir jedoch einen gemeinsamen öffentlichen Schlüssel (Public Key) generieren, bei dem buchstäblich niemand das Master-Geheimnis kennt.

• Gemeinsame Schlüsselgenerierung (Joint Key Generation): Während der Initialisierung erstellt jeder Teilnehmer seinen eigenen privaten Schlüssel. Diese werden zu einem einzigen öffentlichen Schlüssel ($pk$) kombiniert. Wie von Debajyoti Das und Jeongeun Park (2025) in ihrer Arbeit über sPAR dargelegt, entspricht der Master-Geheimschlüssel zwar der Summe aller Einzelschlüssel – da jedoch niemand seinen Teil preisgibt, existiert der „vollständige“ Schlüssel an keinem einzigen Ort im Netzwerk.
• RLWE (Ring Learning With Errors): Dies bildet das mathematische Fundament. Vereinfacht ausgedrückt ist RLWE wie ein komplexes Rätsel, bei dem den Daten ein winziges „Rauschen“ hinzugefügt wird. Für einen Computer ist es extrem schwierig, dies rückwärts zu berechnen, was uns IND-CPA-Sicherheit garantiert (das bedeutet, ein Angreifer kann zwei verschiedene verschlüsselte Nachrichten nicht voneinander unterscheiden, selbst wenn er den Inhalt vermutet).

Die Paketstruktur: Wo der Beweis verankert ist

Wo genau werden die 224 Byte des Zero-Knowledge Proofs (ZKP) platziert? In einer modernen IPv6-Umgebung nutzen wir dafür Extension Headers – genauer gesagt einen benutzerdefinierten „Destination Options“-Header.

Durch die Platzierung des Proofs im Extension Header können Router, die ZKPNet nicht unterstützen, das Paket einfach weiterleiten. „ZKP-fähige“ Knoten hingegen stoppen das Paket, verifizieren den Beweis innerhalb von nur 2,7 ms und leiten es erst dann weiter. Ist der Beweis gefälscht, wird das Paket sofort verworfen.

• Schutz vor Equivocation (Widersprüchlichkeit): Wir verhindern, dass Knoten falsche Informationen verbreiten, indem wir den Verlauf der Kommunikation direkt in die Schlüssel einbetten. Durch die Verwendung eines Hashes der Kommunikationshistorie zur Aktualisierung des öffentlichen Schlüssels in jeder Runde bricht die mathematische Integrität sofort zusammen, falls ein Server versucht, gegenüber verschiedenen Teilnehmern unterschiedliche „Realitäten“ vorzutäuschen.
• Verifizierbare FHE: Anstatt darauf zu vertrauen, dass ein Node die Berechnungen korrekt ausführt, nutzen wir verifizierbare FHE. Dies fungiert wie ein digitaler Beleg, der beweist, dass der Server das Protokoll exakt wie vorgeschrieben befolgt hat.

In unserem Einzelhandels-Szenario ermöglicht diese technische Ebene die Synchronisation von Daten über 100 Filialen hinweg. Die „Choice-of-Three“-Bin-Strategie stellt sicher, dass selbst wenn ein Angreifer ein Paket abfängt und den IPv6-Header analysiert, er nicht feststellen kann, aus welcher Filiale die Daten stammen. Der ZKP bestätigt die Validität des Pfades, ohne die Quelle preiszugeben.

Die Zukunft von DePIN und das zensurresistente Internet

Seien wir ehrlich: Das heutige Internet gleicht eher einer Ansammlung von geschlossenen Systemen („Walled Gardens“), die sich als globales Gemeingut tarnen. Wir haben bereits darüber gesprochen, wie Zero-Knowledge Proofs (ZKP) und P2P-Bandbreite die technische Basis reparieren können. Doch die entscheidende Frage bleibt: Wie lässt sich das skalieren, wenn Millionen von Menschen gleichzeitig Videos streamen wollen?

Die Skalierung dieser Protokolle ist aufgrund des sogenannten „Anonymitäts-Trilemmas“ eine enorme Herausforderung. In der Regel muss man sich für zwei von drei Eigenschaften entscheiden: starke Privatsphäre, niedrige Latenz oder geringer Bandbreiten-Overhead. Die Analyse komplexer Systeme wie Tor zeigt, dass man selbst bei „perfekter“ Kryptografie mit Angriffen auf Systemebene – wie der Traffic-Korrelation – rechnen muss, solange das Netzwerk nicht dicht genug besiedelt ist.

Der größte Flaschenhals für ein dezentrales physisches Infrastrukturnetzwerk (DePIN) ist das Verhältnis zwischen „Beweisgröße“ (Proof Size) und „Beweiszeit“ (Proving Time). Wenn jedes einzelne Paket in einem Web3-VPN einen Groth16-Proof erfordern würde, wäre jeder Router hoffnungslos überfordert. Die Lösung für dieses Problem liegt in rekursiven Beweisen.

• Rekursive SNARKs: Anstatt 1.000 einzelne Paketbeweise mühsam zu verifizieren, kann ein Node diese Beweise zu einem einzigen Meta-Beweis zusammenfassen („Roll-up“). Es funktioniert wie eine Matroschka-Puppe: Die äußere Schicht beweist die Gültigkeit des gesamten Inhalts.
• State-Minimierung: Dies hält die Größe der Blockchain handhabbar. Anstatt dass jeder Node die gesamte Historie des Netzwerks speichern muss, reicht die Verifizierung des neuesten rekursiven Beweises aus, um sicherzustellen, dass die Routing-Tabelle korrekt ist.

Unternehmen erkennen allmählich, dass zentralisierte VPNs ein massives Sicherheitsrisiko für ihre Daten darstellen. Verteilte Nodes machen es Angreifern hingegen extrem schwer, ein klares Ziel zu finden.

• KI-gestütztes Routing: Wir erleben einen Wandel hin zu Software-Defined Networking (SDN), bei dem KI-Agenten in Echtzeit den Pfad wählen, der die höchste Zensurresistenz bietet.
• ISP-Bypass: Durch die Tokenisierung von Konnektivität bauen wir im Grunde ein paralleles Internet auf. Es geht nicht mehr nur darum, die eigene IP-Adresse zu verbergen. Es geht darum, die Infrastruktur selbst zu besitzen, damit ein Internetdienstanbieter (ISP) nicht einfach per Knopfdruck den Zugang sperren kann.

Implementierungsleitfaden für Node-Betreiber

Sie haben sich nun mit der Mathematik und der Theorie vertraut gemacht, aber jetzt fragen Sie sich wahrscheinlich, wie Sie tatsächlich eine Node zum Laufen bringen. Ehrlich gesagt ist die Einrichtung einer ZKP-fähigen Node eher ein Wochenendprojekt, aber es ist der einzige Weg, um vom "Vertrauen in einen VPN-Anbieter" zum "Vertrauen in die Gesetze der Physik" überzugehen.

Node-Spezifikationen & Setup

Sie benötigen keine Serverfarm, aber auf einem Toaster lässt sich das Ganze auch nicht gerade betreiben.

• Mindestanforderungen: Ich empfehle mindestens 8 GB RAM und eine moderne 4-Kern-CPU.
• Netzwerk: Eine symmetrische Glasfaserverbindung ist der Idealfall, aber mindestens 20 Mbit/s Upstream sind erforderlich.

Initialisierung eines Proof-Gadgets

Die meisten modernen dVPN-Projekte nutzen Bibliotheken wie arkworks oder bellman. Hier ist ein Pseudo-Code-Beispiel, wie eine Node ein Gadget zur Pfadvalidierung mittels der ZKPNet-Logik initialisieren könnte:

// Pseudo-Code zur Initialisierung eines ZKP-Routing-Gadgets
use zkpnet_lib::{Prover, PathCircuit};

fn prove_path(secret_path: Vec<u8>, public_root: [u8; 32]) {
    // 1. Initialisierung des Circuits mit dem geheimen Routing-Pfad
    let circuit = PathCircuit {
        path: secret_path,
        root: public_root,
    };

    // 2. Erstellung des Groth16-Proofs (Dauer ca. 468ms)
    let proof = Prover::prove(circuit, &params).expect("Proving failed");

    // 3. Anhängen des 224-Byte-Proofs an den IPv6 Extension Header
    packet.attach_header(0xZK, proof.to_bytes());
}

Wenn Sie das Backend konfigurieren, denken Sie daran, dass die Proving Time (Beweiszeit) der entscheidende Faktor ist – fast eine halbe Sekunde. Wenn Sie dies einrichten, stellen Sie sicher, dass Ihre Node nicht versucht, jedes einzelne Paket zu beweisen. Stattdessen sollten Sie probabilistische Beweise oder Batching (Stapelverarbeitung) verwenden. Sie beweisen dabei während der Pfadeinrichtungsphase, dass Sie ein bestimmtes Zeitfenster des Traffics korrekt verarbeitet haben.

1. Double NAT-Probleme: Wenn sich Ihre Node hinter zwei Routern befindet, wird das P2P-Discovery fehlschlagen. Nutzen Sie UPnP oder manuelles Port-Forwarding.
2. Clock Skew (Zeitversatz): ZKP- und Blockchain-Protokolle reagieren empfindlich auf Zeitabweichungen. Lassen Sie einen lokalen NTP-Daemon laufen.
3. IPv6-Leaks: Viele konfigurieren ihre VPN-Node für IPv4, vergessen aber, dass ihr ISP auch IPv6-Adressen vergibt.

Klar, der Übergang von einem zentralisierten Internet zu einer dezentralen, ZKP-gestützten Infrastruktur wird holprig sein. Wir kämpfen immer noch mit Latenzproblemen und dem "Anonymitäts-Trilemma". Aber der Fortschritt ist real. Egal, ob Sie eine Node für die Token-Rewards betreiben oder weil Sie die Überwachung durch ISPs satt haben: Sie sind Teil des Aufbaus einer resilienteren Infrastruktur. Denken Sie einfach daran: Halten Sie Ihre Firmware aktuell, behalten Sie die CPU-Temperaturen im Auge und – um Himmels willen – verlieren Sie niemals Ihre Private Keys.