#dusk $DUSK
Baru-baru ini saya lanjut membaca dokumen siklus hidup transaksi @Dusk , dan saya sadar bahwa dulu saya menilai satu hal terlalu sederhana:
Transaksi yang berhasil dieksekusi tidak berarti statusnya sudah bisa dianggap oleh sistem keuangan sebagai “fakta”.
Di DuskDS, sebuah transaksi terlebih dahulu diterima, disebarkan, dieksekusi, lalu masih harus melalui konfirmasi akhir.
Dokumentasi resmi bahkan secara khusus mengingatkan bahwa:
included, accepted, confirmed tidak boleh langsung dianggap sebagai payment finality.
Alasannya tidak rumit.
Jika sebuah transaksi masuk ke accepted block, block tersebut masih mungkin di-rollback.
Baru ketika finalized, status benar-benar masuk ke deterministic finality.
Di Succinct Attestation milik Dusk, prosesnya akan berlanjut melalui:
Proposal
→ Validation
→ Ratification
Sampai Ratification selesai, barulah block benar-benar final.
Saya merasa detail ini lebih menarik daripada sekadar “berapa banyak TPS”.
Karena yang paling ditakuti bursa atau sistem keuangan bukanlah terlambat beberapa detik melihat transaksi.
Yang ditakuti adalah:
Saya sudah melakukan pencatatan ke akun pengguna berdasarkan status ini, tetapi pada akhirnya status dasar berubah lagi.
Itulah sebabnya dokumen integrasi Dusk untuk bursa juga secara tegas mensyaratkan agar tidak mencatat lebih awal hanya karena mempool, included event, atau accepted-but-unfinalized block.
Sebenarnya, ini membuat konsep finality menjadi sangat nyata.
Finality bukanlah istilah performa.
Melainkan menjawab pertanyaan:
Sejak momen yang mana sistem dapat mulai tidak lagi khawatir bahwa status ini akan dicabut?
Di situs resmi Dusk, metrik finality yang disebutkan sekarang kira-kira sekitar 10 detik.
Saya tidak terlalu fokus apakah angka ini terlihat bagus.
Yang lebih saya pedulikan adalah, setelah mainnet dipakai dengan beban nyata, apakah batas dari accepted ke finalized ini bisa terus terjaga—tetap jelas dan stabil.
Pada akhirnya, yang benar-benar diandalkan oleh sistem keuangan tetap ini.
Baru-baru ini saya lanjut membaca dokumen siklus hidup transaksi @Dusk , dan saya sadar bahwa dulu saya menilai satu hal terlalu sederhana:
Transaksi yang berhasil dieksekusi tidak berarti statusnya sudah bisa dianggap oleh sistem keuangan sebagai “fakta”.
Di DuskDS, sebuah transaksi terlebih dahulu diterima, disebarkan, dieksekusi, lalu masih harus melalui konfirmasi akhir.
Dokumentasi resmi bahkan secara khusus mengingatkan bahwa:
included, accepted, confirmed tidak boleh langsung dianggap sebagai payment finality.
Alasannya tidak rumit.
Jika sebuah transaksi masuk ke accepted block, block tersebut masih mungkin di-rollback.
Baru ketika finalized, status benar-benar masuk ke deterministic finality.
Di Succinct Attestation milik Dusk, prosesnya akan berlanjut melalui:
Proposal
→ Validation
→ Ratification
Sampai Ratification selesai, barulah block benar-benar final.
Saya merasa detail ini lebih menarik daripada sekadar “berapa banyak TPS”.
Karena yang paling ditakuti bursa atau sistem keuangan bukanlah terlambat beberapa detik melihat transaksi.
Yang ditakuti adalah:
Saya sudah melakukan pencatatan ke akun pengguna berdasarkan status ini, tetapi pada akhirnya status dasar berubah lagi.
Itulah sebabnya dokumen integrasi Dusk untuk bursa juga secara tegas mensyaratkan agar tidak mencatat lebih awal hanya karena mempool, included event, atau accepted-but-unfinalized block.
Sebenarnya, ini membuat konsep finality menjadi sangat nyata.
Finality bukanlah istilah performa.
Melainkan menjawab pertanyaan:
Sejak momen yang mana sistem dapat mulai tidak lagi khawatir bahwa status ini akan dicabut?
Di situs resmi Dusk, metrik finality yang disebutkan sekarang kira-kira sekitar 10 detik.
Saya tidak terlalu fokus apakah angka ini terlihat bagus.
Yang lebih saya pedulikan adalah, setelah mainnet dipakai dengan beban nyata, apakah batas dari accepted ke finalized ini bisa terus terjaga—tetap jelas dan stabil.
Pada akhirnya, yang benar-benar diandalkan oleh sistem keuangan tetap ini.