#dusk $DUSK @Dusk Saya menghabiskan beberapa jam untuk merapikan arsitektur Dusk, membandingkannya dengan banyak proyek di jalur yang sama. Rute modularnya ini—keuntungan dan risikonya sama-sama ditampilkan dengan jelas.
Pemisahan arsitekturnya sangat tegas: lapisan dasar bertanggung jawab atas penyelesaian (settlement) dan ketersediaan data, sedangkan lapisan atas menyediakan lingkungan eksekusi yang kompatibel dengan EVM. Dua lapisan menjalankan perannya masing-masing. Menurut saya, pilihan ini sangat pragmatis—memulai ekosistem rantai yang benar-benar dikembangkan sendiri (pure self-developed) terlalu lambat. Setelah disambungkan ke EVM, alat pengembangan yang sudah matang serta sistem audit dapat langsung digunakan ulang, sehingga ambang masuk bagi pengembang turun drastis.
Namun biayanya juga ada di bagian-bagian kunci. Perpindahan aset lintas lapisan memerlukan mekanisme jembatan (bridge), yang menambah asumsi kepercayaan (trust assumptions) dan memperluas permukaan serangan (attack surface). Dalam pengalaman industri, masalah keamanan yang dipicu desain lintas-lapisan jauh lebih banyak daripada kegagapan yang murni berasal dari gangguan pada mesin virtualnya sendiri. Yang lebih terselubung adalah masalah konsistensi privasi: lapisan EVM bersifat transparan, sementara lapisan penyelesaian memiliki kemampuan kerahasiaan (confidential). Kekuatan privasi untuk aset yang sama berubah tergantung lapisan tempatnya berada. Pengguna sulit merasakannya secara intuitif, dan dari sisi kepatuhan (compliance) juga menambah beban penjelasan.
Menurut saya, bentuk yang lebih sehat adalah pembagian peran yang jelas: lapisan EVM menampung aplikasi umum dan likuiditas, sedangkan lapisan rahasia/kerahasiaan (confidential) secara khusus melayani skenario penyelesaian privasi. Jangan dipaksa mengejar kesetaraan fungsi. Narasi yang terlalu samar seperti “mendukung semua skenario” pada akhirnya besar kemungkinan membuat kedua belah pihak tidak dikerjakan dengan baik.
Jadi, ketika menilai nilai arsitektur ini, fokusnya tidak pernah pada sekadar uji performa (benchmark) di testnet. Yang terpenting adalah apakah batas tanggung jawab (boundary) pemisahan perannya cukup jelas. Apakah dokumentasi pengembangan memberikan panduan lapisan skenario yang tegas? Apakah keadaan aset lintas-lapisan dan batas privasinya dijelaskan dengan gamblang? Detail-detail seperti ini jauh lebih penting daripada sekadar parameter.
Selain itu, saya juga akan mengawasi satu sinyal: aplikasi apa yang akhirnya benar-benar dijalankan oleh lapisan EVM. Jika semuanya hanya meniru protokol umum, maka modularitas itu hanya mengganti cara pemasaran (cara menarik pengguna); jika ada proyek yang secara aktif memanggil kemampuan kerahasiaan di lapisan bawah, barulah arsitektur ini benar-benar menunjukkan keunggulan diferensiasinya.
Pemisahan arsitekturnya sangat tegas: lapisan dasar bertanggung jawab atas penyelesaian (settlement) dan ketersediaan data, sedangkan lapisan atas menyediakan lingkungan eksekusi yang kompatibel dengan EVM. Dua lapisan menjalankan perannya masing-masing. Menurut saya, pilihan ini sangat pragmatis—memulai ekosistem rantai yang benar-benar dikembangkan sendiri (pure self-developed) terlalu lambat. Setelah disambungkan ke EVM, alat pengembangan yang sudah matang serta sistem audit dapat langsung digunakan ulang, sehingga ambang masuk bagi pengembang turun drastis.
Namun biayanya juga ada di bagian-bagian kunci. Perpindahan aset lintas lapisan memerlukan mekanisme jembatan (bridge), yang menambah asumsi kepercayaan (trust assumptions) dan memperluas permukaan serangan (attack surface). Dalam pengalaman industri, masalah keamanan yang dipicu desain lintas-lapisan jauh lebih banyak daripada kegagapan yang murni berasal dari gangguan pada mesin virtualnya sendiri. Yang lebih terselubung adalah masalah konsistensi privasi: lapisan EVM bersifat transparan, sementara lapisan penyelesaian memiliki kemampuan kerahasiaan (confidential). Kekuatan privasi untuk aset yang sama berubah tergantung lapisan tempatnya berada. Pengguna sulit merasakannya secara intuitif, dan dari sisi kepatuhan (compliance) juga menambah beban penjelasan.
Menurut saya, bentuk yang lebih sehat adalah pembagian peran yang jelas: lapisan EVM menampung aplikasi umum dan likuiditas, sedangkan lapisan rahasia/kerahasiaan (confidential) secara khusus melayani skenario penyelesaian privasi. Jangan dipaksa mengejar kesetaraan fungsi. Narasi yang terlalu samar seperti “mendukung semua skenario” pada akhirnya besar kemungkinan membuat kedua belah pihak tidak dikerjakan dengan baik.
Jadi, ketika menilai nilai arsitektur ini, fokusnya tidak pernah pada sekadar uji performa (benchmark) di testnet. Yang terpenting adalah apakah batas tanggung jawab (boundary) pemisahan perannya cukup jelas. Apakah dokumentasi pengembangan memberikan panduan lapisan skenario yang tegas? Apakah keadaan aset lintas-lapisan dan batas privasinya dijelaskan dengan gamblang? Detail-detail seperti ini jauh lebih penting daripada sekadar parameter.
Selain itu, saya juga akan mengawasi satu sinyal: aplikasi apa yang akhirnya benar-benar dijalankan oleh lapisan EVM. Jika semuanya hanya meniru protokol umum, maka modularitas itu hanya mengganti cara pemasaran (cara menarik pengguna); jika ada proyek yang secara aktif memanggil kemampuan kerahasiaan di lapisan bawah, barulah arsitektur ini benar-benar menunjukkan keunggulan diferensiasinya.