menghabiskan pagi ini menelusuri bagaimana transaksi duskevm sebenarnya bergerak melalui sistem dan jujur? 😂 aku kira begitu itu muncul di sebuah blok berarti selesai—ternyata tidak sesederhana itu.
jadi duskevm adalah lapisan yang kompatibel dengan evm di dusk, artinya kamu menulis Solidity, menggunakan wallet evm normal, serta tooling standar seperti foundry atau hardhat, dan membayar gas dengan dusk. tapi transaksinya tidak cuma “hidup” lalu “mati” di duskevm dengan sendirinya. transaksinya melewati siklus seperti rollup. pertama, transaksinya dikirim ke duskevm sequencer, lalu dimasukkan ke blok L2 dengan relatif cepat. setelah itu, batcher mempublikasikan data transaksi tersebut ke duskds—lapisan settlement dan ketersediaan data aktual milik dusk. commitment state dan fault proof adalah yang menghubungkan state hasil itu kembali ke duskds, jadi benar-benar sudah tersettlement, bukan cuma tersimpan di suatu blok L2 sementara menunggu.
yang terus kupikirkan adalah satu kalimat di dokumentasi yang menegaskan bahwa inclusion dan settlement itu benar-benar tahap yang berbeda, dan aplikasi yang memindahkan nilai antara duskevm dan dusk L1 seharusnya memeriksa status protokol atau wallet, bukan sekadar mengasumsikan sesuatu sudah final hanya karena waktu sudah lewat. ini perbedaan yang nyata, bukan sekadar teknis. aku belum menemukan tempat yang menjelaskan seberapa lama jeda itu biasanya dalam praktiknya; inclusion yang cepat jelas tidak berarti settlement instan, tapi aku tidak tahu jendela waktu sebenarnya yang harus ditunggu seseorang.
tapi pilihan desainnya sendiri menurutku masuk akal. daripada membangun chain EVM yang benar-benar terpisah dan melayang sendiri, duskevm tetap “terikat” pada duskds untuk settlement dan data availability, jadi kamu mendapatkan tooling Solidity penuh tanpa kehilangan jaminan lapisan dasar soal finalitas.
jujur aku tidak tahu apakah jeda inclusion ke settlement itu cukup kecil untuk diabaikan dalam aktivitas harian, atau para builder perlu benar-benar memperhitungkannya??
🤔
#dusk @Dusk $DUSK
jadi duskevm adalah lapisan yang kompatibel dengan evm di dusk, artinya kamu menulis Solidity, menggunakan wallet evm normal, serta tooling standar seperti foundry atau hardhat, dan membayar gas dengan dusk. tapi transaksinya tidak cuma “hidup” lalu “mati” di duskevm dengan sendirinya. transaksinya melewati siklus seperti rollup. pertama, transaksinya dikirim ke duskevm sequencer, lalu dimasukkan ke blok L2 dengan relatif cepat. setelah itu, batcher mempublikasikan data transaksi tersebut ke duskds—lapisan settlement dan ketersediaan data aktual milik dusk. commitment state dan fault proof adalah yang menghubungkan state hasil itu kembali ke duskds, jadi benar-benar sudah tersettlement, bukan cuma tersimpan di suatu blok L2 sementara menunggu.
yang terus kupikirkan adalah satu kalimat di dokumentasi yang menegaskan bahwa inclusion dan settlement itu benar-benar tahap yang berbeda, dan aplikasi yang memindahkan nilai antara duskevm dan dusk L1 seharusnya memeriksa status protokol atau wallet, bukan sekadar mengasumsikan sesuatu sudah final hanya karena waktu sudah lewat. ini perbedaan yang nyata, bukan sekadar teknis. aku belum menemukan tempat yang menjelaskan seberapa lama jeda itu biasanya dalam praktiknya; inclusion yang cepat jelas tidak berarti settlement instan, tapi aku tidak tahu jendela waktu sebenarnya yang harus ditunggu seseorang.
tapi pilihan desainnya sendiri menurutku masuk akal. daripada membangun chain EVM yang benar-benar terpisah dan melayang sendiri, duskevm tetap “terikat” pada duskds untuk settlement dan data availability, jadi kamu mendapatkan tooling Solidity penuh tanpa kehilangan jaminan lapisan dasar soal finalitas.
jujur aku tidak tahu apakah jeda inclusion ke settlement itu cukup kecil untuk diabaikan dalam aktivitas harian, atau para builder perlu benar-benar memperhitungkannya??
🤔
#dusk @Dusk $DUSK