Saya melacak bagaimana Dusk memindahkan blok di seluruh jaringan, mengira cerita banjir gosip yang biasa. Tapi saya malah menemukan sesuatu yang lebih sempit dan lebih disengaja.
Kadcast tidak membanjiri. Ia merutekan. Dengan struktur jarak XOR milik Kademlia, setiap node meneruskan data melalui jalur deterministik ke bucket-bucket peer tertentu, bukan ke semua orang. Itulah kisah efisiensi yang biasanya orang berhenti sampai di situ.
Namun perutean yang terstruktur punya kelemahan yang jelas: jika sebuah node di jalur tersebut mati, apakah pesan langsung lenyap di sana? Di situlah saya melambatkan langkah. Kadcast tidak hanya bergantung pada satu jalur per bucket — ia menggunakan parameter redundansi, β, yang memilih beberapa delegasi per bucket untuk menerima dan meneruskan ulang potongan data yang sama. Jika satu hilang, yang lain tetap membawanya.
Lalu ada RaptorQ, ditambahkan sebagai forward error correction: data dienkode sehingga penerima dapat merekonstruksi data asli dari fragmen-fragmen yang sebagian, tanpa harus setiap paket tiba dengan utuh.
Jadi ketahanan itu sebenarnya bukan soal node "tetap hidup". Melainkan soal protokol yang mengasumsikan mereka tidak akan selalu tersedia, dan membangun redundansi ke dalam struktur jalur itu sendiri, bukan ke dalam banjir buta.
Membuat saya bertanya-tanya bagaimana β disetel saat set validator membesar: biaya redundansi makin besar untuk bandwidth, sementara biaya yang lebih kecil untuk reliabilitas. Di skala besar, di mana Dusk benar-benar menarik garis itu?
#dusk $DUSK @Dusk
Kadcast tidak membanjiri. Ia merutekan. Dengan struktur jarak XOR milik Kademlia, setiap node meneruskan data melalui jalur deterministik ke bucket-bucket peer tertentu, bukan ke semua orang. Itulah kisah efisiensi yang biasanya orang berhenti sampai di situ.
Namun perutean yang terstruktur punya kelemahan yang jelas: jika sebuah node di jalur tersebut mati, apakah pesan langsung lenyap di sana? Di situlah saya melambatkan langkah. Kadcast tidak hanya bergantung pada satu jalur per bucket — ia menggunakan parameter redundansi, β, yang memilih beberapa delegasi per bucket untuk menerima dan meneruskan ulang potongan data yang sama. Jika satu hilang, yang lain tetap membawanya.
Lalu ada RaptorQ, ditambahkan sebagai forward error correction: data dienkode sehingga penerima dapat merekonstruksi data asli dari fragmen-fragmen yang sebagian, tanpa harus setiap paket tiba dengan utuh.
Jadi ketahanan itu sebenarnya bukan soal node "tetap hidup". Melainkan soal protokol yang mengasumsikan mereka tidak akan selalu tersedia, dan membangun redundansi ke dalam struktur jalur itu sendiri, bukan ke dalam banjir buta.
Membuat saya bertanya-tanya bagaimana β disetel saat set validator membesar: biaya redundansi makin besar untuk bandwidth, sementara biaya yang lebih kecil untuk reliabilitas. Di skala besar, di mana Dusk benar-benar menarik garis itu?
#dusk $DUSK @Dusk