#dusk $DUSK
Frasa “host functions” terus muncul di whitepaper Dusk, dan saya terus menganggapnya sebagai detail implementasi. Saat saya benar-benar membaca bagian performa, ternyata itu adalah keputusan arsitektural yang lebih disengaja daripada sekadar detail.
Menjalankan ZK di dalam WASM VM: whitepaper mengutip riset yang menunjukkan bahwa eksekusi WASM dapat menjadi 45-255% lebih lambat dibandingkan kode native untuk aplikasi yang kompleks. Overhead ini berasal dari manajemen memori yang tervirtualisasi dan penanganan instruksi tambahan di dalam lingkungan sandbox. Untuk hashing dan validasi tanda tangan itu menyebalkan. Untuk verifikasi bukti ZK yang berjalan pada setiap transaksi, pelambatan 45-255% adalah masalah besar bagi throughput.
Host functions: Dusk mengekspos sejumlah fungsi yang berjalan secara native di mesin host, di luar sandbox WASM. verify_plonk, verify_groth16_bn254, verify_schnorr, verify_bls, dan hash. Kontrak pintar memanggilnya secara langsung; pekerjaan kriptografi yang berat berjalan dengan kecepatan native. Hasilnya direplikasi di seluruh node dengan cara yang sama seperti komputasi lain.
Jadi mengapa tidak semua rantai yang menjalankan ZK melakukan ini.
Memindahkan komputasi keluar dari VM mengurangi jaminan sandboxing. Dalam model eksekusi WASM murni, kontrak yang buggy atau berbahaya diisolasi di dalam batas VM. Saat Anda menambahkan host functions, Anda mengekspos akses tingkat native ke operasi tertentu — dan bug atau salah konfigurasi pada lapisan host function dapat menimbulkan konsekuensi yang tidak bisa dihasilkan sendiri oleh kontrak sandboxed. Anda menukar isolasi dengan throughput.
Saya justru merasa argumen efisiensi energi lebih menarik daripada argumen kecepatan—whitepaper menempatkan host functions sebagian sebagai cara untuk mengurangi biaya energi per-node, bukan hanya latensi. Itu adalah cara pandang yang tidak biasa untuk dokumen desain blockchain.
Yang belum saya lihat dijelaskan adalah bagaimana Dusk menangani versioning host function—apakah perubahan terhadap perilaku sebuah host function merupakan perubahan protokol yang memerlukan konsensus, atau apakah operator bisa memperbarui implementasinya secara independen. @Dusk
$DUSK #dusk
Frasa “host functions” terus muncul di whitepaper Dusk, dan saya terus menganggapnya sebagai detail implementasi. Saat saya benar-benar membaca bagian performa, ternyata itu adalah keputusan arsitektural yang lebih disengaja daripada sekadar detail.
Menjalankan ZK di dalam WASM VM: whitepaper mengutip riset yang menunjukkan bahwa eksekusi WASM dapat menjadi 45-255% lebih lambat dibandingkan kode native untuk aplikasi yang kompleks. Overhead ini berasal dari manajemen memori yang tervirtualisasi dan penanganan instruksi tambahan di dalam lingkungan sandbox. Untuk hashing dan validasi tanda tangan itu menyebalkan. Untuk verifikasi bukti ZK yang berjalan pada setiap transaksi, pelambatan 45-255% adalah masalah besar bagi throughput.
Host functions: Dusk mengekspos sejumlah fungsi yang berjalan secara native di mesin host, di luar sandbox WASM. verify_plonk, verify_groth16_bn254, verify_schnorr, verify_bls, dan hash. Kontrak pintar memanggilnya secara langsung; pekerjaan kriptografi yang berat berjalan dengan kecepatan native. Hasilnya direplikasi di seluruh node dengan cara yang sama seperti komputasi lain.
Jadi mengapa tidak semua rantai yang menjalankan ZK melakukan ini.
Memindahkan komputasi keluar dari VM mengurangi jaminan sandboxing. Dalam model eksekusi WASM murni, kontrak yang buggy atau berbahaya diisolasi di dalam batas VM. Saat Anda menambahkan host functions, Anda mengekspos akses tingkat native ke operasi tertentu — dan bug atau salah konfigurasi pada lapisan host function dapat menimbulkan konsekuensi yang tidak bisa dihasilkan sendiri oleh kontrak sandboxed. Anda menukar isolasi dengan throughput.
Saya justru merasa argumen efisiensi energi lebih menarik daripada argumen kecepatan—whitepaper menempatkan host functions sebagian sebagai cara untuk mengurangi biaya energi per-node, bukan hanya latensi. Itu adalah cara pandang yang tidak biasa untuk dokumen desain blockchain.
Yang belum saya lihat dijelaskan adalah bagaimana Dusk menangani versioning host function—apakah perubahan terhadap perilaku sebuah host function merupakan perubahan protokol yang memerlukan konsensus, atau apakah operator bisa memperbarui implementasinya secara independen. @Dusk
$DUSK #dusk
