Bukti Tanpa Pengetahuan untuk Perutean Anonim | dVPN & DePIN

Masalah pada Perutean Tradisional dan Mengapa Kita Membutuhkan ZKP

Pernahkah Anda bertanya-tanya apakah layanan VPN "tanpa log" (no-logs) yang Anda gunakan benar-benar menjaga privasi seperti yang dijanjikan dalam iklannya? Kenyataannya cukup pahit: sistem perutean (routing) tradisional—bahkan yang sudah terenkripsi sekalipun—secara fundamental cacat karena sangat bergantung pada kepercayaan buta terhadap otoritas pusat dan jalur statis yang sebenarnya sangat mudah dimanipulasi.

Kebanyakan orang menganggap VPN sebagai terowongan ajaib, namun di balik layar, itu hanyalah serangkaian jabat tangan (handshake) dengan server penyedia layanan. Masalah utamanya adalah server-server ini menjadi titik kegagalan terpusat (central point of failure). Meskipun penyedia layanan mengeklaim tidak mencatat log, Anda tetap mempertaruhkan privasi Anda pada integritas kata-kata mereka dan keamanan fisik pusat data mereka.

• Paradoks "Tanpa Log": Anda dipaksa percaya bahwa penyedia layanan tidak sedang ditekan oleh pemerintah atau mengalami kebocoran data diam-diam. Jika server pusat dikompromikan, metadata Anda—siapa Anda dan ke mana tujuan trafik Anda—akan terekspos sepenuhnya.
• Ketidakjujuran Node dalam Jaringan P2P: Dalam jaringan terdesentralisasi, kita sering menemui fenomena "kebohongan perutean" (routing lying). Sebuah node bisa saja mengeklaim memiliki jalur tercepat ke tujuan hanya untuk mencegat paket data Anda guna dianalisis—sebuah skema klasik serangan man-in-the-middle.
• Pengalihan Trafik: Penelitian oleh Jacob D. White di Los Alamos National Laboratory (2023) menyoroti bagaimana router dapat "berbohong" mengenai jalur peruteannya, yang memicu serangan blackholing atau intersepsi di dalam Sistem Otonom (Autonomous Systems). (White, J. D., "ZKPNet: Verifiable Routing," LA-UR-23-29806).

Kita membutuhkan cara untuk membuktikan bahwa suatu jalur perutean itu valid tanpa harus mengungkapkan jalur itu sendiri atau data di dalamnya. Di sinilah Zero-Knowledge Proofs (ZKP) berperan. Bayangkan analogi "Waldo": Saya bisa membuktikan bahwa saya telah menemukan Waldo di peta dengan menunjukkannya melalui lubang kecil pada selembar karton raksasa. Saya membuktikan bahwa saya tahu di mana dia berada tanpa memperlihatkan sisa peta lainnya kepada Anda.

• Minimalisasi Data: ZKP memungkinkan sebuah node untuk membuktikan bahwa ia telah mengikuti protokol dan kebijakan tanpa membocorkan skema jaringan pribadi apa pun.
• Perlindungan Metadata: Berbeda dengan enkripsi biasa yang hanya menyembunyikan konten tetapi meninggalkan "jejak rekam" (IP, stempel waktu), ZKP dapat menyembunyikan identitas pengirim bahkan dari node yang memindahkan data tersebut.
• Verifikasi Tanpa Kepercayaan (Trustless Verification): Anda tidak perlu memercayai pemilik node; Anda cukup memercayai matematika. Jika bukti (proof) tidak tervalidasi, maka paket data tidak akan berpindah.

Dalam sektor keuangan, bank dapat menggunakan ZKP untuk merutekan transaksi melalui jaringan pihak ketiga guna menyamarkan asal-usul transaksi tanpa membiarkan jaringan tersebut melihat detail rekening. Di sektor layanan kesehatan, rumah sakit dapat membagikan catatan pasien melalui jaringan P2P di mana node perutean bahkan tidak bisa "melihat" klinik mana yang meminta data tersebut, sehingga memastikan kepatuhan terhadap undang-undang privasi yang ketat.

Sejujurnya, kondisi perutean internet saat ini adalah tumpukan metadata yang bocor dan jabat tangan yang hanya berlandaskan kata "percayalah pada kami". Namun, jika kita bisa mengganti kepercayaan tersebut dengan kepastian matematis, kita mungkin akhirnya bisa mendapatkan privasi yang selama ini dijanjikan.

Bagaimana ZKPNet dan NIAR Mengubah Peta Permainan

