THE INTERESTING PART OF DUSK'S PRIVACY MODEL MAY BE WHAT IT DOESN'T PUT ONCHAIN
I kept thinking about Dusk's privacy architecture from the opposite direction: not what it hides, but what the network still needs to know.
Phoenix uses shielded UTXOs where notes are committed into a Merkle tree and spent using nullifiers. The underlying transaction can remain confidential while the network verifies the rules required for valid state transitions.
That creates a very specific division of information.
The whitepaper describes the transaction structure as containing the Merkle root, nullifiers, new notes, optional deposits/data, gas parameters and a ZK proof. The network verifies the proof against public inputs rather than directly checking the hidden transaction details.
But here's the detail I find more important.
Dusk isn't trying to make everything permanently invisible.
The architecture also includes Citadel 2, where users can selectively disclose credentials when an application needs proof of eligibility. The Executive Summary describes this as allowing a user to prove possession of a registered license without revealing the license contents.
So the design isn't really:
private vs public.
It's closer to:
private by default + prove only what the application requires.
That is a much more useful model for regulated finance.
But there is still an unresolved operational question. The research specifically flags the possibility that integration with KYC systems and session information could create linkability even when the underlying personal data isn't stored onchain.
Cryptography can protect the transaction.
It can't automatically guarantee that every application built around the transaction preserves the same privacy properties.
That's the part I'd watch.
Can Dusk maintain selective disclosure without allowing the surrounding compliance infrastructure to quietly recreate the surveillance it was designed to avoid?
@Dusk $DUSK #dusk
I kept thinking about Dusk's privacy architecture from the opposite direction: not what it hides, but what the network still needs to know.
Phoenix uses shielded UTXOs where notes are committed into a Merkle tree and spent using nullifiers. The underlying transaction can remain confidential while the network verifies the rules required for valid state transitions.
That creates a very specific division of information.
The whitepaper describes the transaction structure as containing the Merkle root, nullifiers, new notes, optional deposits/data, gas parameters and a ZK proof. The network verifies the proof against public inputs rather than directly checking the hidden transaction details.
But here's the detail I find more important.
Dusk isn't trying to make everything permanently invisible.
The architecture also includes Citadel 2, where users can selectively disclose credentials when an application needs proof of eligibility. The Executive Summary describes this as allowing a user to prove possession of a registered license without revealing the license contents.
So the design isn't really:
private vs public.
It's closer to:
private by default + prove only what the application requires.
That is a much more useful model for regulated finance.
But there is still an unresolved operational question. The research specifically flags the possibility that integration with KYC systems and session information could create linkability even when the underlying personal data isn't stored onchain.
Cryptography can protect the transaction.
It can't automatically guarantee that every application built around the transaction preserves the same privacy properties.
That's the part I'd watch.
Can Dusk maintain selective disclosure without allowing the surrounding compliance infrastructure to quietly recreate the surveillance it was designed to avoid?
@Dusk $DUSK #dusk