Saya memperhatikan sesuatu saat melakukan pengecekan silang alur transaksi @Dusk terhadap aktivitas EVM $DUSK minggu lalu: transaksi-transaksi dikonfirmasi, tetapi jeda antara pengajuan dan finalitas terus bergeser mengikuti pola yang sama sekali tidak sesuai dengan kemacetan jaringan. Asumsi pertama saya sederhana: congestion pricing, semacam yang biasa terlihat di sebagian besar chain ketika ruang blok mulai diperebutkan.
Setelah ditelusuri lebih jauh, saya menemukan bahwa Dusk memisahkan konfirmasi eksekusi dari finalitas penyelesaian. Sebuah transaksi bisa diterima dan diproses oleh lapisan jaringan, sementara penyelesaian yang sebenarnya—bagian yang penting untuk aset yang teregulasi atau dibatasi privasi—melewati jalur konsensus yang berbeda. Itu bukan sekadar kemacetan. Itu berarti protokol memperlakukan "processed" dan "final" sebagai dua status yang benar-benar berbeda, bukan dua kata untuk satu kejadian yang sama.
Penemuan ini mengubah cara saya memandang metrik aktivitas sepenuhnya. Kebanyakan orang, termasuk saya sendiri sampai baru-baru ini, menggabungkan throughput dengan jaminan finalitas. Namun jika eksekusi dan finalitas dipisahkan sejak desainnya, lonjakan pada volume transaksi yang terlihat tidak selalu berarti lonjakan pada aktivitas ekonomi yang benar-benar terkonfirmasi. Efek orde kedua adalah dasbor yang menampilkan jumlah tx mentah bisa melebih-lebihkan penggunaan nyata selama periode ketika finalitas tertinggal dari eksekusi.
Hal yang belum saya selesaikan adalah apakah pemisahan ini merupakan pilihan ketahanan yang disengaja atau sekadar efek samping dari cara validator menyusun urutan kerja di bawah batasan selective disclosure. Jika memang disengaja, itu menunjukkan bahwa jaringan mengoptimalkan integritas penyelesaian dibanding kecepatan yang jadi headline—ini kompromi yang nyata, bukan sebuah cacat, tetapi saya belum bisa memastikan bagaimana validator diberi insentif untuk memprioritaskan satu jalur dibanding jalur lainnya saat beban tinggi.
Ke depan, saya akan memantau selisih antara timestamp eksekusi dan timestamp penyelesaian pada berbagai kondisi beban, bukan hanya rata-rata waktu finalitas. Saya juga ingin melihat apakah partisipasi validator bergeser ketika selisih itu melebar, karena itu akan memberi tahu saya apakah operator secara aktif mengelolanya atau hanya menyerapnya secara pasif.#dusk
Setelah ditelusuri lebih jauh, saya menemukan bahwa Dusk memisahkan konfirmasi eksekusi dari finalitas penyelesaian. Sebuah transaksi bisa diterima dan diproses oleh lapisan jaringan, sementara penyelesaian yang sebenarnya—bagian yang penting untuk aset yang teregulasi atau dibatasi privasi—melewati jalur konsensus yang berbeda. Itu bukan sekadar kemacetan. Itu berarti protokol memperlakukan "processed" dan "final" sebagai dua status yang benar-benar berbeda, bukan dua kata untuk satu kejadian yang sama.
Penemuan ini mengubah cara saya memandang metrik aktivitas sepenuhnya. Kebanyakan orang, termasuk saya sendiri sampai baru-baru ini, menggabungkan throughput dengan jaminan finalitas. Namun jika eksekusi dan finalitas dipisahkan sejak desainnya, lonjakan pada volume transaksi yang terlihat tidak selalu berarti lonjakan pada aktivitas ekonomi yang benar-benar terkonfirmasi. Efek orde kedua adalah dasbor yang menampilkan jumlah tx mentah bisa melebih-lebihkan penggunaan nyata selama periode ketika finalitas tertinggal dari eksekusi.
Hal yang belum saya selesaikan adalah apakah pemisahan ini merupakan pilihan ketahanan yang disengaja atau sekadar efek samping dari cara validator menyusun urutan kerja di bawah batasan selective disclosure. Jika memang disengaja, itu menunjukkan bahwa jaringan mengoptimalkan integritas penyelesaian dibanding kecepatan yang jadi headline—ini kompromi yang nyata, bukan sebuah cacat, tetapi saya belum bisa memastikan bagaimana validator diberi insentif untuk memprioritaskan satu jalur dibanding jalur lainnya saat beban tinggi.
Ke depan, saya akan memantau selisih antara timestamp eksekusi dan timestamp penyelesaian pada berbagai kondisi beban, bukan hanya rata-rata waktu finalitas. Saya juga ingin melihat apakah partisipasi validator bergeser ketika selisih itu melebar, karena itu akan memberi tahu saya apakah operator secara aktif mengelolanya atau hanya menyerapnya secara pasif.#dusk