Jika sebuah transaksi berangkat dari tangan Anda, ujian sesungguhnya bukan seberapa cepat mesin lokal Anda, melainkan apakah pesan tersebut bisa sampai dengan rapi ke node yang membutuhkannya. Pengguna tidak melihat perjalanan ini, tetapi perjalanan inilah yang memengaruhi mengapa konsensus bisa lambat, dan mengapa pemrosesan yang sama bisa terjadi berulang.
Anggap jaringan seperti sebuah kota: cara yang paling kasar adalah setiap persimpangan menyalin pemberitahuan yang sama dan mengirimkannya ke semua persimpangan tetangga. Memang pemberitahuan bisa tersebar, tetapi biayanya adalah duplikasi yang sangat besar. Gagasan Kadcast bukan membuat setiap node berteriak sekali, melainkan memanfaatkan jarak di Kademlia dan jarak berbasis XOR untuk menyusun hubungan penerusan yang terstruktur, sehingga mengurangi penyebaran tanpa pandang bulu (flooding).
Di sini yang paling penting bukan “seberapa dekat Dusk dengan target”, melainkan Anda akhirnya memiliki pertanyaan yang lebih tepat: di mana letak biaya untuk menutupi (meliputi) pesan? Waktu eksekusi hanya menjawab seberapa cepat node memproses sesuatu; jalur penyebaran harus menjawab bagaimana pesan dikirim ke node lain. Jika dua sisi perhitungan ini tidak dilihat lengkap, Anda tidak bisa menganggap hasil parsial sebagai performa keseluruhan.
Tentu saja, di whitepaper, Kadcast adalah desain mekanisme, bukan laporan benchmark untuk mainnet saat ini. Ukuran node, fluktuasi jaringan, dan jalur aktual semuanya dapat mengubah hasil akhir. Lihat @Dusk —saya akan lebih dulu menggambar jalur tersebut, baru menilai apakah konsensus tersendat karena broadcast berulang. $DUSK adalah token asli jaringan; tidak bisa dijadikan bukti untuk gambar ini. #dusk juga sebaiknya membahas dari awal bagaimana pesan sampai.
Dari sudut pandang penggunaan biasa, pesan konfirmasi tidak muncul begitu saja—ia harus melalui propagasi, penerimaan, dan pemrosesan berulang. Kita tentu tidak bisa menarik kesimpulan langsung untuk mainnet hanya dari whitepaper, tetapi kita bisa memastikan pertanyaannya benar terlebih dahulu: jika sebuah execution engine masih menerapkan cara cakupan pesan yang tidak efisien, lapisan mana yang akan menyeret pengalaman akhir yang dilihat pengguna? Memasukkan jalur ke dalam performa adalah bagian yang layak diamati dari mekanisme ini.
Lihat jalurnya dulu, baru lihat angkanya; urutannya tidak boleh dibalik. Jangan hanya fokus pada kecepatan eksekusi.
Anggap jaringan seperti sebuah kota: cara yang paling kasar adalah setiap persimpangan menyalin pemberitahuan yang sama dan mengirimkannya ke semua persimpangan tetangga. Memang pemberitahuan bisa tersebar, tetapi biayanya adalah duplikasi yang sangat besar. Gagasan Kadcast bukan membuat setiap node berteriak sekali, melainkan memanfaatkan jarak di Kademlia dan jarak berbasis XOR untuk menyusun hubungan penerusan yang terstruktur, sehingga mengurangi penyebaran tanpa pandang bulu (flooding).
Di sini yang paling penting bukan “seberapa dekat Dusk dengan target”, melainkan Anda akhirnya memiliki pertanyaan yang lebih tepat: di mana letak biaya untuk menutupi (meliputi) pesan? Waktu eksekusi hanya menjawab seberapa cepat node memproses sesuatu; jalur penyebaran harus menjawab bagaimana pesan dikirim ke node lain. Jika dua sisi perhitungan ini tidak dilihat lengkap, Anda tidak bisa menganggap hasil parsial sebagai performa keseluruhan.
Tentu saja, di whitepaper, Kadcast adalah desain mekanisme, bukan laporan benchmark untuk mainnet saat ini. Ukuran node, fluktuasi jaringan, dan jalur aktual semuanya dapat mengubah hasil akhir. Lihat @Dusk —saya akan lebih dulu menggambar jalur tersebut, baru menilai apakah konsensus tersendat karena broadcast berulang. $DUSK adalah token asli jaringan; tidak bisa dijadikan bukti untuk gambar ini. #dusk juga sebaiknya membahas dari awal bagaimana pesan sampai.
Dari sudut pandang penggunaan biasa, pesan konfirmasi tidak muncul begitu saja—ia harus melalui propagasi, penerimaan, dan pemrosesan berulang. Kita tentu tidak bisa menarik kesimpulan langsung untuk mainnet hanya dari whitepaper, tetapi kita bisa memastikan pertanyaannya benar terlebih dahulu: jika sebuah execution engine masih menerapkan cara cakupan pesan yang tidak efisien, lapisan mana yang akan menyeret pengalaman akhir yang dilihat pengguna? Memasukkan jalur ke dalam performa adalah bagian yang layak diamati dari mekanisme ini.
Lihat jalurnya dulu, baru lihat angkanya; urutannya tidak boleh dibalik. Jangan hanya fokus pada kecepatan eksekusi.