Kita telah memahami bahwa perutean internet saat ini pada dasarnya hanyalah serangkaian "janji manis" antar server. Jika kita ingin melangkah lebih jauh, kita membutuhkan perhitungan matematis nyata yang tidak membocorkan rahasia bisnis kita. Di sinilah ZKPNet dan NIAR (Network Infrastructure for Anonymous Routing) berperan. NIAR pada dasarnya adalah kerangka kerja yang memungkinkan kita membangun jalur anonim ini tanpa adanya otoritas pusat.

Biasanya, jika sebuah router ingin membuktikan bahwa ia dapat menjangkau suatu tujuan, ia harus menunjukkan tabel perutean atau skema internalnya kepada Anda. Ini adalah mimpi buruk keamanan bagi ISP atau jaringan rumah sakit. Jacob D. White dari Los Alamos National Laboratory (2023) memperkenalkan ZKPNet, sebuah pustaka berbasis bahasa Rust yang membuat "gadget" untuk atestasi ini.

• Jejak yang Sangat Kecil: Bukti-bukti (proofs) ini berukuran sangat kecil, terkadang hanya 224 bita menggunakan protokol groth16. Anda dapat menyematkannya ke dalam header tanpa merusak batas MTU (Maximum Transmission Unit) Anda.
• Keterjangkauan Satu Lompatan (Single-Hop): Sebuah node dapat membuktikan bahwa ia memiliki jalur valid ke "Router Y" tanpa harus menunjukkan secara persis berapa banyak lompatan (hops) yang dilalui atau seperti apa rupa alamat IP internalnya.
• Kompromi Performa: Latensi waktu nyata (real-time latency) adalah hambatan besar di sini. Tolok ukur pada chip M1 Max menunjukkan bahwa proses pembuktian membutuhkan waktu sekitar 468ms. Bagi satu paket data, 468ms adalah waktu yang sangat lama, jadi kita tidak menggunakannya untuk setiap bit data. Sebaliknya, ZKP digunakan untuk operasi control-plane—seperti saat mengatur jalur—sementara data aktual akan mengalir cepat setelah "kepercayaan" (trust) terjalin.

Kemudian ada sPAR (Somewhat Practical Anonymous Router), yang mencoba memperbaiki persyaratan "node jujur" dalam sistem seperti Tor. Sebagaimana dibahas oleh Debajyoti Das dan Jeongeun Park (2025), sPAR menggunakan multi-party fully homomorphic encryption (FHE) sehingga router itu sendiri pun tidak tahu ke mana ia mengirimkan data.

Bagian yang menarik adalah bagaimana sistem ini menghindari "masalah tabrakan" (collision problem). Jika banyak orang mencoba menggunakan slot bandwidth yang sama, data akan rusak. sPAR menggunakan strategi pilihan-dari-tiga—sebuah trik matematika ball-and-bins—di mana klien memilih tiga indeks acak dan pesan akan mendarat di indeks pertama yang tersedia.

• Penempatan Homomorfik: Server menempatkan paket Anda ke dalam sebuah "keranjang" tanpa pernah melihat indeks yang Anda pilih. Semuanya dilakukan saat data masih dalam kondisi terenkripsi.
• Batas Skalabilitas: Saat ini, sPAR belum akan menggantikan jaringan web global. Sistem ini mendukung sekitar 128 pengguna dengan latensi beberapa detik, menjadikannya sangat cocok untuk kebutuhan khusus seperti pencampuran transaksi kripto (crypto mixing) atau pengiriman pesan privat dalam jaringan lokal (LAN).

Bayangkan sebuah jaringan ritel yang perlu menyinkronkan inventaris. Dengan menggunakan perutean gaya sPAR, server pusat tidak dapat memetakan toko mana yang mengirimkan pembaruan data tertentu. Hal ini mencegah kompetitor mengendus lokasi mana yang paling menguntungkan hanya berdasarkan volume lalu lintas data yang masuk.

Penambangan bandwidth dan ekonomi jaringan berbasis token

Pernahkah Anda terpikir bagaimana koneksi internet di rumah hanya berdiam diri tanpa melakukan apa pun saat Anda sedang bekerja atau tidur? Pada dasarnya, itu adalah aset yang terbuang percuma, ibarat memiliki kamar kosong yang tidak pernah Anda sewakan.

Gerakan DePIN (Decentralized Physical Infrastructure Networks) mengubah paradigma ini dengan menciptakan konsep "Airbnb untuk bandwidth". Alih-alih hanya membayar tagihan bulanan ke penyedia layanan internet (ISP), Anda kini bisa mendapatkan imbalan kripto dengan membagikan koneksi yang tidak terpakai ke dalam jaringan P2P global.

