Semalaman aku tidak bisa tidur, meneliti dokumen whitepaper $DUSK , membaca bagian struktur note Phoenix. Ada satu kalimat yang membuatku berhenti dan menatapnya cukup lama
Field terenkripsi pada note, enc, dienkripsi menggunakan view key milik penerima. Whitepaper mengatakan bahwa view key memungkinkan pengguna mendelegasikan izin untuk mencari transaksi lewat jaringan hasil pemindaian kepada pihak ketiga, tetapi pihak tersebut tidak mendapatkan secret key lengkap, sehingga mereka tidak bisa membelanjakan uang
Awalnya aku kurang memperhatikan detail ini. Setelah kupikirkan lebih dalam, ternyata ini adalah inti dari kriptografi untuk selective disclosure. Data transaksi yang sama, tetapi akses yang berbeda dikendalikan oleh kunci yang berbeda
Definisi view key di whitepaper adalah (a, B), sedangkan secret key adalah (a, b). Hilangnya satu komponen kunci privat b menambah satu lapisan batas keamanan. Data terenkripsi note dapat didekripsi untuk dilihat, tetapi tidak dapat menghasilkan nullifier yang sesuai untuk membelanjakannya. Inti dari mekanisme ini adalah: kendali dan hak penggunaan dapat dipisahkan
Bagi publik, transaksi terenkripsi; bukti ZK hanya memverifikasi kebenaran tanpa membuka data. Bagi regulator, pihak yang berwenang memperoleh view key sehingga bisa mendekripsi isi detail note, memverifikasi saldo, pihak lawan transaksi, dan kepatuhan, tetapi tidak bisa menggunakan dana. @Dusk situs resminya menyebut ini controlled visibility for audit, supervision, and regulated disclosure—semakin kubaca, semakin kurasa istilah itu tepat
Satu set kunci kriptografi, sekaligus menyelesaikan dua kebutuhan yang tampak bertentangan: privasi dan kepatuhan. Publik tidak melihat, regulator bisa melihat dengan jelas, dan pengguna yang memutuskan sendiri
#dusk
Tapi jujur, aku belum sepenuhnya memahami bagaimana menyelaraskan mekanisme view key ini di lingkungan EVM Hedger. View key dalam whitepaper dirancang untuk model UTXO native Phoenix, sedangkan Hedger memakai model hybrid UTXO/akun. Apakah sistem kunci keduanya bisa dipetakan dengan mulus, aku belum menemukan jawaban yang jelas
Field terenkripsi pada note, enc, dienkripsi menggunakan view key milik penerima. Whitepaper mengatakan bahwa view key memungkinkan pengguna mendelegasikan izin untuk mencari transaksi lewat jaringan hasil pemindaian kepada pihak ketiga, tetapi pihak tersebut tidak mendapatkan secret key lengkap, sehingga mereka tidak bisa membelanjakan uang
Awalnya aku kurang memperhatikan detail ini. Setelah kupikirkan lebih dalam, ternyata ini adalah inti dari kriptografi untuk selective disclosure. Data transaksi yang sama, tetapi akses yang berbeda dikendalikan oleh kunci yang berbeda
Definisi view key di whitepaper adalah (a, B), sedangkan secret key adalah (a, b). Hilangnya satu komponen kunci privat b menambah satu lapisan batas keamanan. Data terenkripsi note dapat didekripsi untuk dilihat, tetapi tidak dapat menghasilkan nullifier yang sesuai untuk membelanjakannya. Inti dari mekanisme ini adalah: kendali dan hak penggunaan dapat dipisahkan
Bagi publik, transaksi terenkripsi; bukti ZK hanya memverifikasi kebenaran tanpa membuka data. Bagi regulator, pihak yang berwenang memperoleh view key sehingga bisa mendekripsi isi detail note, memverifikasi saldo, pihak lawan transaksi, dan kepatuhan, tetapi tidak bisa menggunakan dana. @Dusk situs resminya menyebut ini controlled visibility for audit, supervision, and regulated disclosure—semakin kubaca, semakin kurasa istilah itu tepat
Satu set kunci kriptografi, sekaligus menyelesaikan dua kebutuhan yang tampak bertentangan: privasi dan kepatuhan. Publik tidak melihat, regulator bisa melihat dengan jelas, dan pengguna yang memutuskan sendiri
#dusk
Tapi jujur, aku belum sepenuhnya memahami bagaimana menyelaraskan mekanisme view key ini di lingkungan EVM Hedger. View key dalam whitepaper dirancang untuk model UTXO native Phoenix, sedangkan Hedger memakai model hybrid UTXO/akun. Apakah sistem kunci keduanya bisa dipetakan dengan mulus, aku belum menemukan jawaban yang jelas