Mari kita bahas performa blockchain: dari sepuluh orang, sembilan pertama biasanya langsung bereaksi ke TPS. Yang satu lagi mungkin memperhatikan latensi. Tapi proyek Dusk, kalau kamu buka whitepaper-nya dan telusuri dengan saksama, kamu akan menemukan satu hal yang jauh lebih layak diawasi daripada kecepatan transaksi—yaitu bagaimana antar node “berbicara”.
Biskuit saja, BTC turun tidak banyak!
Aku bilang ini bukan karena TPS tidak penting, melainkan karena “menghitung dengan cepat” dan “mengirim dengan cepat” itu benar-benar dua hal yang berbeda. Sekuat apa pun execution layer, sekecermat apa pun desain konsensusnya, kalau pesan di jaringan node malah macet—proposal tidak bisa sampai ke validator, hasil verifikasi tidak bisa kembali ke komite ratification—maka seluruh proses tiga tahap terpaksa menunggu. Jika blok terlambat beberapa detik, dampaknya ringan: pengalaman pengguna turun; dampaknya berat: node-node yang berbeda melihat blok kandidat yang berbeda, dan tingkat stale block pun meroket.
Dusk memilih jalur Kadcast. Ini bukan model broadcast seperti Gossip yang “asal kirim ke semua orang”. Kadcast membangun jaringan penutup terstruktur berbasis Kademlia DHT: jarak XOR antar ID node menentukan routing, dan pesan “mengembang” bertahap seperti pohon. Kedengarannya akademis, ya? Tapi inti logikanya sebenarnya cuma satu kalimat: setiap pesan hanya menempuh rute yang seharusnya, tidak melewati jalan yang tidak perlu.
Whitepaper mengutip riset yang menyebut bahwa Kadcast bisa menghemat 25% hingga 50% bandwidth dibanding Gossip. Misalnya, jika sebelumnya butuh 100 unit bandwidth, sekarang kira-kira 50 hingga 75 unit—tetapi angka itu tidak bisa diterjemahkan langsung menjadi “biaya node berkurang setengah”. Konfigurasi mesin tidak berubah, perhitungan proof tidak berubah, biaya penyimpanan tidak berubah; yang berubah cuma biaya transmisi di lapisan jaringan. Tapi kalau dipikir-pikir, untuk orang yang menjalankan node: bandwidth yang tinggal setengah itu artinya apa? Artinya, dengan kondisi bandwidth yang sama, kamu bisa menghubungkan lebih banyak node; atau dengan skala node yang sama, kamu tidak terlalu mudah tersendat karena biaya bandwidth.
Ada satu detail yang cukup menjelaskan semuanya. Di dokumentasi node, 9000/udp ditandai sebagai port wajib agar Kadcast bisa berjalan. Provisioner yang ingin ikut konsensus harus memastikan kanal ini bisa dijangkau; sementara 8080/tcp justru opsional, hanya diperlukan kalau kamu butuh endpoint untuk melakukan query. Dengan kata lain, Kadcast bukan hiasan pada diagram arsitektur—ia benar-benar menempel pada ambang batas agar sebuah node bisa ikut konsensus.
Orang yang familiar dengan broadcast P2P di BTC tahu bahwa cara pesan menyeberang jaringan node bukanlah hal sepele. @Dusk $DUSK #dusk
Biskuit saja, BTC turun tidak banyak!
Aku bilang ini bukan karena TPS tidak penting, melainkan karena “menghitung dengan cepat” dan “mengirim dengan cepat” itu benar-benar dua hal yang berbeda. Sekuat apa pun execution layer, sekecermat apa pun desain konsensusnya, kalau pesan di jaringan node malah macet—proposal tidak bisa sampai ke validator, hasil verifikasi tidak bisa kembali ke komite ratification—maka seluruh proses tiga tahap terpaksa menunggu. Jika blok terlambat beberapa detik, dampaknya ringan: pengalaman pengguna turun; dampaknya berat: node-node yang berbeda melihat blok kandidat yang berbeda, dan tingkat stale block pun meroket.
Dusk memilih jalur Kadcast. Ini bukan model broadcast seperti Gossip yang “asal kirim ke semua orang”. Kadcast membangun jaringan penutup terstruktur berbasis Kademlia DHT: jarak XOR antar ID node menentukan routing, dan pesan “mengembang” bertahap seperti pohon. Kedengarannya akademis, ya? Tapi inti logikanya sebenarnya cuma satu kalimat: setiap pesan hanya menempuh rute yang seharusnya, tidak melewati jalan yang tidak perlu.
Whitepaper mengutip riset yang menyebut bahwa Kadcast bisa menghemat 25% hingga 50% bandwidth dibanding Gossip. Misalnya, jika sebelumnya butuh 100 unit bandwidth, sekarang kira-kira 50 hingga 75 unit—tetapi angka itu tidak bisa diterjemahkan langsung menjadi “biaya node berkurang setengah”. Konfigurasi mesin tidak berubah, perhitungan proof tidak berubah, biaya penyimpanan tidak berubah; yang berubah cuma biaya transmisi di lapisan jaringan. Tapi kalau dipikir-pikir, untuk orang yang menjalankan node: bandwidth yang tinggal setengah itu artinya apa? Artinya, dengan kondisi bandwidth yang sama, kamu bisa menghubungkan lebih banyak node; atau dengan skala node yang sama, kamu tidak terlalu mudah tersendat karena biaya bandwidth.
Ada satu detail yang cukup menjelaskan semuanya. Di dokumentasi node, 9000/udp ditandai sebagai port wajib agar Kadcast bisa berjalan. Provisioner yang ingin ikut konsensus harus memastikan kanal ini bisa dijangkau; sementara 8080/tcp justru opsional, hanya diperlukan kalau kamu butuh endpoint untuk melakukan query. Dengan kata lain, Kadcast bukan hiasan pada diagram arsitektur—ia benar-benar menempel pada ambang batas agar sebuah node bisa ikut konsensus.
Orang yang familiar dengan broadcast P2P di BTC tahu bahwa cara pesan menyeberang jaringan node bukanlah hal sepele. @Dusk $DUSK #dusk