Membangun VPN terdesentralisasi (dVPN) atau jaringan proksi yang mumpuni membutuhkan ribuan simpul (node) agar benar-benar berfungsi secara optimal. Untuk mendorong orang menjalankan node ini, berbagai proyek menggunakan insentif berbasis token. Anda menyediakan jalur koneksinya, dan jaringan akan membayar Anda dalam bentuk token utilitas.

Namun, ada hambatan teknis yang besar: bagaimana jaringan tahu bahwa Anda benar-benar menyediakan bandwidth berkualitas tinggi tanpa memata-matai lalu lintas data yang Anda teruskan? Jika sebuah node mulai mencatat data pengguna untuk "membuktikan" bahwa ia bekerja, maka aspek privasi dari VPN Web3 akan hilang seketika.

• Penambangan Bandwidth: Pengguna memasang aplikasi klien node ringan yang menyumbangkan kapasitas unggah ke dalam kolam (pool) jaringan. Imbalan biasanya dihitung berdasarkan waktu aktif (uptime), kecepatan transmisi (throughput), dan permintaan geografis.
• Bukti yang Menjaga Privasi: Di sinilah Zero-Knowledge Proofs (ZKP) menjadi penyelamat. Anda dapat membuktikan keterjangkauan dan kepatuhan protokol tanpa harus mengungkap isi paket data atau peta jaringan internal.
• Kualitas Layanan (QoS): Setiap node dapat memberikan "Bukti Bandwidth" (Proof of Bandwidth) yang menggunakan atestasi matematis untuk memverifikasi bahwa mereka tidak membatasi kecepatan (throttling) atau membuang paket data (blackholing).

Jika Anda ingin mengikuti perkembangan protokol VPN spesifik ini, mengunjungi SquirrelVPN untuk mendapatkan berita terbaru tentang teknologi VPN dan pembaruan keamanan adalah langkah yang tepat. Mereka terus memantau pergeseran dari pusat data terpusat menuju model node terdistribusi ini.

Aspek "ekonomi" dari sistem ini terjadi secara on-chain. Kontrak pintar (smart contract) bertindak sebagai perantara otomatis yang menangani pertukaran antara pengguna yang membutuhkan privasi dan penyedia node yang memiliki kelebihan bandwidth.

• Pembayaran P2P Otomatis: Alih-alih membayar langganan bulanan ke korporasi raksasa, Anda membayar sesuai dengan apa yang Anda gunakan. Kontrak pintar melepaskan pembayaran mikro (micro-payments) kepada penyedia node secara real-time.
• Ketahanan terhadap Serangan Sybil: Jika satu orang menjalankan 1.000 node palsu dari satu server tunggal, desentralisasi jaringan bisa hancur. Protokol proof-of-bandwidth—yang sering kali didukung oleh persyaratan pasak (staking)—membuat tindakan "berbohong" tentang sumber daya menjadi sangat mahal dan tidak menguntungkan.

Dalam contoh layanan kesehatan kita, sebuah klinik dapat membayar bandwidth di jaringan ini menggunakan token. Karena jaringan menggunakan logika sPAR yang telah dibahas sebelumnya, klinik tersebut mendapatkan anonimitas, dan penyedia node mendapatkan bayaran, semuanya terjadi tanpa ISP bisa melihat pola lalu lintas data antara klinik dan rumah sakit.

Bedah Tuntas Lapisan Protokol Teknis

Setelah kita membahas model ekonomi, kini saatnya beralih ke lapisan protokol teknis yang sebenarnya. Di bagian ini, kita akan mendalami mekanisme teknis bagaimana bukti-bukti keamanan ini disematkan ke dalam setiap paket data.

Terobosan utama di sini adalah penghapusan titik kegagalan tunggal (single point of failure). Dalam konfigurasi konvensional, satu entitas memegang kendali penuh atas kunci keamanan. Namun, dengan multi-party fully homomorphic encryption (fhe), kita dapat menghasilkan kunci publik bersama di mana secara harfiah tidak ada satu pun pihak yang mengetahui rahasia utamanya (master secret).

