#dusk $DUSK @Dusk
Awalnya saya mengira batas 50 iterasi Dusk hanyalah langit-langit teknis. Semakin saya melihatnya, semakin terasa seperti jendela kecil tentang bagaimana jaringan menangani perselisihan.
Konsensus Dusk dirancang untuk bergerak melalui proposal, validasi, dan ratifikasi, dengan provisioner dipilih melalui sortisi deterministik. Tetapi ketika pesan datang terlambat, provisioner menghilang, atau komunikasi menjadi berantakan, konsensus tidak langsung menyerah. Ia diberi lebih banyak kesempatan untuk mencapai konvergensi.
Itu mengubah cara saya membaca angka tersebut.
Ini sebenarnya bukan soal “50 percobaan”. Lebih terasa seperti anggaran kesabaran ketika jaringan berhenti berperilaku normal.
Saya juga menemukan pekerjaan Dusk terkait cara menghentikan lebih cepat iterasi yang waktunya habis dan mem-ropagasi ulang pesan dari iterasi masa lalu atau masa depan itu menarik. Menurut saya, itu menunjukkan masalah yang kurang terlihat: pemulihan bukan sekadar soal mencoba lagi, melainkan membuat upaya tambahan tersebut menjadi berguna.
Dan di situlah komprominya menjadi menarik.
Terlalu sedikit iterasi bisa membuat gangguan sementara terlihat seperti kegagalan. Terlalu banyak bisa membuat jaringan menghabiskan waktu mengejar kesepakatan sementara latensi terus bertambah.
Jadi saya terus kembali ke ini:
Seberapa besar perselisihan yang bisa ditoleransi Dusk sebelum mekanisme yang dirancang untuk memulihkannya justru menjadi sumber keterlambatan?
@Dusk #dusk $DUSK
Awalnya saya mengira batas 50 iterasi Dusk hanyalah langit-langit teknis. Semakin saya melihatnya, semakin terasa seperti jendela kecil tentang bagaimana jaringan menangani perselisihan.
Konsensus Dusk dirancang untuk bergerak melalui proposal, validasi, dan ratifikasi, dengan provisioner dipilih melalui sortisi deterministik. Tetapi ketika pesan datang terlambat, provisioner menghilang, atau komunikasi menjadi berantakan, konsensus tidak langsung menyerah. Ia diberi lebih banyak kesempatan untuk mencapai konvergensi.
Itu mengubah cara saya membaca angka tersebut.
Ini sebenarnya bukan soal “50 percobaan”. Lebih terasa seperti anggaran kesabaran ketika jaringan berhenti berperilaku normal.
Saya juga menemukan pekerjaan Dusk terkait cara menghentikan lebih cepat iterasi yang waktunya habis dan mem-ropagasi ulang pesan dari iterasi masa lalu atau masa depan itu menarik. Menurut saya, itu menunjukkan masalah yang kurang terlihat: pemulihan bukan sekadar soal mencoba lagi, melainkan membuat upaya tambahan tersebut menjadi berguna.
Dan di situlah komprominya menjadi menarik.
Terlalu sedikit iterasi bisa membuat gangguan sementara terlihat seperti kegagalan. Terlalu banyak bisa membuat jaringan menghabiskan waktu mengejar kesepakatan sementara latensi terus bertambah.
Jadi saya terus kembali ke ini:
Seberapa besar perselisihan yang bisa ditoleransi Dusk sebelum mekanisme yang dirancang untuk memulihkannya justru menjadi sumber keterlambatan?
@Dusk #dusk $DUSK