#dusk $DUSK @Dusk Saya masih belum mengerti satu hal: Dusk memiliki lingkungan eksekusi native untuk smart contract sendiri, khusus untuk menjalankan kontrak yang ditulis dengan Rust. Pada saat yang sama, mereka juga menyiapkan layer eksekusi yang kompatibel dengan Ethereum, sehingga orang bisa menulis smart contract dengan bahasa yang biasa mereka kenal. Dua lingkungan ini sama-sama dipelihara, dan rasanya itu menambah beban pemeliharaan. Kali ini saya memang ingin memastikan, pilihan ini sebenarnya mengejar apa.
Setelah mencari referensi, pemahaman saya adalah bahwa ini sesungguhnya melayani dua jenis kelompok developer yang benar-benar berbeda. Untuk lingkungan native, targetnya adalah tim yang bersedia belajar Rust secara langsung dan ingin mendapatkan kemampuan paling dasar di dalam protokol (misalnya, mengoperasikan akun terenkripsi yang tersembunyi secara langsung). Dari sisi performa dan fleksibilitas, ini lebih tinggi, tetapi tingkat kesulitannya juga lebih tinggi. Di pasaran, jumlah orang yang menulis smart contract dengan Rust memang jauh lebih sedikit daripada yang menulis kontrak dengan bahasa ekosistem Ethereum.
Sementara layer yang kompatibel dengan Ethereum tujuannya adalah “memanfaatkan yang sudah ada” — di luar sana sudah ada banyak developer dan banyak toolchain siap pakai yang dibangun di sekitar ekosistem Ethereum. Jika Dusk tidak menyediakan pintu masuk yang kompatibel, sebagian besar orang di kelompok ini pada dasarnya tidak mau mempelajari lagi toolchain dari nol hanya untuk sebuah chain baru; mereka cenderung memilih untuk mengembangkan di tempat lain yang lebih kompatibel.
Awalnya saya merasa ini seperti “ingin dapat semuanya”—mencoba menyenangkan dua sisi sekaligus, sehingga bisa jadi keduanya tidak dikerjakan dengan optimal. Tetapi setelah saya membaca penjelasan resmi mengenai posisi kedua layer tersebut, saya baru sadar bahwa mereka memang tidak berniat membuat dua layer ini benar-benar setara fungsinya. Layer native digunakan untuk skenario level protokol yang membutuhkan pengikatan mendalam pada kemampuan privasi dan settlement. Sedangkan layer yang kompatibel dengan Ethereum lebih berfungsi untuk koneksi cepat ke ekosistem eksternal dan aplikasi yang sudah jadi. Dengan pembagian seperti ini, rasanya tidak dianggap membuat roda yang sama dua kali; ini lebih seperti membuka pintu yang berbeda untuk kebutuhan yang berbeda, bukan mengerjakan satu hal yang sama dua kali.
Namun, saya juga belum menemukan data distribusi developer secara spesifik—misalnya, dari aplikasi yang benar-benar sudah dideploy, perbandingan antara yang menggunakan jalur native dan yang menggunakan jalur kompatibilitas Ethereum kira-kira berapa. Di bagian ini, sementara tidak ada angka yang bisa diverifikasi. Jadi, yang bisa dikatakan adalah bahwa ide desain arsitekturnya masuk akal. Tapi setelah ide itu diimplementasikan, jalur mana yang benar-benar digunakan, itu tetap perlu dibuktikan oleh jumlah aplikasi yang benar-benar dideploy di masa mendatang.
Setelah mencari referensi, pemahaman saya adalah bahwa ini sesungguhnya melayani dua jenis kelompok developer yang benar-benar berbeda. Untuk lingkungan native, targetnya adalah tim yang bersedia belajar Rust secara langsung dan ingin mendapatkan kemampuan paling dasar di dalam protokol (misalnya, mengoperasikan akun terenkripsi yang tersembunyi secara langsung). Dari sisi performa dan fleksibilitas, ini lebih tinggi, tetapi tingkat kesulitannya juga lebih tinggi. Di pasaran, jumlah orang yang menulis smart contract dengan Rust memang jauh lebih sedikit daripada yang menulis kontrak dengan bahasa ekosistem Ethereum.
Sementara layer yang kompatibel dengan Ethereum tujuannya adalah “memanfaatkan yang sudah ada” — di luar sana sudah ada banyak developer dan banyak toolchain siap pakai yang dibangun di sekitar ekosistem Ethereum. Jika Dusk tidak menyediakan pintu masuk yang kompatibel, sebagian besar orang di kelompok ini pada dasarnya tidak mau mempelajari lagi toolchain dari nol hanya untuk sebuah chain baru; mereka cenderung memilih untuk mengembangkan di tempat lain yang lebih kompatibel.
Awalnya saya merasa ini seperti “ingin dapat semuanya”—mencoba menyenangkan dua sisi sekaligus, sehingga bisa jadi keduanya tidak dikerjakan dengan optimal. Tetapi setelah saya membaca penjelasan resmi mengenai posisi kedua layer tersebut, saya baru sadar bahwa mereka memang tidak berniat membuat dua layer ini benar-benar setara fungsinya. Layer native digunakan untuk skenario level protokol yang membutuhkan pengikatan mendalam pada kemampuan privasi dan settlement. Sedangkan layer yang kompatibel dengan Ethereum lebih berfungsi untuk koneksi cepat ke ekosistem eksternal dan aplikasi yang sudah jadi. Dengan pembagian seperti ini, rasanya tidak dianggap membuat roda yang sama dua kali; ini lebih seperti membuka pintu yang berbeda untuk kebutuhan yang berbeda, bukan mengerjakan satu hal yang sama dua kali.
Namun, saya juga belum menemukan data distribusi developer secara spesifik—misalnya, dari aplikasi yang benar-benar sudah dideploy, perbandingan antara yang menggunakan jalur native dan yang menggunakan jalur kompatibilitas Ethereum kira-kira berapa. Di bagian ini, sementara tidak ada angka yang bisa diverifikasi. Jadi, yang bisa dikatakan adalah bahwa ide desain arsitekturnya masuk akal. Tapi setelah ide itu diimplementasikan, jalur mana yang benar-benar digunakan, itu tetap perlu dibuktikan oleh jumlah aplikasi yang benar-benar dideploy di masa mendatang.