@Dusk #dusk
$DUSK Komponen Inti
Jaringan Dusk menggunakan arsitektur modular yang dirancang untuk keuangan teregulasi: privasi jika diperlukan, transparansi jika bermanfaat, dan penyelesaian deterministik ketika alur kerja pasar memerlukannya. Secara garis besar:
Komponen :
1. DuskDS
Peran :
Fondasi settlement dan ketersediaan data: konsensus, finalitas, dan model transaksi Dusk
Ke mana selanjutnya :
Dusk memiliki arsitektur dua lapis:
DuskDS – lapisan settlement dan data (konsensus, ketersediaan data, model transaksi)
DuskEVM – lapisan eksekusi EVM tempat smart contract berjalan dan tempat Hedger berada
Halaman ini menjelaskan model transaksi pada DuskDS. Ini menjadi latar belakang bagi mereka yang ingin memahami bagaimana settlement dan privasi bekerja di balik layar. Jika Anda membangun dApps di DuskEVM, Anda sebagian besar akan berinteraksi dengan Hedger dan kontrak EVM.
Phoenix vs Moonlight (di DuskDS)Di DuskDS, nilai dapat berpindah dalam dua cara bawaan:
Moonlight – transfer berbasis akun yang bersifat publik
Phoenix – transfer terselubung, berbasis note, menggunakan bukti zero-knowledge
Pada akhirnya keduanya melakukan settlement di rantai yang sama, tetapi keduanya mengekspos informasi yang berbeda kepada pengamat.
Untuk detail implementasi lengkap, Anda dapat merujuk ke Whitepaper.
Moonlight – saldo publik
Moonlight adalah model transaksi yang transparan:
Akun memiliki saldo yang terlihat.
Transfer menampilkan pengirim, penerima, dan jumlah.
Cocok untuk alur yang harus dapat diamati (mis. beberapa skenario treasury atau pelaporan).
Secara konsep ia berperilaku seperti model akun standar.
Bagi kebanyakan pengguna, ini adalah “cara transparan untuk memindahkan DUSK” di level protokol.
Phoenix – saldo terselubung
Phoenix adalah model yang menjaga privasi:
Dana disimpan sebagai “note” terenkripsi, bukan sebagai saldo eksplisit.
Transaksi membuktikan kebenaran (tidak ada double spend, cukup dana) dengan bukti zero-knowledge tanpa mengungkap:berapa banyak yang dipindahkan,siapa yang mengirim note, kecuali kepada penerima,di antara note-note spesifik mana.
Pengguna dapat mengungkapkan informasi secara selektif melalui viewing keys ketika regulasi atau audit memerlukannya.
$DUSK Komponen Inti
Jaringan Dusk menggunakan arsitektur modular yang dirancang untuk keuangan teregulasi: privasi jika diperlukan, transparansi jika bermanfaat, dan penyelesaian deterministik ketika alur kerja pasar memerlukannya. Secara garis besar:
Komponen :
1. DuskDS
Peran :
Fondasi settlement dan ketersediaan data: konsensus, finalitas, dan model transaksi Dusk
Ke mana selanjutnya :
Dusk memiliki arsitektur dua lapis:
DuskDS – lapisan settlement dan data (konsensus, ketersediaan data, model transaksi)
DuskEVM – lapisan eksekusi EVM tempat smart contract berjalan dan tempat Hedger berada
Halaman ini menjelaskan model transaksi pada DuskDS. Ini menjadi latar belakang bagi mereka yang ingin memahami bagaimana settlement dan privasi bekerja di balik layar. Jika Anda membangun dApps di DuskEVM, Anda sebagian besar akan berinteraksi dengan Hedger dan kontrak EVM.
Phoenix vs Moonlight (di DuskDS)Di DuskDS, nilai dapat berpindah dalam dua cara bawaan:
Moonlight – transfer berbasis akun yang bersifat publik
Phoenix – transfer terselubung, berbasis note, menggunakan bukti zero-knowledge
Pada akhirnya keduanya melakukan settlement di rantai yang sama, tetapi keduanya mengekspos informasi yang berbeda kepada pengamat.
Untuk detail implementasi lengkap, Anda dapat merujuk ke Whitepaper.
Moonlight – saldo publik
Moonlight adalah model transaksi yang transparan:
Akun memiliki saldo yang terlihat.
Transfer menampilkan pengirim, penerima, dan jumlah.
Cocok untuk alur yang harus dapat diamati (mis. beberapa skenario treasury atau pelaporan).
Secara konsep ia berperilaku seperti model akun standar.
Bagi kebanyakan pengguna, ini adalah “cara transparan untuk memindahkan DUSK” di level protokol.
Phoenix – saldo terselubung
Phoenix adalah model yang menjaga privasi:
Dana disimpan sebagai “note” terenkripsi, bukan sebagai saldo eksplisit.
Transaksi membuktikan kebenaran (tidak ada double spend, cukup dana) dengan bukti zero-knowledge tanpa mengungkap:berapa banyak yang dipindahkan,siapa yang mengirim note, kecuali kepada penerima,di antara note-note spesifik mana.
Pengguna dapat mengungkapkan informasi secara selektif melalui viewing keys ketika regulasi atau audit memerlukannya.
