#dusk $DUSK @Dusk
Telah membandingkan jalur verifikasi kriptografis Dusk dengan apa yang akan diperlukan oleh alternatif yang sepenuhnya tersandbox, sejak "moved outside WASM" disebutkan tanpa landasan numerik yang kuat di sebagian besar bacaan yang saya temui.
Materi Dusk sendiri mengonfirmasi bahwa Piecrust mengekspos hashing, verifikasi PLONK, verifikasi Groth16, dan pemeriksaan tanda tangan sebagai fungsi host — kode native yang dipanggil langsung oleh runtime, melewati mesin virtual WASM sepenuhnya untuk operasi-operasi spesifik ini. Secara terpisah, saya menemukan bahwa Phoenix secara khusus menggunakan varian tanda tangan double-Schnorr, yang dijelaskan di repositori Dusk sebagai pengenalan baru yang mendelegasikan komputasi bukti tanpa mengekspos kunci rahasia penandatangan — artinya bahkan lapisan tanda tangan, bukan hanya lapisan bukti ZK, dirancang untuk berjalan melalui jalur native ini.
Hitunglah apa yang tetap berada di dalam WASM versus apa yang tidak. Logika kontrak umum — perubahan status, aturan bisnis — berjalan tersandbox. Setiap primitif kriptografis yang benar-benar bergantung pada transaksi Phoenix berjalan secara native.
Ini masih sebuah hipotesis yang layak dinyatakan dengan tepat: saya belum menemukan benchmark yang dipublikasikan secara spesifik untuk mengukur seberapa jauh lebih lambat verifikasi Phoenix jika pemeriksaan ini tetap berada di dalam WASM dibandingkan jika dijalankan sebagai fungsi host pada pengaturan Dusk saat ini.
Apa yang berubah dalam pembacaan saya: saya semula mengira ini murni pilihan optimasi. Namun ini juga merupakan pilihan batas keamanan — kode native membawa sifat permukaan serangan yang berbeda dibanding kode WASM tersandbox, yang tidak tercakup hanya oleh kerangka performa.
Telah membandingkan jalur verifikasi kriptografis Dusk dengan apa yang akan diperlukan oleh alternatif yang sepenuhnya tersandbox, sejak "moved outside WASM" disebutkan tanpa landasan numerik yang kuat di sebagian besar bacaan yang saya temui.
Materi Dusk sendiri mengonfirmasi bahwa Piecrust mengekspos hashing, verifikasi PLONK, verifikasi Groth16, dan pemeriksaan tanda tangan sebagai fungsi host — kode native yang dipanggil langsung oleh runtime, melewati mesin virtual WASM sepenuhnya untuk operasi-operasi spesifik ini. Secara terpisah, saya menemukan bahwa Phoenix secara khusus menggunakan varian tanda tangan double-Schnorr, yang dijelaskan di repositori Dusk sebagai pengenalan baru yang mendelegasikan komputasi bukti tanpa mengekspos kunci rahasia penandatangan — artinya bahkan lapisan tanda tangan, bukan hanya lapisan bukti ZK, dirancang untuk berjalan melalui jalur native ini.
Hitunglah apa yang tetap berada di dalam WASM versus apa yang tidak. Logika kontrak umum — perubahan status, aturan bisnis — berjalan tersandbox. Setiap primitif kriptografis yang benar-benar bergantung pada transaksi Phoenix berjalan secara native.
Ini masih sebuah hipotesis yang layak dinyatakan dengan tepat: saya belum menemukan benchmark yang dipublikasikan secara spesifik untuk mengukur seberapa jauh lebih lambat verifikasi Phoenix jika pemeriksaan ini tetap berada di dalam WASM dibandingkan jika dijalankan sebagai fungsi host pada pengaturan Dusk saat ini.
Apa yang berubah dalam pembacaan saya: saya semula mengira ini murni pilihan optimasi. Namun ini juga merupakan pilihan batas keamanan — kode native membawa sifat permukaan serangan yang berbeda dibanding kode WASM tersandbox, yang tidak tercakup hanya oleh kerangka performa.
Pure optimization
100%
Also a security tradeoff
0%
1 Voting • Voting ditutup