Anonim Trafik Yönlendirme İçin Sıfır Bilgi Kanıtları | dVPN

Geleneksel Yönlendirmenin Sorunları ve Neden ZKP'ye İhtiyacımız Var?

"Kayıt tutmayan" (no-logs) VPN hizmetinizin gerçekten pazarlarda iddia edildiği kadar gizlilik odaklı olup olmadığını hiç merak ettiniz mi? Kabul etmesi zor bir gerçek ama geleneksel yönlendirme —şifrelenmiş olsa bile— temelden kusurludur; çünkü merkezi otoritelere duyulan körü körüne güvene ve manipüle edilmesi şaşırtıcı derecede kolay olan statik yollara dayanır.

Çoğu kişi bir VPN'i sihirli bir tünel sanır, ancak işin mutfağında bu sadece bir sağlayıcının sunucusuyla yapılan bir dizi el sıkışmadan ibarettir. Buradaki asıl sorun, bu sunucuların merkezi birer başarısızlık noktası (central point of failure) haline gelmesidir. Bir sağlayıcı kayıt tutmadığını söylese bile, gizliliğinizi hala onların sözüne ve veri merkezlerinin fiziksel güvenliğine emanet ediyorsunuz demektir.

• "Kayıt Tutmama" Paradoksu: Sağlayıcının bir hükümet tarafından zorlanmadığından veya sessiz bir veri sızıntısına maruz kalmadığından emin olamazsınız. Eğer merkezi sunucu ele geçirilirse, meta verileriniz —kim olduğunuz ve nereye bağlandığınız— tamamen açığa çıkar.
• P2P Ağlarda Düğüm Sahtekarlığı: Merkeziyetsiz ağlarda "yönlendirme yalanları" ile karşılaşırız. Bir düğüm (node), paketlerinizi analiz etmek amacıyla ele geçirmek için hedefe giden en hızlı yolun kendisinde olduğunu iddia edebilir; bu, klasik bir "ortadaki adam" (man-in-the-middle) saldırısı kurgusudur.
• Trafik Saptırma: Los Alamos Ulusal Laboratuvarı'ndan Jacob D. White'ın araştırması (2023), yönlendiricilerin izledikleri yol hakkında nasıl "yalan söyleyebileceğini", bunun da Otonom Sistemler içinde blackholing (veriyi yutma) veya dinleme saldırılarına yol açabileceğini vurgulamaktadır. (White, J. D., "ZKPNet: Verifiable Routing," LA-UR-23-29806).

Yönlendirme yolunun kendisini veya içindeki veriyi ifşa etmeden, o yolun geçerli olduğunu kanıtlamanın bir yoluna ihtiyacımız var. İşte Sıfır Bilgi Kanıtları (Zero-Knowledge Proofs - ZKP) burada devreye giriyor. Bunu "Waldo Nerede?" örneğiyle düşünebilirsiniz: Waldo'yu devasa bir kartonun üzerindeki minicik bir delikten göstererek bulduğumu kanıtlayabilirim. Haritanın geri kalanını size göstermeden, Waldo'nun yerini bildiğimi kanıtlamış olurum.

• Veri Minimizasyonu: ZKP, bir düğümün herhangi bir özel ağ şemasını sızdırmadan, protokole ve politikalara uyduğunu kanıtlamasına olanak tanır.
• Meta Veri Koruması: Sadece içeriği gizleyen ancak arkasında "ekmek kırıntıları" (IP adresleri, zaman damgaları) bırakan basit şifrelemenin aksine ZKP, göndericinin kimliğini veriyi taşıyan düğümlerden bile gizleyebilir.
• Güven Gerektirmeyen Doğrulama (Trustless): Düğüm sahibine güvenmeniz gerekmez; matematiğe güvenirsiniz. Eğer kanıt doğrulanmazsa, paket hareket etmez.

Finans sektöründe bir banka, hesap detaylarını ağa göstermeden işlemin kaynağını maskelemek için ZKP kullanarak işlemleri üçüncü taraf bir ağ üzerinden yönlendirebilir. Sağlık alanında ise bir hastane, hasta kayıtlarını bir P2P ağı üzerinden paylaşabilir; burada yönlendirme düğümleri hangi kliniğin veri talep ettiğini bile "göremez", böylece katı gizlilik yasalarına tam uyum sağlanır.

