"Tunggu 12 konfirmasi" adalah saran standar di sebagian besar chain, dan jujur saja tidak ada yang pernah menjelaskan mengapa 12, atau apa sebenarnya yang terjadi selama blok-blok tersebut. Dusk sama sekali tidak menggunakan jalan pintas itu — ia menjalankan state machine yang benar untuk menentukan kapan sebuah blok aman.
Sebuah blok bergerak melalui empat state: accepted, attested, confirmed, final. Titik awalnya bergantung pada satu angka — berapa banyak iterasi sebelumnya pada ronde tersebut gagal sebelum iterasi dari blok ini berhasil. Paper menyebutnya n. Jika n = 0, artinya blok mendarat pada iterasi pertama tanpa kegagalan apa pun sebelum itu, maka blok tersebut langsung ditandai sebagai attested. Jika n lebih besar dari 0, artinya iterasi sebelumnya pada ronde itu gagal terlebih dahulu, maka blok tersebut hanya ditandai sebagai accepted, yaitu state yang lebih lemah.
Perbedaannya penting karena blok yang accepted masih bisa digantikan oleh blok lain yang bersaing dari iterasi yang lebih rendah — jadi belum aman. Blok attested tidak bisa diganti dengan cara itu, karena tidak ada iterasi yang lebih rendah lagi yang bisa mengalahkannya. Dari situ, confirmed berarti saja bahwa sebuah blok memiliki cukup blok successor yang tepat bertumpuk di atasnya, dan final berarti seluruh rantai leluhur (ancestors) juga final, sehingga mengunci statusnya secara permanen.
Bagian yang menurutku benar-benar kurang dihargai di sini adalah contoh yang ada di paper itu sendiri: sebuah blok pada iterasi 5, ketika hanya dua dari iterasi sebelumnya yang memiliki fail attestation, ditandai sebagai accepted dan membutuhkan empat blok attested atau confirmed lagi yang bertumpuk di atasnya sebelum menjadi confirmed. Itu bukan angka konfirmasi yang diambil sembarangan dari mana pun; angka itu dihitung langsung dari seberapa kacau ronde tertentu tersebut. Ronde yang bersih akan selesai lebih cepat. Ronde yang kasar akan memakan lebih lama. Ini model yang sangat berbeda daripada "pokoknya tunggu 12 blok tanpa peduli apa yang terjadi."
Kalau jujur, ini terasa seperti detail desain yang jauh lebih penting bagi institusi yang menilai settlement finality dibandingkan bagi trader ritel — tidak ada yang peduli dengan jumlah iterasi saat menukar token, tetapi bank yang menjalankan settlement sekuritas jelas akan peduli.
@Dusk
$DUSK
#dusk
Sebuah blok bergerak melalui empat state: accepted, attested, confirmed, final. Titik awalnya bergantung pada satu angka — berapa banyak iterasi sebelumnya pada ronde tersebut gagal sebelum iterasi dari blok ini berhasil. Paper menyebutnya n. Jika n = 0, artinya blok mendarat pada iterasi pertama tanpa kegagalan apa pun sebelum itu, maka blok tersebut langsung ditandai sebagai attested. Jika n lebih besar dari 0, artinya iterasi sebelumnya pada ronde itu gagal terlebih dahulu, maka blok tersebut hanya ditandai sebagai accepted, yaitu state yang lebih lemah.
Perbedaannya penting karena blok yang accepted masih bisa digantikan oleh blok lain yang bersaing dari iterasi yang lebih rendah — jadi belum aman. Blok attested tidak bisa diganti dengan cara itu, karena tidak ada iterasi yang lebih rendah lagi yang bisa mengalahkannya. Dari situ, confirmed berarti saja bahwa sebuah blok memiliki cukup blok successor yang tepat bertumpuk di atasnya, dan final berarti seluruh rantai leluhur (ancestors) juga final, sehingga mengunci statusnya secara permanen.
Bagian yang menurutku benar-benar kurang dihargai di sini adalah contoh yang ada di paper itu sendiri: sebuah blok pada iterasi 5, ketika hanya dua dari iterasi sebelumnya yang memiliki fail attestation, ditandai sebagai accepted dan membutuhkan empat blok attested atau confirmed lagi yang bertumpuk di atasnya sebelum menjadi confirmed. Itu bukan angka konfirmasi yang diambil sembarangan dari mana pun; angka itu dihitung langsung dari seberapa kacau ronde tertentu tersebut. Ronde yang bersih akan selesai lebih cepat. Ronde yang kasar akan memakan lebih lama. Ini model yang sangat berbeda daripada "pokoknya tunggu 12 blok tanpa peduli apa yang terjadi."
Kalau jujur, ini terasa seperti detail desain yang jauh lebih penting bagi institusi yang menilai settlement finality dibandingkan bagi trader ritel — tidak ada yang peduli dengan jumlah iterasi saat menukar token, tetapi bank yang menjalankan settlement sekuritas jelas akan peduli.
@Dusk
$DUSK
#dusk
