Sesuatu yang terus saya kembali pada arsitektur @Dusk adalah bagaimana ia memisahkan penyelesaian (settlement) dari eksekusi secara sengaja, alih-alih memaksa satu lapisan mengerjakan keduanya.
DuskDS berada di bagian bawah menangani konsensus, ketersediaan data, dan settlement. Di atasnya, DuskVM menjalankan kontrak Rust/WASM native untuk aplikasi yang berfokus pada privasi, sementara DuskEVM memberi pengembang Solidity jalur yang familiar melalui kompatibilitas OP Stack. Gaya eksekusi yang berbeda, tetapi semuanya mem-post kembali ke DuskDS dan mewarisi finalitas yang sama.
Untuk keuangan yang teregulasi, saya pikir pemisahan ini adalah pilihan yang tepat. Obligasi tokenized dan aplikasi perdagangan yang rahasia memiliki kebutuhan eksekusi yang sangat berbeda, tetapi keduanya memerlukan settlement dengan perilaku yang sama setiap kali. Dan karena lisensi NPEX mencakup seluruh tumpukan, sebuah aset tidak keluar dari batas regulasinya hanya karena ia berpindah lingkungan. Satu token DUSK membayar gas di seluruh lapisan, dengan bridge yang dijalankan validator untuk memindahkan nilai di antara lapisan tersebut, bukan memakai aset yang dibungkus (wrapped).
Bagian yang saya anggap mudah untuk diremehkan adalah bahwa menambahkan lingkungan eksekusi adalah setengah yang sederhana. Menjaga semuanya tetap tertambat pada satu settlement dan lapisan data tanpa melemahkannya adalah masalah rekayasa yang lebih sulit — dan celah (seams) di antara lapisan biasanya tempat desain modular diuji. Dusk yang menjeda bridge-nya untuk peninjauan keamanan sebelum peluncuran DuskEVM adalah pertanda baik bahwa mereka memperlakukan celah-celah itu dengan serius.
Hal yang ingin saya lihat berikutnya adalah bagaimana DuskDS bertahan saat DuskEVM membawa beban kerja yang lebih berat dan lebih beragam ke tingkat settlement.
Anda lebih ingin melihat #dusk berkembang ke lebih banyak lingkungan eksekusi, atau terus memperkuat koneksi antara lapisan yang sudah dimilikinya?
$DUSK #dusk @Dusk _Foundation.
DuskDS berada di bagian bawah menangani konsensus, ketersediaan data, dan settlement. Di atasnya, DuskVM menjalankan kontrak Rust/WASM native untuk aplikasi yang berfokus pada privasi, sementara DuskEVM memberi pengembang Solidity jalur yang familiar melalui kompatibilitas OP Stack. Gaya eksekusi yang berbeda, tetapi semuanya mem-post kembali ke DuskDS dan mewarisi finalitas yang sama.
Untuk keuangan yang teregulasi, saya pikir pemisahan ini adalah pilihan yang tepat. Obligasi tokenized dan aplikasi perdagangan yang rahasia memiliki kebutuhan eksekusi yang sangat berbeda, tetapi keduanya memerlukan settlement dengan perilaku yang sama setiap kali. Dan karena lisensi NPEX mencakup seluruh tumpukan, sebuah aset tidak keluar dari batas regulasinya hanya karena ia berpindah lingkungan. Satu token DUSK membayar gas di seluruh lapisan, dengan bridge yang dijalankan validator untuk memindahkan nilai di antara lapisan tersebut, bukan memakai aset yang dibungkus (wrapped).
Bagian yang saya anggap mudah untuk diremehkan adalah bahwa menambahkan lingkungan eksekusi adalah setengah yang sederhana. Menjaga semuanya tetap tertambat pada satu settlement dan lapisan data tanpa melemahkannya adalah masalah rekayasa yang lebih sulit — dan celah (seams) di antara lapisan biasanya tempat desain modular diuji. Dusk yang menjeda bridge-nya untuk peninjauan keamanan sebelum peluncuran DuskEVM adalah pertanda baik bahwa mereka memperlakukan celah-celah itu dengan serius.
Hal yang ingin saya lihat berikutnya adalah bagaimana DuskDS bertahan saat DuskEVM membawa beban kerja yang lebih berat dan lebih beragam ke tingkat settlement.
Anda lebih ingin melihat #dusk berkembang ke lebih banyak lingkungan eksekusi, atau terus memperkuat koneksi antara lapisan yang sudah dimilikinya?
$DUSK #dusk @Dusk _Foundation.
