#dusk $DUSK
Dalam beberapa hari terakhir saya membaca dokumentasi DuskEVM dari @Dusk , dan ada satu detail yang sebelumnya memang saya lewatkan:
Transaksi yang dipaketkan di DuskEVM tidak berarti transaksi tersebut sudah benar-benar selesai.
Dalam arsitektur yang sekarang ini, DuskEVM dan DuskDS tidak mengerjakan satu hal yang sama.
Kontrak Solidity dieksekusi dulu di DuskEVM, lalu transaksi masuk ke sequencer dan dimasukkan ke dalam block L2. Setelah itu, batcher masih perlu mengirimkan data transaksi ke DuskDS, dan statusnya akan terus diverifikasi melalui mekanisme seperti commitment dan fault proof.
Pada akhirnya, yang bertanggung jawab untuk settlement dan data availability adalah DuskDS.
Jadi, dari pemahaman saya saat ini, justru saya tidak akan menyederhanakannya menjadi “Dusk menambahkan EVM”.
Yang lebih tepat adalah:
DuskEVM yang mengeksekusi, DuskDS yang menentukan apakah hasilnya dianggap valid atau tidak.
Ini juga menjelaskan mengapa dokumentasi resmi secara khusus membedakan transaction inclusion dan settlement.
Termasuk alur withdrawal di testnet saat ini, kita bisa melihat pola desain seperti ini: pertama di DuskEVM initiate, lalu Dusk L1 prove, dan terakhir finalize. Bukan berarti begitu L2 menampilkan sukses, semuanya benar-benar selesai.
Perbedaan ini mungkin tidak terlalu terasa untuk transfer biasa, tapi jika dibawa ke skenario keuangan, menurut saya justru ini penting.
Untuk hal seperti sekuritas dan dana—kalau benar-benar ingin di-on-chain—yang pada akhirnya orang pedulikan bukan cuma “apakah transaksinya cepat”, tapi ada pertanyaan yang lebih praktis:
Di layer mana status ini mendapatkan finalitas?
Jadi ke depannya, saat melihat DuskEVM mainnet, selain performa dan kompatibilitas Solidity, saya ingin tahu bagaimana performa nyata dari rantai dari execution sampai settlement di DuskDS.
Setidaknya, pembagian peran dalam arsitektur sekarang, menurut saya sudah saya pahami.
Dalam beberapa hari terakhir saya membaca dokumentasi DuskEVM dari @Dusk , dan ada satu detail yang sebelumnya memang saya lewatkan:
Transaksi yang dipaketkan di DuskEVM tidak berarti transaksi tersebut sudah benar-benar selesai.
Dalam arsitektur yang sekarang ini, DuskEVM dan DuskDS tidak mengerjakan satu hal yang sama.
Kontrak Solidity dieksekusi dulu di DuskEVM, lalu transaksi masuk ke sequencer dan dimasukkan ke dalam block L2. Setelah itu, batcher masih perlu mengirimkan data transaksi ke DuskDS, dan statusnya akan terus diverifikasi melalui mekanisme seperti commitment dan fault proof.
Pada akhirnya, yang bertanggung jawab untuk settlement dan data availability adalah DuskDS.
Jadi, dari pemahaman saya saat ini, justru saya tidak akan menyederhanakannya menjadi “Dusk menambahkan EVM”.
Yang lebih tepat adalah:
DuskEVM yang mengeksekusi, DuskDS yang menentukan apakah hasilnya dianggap valid atau tidak.
Ini juga menjelaskan mengapa dokumentasi resmi secara khusus membedakan transaction inclusion dan settlement.
Termasuk alur withdrawal di testnet saat ini, kita bisa melihat pola desain seperti ini: pertama di DuskEVM initiate, lalu Dusk L1 prove, dan terakhir finalize. Bukan berarti begitu L2 menampilkan sukses, semuanya benar-benar selesai.
Perbedaan ini mungkin tidak terlalu terasa untuk transfer biasa, tapi jika dibawa ke skenario keuangan, menurut saya justru ini penting.
Untuk hal seperti sekuritas dan dana—kalau benar-benar ingin di-on-chain—yang pada akhirnya orang pedulikan bukan cuma “apakah transaksinya cepat”, tapi ada pertanyaan yang lebih praktis:
Di layer mana status ini mendapatkan finalitas?
Jadi ke depannya, saat melihat DuskEVM mainnet, selain performa dan kompatibilitas Solidity, saya ingin tahu bagaimana performa nyata dari rantai dari execution sampai settlement di DuskDS.
Setidaknya, pembagian peran dalam arsitektur sekarang, menurut saya sudah saya pahami.