Dürüst olmak gerekirse, internet yönlendirmesinin mevcut durumu sızdıran meta veriler ve "bana güven" temelli el sıkışmalardan ibaret bir karmaşadır. Ancak bu güveni matematiksel kesinlikle değiştirebilirsek, nihayet bize vaat edilen gerçek gizliliğe kavuşabiliriz.

ZKPNet ve NIAR Oyunun Kurallarını Nasıl Değiştiriyor?

Mevcut internet yönlendirme sisteminin temelinde sunucular arası "sözlü taahhütlerin" yattığını artık biliyoruz. Eğer bu ilkel yapının ötesine geçmek istiyorsak, ticari sırlarımızı veya verilerimizi sızdırmayan, gerçek matematiksel temellere dayanan bir çözüme ihtiyacımız var. İşte ZKPNet ve NIAR (Anonim Yönlendirme için Ağ Altyapısı) tam bu noktada devreye giriyor. NIAR, merkezi bir otoriteye ihtiyaç duymadan bu anonim yolları oluşturmamıza olanak tanıyan temel çerçevedir.

Normal şartlarda bir yönlendirici (router), bir hedefe ulaşabileceğini kanıtlamak isterse yönlendirme tablosunu veya bazı dahili şemalarını paylaşmak zorundadır. Bu durum, bir internet servis sağlayıcısı (ISP) veya bir hastane ağı için tam bir güvenlik kabusudur. Los Alamos Ulusal Laboratuvarı'ndan Jacob D. White (2023), bu tür tasdik işlemleri için "gadget'lar" oluşturan, Rust tabanlı bir kütüphane olan ZKPNet'i tanıttı.

• Minimum Veri Boyutu: Bu kanıtlar oldukça küçüktür; groth16 protokolü kullanıldığında bazen sadece 224 byte kadardır. Bu veriyi, MTU (Maksimum İletim Birimi) sınırlarını zorlamadan bir başlık (header) içine kolayca yerleştirebilirsiniz.
• Tek Atlamalı (Single-Hop) Erişilebilirlik: Bir düğüm (node), kaç atlama yapıldığını veya dahili IP adreslerinin ne olduğunu ifşa etmeden, "Y Yönlendiricisine" geçerli bir yolu olduğunu kanıtlayabilir.
• Performans Dengesi: Buradaki en büyük engel gerçek zamanlı gecikme süresidir. M1 Max üzerindeki kıyaslama testleri, kanıtlama işleminin yaklaşık 468 ms sürdüğünü gösteriyor. Tek bir paket için 468 ms çok uzun bir süre olduğundan, bu yöntemi her bir veri biti için kullanmıyoruz. Bunun yerine Sıfır Bilgi Kanıtı (ZKP), yolun kurulumu gibi kontrol düzlemi (control-plane) işlemleri için kullanılır; "güven" bir kez tesis edildikten sonra asıl veri akışı hızla gerçekleşir.

Diğer tarafta ise Tor gibi sistemlerdeki "dürüst düğüm" zorunluluğunu ortadan kaldırmayı hedefleyen sPAR (Kısmen Pratik Anonim Yönlendirici) bulunuyor. Debajyoti Das ve Jeongeun Park (2025) tarafından ele alındığı üzere sPAR, çok partili tam homomorfik şifreleme (FHE) kullanarak yönlendiricinin bile veriyi nereye gönderdiğini bilmemesini sağlar.

Sistemin en etkileyici yanı "çakışma problemini" (collision problem) çözme biçimidir. Eğer çok sayıda kullanıcı aynı bant genişliği yuvasını kullanmaya çalışırsa veri bozulur. sPAR, bir "top ve kutu" matematik hilesi olan üçlü seçim stratejisini kullanır; istemci rastgele üç dizin seçer ve mesaj, ilk boş olan yuvaya yerleşir.

