duskvm

Saya terus-menerus melakukan kesalahan dalam satu hal saat memikirkan Moonlight dan Phoenix: Saya memperlakukan bentuk status seolah-olah itu juga menentukan finalitas.

Asumsi itu mulai mengganggu saya.
Moonlight tiba di #DuskVM dengan membawa model akun publik: Saldo, Pengirim, Penerima, Jumlah, dan Perkembangan Nonce.
Phoenix dibangun di sekitar jalur yang sama sekali berbeda: Catatan Terenkripsi, Output Terlindungi, Pembatal, dan Status Pribadi.
Naluri pertama saya adalah bahwa dua sistem yang sangat berbeda tersebut mungkin membutuhkan dua cara berbeda untuk menjadi final.

Tetapi mungkin di situlah saya menambahkan kompleksitas yang sebenarnya tidak ada.
Moonlight dapat tetap berbentuk akun. Phoenix dapat tetap berbentuk catatan. #DuskVM tidak perlu meratakan salah satu dari keduanya ke dalam format status universal hanya untuk memutuskan kapan eksekusi selesai.

Itu juga membuat saya mempertimbangkan kembali #DuskDS .
Saya sebelumnya berasumsi bahwa itu perlu membuat satu status bersama $DUSK di bawah kedua model. Sekarang saya kurang yakin akan hal itu.
Logika eksekusi dapat tetap terspesialisasi sementara Dusk L1 masih memberikan status hasil satu batas akhir deterministik.
Dan jujur ​​saja, pemisahan itu lebih menarik bagi saya daripada model status individual.
Cara yang berbeda untuk merepresentasikan status tidak selalu memerlukan jawaban yang berbeda untuk pertanyaan kapan status itu akhirnya selesai.
Hal yang masih saya pertanyakan adalah seberapa bersih pemisahan ini berlaku ketika Moonlight dan Phoenix menjadi lebih kompleks.

#dusk $DUSK @Dusk

#dusk $DUSK @Dusk
Tumpukan Modular Dusk: Tiga Lapisan, Satu Tujuan

Bagaimana jika arsitektur blockchain memperlakukan penyelesaian (settlement) dan eksekusi sebagai pekerjaan yang terpisah?

@Dusk mengambil pendekatan itu dengan desain modular yang dibangun di sekitar tiga komponen:

1. DuskDS — fondasi settlement
Ini menangani konsensus, finalitas, ketersediaan data, dan model transaksi asli Dusk, termasuk Moonlight untuk transfer publik dan Phoenix untuk transfer terlindungi (shielded).

2. DuskEVM — jalur EVM
Pengembang dapat menggunakan Solidity dan alat bantu Ethereum yang sudah familiar sementara aplikasi menyelesaikan transaksi melalui DuskDS. Ini membuat lingkungannya lebih mudah diakses untuk DeFi berbasis EVM dan aplikasi aset tokenisasi.

3. DuskVM — eksekusi langsung L1
DuskVM menjalankan kontrak pintar Rust/WASM secara langsung di Dusk L1, sehingga cocok untuk aplikasi yang membutuhkan akses lebih dalam ke model transaksi Dusk, privasi, atau kapabilitas zero-knowledge.

Bagian yang menarik justru pemisahannya: aplikasi yang berbeda dapat memilih lingkungan eksekusi yang mereka butuhkan tanpa mengganti lapisan settlement yang menjadi dasar.

Untuk $DUSK , ini menciptakan fondasi agar kompatibilitas EVM, eksekusi langsung L1, privasi, dan settlement deterministik dapat bekerja dalam arsitektur yang lebih luas yang sama.

#DUSK #DuskEVM #DuskVM

Polling: 🏗️ Bagian mana dari arsitektur modular Dusk yang paling menarik minat Anda?

@Dusk sedang membangun sesuatu di DeFi dan tokenized finance akan semakin membutuhkan: privasi tanpa kehilangan kepatuhan. Public blockchains kuat karena transaksi dapat transparan dan dapat diverifikasi, tetapi pasar keuangan yang teregulasi tidak boleh mempublikasikan setiap saldo, posisi, detail investor, atau transaksi secara terbuka. @Dusk mendekati tantangan ini dengan menggabungkan teknologi zero-knowledge, confidential transfers, selective disclosure, access controls, dan deterministic settlement. �
Dusk +1
Yang membuat pendekatan ini menarik adalah gagasan bahwa privasi tidak harus berarti menyembunyikan semuanya. Peserta yang berwenang dapat menerima informasi yang mereka butuhkan, sementara data sensitif tetap terlindungi dari paparan publik yang tidak perlu. Ini bisa sangat relevan untuk sekuritas tokenized, real-world assets, institutional DeFi, dan alur kerja keuangan lainnya di mana kriteria kelayakan, pelaporan, batasan transfer, serta aturan settlement menjadi penting. �
DOCS +1
Dusk juga menggunakan arsitektur modular, dengan #DuskDS berfokus pada settlement dan data availability, #DuskVM untuk eksekusi native Rust/WASM, dan #DuskEVM untuk aplikasi yang kompatibel dengan EVM. Itu memberi pengembang jalur yang berbeda tergantung apakah sebuah aplikasi memprioritaskan privasi native, tooling EVM yang sudah familiar, atau infrastruktur settlement yang sesuai regulasi. �
DOCS
Bagi saya, bagian menarik dari Dusk bukan sekadar “privasi”. Yang menarik adalah kombinasi privasi, kepatuhan, dan settlement yang dapat diprediksi dalam satu infrastruktur keuangan. Jika lebih banyak real-world assets dan pasar institusional beralih ke on-chain, kapabilitas ini bisa menjadi semakin penting. #dusk $DUSK