Saya meninjau kembali whitepaper Dusk malam tadi, dengan fokus pada bagian mode darurat, fallback, dan rolling finality. Detailnya ternyata lebih bernuansa daripada yang awalnya saya kira.

Mode darurat aktif setelah 16 iterasi gagal. Timeout langkah kemudian dinonaktifkan, dan iterasi terbuka berlanjut hingga sebuah blok kandidat mencapai kuorum pada validasi dan ratifikasi. Beberapa iterasi dapat berjalan sekaligus, yang meningkatkan peluang menghasilkan sebuah blok, tetapi juga meningkatkan kemungkinan terjadinya fork. Jika beberapa kandidat mencapai kesepakatan, iterasi dengan nilai terendah yang dipilih. Pada iterasi terakhir, provisioner dapat meminta blok darurat, tetapi diperlukan provisioner yang memegang mayoritas dari total aset jaringan.

Aturan fallback juga menarik perhatian saya: sebuah blok dari iterasi J > 0 berpotensi digantikan oleh blok dengan iterasi lebih rendah yang kemudian mencapai konsensus, sementara iterasi 0 tidak dapat digantikan dengan cara ini.

Lalu rolling finality menambah lapisan lain. Jika n iterasi sebelumnya gagal dalam attestation, sebuah blok diterima dan perlu 2×n blok berturut-turut yang ter-attestasi atau terkonfirmasi agar menjadi terkonfirmasi. Contoh di paper menggunakan iterasi 5, n=2, yang berarti diperlukan 4 blok lagi.

Saya masih bertanya-tanya: apakah desain ini menimbulkan risiko sentralisasi yang berarti terkait pemulihan darurat berbobot aset?

@Dusk #dusk $DUSK