Saya mencoba melacak di mana privasi sebenarnya dimulai di dalam aplikasi Solidity pada @Dusk .
Saya berasumsi bahwa sebuah kontrak yang dideploy di DuskEVM akan entah bagaimana mewarisi privasi Dusk karena data dan settlement-nya akhirnya melewati DuskDS.
Namun, begitulah cara stack itu tidak bekerja.
DuskEVM memberi pengembang eksekusi EVM yang sudah familiar. Mereka bisa menggunakan Solidity, Hardhat, Foundry, dan wallet yang sudah ada.
DuskDS berada di bawahnya sebagai dasar settlement dan ketersediaan data.
Tetapi sebuah kontrak Solidity biasa tetap bisa mempublikasikan statusnya seperti aplikasi EVM lainnya.
Kerahasiaan harus dirancang ke dalam aplikasi melalui Hedger, atau ditangani lebih dekat ke jalur privasi native Dusk melalui DuskVM dan Phoenix.
Kerahasiaan tidak otomatis ditambahkan hanya karena kontrak tersebut berjalan di dalam ekosistem Dusk.
Batas itulah yang membuat saya berhenti.
Bayangkan sebuah pasar obligasi yang ditokenisasi.
Harga pasar mungkin perlu tetap publik.
Kelayakan investor hanya perlu dibuktikan.
Saldo pemegang kemungkinan besar harus tetap privat.
Penerbit atau regulator mungkin memerlukan akses terkontrol ke catatan tertentu.
Keempat bagian itu tidak bisa begitu saja ditempatkan di dalam status Solidity publik yang sama.
Hedger dimaksudkan untuk memecahkan sebagian masalah ini dengan menjaga nilai tetap terenkripsi sementara proof pengetahuan nol memverifikasi bahwa transaksi mengikuti aturannya.
Tapi pengembang tetap harus memutuskan apa yang masuk ke alur terenkripsi, apa yang tetap publik, dan siapa yang menerima hak pengungkapan.
Satu pilihan desain yang buruk saja bisa mengekspos data keuangan sensitif sebelum kriptografi sempat melindunginya.
Jadi, saya kurang fokus pada berapa banyak primitive kriptografi yang didukung Dusk.
Saya mengamati apakah alat-alatnya membuat batas publik/privat cukup jelas agar tim Solidity biasa bisa menggunakannya dengan benar.
Dusk dapat menyediakan jalur privasinya.
Dusk tidak bisa membuat keputusan arsitektur itu untuk setiap aplikasi.
#dusk $DUSK
Saya berasumsi bahwa sebuah kontrak yang dideploy di DuskEVM akan entah bagaimana mewarisi privasi Dusk karena data dan settlement-nya akhirnya melewati DuskDS.
Namun, begitulah cara stack itu tidak bekerja.
DuskEVM memberi pengembang eksekusi EVM yang sudah familiar. Mereka bisa menggunakan Solidity, Hardhat, Foundry, dan wallet yang sudah ada.
DuskDS berada di bawahnya sebagai dasar settlement dan ketersediaan data.
Tetapi sebuah kontrak Solidity biasa tetap bisa mempublikasikan statusnya seperti aplikasi EVM lainnya.
Kerahasiaan harus dirancang ke dalam aplikasi melalui Hedger, atau ditangani lebih dekat ke jalur privasi native Dusk melalui DuskVM dan Phoenix.
Kerahasiaan tidak otomatis ditambahkan hanya karena kontrak tersebut berjalan di dalam ekosistem Dusk.
Batas itulah yang membuat saya berhenti.
Bayangkan sebuah pasar obligasi yang ditokenisasi.
Harga pasar mungkin perlu tetap publik.
Kelayakan investor hanya perlu dibuktikan.
Saldo pemegang kemungkinan besar harus tetap privat.
Penerbit atau regulator mungkin memerlukan akses terkontrol ke catatan tertentu.
Keempat bagian itu tidak bisa begitu saja ditempatkan di dalam status Solidity publik yang sama.
Hedger dimaksudkan untuk memecahkan sebagian masalah ini dengan menjaga nilai tetap terenkripsi sementara proof pengetahuan nol memverifikasi bahwa transaksi mengikuti aturannya.
Tapi pengembang tetap harus memutuskan apa yang masuk ke alur terenkripsi, apa yang tetap publik, dan siapa yang menerima hak pengungkapan.
Satu pilihan desain yang buruk saja bisa mengekspos data keuangan sensitif sebelum kriptografi sempat melindunginya.
Jadi, saya kurang fokus pada berapa banyak primitive kriptografi yang didukung Dusk.
Saya mengamati apakah alat-alatnya membuat batas publik/privat cukup jelas agar tim Solidity biasa bisa menggunakannya dengan benar.
Dusk dapat menyediakan jalur privasinya.
Dusk tidak bisa membuat keputusan arsitektur itu untuk setiap aplikasi.
#dusk $DUSK
