Jadi, izinkan saya memandu Anda melalui arsitektur privasi Dusk ini. Arsitektur tersebut benar-benar dibangun di atas kumpulan tertentu primitif kriptografi, dan ini penting: masing-masing dari semuanya punya tugas yang tidak bisa dilakukan oleh yang lain.
Mulai dari BLS12-381—itulah yang @Dusk_Foundation gunakan untuk menguatkan tanda tangan dan sebagian besar kriptografi terkait ZK-nya. Lalu, khusus untuk lapisan privasi Phoenix, Dusk mengandalkan sesuatu yang disebut JubJub, yaitu kurva yang ramah SNARK. Dan jujur saja, tanpa itu, bukti terlindungi (shielded proofs) di Dusk akan jauh terlalu lambat untuk benar-benar dijalankan dalam praktik.
Untuk autentikasi di seluruh jaringan, $DUSK tetap menggunakan tanda tangan Schnorr: pilihan yang bersih dan sudah diuji dengan baik, tidak ada unsur eksperimen di dalamnya. Sekarang, di dalam sirkuit ZK Dusk, hashing ditangani oleh Poseidon, dan yang satu ini dibangun khusus agar tetap murah dalam konteks ketika fungsi hash yang lebih lama justru cepat menjadi mahal begitu Anda menjatuhkannya ke dalam sebuah sirkuit.
Saat membahas bukti status dan keanggotaan, #dusk menggunakan sparse Merkle tree, dan seluruh lapisan pembuatan serta verifikasi berjalan di atas PLONK. Di atas semuanya itu, Dusk juga menerapkan sesuatu yang disebut agregasi BLS—pada dasarnya ini mengompres tanda tangan seluruh sebuah komite menjadi satu paket tunggal, alih-alih jaringan harus memverifikasi satu per satu.
Baik, izinkan saya merangkum barisan lengkapnya agar jelas:
BLS12-381 — tanda tangan dan kriptografi terkait ZK
JubJub — kurva ramah SNARK yang menjadi dasar privasi gaya Phoenix
Schnorr — tanda tangan dan autentikasi
Poseidon — hashing ramah ZK
Sparse Merkle tree — bukti keanggotaan dan status
PLONK — proving dan verifikasi ZK
Agregasi BLS — mengompres tanda tangan komite menjadi satu
Nah, ada sesuatu yang perlu diperhatikan: masing-masing primitif ini pada dasarnya tidak berarti banyak hanya kalau sekadar dibiarkan tergeletak di atas kertas. Kriptografi Dusk bisa saja sepenuhnya kuat secara matematis, tetapi tetap bisa dirusak dalam praktik—misalnya karena serialisasi yang buruk, pemeriksaan subgroup yang terlewat, pengikatan binding transkrip yang lemah, atau pemisahan domain yang dilewati. Jadi, kalau Anda benar-benar ingin menilai fondasi kriptografi Dusk secara adil.
Mulai dari BLS12-381—itulah yang @Dusk_Foundation gunakan untuk menguatkan tanda tangan dan sebagian besar kriptografi terkait ZK-nya. Lalu, khusus untuk lapisan privasi Phoenix, Dusk mengandalkan sesuatu yang disebut JubJub, yaitu kurva yang ramah SNARK. Dan jujur saja, tanpa itu, bukti terlindungi (shielded proofs) di Dusk akan jauh terlalu lambat untuk benar-benar dijalankan dalam praktik.
Untuk autentikasi di seluruh jaringan, $DUSK tetap menggunakan tanda tangan Schnorr: pilihan yang bersih dan sudah diuji dengan baik, tidak ada unsur eksperimen di dalamnya. Sekarang, di dalam sirkuit ZK Dusk, hashing ditangani oleh Poseidon, dan yang satu ini dibangun khusus agar tetap murah dalam konteks ketika fungsi hash yang lebih lama justru cepat menjadi mahal begitu Anda menjatuhkannya ke dalam sebuah sirkuit.
Saat membahas bukti status dan keanggotaan, #dusk menggunakan sparse Merkle tree, dan seluruh lapisan pembuatan serta verifikasi berjalan di atas PLONK. Di atas semuanya itu, Dusk juga menerapkan sesuatu yang disebut agregasi BLS—pada dasarnya ini mengompres tanda tangan seluruh sebuah komite menjadi satu paket tunggal, alih-alih jaringan harus memverifikasi satu per satu.
Baik, izinkan saya merangkum barisan lengkapnya agar jelas:
BLS12-381 — tanda tangan dan kriptografi terkait ZK
JubJub — kurva ramah SNARK yang menjadi dasar privasi gaya Phoenix
Schnorr — tanda tangan dan autentikasi
Poseidon — hashing ramah ZK
Sparse Merkle tree — bukti keanggotaan dan status
PLONK — proving dan verifikasi ZK
Agregasi BLS — mengompres tanda tangan komite menjadi satu
Nah, ada sesuatu yang perlu diperhatikan: masing-masing primitif ini pada dasarnya tidak berarti banyak hanya kalau sekadar dibiarkan tergeletak di atas kertas. Kriptografi Dusk bisa saja sepenuhnya kuat secara matematis, tetapi tetap bisa dirusak dalam praktik—misalnya karena serialisasi yang buruk, pemeriksaan subgroup yang terlewat, pengikatan binding transkrip yang lemah, atau pemisahan domain yang dilewati. Jadi, kalau Anda benar-benar ingin menilai fondasi kriptografi Dusk secara adil.