Saya meninjau kembali dokumentasi Dusk tadi malam, dan saya jadi lebih tertarik pada pertanyaan desain daripada klaim teknis.

Hal pertama yang langsung menarik perhatian saya adalah pemisahan antara Moonlight dan Phoenix. Moonlight berbasis akun, dengan kunci publik, nonce, dan saldo, sementara Phoenix menggunakan UTXO sebagai “catatan” di dalam sebuah pohon Merkle. Bidang transaksi Moonlight mencakup from, to, value, nonce, deposit, data, gas_limit, gas_price, dan signature, dengan gas maksimum dihitung sebagai gas_limit × gas_price.

Phoenix menjadi semakin menarik. Ia menggunakan kurva Jubjub, dengan kunci publik (A,B), kunci rahasia (a,b), dan kunci view (a,B). Struktur catatan mencakup type, com, enc, npk, R, dan encsender. Kunci catatan sekali pakai diturunkan sebagai npk = H(rA)G + B, sedangkan kunci pembelanjaan adalah nsk = H(aR) + b.

Saya masih mencoba memahami batas kepercayaan seputar pembuatan bukti ZK dan delegated scanning. Dokumentasinya menyatakan pihak ketiga dapat menghasilkan bukti atau melakukan pemindaian menggunakan view keys tanpa memperoleh otoritas pembelanjaan, tetapi di mana titik-titik kegagalannya?

Dan dengan nullifier, Merkle roots terbaru, serta gas yang ditangani di dalam bukti, bagaimana mekanisme ini berperilaku dalam kondisi jaringan yang bersifat adversarial? Bagian mana yang terdesentralisasi, dan asumsi mana yang sebaiknya diteliti pengguna?

#dusk $DUSK @Dusk