Bagaimana jika membuat infrastruktur blockchain lebih mudah digunakan kadang berarti memberi pengembang lebih dari satu cara untuk membangunnya?
Saya melihat hal ini saat menjelajahi DUSK, dan pemisahannya antara DuskVM dan DuskEVM membuat saya berhenti sejenak. Biasanya saya menganggap sebuah blockchain punya satu lingkungan eksekusi utama, sementara semuanya yang lain diperlakukan sebagai alat bantu di sekelilingnya.
DUSK mengambil jalur yang berbeda. DuskEVM menyediakan eksekusi Solidity dan Vyper dengan alat-alat Ethereum yang sudah familiar, sementara DuskVM menjalankan kontrak Rust/WASM langsung di Dusk L1. Kedua jalur ini bermuara pada jaringan yang mendasari yang sama, tetapi keduanya melayani kebutuhan pengembangan yang berbeda.
Awalnya, ini tampak seperti kemudahan teknis. Lalu saya mulai memikirkan masalah yang ada di baliknya.
Pengembang sudah punya kebiasaan, pustaka, wallet, dan codebase yang mereka pahami. Meminta setiap aplikasi keuangan untuk meninggalkan alat-alat itu hanya demi mengakses lingkungan penyelesaian yang berbeda menciptakan gesekan yang tidak perlu. Pada saat yang sama, beberapa aplikasi mungkin memerlukan akses langsung ke aset native, fitur privasi, atau kemampuan protokol tingkat lebih rendah yang tidak secara alami disediakan oleh lingkungan EVM.
Kompromi itu terasa sangat relevan dengan perancangan infrastruktur.
Saat meneliti DUSK, saya mendapati diri bertanya-tanya apakah interoperabilitas kadang dibahas terlalu sempit. Mungkin kompatibilitas tidak hanya soal menghubungkan rantai yang berbeda; kompatibilitas juga bisa berarti memungkinkan model pengembangan yang berbeda untuk hidup berdampingan tanpa memaksa setiap aplikasi masuk ke satu jalur teknis.
Pertanyaan menarik bagi saya adalah sampai di mana abstraksi harus berakhir. Abstraksi yang terlalu sedikit menimbulkan gesekan, sementara abstraksi yang terlalu banyak bisa menyembunyikan kemampuan yang pada akhirnya kelak dibutuhkan pengembang.
DUSK membuat batas itu layak untuk diperiksa dari sudut pandang seorang pembangun, bukan hanya dari sudut pandang pasar.
#dusk $DUSK @Dusk
Saya melihat hal ini saat menjelajahi DUSK, dan pemisahannya antara DuskVM dan DuskEVM membuat saya berhenti sejenak. Biasanya saya menganggap sebuah blockchain punya satu lingkungan eksekusi utama, sementara semuanya yang lain diperlakukan sebagai alat bantu di sekelilingnya.
DUSK mengambil jalur yang berbeda. DuskEVM menyediakan eksekusi Solidity dan Vyper dengan alat-alat Ethereum yang sudah familiar, sementara DuskVM menjalankan kontrak Rust/WASM langsung di Dusk L1. Kedua jalur ini bermuara pada jaringan yang mendasari yang sama, tetapi keduanya melayani kebutuhan pengembangan yang berbeda.
Awalnya, ini tampak seperti kemudahan teknis. Lalu saya mulai memikirkan masalah yang ada di baliknya.
Pengembang sudah punya kebiasaan, pustaka, wallet, dan codebase yang mereka pahami. Meminta setiap aplikasi keuangan untuk meninggalkan alat-alat itu hanya demi mengakses lingkungan penyelesaian yang berbeda menciptakan gesekan yang tidak perlu. Pada saat yang sama, beberapa aplikasi mungkin memerlukan akses langsung ke aset native, fitur privasi, atau kemampuan protokol tingkat lebih rendah yang tidak secara alami disediakan oleh lingkungan EVM.
Kompromi itu terasa sangat relevan dengan perancangan infrastruktur.
Saat meneliti DUSK, saya mendapati diri bertanya-tanya apakah interoperabilitas kadang dibahas terlalu sempit. Mungkin kompatibilitas tidak hanya soal menghubungkan rantai yang berbeda; kompatibilitas juga bisa berarti memungkinkan model pengembangan yang berbeda untuk hidup berdampingan tanpa memaksa setiap aplikasi masuk ke satu jalur teknis.
Pertanyaan menarik bagi saya adalah sampai di mana abstraksi harus berakhir. Abstraksi yang terlalu sedikit menimbulkan gesekan, sementara abstraksi yang terlalu banyak bisa menyembunyikan kemampuan yang pada akhirnya kelak dibutuhkan pengembang.
DUSK membuat batas itu layak untuk diperiksa dari sudut pandang seorang pembangun, bukan hanya dari sudut pandang pasar.
#dusk $DUSK @Dusk
