Tadi malam jam 10:00 aku tidak bisa tidur, lalu aku membuka lagi buku putih “$DUSK ” bagian 2 yang membahas tabel routing Kadcast: berdasarkan jarak XOR dibagi ke dalam bucket, dan setiap bucket menyimpan banyak node setara.
Awalnya aku tidak langsung paham satu hal. ID node berukuran 160 bit, secara teori rentang jaraknya sangat besar—lalu bagaimana strategi pembagian bucket menentukan batas-batasnya? Dalam Kademlia, setiap segmen jarak memiliki satu bucket: semakin dekat dengan kita, bucket-nya semakin kecil; semakin jauh, bucket-nya semakin besar.
Desain ini dipakai lagi dalam Kadcast, tapi ada satu bagian yang baru kusadari setelah membacanya dua kali. Broadcast Kadcast tidak mengirim ke semua node di seluruh bucket; ia hanya meneruskan ke node terpilih dengan jarak XOR yang meningkat. Artinya, setiap node hanya bertugas meneruskan pesan ke “lapisan” yang lebih jauh dari dirinya, tanpa difusi ke samping.
Keuntungan dari logika ini baru aku pahami kemudian. Ia mengubah difusi pesan Gossip tradisional menjadi pesan seperti “estafet”: setiap node hanya melakukan sekali penerusan, tidak melakukan forward berulang. Namun, cara ini menuntut akurasi tabel routing yang sangat tinggi. Jika suatu node sedang offline sementara tabel routing tidak sempat diperbarui, pesan bisa terputus. Buku putih mengatakan bahwa desain redundansi di dalam bucket dapat mengatasi masalah ini, tapi aku belum melihat data spesifik—misalnya berapa banyak peer yang harus disimpan dalam satu bucket, dan berapa interval refresh-nya.
Setelah membaca keseluruhan teks, aku teringat satu pertanyaan. “@Dusk ” sedang melakukan transaksi privat sekaligus membangun P2P privat—di antara dua lapisan ini ada semacam hubungan. Lapisan transaksi menggunakan Phoenix untuk menyembunyikan isi transaksi, sedangkan lapisan jaringan menggunakan Kadcast untuk menyembunyikan jalur penyebaran. Kalau hanya melakukan salah satu lapisan, sementara lapisan lainnya tidak, penyerang bisa menemukan celah dari lapisan yang tidak dilindungi. Misalnya, lapisan transaksi menyembunyikan jumlah menggunakan zk-SNARKs, tetapi lapisan jaringan memakai Gossip standar, alamat IP dan waktu penyebaran masih bisa mengungkap aktivitas transaksi. Keberadaan Kadcast membuat lapisan jaringan tidak menjadi titik lemah dalam rantai privasi—penilaian ini lebih menunjukkan nilainya dibanding sekadar optimasi efisiensi broadcast.
#dusk
Namun, biaya dari pendekatan ini adalah kompleksitas pemeliharaan tabel routing. Jika skala jaringan besar dan node sering masuk/keluar, apakah Kadcast bisa mempertahankan efek tersebut? Aku masih perlu melihat lebih banyak materi untuk menilainya. Buku putih saat ini belum menyediakan data jangka panjang
Awalnya aku tidak langsung paham satu hal. ID node berukuran 160 bit, secara teori rentang jaraknya sangat besar—lalu bagaimana strategi pembagian bucket menentukan batas-batasnya? Dalam Kademlia, setiap segmen jarak memiliki satu bucket: semakin dekat dengan kita, bucket-nya semakin kecil; semakin jauh, bucket-nya semakin besar.
Desain ini dipakai lagi dalam Kadcast, tapi ada satu bagian yang baru kusadari setelah membacanya dua kali. Broadcast Kadcast tidak mengirim ke semua node di seluruh bucket; ia hanya meneruskan ke node terpilih dengan jarak XOR yang meningkat. Artinya, setiap node hanya bertugas meneruskan pesan ke “lapisan” yang lebih jauh dari dirinya, tanpa difusi ke samping.
Keuntungan dari logika ini baru aku pahami kemudian. Ia mengubah difusi pesan Gossip tradisional menjadi pesan seperti “estafet”: setiap node hanya melakukan sekali penerusan, tidak melakukan forward berulang. Namun, cara ini menuntut akurasi tabel routing yang sangat tinggi. Jika suatu node sedang offline sementara tabel routing tidak sempat diperbarui, pesan bisa terputus. Buku putih mengatakan bahwa desain redundansi di dalam bucket dapat mengatasi masalah ini, tapi aku belum melihat data spesifik—misalnya berapa banyak peer yang harus disimpan dalam satu bucket, dan berapa interval refresh-nya.
Setelah membaca keseluruhan teks, aku teringat satu pertanyaan. “@Dusk ” sedang melakukan transaksi privat sekaligus membangun P2P privat—di antara dua lapisan ini ada semacam hubungan. Lapisan transaksi menggunakan Phoenix untuk menyembunyikan isi transaksi, sedangkan lapisan jaringan menggunakan Kadcast untuk menyembunyikan jalur penyebaran. Kalau hanya melakukan salah satu lapisan, sementara lapisan lainnya tidak, penyerang bisa menemukan celah dari lapisan yang tidak dilindungi. Misalnya, lapisan transaksi menyembunyikan jumlah menggunakan zk-SNARKs, tetapi lapisan jaringan memakai Gossip standar, alamat IP dan waktu penyebaran masih bisa mengungkap aktivitas transaksi. Keberadaan Kadcast membuat lapisan jaringan tidak menjadi titik lemah dalam rantai privasi—penilaian ini lebih menunjukkan nilainya dibanding sekadar optimasi efisiensi broadcast.
#dusk
Namun, biaya dari pendekatan ini adalah kompleksitas pemeliharaan tabel routing. Jika skala jaringan besar dan node sering masuk/keluar, apakah Kadcast bisa mempertahankan efek tersebut? Aku masih perlu melihat lebih banyak materi untuk menilainya. Buku putih saat ini belum menyediakan data jangka panjang