• Pembuatan Kunci Bersama (Joint Key Generation): Selama proses penyiapan, setiap partisipan membuat kunci rahasia mereka sendiri. Kunci-kunci ini kemudian digabungkan menjadi satu kunci publik tunggal ($pk$). Sebagaimana dipaparkan oleh Debajyoti Das dan Jeongeun Park (2025) dalam studi mereka mengenai sPAR, kunci rahasia utama hanyalah jumlah dari semua kunci individu. Namun, karena tidak ada yang membagikan kunci mereka, kunci "utuh" tersebut tidak pernah eksis di satu lokasi mana pun.
• RLWE (Ring Learning With Errors): Ini adalah fondasi matematisnya. Dalam bahasa awam, RLWE ibarat teka-teki kompleks di mana Anda menambahkan sedikit "gangguan" (noise) ke dalam data. Teka-teki ini sangat sulit dipecahkan secara terbalik oleh komputer, yang memberikan kita keamanan ind-cpa (artinya penyerang tidak dapat membedakan dua pesan terenkripsi yang berbeda, bahkan jika mereka menebak isi di dalamnya).

Struktur Paket: Tempat Bukti Berada

Lantas, di mana Zero-Knowledge Proof (ZKP) sebesar 224 bita tersebut ditempatkan? Dalam konfigurasi IPv6 modern, kita memanfaatkan Extension Headers. Secara spesifik, kita menggunakan header "Destination Options" yang dikustomisasi.

Dengan menempatkan bukti di dalam extension header, router yang tidak mendukung ZKPNet dapat tetap meneruskan paket tersebut secara normal. Namun, node yang "sadar ZKP" (ZKP-aware) akan memprosesnya, memverifikasi bukti dalam waktu 2,7 milidetik, dan kemudian meneruskannya. Jika bukti terdeteksi palsu, paket akan segera dibuang (dropped).

• Perlindungan Ekuivokasi (Equivocation Protection): Kita dapat mencegah node melakukan manipulasi dengan menanamkan riwayat percakapan ke dalam kunci. Dengan menggunakan hash dari riwayat komunikasi untuk memperbarui kunci publik di setiap putaran, jika server mencoba menunjukkan "realitas" yang berbeda kepada Alice dibandingkan kepada Bob, maka perhitungan matematisnya akan gagal atau tidak sinkron.
• Verifiable fhe: Alih-alih hanya mempercayai node untuk melakukan perhitungan dengan benar, kita menggunakan verifiable fhe. Ini berfungsi seperti struk digital yang membuktikan bahwa server telah mengikuti protokol secara tepat sesuai aturan.

Dalam skenario penggunaan ritel kami, lapisan teknis inilah yang memungkinkan 100 toko untuk menyinkronkan data secara aman. Strategi bin "pilihan-dari-tiga" (choice-of-three) memastikan bahwa meskipun penyerang mencegat paket dan memeriksa header IPv6, mereka tidak dapat mengetahui dari toko mana data tersebut berasal. Hal ini dikarenakan ZKP membuktikan bahwa jalur tersebut valid tanpa harus mengungkap identitas sumbernya.

Masa Depan DePIN dan Internet yang Resisten Terhadap Sensor

Jika kita jujur, internet saat ini pada dasarnya hanyalah sekumpulan "taman bertembok" (walled gardens) yang berpura-pura menjadi ruang publik global. Kita telah membahas bagaimana Zero-Knowledge Proof (ZKP) dan bandwidth P2P dapat memperbaiki sistem teknisnya, namun pertanyaan utamanya adalah bagaimana sistem ini dapat berskala ketika ada jutaan orang yang mencoba melakukan streaming video secara bersamaan.

Menskalakan protokol-protokol ini adalah bagian yang sangat rumit karena adanya "trilemma anonimitas". Secara umum, Anda harus memilih dua dari tiga aspek: privasi yang kuat, latensi rendah, atau beban bandwidth (overhead) yang rendah. Menganalisis sistem kompleks seperti Tor menunjukkan bahwa bahkan dengan kriptografi yang "sempurna" sekalipun, Anda tetap harus menghadapi serangan tingkat sistem seperti korelasi lalu lintas jika jaringan tidak cukup padat.

Hambatan terbesar bagi Jaringan Infrastruktur Fisik Terdesentralisasi (DePIN) adalah perbandingan antara "ukuran bukti" (proof size) versus "waktu pembuktian" (proving time). Jika setiap paket dalam VPN Web3 memerlukan bukti Groth16, perangkat router Anda akan mengalami overheat. Untuk mengatasi hal ini, kita beralih ke bukti rekursif (recursive proofs).

• SNARK Rekursif: Alih-alih memverifikasi 1.000 bukti paket individu, sebuah node dapat melakukan "roll up" atau merangkum bukti-bukti tersebut menjadi satu bukti meta tunggal. Ini seperti boneka Rusia (Matryoshka) di mana lapisan terluar membuktikan validitas semua yang ada di dalamnya.
• Penyusutan State: Teknik ini menjaga ukuran blockchain tetap terkendali. Alih-alih setiap node harus mengetahui seluruh riwayat jaringan, mereka hanya perlu memverifikasi bukti rekursif terbaru untuk memastikan bahwa tabel perutean (routing table) tersebut jujur dan valid.

