#dusk $DUSK
Dalam beberapa hari ini, saya membaca Developer Update edisi terbaru @Dusk , dan ada satu pembaruan yang menurut saya lebih layak diperhatikan daripada “menambahkan fitur ZK lagi”.
Sekarang zk-tools mulai melengkapi tools untuk menghasilkan dan memverifikasi Groth16 Solidity verifier.
Sekilas terlihat kecil.
Tapi kalau memang pernah menulis aplikasi ZK, Anda tahu bahwa membuat proof itu baru separuh cerita.
Bagian berikutnya ada masalah yang sangat nyata:
bagaimana kontrak Solidity “mengenali” proof ini?
Aturan definisi circuit, prover menghasilkan proof, lalu di sisi EVM tetap diperlukan contract verifier untuk memeriksa apakah proof dan public inputs memenuhi constraint dari circuit yang semula.
Kalau lapisan antarmuka ini tidak dibuat dengan baik, seberapa pun kuat kriptografinya, bagi developer Solidity biasa tetap akan terasa jauh.
Jadi, ketika saya melihat pembaruan Dusk kali ini, fokusnya bukan pada nama Groth16.
Melainkan pada apa yang sedang mereka lengkapi:
proof → verifier → aplikasi Solidity
Rangkaian “engineering” di bagian tengah.
Tentu saja, verifier juga tidaklah sempurna.
Ia hanya bisa memastikan apakah sebuah proof sesuai dengan circuit yang sudah ditulis sebelumnya, tetapi dari mana data itu berasal, apakah aturan ini punya makna bisnis, dan apakah kredensialnya masih berlaku saat ini—itu tetap harus didefinisikan oleh aplikasi itu sendiri.
Justru menurut saya itu normal.
Kriptografi bertugas memastikan “bukti” itu tervalidasi, sementara produk bertugas memutuskan bukti tersebut akan dipakai untuk apa.
DuskEVM saat ini masih di Testnet, jadi saya tidak akan langsung menyimpulkan bahwa seluruh workflow ZK sudah matang hanya karena ada tambahan verifier tooling.
Tapi pembaruan seperti ini setidaknya jauh lebih nyata dibanding sekadar kalimat “mendukung ZK”.
Yang benar-benar membuat developer bisa memakainya, sering kali justru antarmuka yang terlihat tidak terlalu “menggoda”.
Dalam beberapa hari ini, saya membaca Developer Update edisi terbaru @Dusk , dan ada satu pembaruan yang menurut saya lebih layak diperhatikan daripada “menambahkan fitur ZK lagi”.
Sekarang zk-tools mulai melengkapi tools untuk menghasilkan dan memverifikasi Groth16 Solidity verifier.
Sekilas terlihat kecil.
Tapi kalau memang pernah menulis aplikasi ZK, Anda tahu bahwa membuat proof itu baru separuh cerita.
Bagian berikutnya ada masalah yang sangat nyata:
bagaimana kontrak Solidity “mengenali” proof ini?
Aturan definisi circuit, prover menghasilkan proof, lalu di sisi EVM tetap diperlukan contract verifier untuk memeriksa apakah proof dan public inputs memenuhi constraint dari circuit yang semula.
Kalau lapisan antarmuka ini tidak dibuat dengan baik, seberapa pun kuat kriptografinya, bagi developer Solidity biasa tetap akan terasa jauh.
Jadi, ketika saya melihat pembaruan Dusk kali ini, fokusnya bukan pada nama Groth16.
Melainkan pada apa yang sedang mereka lengkapi:
proof → verifier → aplikasi Solidity
Rangkaian “engineering” di bagian tengah.
Tentu saja, verifier juga tidaklah sempurna.
Ia hanya bisa memastikan apakah sebuah proof sesuai dengan circuit yang sudah ditulis sebelumnya, tetapi dari mana data itu berasal, apakah aturan ini punya makna bisnis, dan apakah kredensialnya masih berlaku saat ini—itu tetap harus didefinisikan oleh aplikasi itu sendiri.
Justru menurut saya itu normal.
Kriptografi bertugas memastikan “bukti” itu tervalidasi, sementara produk bertugas memutuskan bukti tersebut akan dipakai untuk apa.
DuskEVM saat ini masih di Testnet, jadi saya tidak akan langsung menyimpulkan bahwa seluruh workflow ZK sudah matang hanya karena ada tambahan verifier tooling.
Tapi pembaruan seperti ini setidaknya jauh lebih nyata dibanding sekadar kalimat “mendukung ZK”.
Yang benar-benar membuat developer bisa memakainya, sering kali justru antarmuka yang terlihat tidak terlalu “menggoda”.