• Homomorfik Yerleştirme: Sunucu, seçtiğiniz dizini asla görmeden paketinizi bir "kovaya" yerleştirir. Tüm bu işlem, veri hala şifreliyken gerçekleştirilir.
• Ölçeklenebilirlik Sınırları: Mevcut durumda sPAR, küresel internetin yerini alacak düzeyde değildir. Birkaç saniyelik gecikmeyle yaklaşık 128 kullanıcıyı destekler; bu da onu kripto işlemlerini karıştırmak (mixing) veya bir yerel ağ (LAN) içinde özel mesajlaşma gibi niş alanlar için mükemmel kılar.

Envanter senkronizasyonu yapması gereken bir perakende zincirini hayal edin. sPAR tarzı bir yönlendirme kullanarak, merkezi sunucu hangi mağazanın hangi güncellemeyi gönderdiğini haritalandıramaz. Bu sayede rakiplerin, trafik hacmine bakarak hangi şubelerin daha kârlı olduğunu tespit etmesi engellenmiş olur.

Bant genişliği madenciliği ve token tabanlı ağ ekonomisi

İşteyken veya uyurken evdeki internetinizin öylece boşta durduğunu hiç düşündünüz mü? Bu durum, aslında hiç kiraya vermediğiniz boş bir misafir odasına sahip olmak gibi, verimsiz kullanılan bir varlıktır.

İşte DePIN (Merkeziyetsiz Fiziksel Altyapı Ağları) hareketi, "bant genişliği için Airbnb" modelini yaratarak bu durumu tamamen değiştiriyor. Her ay sadece internet servis sağlayıcınıza (ISS) ödeme yapmak yerine, kullanılmayan bağlantınızı küresel bir P2P (eşten eşe) ağıyla paylaşarak kripto para kazanabiliyorsunuz.

Merkeziyetsiz bir VPN (dVPN) veya proxy ağının gerçekten işlevsel olabilmesi için binlerce düğüme (node) ihtiyacı vardır. Projeler, insanları bu düğümleri çalıştırmaya teşvik etmek için token tabanlı teşvikler kullanır. Siz ağa erişim hattı sağlarsınız, ağ da size hizmet tokenları ile ödeme yapar.

Ancak burada aşılması gereken devasa bir teknik engel var: Ağ, yönlendirdiğiniz trafiği gözetlemeden gerçekten yüksek kaliteli bant genişliği sağladığınızı nasıl bilebilir? Eğer bir düğüm, çalıştığını "ispatlamak" için kullanıcı verilerini kaydetmeye başlar başlamaz, bir Web3 VPN'in sunduğu tüm gizlilik vaadi yerle bir olur.

• Bant Genişliği Madenciliği: Kullanıcılar, ağ havuzuna yükleme (upstream) kapasitesi sağlayan hafif bir düğüm istemcisi kurarlar. Ödüller genellikle çevrimiçi kalma süresi (uptime), veri aktarım hızı (throughput) ve coğrafi talebe göre hesaplanır.
• Gizliliği Koruyan İspatlar: İşte burada Sıfır Bilgi Kanıtları (ZKP) hayat kurtarıcıdır. Paket içeriklerini veya dahili ağ haritalarını ifşa etmeden, erişilebilirliğinizi ve protokol uyumluluğunuzu kanıtlayabilirsiniz.
• Hizmet Kalitesi (QoS): Düğümler, trafiği kısıtlamadıklarını veya paketleri "kara deliğe" (blackholing) atmadıklarını doğrulamak için matematiksel onaylar kullanan bir "Bant Genişliği Kanıtı" (Proof of Bandwidth) sunabilirler.

Bu özel VPN protokollerinin nasıl geliştiğini yakından takip etmek isterseniz, VPN teknolojileri ve güvenlik güncellemeleri hakkındaki en son haberler için SquirrelVPN adresine göz atmak akıllıca bir adım olacaktır. Merkezi veri merkezlerinden bu tür dağıtık düğüm modellerine geçiş sürecini anlık olarak takip ediyorlar.

Bu işin "ekonomi" kısmı tamamen zincir üstünde (on-chain) gerçekleşir. Akıllı sözleşmeler, gizliliğe ihtiyaç duyan kullanıcılar ile fazla bant genişliğine sahip düğüm operatörleri arasındaki değiş tokuşu yöneten otomatik bir aracı görevi görür.

