Saya melihat arsitektur Dusk hari ini, dan satu hal menjadi lebih masuk akal setelah saya menggali lebih dalam:
Dusk tidak memaksa setiap pengembang untuk masuk ke lingkungan eksekusi yang sama.
Sebaliknya, ia memisahkan settlement dari eksekusi.
Di bagian dasarnya ada DuskDS, yang menangani konsensus, finality, dan ketersediaan data.
Lalu di atasnya ada dua jalur berbeda.
DuskVM menjalankan kontrak Rust/WASM langsung di Dusk L1.
DuskEVM memberi pengembang lingkungan yang kompatibel dengan EVM untuk Solidity dan Vyper, sementara tetap melakukan settlement melalui DuskDS.
Awalnya, memiliki dua lingkungan tampak seperti kompleksitas yang tidak perlu bagi saya.
Tapi alasannya menjadi lebih jelas.
Sebuah aplikasi yang membutuhkan akses langsung ke model transaksi asli Dusk, privasi, atau kemampuan zero-knowledge dapat menggunakan DuskVM.
Sebuah tim yang sudah berkutat di ekosistem pengembang Ethereum bisa menggunakan DuskEVM, dengan alat yang sudah familiar dan Solidity, alih-alih membangun ulang seluruh alur kerja pengembangannya.
Itu pertukaran yang menarik.
Dusk sebenarnya tidak meminta pengembang untuk memilih antara infrastruktur native dan kompatibilitas EVM.
Dusk berupaya mempertahankan keduanya sambil menempatkan settlement di bawah keduanya.
Pertanyaan yang masih saya miliki adalah pertanyaan yang penting:
Apakah keberadaan dua jalur eksekusi ini benar-benar akan menarik cukup banyak pembangun yang berbeda untuk membenarkan kompleksitas arsitektur tambahan?
Bagi saya, itu adalah hal yang lebih menarik untuk diamati daripada sekadar menyebut Dusk “kompatibel dengan EVM.”
#dusk $DUSK @Dusk
Dusk tidak memaksa setiap pengembang untuk masuk ke lingkungan eksekusi yang sama.
Sebaliknya, ia memisahkan settlement dari eksekusi.
Di bagian dasarnya ada DuskDS, yang menangani konsensus, finality, dan ketersediaan data.
Lalu di atasnya ada dua jalur berbeda.
DuskVM menjalankan kontrak Rust/WASM langsung di Dusk L1.
DuskEVM memberi pengembang lingkungan yang kompatibel dengan EVM untuk Solidity dan Vyper, sementara tetap melakukan settlement melalui DuskDS.
Awalnya, memiliki dua lingkungan tampak seperti kompleksitas yang tidak perlu bagi saya.
Tapi alasannya menjadi lebih jelas.
Sebuah aplikasi yang membutuhkan akses langsung ke model transaksi asli Dusk, privasi, atau kemampuan zero-knowledge dapat menggunakan DuskVM.
Sebuah tim yang sudah berkutat di ekosistem pengembang Ethereum bisa menggunakan DuskEVM, dengan alat yang sudah familiar dan Solidity, alih-alih membangun ulang seluruh alur kerja pengembangannya.
Itu pertukaran yang menarik.
Dusk sebenarnya tidak meminta pengembang untuk memilih antara infrastruktur native dan kompatibilitas EVM.
Dusk berupaya mempertahankan keduanya sambil menempatkan settlement di bawah keduanya.
Pertanyaan yang masih saya miliki adalah pertanyaan yang penting:
Apakah keberadaan dua jalur eksekusi ini benar-benar akan menarik cukup banyak pembangun yang berbeda untuk membenarkan kompleksitas arsitektur tambahan?
Bagi saya, itu adalah hal yang lebih menarik untuk diamati daripada sekadar menyebut Dusk “kompatibel dengan EVM.”
#dusk $DUSK @Dusk