#dusk $DUSK @Dusk
Ehsan bertanya sesuatu saat makan malam yang membuatku meninjau ulang sebuah detail tentang Dusk
Mengapa seorang pengembang harus pernah berasumsi bahwa cukup banyak waktu telah berlalu berarti suatu kondisi ekonomi sudah siap digunakan?
Kedengarannya sederhana, tetapi menjadi penting ketika eksekusi dan penyelesaian dipisahkan. DuskDS menyediakan fondasi settlement, finalitas, dan ketersediaan data, sementara DuskVM menjalankan kontrak Rust/WASM secara langsung di L1 dan DuskEVM menyediakan eksekusi EVM yang diselesaikan melalui DuskDS.
Bagian yang menarik adalah bahwa jembatan Dusk tidak memperlakukan waktu sebagai primitif keamanan.
Penarikan (withdrawal) DuskEVM bergerak melalui tahapan yang berbeda: inisiasi, pembuatan bukti (proof), dan finalisasi. Apakah tindakan berikutnya sudah siap bergantung pada kondisi jaringan yang dipublikasikan, kematangan bukti (proof maturity), dan pemeriksaan dispute-game. Dokumentasi secara eksplisit memberi tahu pengembang untuk tidak menghitung kesiapan hanya dari waktu yang telah berlalu.
Detail itu memiliki implikasi yang lebih besar daripada jembatannya sendiri.
Dalam infrastruktur keuangan, pengembang sering mengubah proses asinkron menjadi logika aplikasi yang sederhana: tunggu X menit, lalu menganggap statusnya aman untuk dikonsumsi. Namun jika kesiapan protokol bergantung pada state dan bukti (proof) alih-alih jam yang tetap, pintasan itu dapat menciptakan risiko integrasi yang tersembunyi.
Aplikasi mungkin sepenuhnya benar tentang transaksi yang ia kirim, namun keliru tentang kapan konsekuensi ekonominya menjadi dapat digunakan.
Perbedaan itulah yang menurutku bernilai dalam Dusk. Finalitas bukan sekadar stempel waktu yang ditempel pada sebuah transaksi. Untuk sistem lintas-lingkungan (cross-environment), finalitas menjadi sebuah state yang didefinisikan Protokol yang harus dibaca dan dihormati oleh aplikasi.
Saat Dusk memperluas lapisan-lapisan eksekusinya, aku pikir ini menjadi prinsip penting bagi pengembang
Haruskah state kesiapan yang didefinisikan Protokol menjadi antarmuka tingkat pertama (First-class) untuk aplikasi keuangan, alih-alih membiarkan pengintegrasi menyimpulkan finalitas dari waktu dan status transaksi? ⚙️
@Binance Square Official $SOL
Ehsan bertanya sesuatu saat makan malam yang membuatku meninjau ulang sebuah detail tentang Dusk
Mengapa seorang pengembang harus pernah berasumsi bahwa cukup banyak waktu telah berlalu berarti suatu kondisi ekonomi sudah siap digunakan?
Kedengarannya sederhana, tetapi menjadi penting ketika eksekusi dan penyelesaian dipisahkan. DuskDS menyediakan fondasi settlement, finalitas, dan ketersediaan data, sementara DuskVM menjalankan kontrak Rust/WASM secara langsung di L1 dan DuskEVM menyediakan eksekusi EVM yang diselesaikan melalui DuskDS.
Bagian yang menarik adalah bahwa jembatan Dusk tidak memperlakukan waktu sebagai primitif keamanan.
Penarikan (withdrawal) DuskEVM bergerak melalui tahapan yang berbeda: inisiasi, pembuatan bukti (proof), dan finalisasi. Apakah tindakan berikutnya sudah siap bergantung pada kondisi jaringan yang dipublikasikan, kematangan bukti (proof maturity), dan pemeriksaan dispute-game. Dokumentasi secara eksplisit memberi tahu pengembang untuk tidak menghitung kesiapan hanya dari waktu yang telah berlalu.
Detail itu memiliki implikasi yang lebih besar daripada jembatannya sendiri.
Dalam infrastruktur keuangan, pengembang sering mengubah proses asinkron menjadi logika aplikasi yang sederhana: tunggu X menit, lalu menganggap statusnya aman untuk dikonsumsi. Namun jika kesiapan protokol bergantung pada state dan bukti (proof) alih-alih jam yang tetap, pintasan itu dapat menciptakan risiko integrasi yang tersembunyi.
Aplikasi mungkin sepenuhnya benar tentang transaksi yang ia kirim, namun keliru tentang kapan konsekuensi ekonominya menjadi dapat digunakan.
Perbedaan itulah yang menurutku bernilai dalam Dusk. Finalitas bukan sekadar stempel waktu yang ditempel pada sebuah transaksi. Untuk sistem lintas-lingkungan (cross-environment), finalitas menjadi sebuah state yang didefinisikan Protokol yang harus dibaca dan dihormati oleh aplikasi.
Saat Dusk memperluas lapisan-lapisan eksekusinya, aku pikir ini menjadi prinsip penting bagi pengembang
Haruskah state kesiapan yang didefinisikan Protokol menjadi antarmuka tingkat pertama (First-class) untuk aplikasi keuangan, alih-alih membiarkan pengintegrasi menyimpulkan finalitas dari waktu dan status transaksi? ⚙️
@Binance Square Official $SOL