• Otomatik P2P Ödemeler: Dev bir şirkete aylık sabit abonelik ücreti ödemek yerine, tam olarak kullandığınız kadar ödeme yaparsınız. Akıllı sözleşme, düğüm sağlayıcılarına gerçek zamanlı olarak mikro ödemeler aktarır.
• Sybil Saldırısı Direnci: Tek bir sunucudan 1.000 tane sahte düğüm çalıştıran bir kişi, ağın merkeziyetsizliğini bozabilir. Genellikle stake (pay kanıtı) gereksinimleriyle desteklenen bant genişliği kanıtı protokolleri, kaynaklar hakkında "yalan söylemeyi" maliyet açısından imkansız hale getirir.

Sağlık sektörü örneğimiz üzerinden gidersek; bir klinik, bu ağdaki bant genişliği için token kullanarak ödeme yapabilir. Ağ, daha önce bahsettiğimiz sPAR mantığını kullandığı için klinik anonimlik kazanır, düğüm operatörleri ödemesini alır ve tüm bunlar gerçekleşirken ISS, klinikten hastaneye giden trafik modellerini asla göremez.

Teknik Protokol Katmanına Derinlemesine Bakış

Ekonomik modelden gerçek teknik protokol katmanına geçiş yapıyoruz. Burası, bu kanıtları bir veri paketine teknik olarak nasıl yerleştirdiğimizin detaylarına indiğimiz kısımdır.

Buradaki asıl devrim, tek bir hata noktasından (single point of failure) uzaklaşmaktır. Tipik bir kurulumda, kalenin anahtarları tek bir kişinin elindedir. Ancak çok taraflı tam homomorfik şifreleme (multi-party FHE) ile, hiç kimsenin ana sırrı (master secret) bilmediği ortak bir genel anahtar (public key) oluşturabiliyoruz.

• Ortak Anahtar Üretimi: Kurulum sırasında her katılımcı kendi gizli anahtarını oluşturur. Bunlar tek bir genel anahtar ($pk$) altında birleştirilir. Debajyoti Das ve Jeongeun Park'ın (2025) sPAR üzerine yaptıkları çalışmada belirttikleri gibi, ana gizli anahtar tüm bireysel anahtarların toplamıdır; ancak hiç kimse kendi anahtarını paylaşmadığı için "bütün" anahtar tek bir yerde asla var olmaz.
• RLWE (Hatalarla Halka Öğrenme): Bu işin matematiksel temelidir. Basit bir tabirle RLWE, veriye küçük bir miktar "gürültü" eklediğiniz karmaşık bir bulmaca gibidir. Bir bilgisayarın bunu geriye doğru çözmesi son derece zordur; bu da bize ind-cpa güvenliği sağlar (yani bir saldırgan, içeriği tahmin etse bile iki farklı şifrelenmiş mesajı birbirinden ayırt edemez).

Paket Yapısı: Kanıtın Saklandığı Yer

Peki, o 224 baytlık Sıfır Bilgi Kanıtı (ZKP) tam olarak nereye yerleşiyor? Modern bir IPv6 kurulumunda, Uzantı Başlıklarını (Extension Headers) kullanıyoruz. Spesifik olarak, özel bir "Hedef Seçenekleri" (Destination Options) başlığı kullanmaktayız.

Kanıtı uzantı başlığına koyarak, ZKPNet'i desteklemeyen yönlendiricilerin (router) paketi doğrudan iletmesini sağlıyoruz. Ancak "ZKP uyumlu" düğümler (nodes) durur, kanıtı 2,7 ms içinde doğrular ve ardından iletir. Eğer kanıt sahteyse, paket anında düşürülür.

