#dusk $DUSK
Frasa "emergency mode" terus muncul di whitepaper Dusk dan saya terus melangkah melewatinya. Saat akhirnya saya membaca bagiannya, mekanismenya ternyata lebih spesifik daripada yang disiratkan oleh namanya.
Konsensus normal Dusk: setiap putaran berjalan hingga maksimal 50 iterasi. Setiap langkah—Proposal, Validation, Ratification—memiliki batas waktu (timeout). Jika tidak ada kuorum yang terbentuk sebelum batas waktu, langkah tersebut dilewati dan akhirnya iterasi baru dimulai. Berurutan, terbatas, dapat diprediksi.
Emergency mode berbeda. Mode ini aktif setelah 16 iterasi berturut-turut gagal—di mana kegagalan berarti kuorum tidak tercapai, biasanya karena validator sedang offline atau terisolasi. Setelah dipicu: batas waktu langkah dinonaktifkan. Iterasi baru dimulai, tetapi setiap iterasi yang sedang berlangsung tetap aktif alih-alih ditutup. Banyak iterasi terbuka berjalan bersamaan. Ini meningkatkan peluang untuk menghasilkan sebuah blok. Namun juga meningkatkan peluang terjadinya fork.
Fork dalam emergency mode diselesaikan dengan memilih blok dari nomor iterasi terendah. Jika jaringan masih tidak bisa membentuk blok, pilihan terakhir adalah blok darurat: blok kosong, tanpa transaksi, ditandatangani oleh Dusk sebagai entitas menggunakan kunci publik globalnya. Penyedia yang memegang mayoritas porsi kepemilikan (stake) memintanya.
Jadi, mengapa jaringan tidak menjalankan emergency mode setiap kali ingin lebih cepat.
Mode normal mengorbankan sedikit kecepatan demi finalitas yang lebih bersih. Iterasi terbuka yang berjalan bersamaan meningkatkan kelangsungan (liveness) saat kondisi tertekan, tetapi memperkenalkan kompleksitas—fallback blok kosong adalah intervensi yang terpusat: rantai tetap bergerak, tetapi yang menggerakkannya adalah entitas Dusk.
Saya justru menganggap desain blok darurat sebagai pertanyaan yang lebih menarik—karena ini berarti jaminan liveness pada akhirnya bergantung pada ketersediaan dan kesediaan entitas Dusk untuk menandatangani. Keamanan protokol dan desentralisasi menarik ke arah yang sedikit berbeda di sini.
Yang belum saya lihat dijelaskan adalah apa yang terjadi pada transaksi yang sedang diproses ketika blok darurat menggantikan blok normal—apakah transaksi-transaksi tersebut disertakan lagi pada putaran berikutnya ataukah malah dibatalkan. @Dusk
$DUSK #dusk
Frasa "emergency mode" terus muncul di whitepaper Dusk dan saya terus melangkah melewatinya. Saat akhirnya saya membaca bagiannya, mekanismenya ternyata lebih spesifik daripada yang disiratkan oleh namanya.
Konsensus normal Dusk: setiap putaran berjalan hingga maksimal 50 iterasi. Setiap langkah—Proposal, Validation, Ratification—memiliki batas waktu (timeout). Jika tidak ada kuorum yang terbentuk sebelum batas waktu, langkah tersebut dilewati dan akhirnya iterasi baru dimulai. Berurutan, terbatas, dapat diprediksi.
Emergency mode berbeda. Mode ini aktif setelah 16 iterasi berturut-turut gagal—di mana kegagalan berarti kuorum tidak tercapai, biasanya karena validator sedang offline atau terisolasi. Setelah dipicu: batas waktu langkah dinonaktifkan. Iterasi baru dimulai, tetapi setiap iterasi yang sedang berlangsung tetap aktif alih-alih ditutup. Banyak iterasi terbuka berjalan bersamaan. Ini meningkatkan peluang untuk menghasilkan sebuah blok. Namun juga meningkatkan peluang terjadinya fork.
Fork dalam emergency mode diselesaikan dengan memilih blok dari nomor iterasi terendah. Jika jaringan masih tidak bisa membentuk blok, pilihan terakhir adalah blok darurat: blok kosong, tanpa transaksi, ditandatangani oleh Dusk sebagai entitas menggunakan kunci publik globalnya. Penyedia yang memegang mayoritas porsi kepemilikan (stake) memintanya.
Jadi, mengapa jaringan tidak menjalankan emergency mode setiap kali ingin lebih cepat.
Mode normal mengorbankan sedikit kecepatan demi finalitas yang lebih bersih. Iterasi terbuka yang berjalan bersamaan meningkatkan kelangsungan (liveness) saat kondisi tertekan, tetapi memperkenalkan kompleksitas—fallback blok kosong adalah intervensi yang terpusat: rantai tetap bergerak, tetapi yang menggerakkannya adalah entitas Dusk.
Saya justru menganggap desain blok darurat sebagai pertanyaan yang lebih menarik—karena ini berarti jaminan liveness pada akhirnya bergantung pada ketersediaan dan kesediaan entitas Dusk untuk menandatangani. Keamanan protokol dan desentralisasi menarik ke arah yang sedikit berbeda di sini.
Yang belum saya lihat dijelaskan adalah apa yang terjadi pada transaksi yang sedang diproses ketika blok darurat menggantikan blok normal—apakah transaksi-transaksi tersebut disertakan lagi pada putaran berikutnya ataukah malah dibatalkan. @Dusk
$DUSK #dusk
