Saya dulu menganggap konfirmasi blok itu sederhana: transaksi masuk ke blok, lalu hitung beberapa blok ke depan, pada dasarnya itu sudah cukup aman. Tapi malam ini saya membaca dokumen lifecycle untuk transaksi @Dusk , dan satu kalimat langsung membuat saya buntu: “accepted blocks can still be reverted”. Kalau sudah diterima, kenapa masih bisa ditarik kembali?
Baru setelah saya membaca 2024 Whitepaper saya paham. Konsensus satu putaran pada Dusk akan melalui beberapa iteration; dalam round yang sama, bisa muncul blok-bblok yang saling bersaing. Blok dengan iteration yang lebih tinggi, meskipun sudah accepted, tetap bisa memicu fallback bila blok kompetitor dengan iteration yang lebih rendah memenuhi syarat.
“Melihat transaksi sudah on-chain” tidak otomatis berarti transaksi itu tidak bisa digantikan.
Rolling Finality juga terasa lebih tidak intuitif. Whitepaper menggunakan n untuk menyatakan jumlah iteration yang belum selesai attestation hingga kepastian. Blok yang sudah accepted baru akan menjadi confirmed setelah menunggu 2×n blok penerus yang berurutan dan telah attested atau confirmed. Misal n=3, maka Anda perlu mengamati 6 blok berikutnya yang memenuhi syarat.
Di sini saya sadar: “jumlah konfirmasi” bukan ukuran yang seragam. Walaupun sama-sama sudah on-chain, riwayat konsensus yang berbeda membuat tingkat kestabilannya juga berbeda.
Saran yang diberikan oleh Docs saat ini lebih langsung: included, accepted, bahkan confirmed jangan dianggap sebagai sinyal pembayaran yang sudah aman. Tetap tunggu sampai benar-benar finalized.
Untuk transfer kecil, selisihnya mungkin hanya beberapa detik; tapi kalau dimasukkan ke skenario besar seperti OTC atau settlement DvP untuk RWA, “melihat transaksi” dan “penyelesaian yang tidak dapat dibatalkan” adalah dua hal yang benar-benar berbeda. Ke depannya, saat melihat transaksi besar di Dusk, cukup tanya: sudah finalized?
#dusk $DUSK @Dusk
Baru setelah saya membaca 2024 Whitepaper saya paham. Konsensus satu putaran pada Dusk akan melalui beberapa iteration; dalam round yang sama, bisa muncul blok-bblok yang saling bersaing. Blok dengan iteration yang lebih tinggi, meskipun sudah accepted, tetap bisa memicu fallback bila blok kompetitor dengan iteration yang lebih rendah memenuhi syarat.
“Melihat transaksi sudah on-chain” tidak otomatis berarti transaksi itu tidak bisa digantikan.
Rolling Finality juga terasa lebih tidak intuitif. Whitepaper menggunakan n untuk menyatakan jumlah iteration yang belum selesai attestation hingga kepastian. Blok yang sudah accepted baru akan menjadi confirmed setelah menunggu 2×n blok penerus yang berurutan dan telah attested atau confirmed. Misal n=3, maka Anda perlu mengamati 6 blok berikutnya yang memenuhi syarat.
Di sini saya sadar: “jumlah konfirmasi” bukan ukuran yang seragam. Walaupun sama-sama sudah on-chain, riwayat konsensus yang berbeda membuat tingkat kestabilannya juga berbeda.
Saran yang diberikan oleh Docs saat ini lebih langsung: included, accepted, bahkan confirmed jangan dianggap sebagai sinyal pembayaran yang sudah aman. Tetap tunggu sampai benar-benar finalized.
Untuk transfer kecil, selisihnya mungkin hanya beberapa detik; tapi kalau dimasukkan ke skenario besar seperti OTC atau settlement DvP untuk RWA, “melihat transaksi” dan “penyelesaian yang tidak dapat dibatalkan” adalah dua hal yang benar-benar berbeda. Ke depannya, saat melihat transaksi besar di Dusk, cukup tanya: sudah finalized?
#dusk $DUSK @Dusk