• Yanlış Beyan Koruması (Equivocation Protection): İletişim geçmişini anahtarların içine işleyerek düğümlerin yalan söylemesini engelleyebiliriz. Her oturumda genel anahtarı güncellemek için iletişim geçmişinin bir özetini (hash) kullanarak, sunucunun Alice'e Bob'unkinden farklı bir "gerçeklik" göstermeye çalışması durumunda matematiksel yapı bozulur.
• Doğrulanabilir FHE: Bir düğümün matematiği doğru yapacağına güvenmek yerine, doğrulanabilir FHE kullanıyoruz. Bu, sunucunun protokolü tam olarak yazıldığı gibi uyguladığını kanıtlayan dijital bir makbuz gibidir.

Perakende kullanım senaryomuzda, bu teknik katman 100 mağazanın verilerini senkronize etmesine olanak tanır. "Üçlü seçim" (choice-of-three) kutu stratejisi, bir saldırgan paketi ele geçirip IPv6 başlığına baksa bile, verinin hangi mağazadan geldiğini anlayamamasını sağlar; çünkü ZKP, kaynağın adını vermeden yolun geçerli olduğunu kanıtlar.

DePIN'in Geleceği ve Sansüre Dayanaklı İnternet

Dürüst olmak gerekirse, günümüz interneti aslında küresel bir ortak alanmış gibi davranan, etrafı yüksek duvarlarla çevrili bahçelerden oluşuyor. Önceki bölümlerde, Sıfır Bilgi Kanıtları (ZKP) ve eşler arası (P2P) bant genişliğinin bu sistemin altyapısını nasıl düzeltebileceğinden bahsettik; ancak asıl soru, milyonlarca insan aynı anda video izlemeye çalıştığında bu sistemin nasıl ölçekleneceğidir.

Bu protokolleri ölçeklendirmek, "anonimlik üçlemi" (anonymity trilemma) nedeniyle oldukça karmaşık bir hal alıyor. Genellikle şu üçünden ikisini seçmeniz gerekir: güçlü gizlilik, düşük gecikme süresi veya düşük bant genişliği yükü. Tor gibi karmaşık sistemleri analiz ettiğimizde, "kusursuz" bir kriptografiye sahip olsanız bile, ağ yeterince yoğun değilse trafik korelasyonu gibi sistem düzeyindeki saldırılarla hala karşı karşıya kaldığınızı görüyoruz.

Merkeziyetsiz Fiziksel Altyapı Ağları (DePIN) için en büyük darboğaz, "kanıt boyutu" ile "kanıtlama süresi" arasındaki dengedir. Bir Web3 VPN içindeki her veri paketi bir Groth16 kanıtına ihtiyaç duyarsa, yönlendiriciniz (router) aşırı yükten çalışamaz hale gelir. Bunu çözmek için özyinelemeli kanıtlar (recursive proofs) üzerinde çalışıyoruz.

• Özyinelemeli SNARK'lar: Bir düğüm (node), 1.000 ayrı paket kanıtını tek tek doğrulamak yerine, bu kanıtları tek bir "meta-kanıt" içinde birleştirebilir (roll-up). Bu, en dıştaki katmanın içindeki her şeyin geçerliliğini kanıtladığı bir matruşka bebeği gibidir.
• Durum Küçültme (Shrinking the State): Bu yöntem, blokzinciri boyutunu yönetilebilir kılar. Her düğümün ağın tüm geçmişini bilmesine gerek kalmaz; yönlendirme tablosunun dürüst olduğunu anlamak için sadece en son özyinelemeli kanıtı doğrulamaları yeterlidir.

İş dünyası, merkezi VPN servislerinin veri güvenliği açısından aslında birer risk faktörü olduğunun farkına varmaya başladı. Dağıtık düğümler, saldırganlar için hedefi vurmayı çok daha zor hale getiriyor.

• Yapay Zeka Tabanlı Yönlendirme: Yapay zeka ajanlarının gerçek zamanlı olarak sansüre en dayanıklı yolu seçtiği, yazılım tanımlı ağlara (SDN) doğru bir kayış görüyoruz.
• İnternet Servis Sağlayıcılarını (ISP) Devre Dışı Bırakmak: Bağlanabilirliği tokenize ederek aslında paralel bir internet inşa ediyoruz. Artık mesele sadece IP adresinizi gizlemek değil; altyapının sahibi olmak, böylece bir servis sağlayıcının tek bir hamleyle erişiminizi kesmesini engellemek.

