#dusk $DUSK @Dusk $DUSK

Proposal, Validasi, Ratifikasi: Jalur Tiga Langkah Dusk menuju Blok Final

awalnya aku mengira finalitas blok di Dusk bekerja seperti satu suara saja — mengusulkan, mengonfirmasi, selesai.

ternyata itu tiga langkah terpisah, dan aku harus menelusuri satu per satu untuk memahami alasannya.

langkah Proposal memilih satu penyedia, melalui sortisi deterministik, untuk menghasilkan kandidat blok dan menyiarkannya. jika tidak ada yang datang sebelum batas waktu, iterasi itu saja yang gagal — tidak ada kandidat, dan sejauh yang bisa kulihat dari dokumentasi, tidak ada langkah generator cadangan yang mengambil alih.

lalu aku menelusuri apa yang terjadi berikutnya. outputnya masuk ke Validation: sebuah komite baru, yang juga dipilih secara acak, memeriksa kandidat terhadap ujung (tip) rantai saat ini dan memberikan suara Valid atau Invalid. kuorum membutuhkan dua pertiga suara Valid, atau mayoritas sederhana yang memilih Invalid — salah satu ambang ini mengakhiri langkah.

langkah ketiga, dan ini yang hampir kulupakan: Ratification. masih komite lain, yang memilih secara khusus apakah Validation benar-benar mencapai kuorum yang nyata, bukan memeriksa konten blok lagi. aturan dua pertiga-atau-mayoritas yang sama juga berlaku di sini.

tiga komite, tiga penilaian berbeda — aku tidak menemukan ada langkah yang mengulang pekerjaan yang sudah dilakukan oleh langkah sebelumnya.

yang menonjol bagiku adalah seberapa besar pengujian (scrutiny) yang dilakukan sebelum mainnet. Dusk menjalankan sepuluh audit di seluruh tumpukan teknologinya, dengan laporan lebih dari dua ratus halaman. salah satu dari sepuluh audit itu, dari Oak Security, membahas SA secara spesifik, menyoroti masalah terkait insentif slashing dan logika voting — semuanya yang kritis sudah diselesaikan sebelum peluncuran.

jadi, “memfinalkan sebuah blok” tidaklah satu keputusan, sejauh yang bisa kupahami. ini tiga pemeriksaan yang diverifikasi secara independen yang ditumpuk berurutan, dan masing-masing mampu memulai ulang proses — hingga lima puluh iterasi per putaran — jika tidak lolos.

apakah tingkat pengawasan pra-peluncuran seperti ini benar-benar mengurangi risiko di sini, atau itu hanya berarti bahwa setiap kekurangan yang lolos justru menjadi lebih sulit ditemukan belakangan?