Kami mengalami pemadaman bergilir di Islamabad minggu lalu, ketika jaringan terus gagal berulang kali, dan setiap kali jaringan kembali, sistem cadangan harus memulai ulang dari awal, bukan melanjutkan dari titik terakhir. Saya mengira mode darurat Dusk bekerja dengan cara yang sama—macet jaringan, lalu sistem terus mencoba lagi dengan timeout tetap yang sama sampai ada yang berhasil.
Tapi kenyataannya tidak begitu. Mode darurat baru aktif setelah 16 iterasi berturut-turut gagal, dan begitu aktif, seluruh struktur timeout dihapus. Iterasi tidak kedaluwarsa lagi; iterasi berjalan terus tanpa batas sampai sebuah blok kandidat benar-benar diajukan dan mencapai kuorum pada tahap validasi serta ratifikasi. Vote NoCandidate dan NoQuorum juga dinonaktifkan, jadi setiap langkah harus benar-benar berhasil sebelum langkah berikutnya dimulai.
Yang benar-benar membuat saya memahami ini adalah bahwa beberapa iterasi terbuka bisa berjalan sekaligus. Itu bukan cacat, melainkan disengaja—untuk meningkatkan peluang setidaknya satu di antaranya menghasilkan blok yang valid. Konsekuensinya adalah risiko fork yang lebih besar, yang diselesaikan dengan selalu memilih kandidat yang mencapai konsensus pada nomor iterasi paling rendah.
Ada juga upaya terakhir di dalam upaya terakhir. Jika bahkan iterasi terakhir macet, provisioner yang memegang mayoritas dari total stake dapat meminta sebuah blok darurat—blok kosong khusus yang ditandatangani Dusk tanpa transaksi di dalamnya—hanya untuk menjaga ronde tetap berjalan.
Yang tidak disebutkan dalam whitepaper adalah seberapa sering ini sebenarnya pernah terpicu pada infrastruktur Dusk yang nyata sejauh ini. Saya tidak punya data untuk mendukung klaim frekuensi.
Uji nyata bagi DUSK adalah seberapa jarang mode darurat perlu dipanggil begitu mainnet berjalan pada skala nyata.
Ada yang benar-benar menyaksikan mode darurat terpicu di Dusk sejauh ini?
@Dusk #dusk $DUSK
Tapi kenyataannya tidak begitu. Mode darurat baru aktif setelah 16 iterasi berturut-turut gagal, dan begitu aktif, seluruh struktur timeout dihapus. Iterasi tidak kedaluwarsa lagi; iterasi berjalan terus tanpa batas sampai sebuah blok kandidat benar-benar diajukan dan mencapai kuorum pada tahap validasi serta ratifikasi. Vote NoCandidate dan NoQuorum juga dinonaktifkan, jadi setiap langkah harus benar-benar berhasil sebelum langkah berikutnya dimulai.
Yang benar-benar membuat saya memahami ini adalah bahwa beberapa iterasi terbuka bisa berjalan sekaligus. Itu bukan cacat, melainkan disengaja—untuk meningkatkan peluang setidaknya satu di antaranya menghasilkan blok yang valid. Konsekuensinya adalah risiko fork yang lebih besar, yang diselesaikan dengan selalu memilih kandidat yang mencapai konsensus pada nomor iterasi paling rendah.
Ada juga upaya terakhir di dalam upaya terakhir. Jika bahkan iterasi terakhir macet, provisioner yang memegang mayoritas dari total stake dapat meminta sebuah blok darurat—blok kosong khusus yang ditandatangani Dusk tanpa transaksi di dalamnya—hanya untuk menjaga ronde tetap berjalan.
Yang tidak disebutkan dalam whitepaper adalah seberapa sering ini sebenarnya pernah terpicu pada infrastruktur Dusk yang nyata sejauh ini. Saya tidak punya data untuk mendukung klaim frekuensi.
Uji nyata bagi DUSK adalah seberapa jarang mode darurat perlu dipanggil begitu mainnet berjalan pada skala nyata.
Ada yang benar-benar menyaksikan mode darurat terpicu di Dusk sejauh ini?
@Dusk #dusk $DUSK