Düğüm Operatörleri İçin Uygulama Rehberi

Matematiksel temelleri ve teoriyi incelediniz; şimdi muhtemelen bir düğümü (node) fiilen nasıl çalıştıracağınızı merak ediyorsunuz. Dürüst olmak gerekirse, ZKP (Sıfır Bilgi Kanıtı) destekli bir düğüm kurmak biraz "hafta sonu projesi" kıvamındadır; ancak "bir VPN sağlayıcısına güvenmekten", "fiziğin yasalarına güvenmeye" geçmenin tek yolu da budur.

Düğüm Özellikleri ve Kurulum

Bir sunucu çiftliğine ihtiyacınız yok, ancak sistemi bir ekmek kızartma makinesinde çalıştıramayacağınız da aşikâr.

• Minimum Özellikler: En az 8 GB RAM ve modern bir 4 çekirdekli işlemciyi hedeflemenizi öneririm.
• Ağ: Simetrik fiber bağlantı ideal olandır, ancak en az 20 Mbps yükleme (upstream) hızı gereklidir.

Bir Kanıt Aracını (Proof Gadget) Başlatma

Çoğu modern dVPN projesi, arkworks veya bellman gibi kütüphaneler kullanır. İşte bir düğümün ZKPNet mantığını kullanarak bir yol doğrulama aracını nasıl başlatabileceğine dair sözde kod (pseudo-code) örneği:

// ZKP yönlendirme aracını başlatmak için sözde kod
use zkpnet_lib::{Prover, PathCircuit};

fn prove_path(secret_path: Vec<u8>, public_root: [u8; 32]) {
    // 1. Devreyi gizli yönlendirme yolu ile başlatın
    let circuit = PathCircuit {
        path: secret_path,
        root: public_root,
    };

    // 2. Groth16 kanıtını oluşturun (yaklaşık 468 ms sürer)
    let proof = Prover::prove(circuit, &params).expect("Kanıtlama başarısız oldu");

    // 3. 224 baytlık kanıtı IPv6 Uzantı Başlığına (Extension Header) ekleyin
    packet.attach_header(0xZK, proof.to_bytes());
}

Arka ucu (backend) yapılandırırken, kanıtlama süresinin (proving time) en kritik engel olduğunu unutmayın; bu işlem yaklaşık yarım saniye sürer. Eğer bu kurulumu yapıyorsanız, düğümünüzün her bir paketi tek tek kanıtlamaya çalışmadığından emin olun. Bunun yerine, olasılıksal kanıtlar (probabilistic proofs) veya toplu işlem (batching) yöntemlerini kullanmalısınız. Yol kurulum aşamasında, belirli bir trafik penceresini doğru şekilde yönettiğinizi kanıtlarsınız.

1. Çift NAT Sorunları: Düğümünüz iki yönlendiricinin (router) arkasındaysa, P2P keşfi başarısız olacaktır. UPnP kullanın veya manuel port yönlendirme yapın.
2. Saat Kayması (Clock Skew): ZKP ve blokzincir protokolleri zamana karşı duyarlıdır. Yerel bir NTP arka plan programı (daemon) çalıştırın.
3. IPv6 Sızıntıları: Birçok kişi VPN düğümünü IPv4 için yapılandırır ancak internet servis sağlayıcısının (ISS) IPv6 adresleri dağıttığını unutur.

Merkezi bir internetten, merkeziyetsiz ve ZKP destekli bir internete geçiş süreci biraz sancılı olacaktır. Hâlâ gecikme (latency) sorunları ve "anonimlik üçlemi" (anonymity trilemma) ile mücadele ediyoruz. Ancak kaydedilen ilerleme gerçektir. İster token kazanmak için ister ISS gözetiminden bıktığınız için bir düğüm çalıştırıyor olun, daha dirençli bir altyapının inşasına katkıda bulunuyorsunuz. Unutmayın: Donanım yazılımınızı güncel tutun, işlemci sıcaklıklarınızı takip edin ve ne yaparsanız yapın, özel anahtarlarınızı (private keys) asla kaybetmeyin.