Dunia bisnis mulai menyadari bahwa VPN terpusat adalah liabilitas bagi keamanan data. Penggunaan node yang terdistribusi membuat target serangan jauh lebih sulit untuk ditembus.

• Perutean Berbasis AI: Kita melihat pergeseran ke arah Software-Defined Networking (SDN) di mana agen AI memilih jalur yang paling tahan sensor secara real-time.
• Bypass ISP: Dengan melakukan tokenisasi konektivitas, kita pada dasarnya sedang membangun internet paralel. Ini bukan lagi sekadar menyembunyikan alamat IP Anda; ini tentang kepemilikan infrastruktur sehingga penyedia layanan internet (ISP) tidak bisa begitu saja memutus akses Anda hanya dengan menekan satu tombol.

Panduan Implementasi bagi Operator Node

Anda telah mempelajari teori dan perhitungan matematisnya, namun sekarang Anda mungkin bertanya-tanya bagaimana cara menjalankan node secara nyata. Jujur saja, menyiapkan node berbasis zero-knowledge proof (ZKP) adalah proyek akhir pekan yang cukup menantang, tetapi ini adalah satu-satunya cara untuk beralih dari sekadar "mempercayai penyedia VPN" menjadi "mempercayai hukum fisika."

Spesifikasi & Konfigurasi Node

Anda tidak memerlukan pusat data raksasa, namun Anda juga tidak bisa menjalankannya pada perangkat dengan spesifikasi rendah.

• Spesifikasi Minimum: Saya sarankan setidaknya menggunakan RAM 8GB dan CPU modern dengan 4 core.
• Jaringan: Koneksi serat optik simetris adalah kondisi ideal, namun setidaknya dibutuhkan kecepatan unggah (upstream) sebesar 20Mbps.

Inisialisasi Gadget Pembuktian (Proof Gadget)

Sebagian besar proyek dVPN modern menggunakan pustaka seperti arkworks atau bellman. Berikut adalah contoh kode semu (pseudo-code) tentang bagaimana sebuah node menginisialisasi gadget validasi jalur menggunakan logika ZKPNet:

// Kode semu untuk inisialisasi gadget perutean ZKP
use zkpnet_lib::{Prover, PathCircuit};

fn prove_path(secret_path: Vec<u8>, public_root: [u8; 32]) {
    // 1. Inisialisasi sirkuit dengan jalur perutean rahasia
    let circuit = PathCircuit {
        path: secret_path,
        root: public_root,
    };

    // 2. Menghasilkan bukti Groth16 (membutuhkan waktu ~468ms)
    let proof = Prover::prove(circuit, &params).expect("Proving failed");

    // 3. Menyematkan bukti 224-byte ke dalam IPv6 Extension Header
    packet.attach_header(0xZK, proof.to_bytes());
}

Saat Anda mengonfigurasi backend, ingatlah bahwa proving time (waktu pembuktian) adalah kendala utamanya—bisa memakan waktu hampir setengah detik. Jika Anda menyiapkan sistem ini, pastikan node Anda tidak mencoba membuktikan setiap paket data satu per satu. Sebaliknya, gunakan pembuktian probabilistik atau sistem batching (pengelompokan). Anda membuktikan bahwa Anda telah menangani satu jendela lalu lintas data dengan benar selama fase pengaturan jalur.

1. Masalah Double NAT: Jika node Anda berada di belakang dua router, penemuan peer-to-peer (P2P) akan gagal. Gunakan UPnP atau lakukan penerusan port (port forwarding) secara manual.
2. Penyimpangan Waktu (Clock Skew): Protokol ZKP dan blockchain sangat sensitif terhadap sinkronisasi waktu. Jalankan daemon NTP lokal.
3. Kebocoran IPv6: Banyak orang mengonfigurasi node VPN mereka untuk IPv4 tetapi lupa bahwa ISP mereka memberikan alamat IPv6.

Transisi dari internet terpusat ke internet terdesentralisasi berbasis ZKP memang akan penuh tantangan. Kita masih berjuang mengatasi masalah latensi dan "trilema anonimitas." Namun, kemajuannya sangat nyata. Baik Anda menjalankan node demi mendapatkan imbalan token atau karena Anda lelah dengan pengawasan ISP, Anda sedang berkontribusi membangun infrastruktur yang lebih tangguh. Ingatlah: selalu perbarui firmware Anda, pantau suhu CPU, dan demi apa pun, jangan sampai kehilangan kunci privat (private keys) Anda.