#dusk $DUSK Today I was reviewing the transaction model documentation for Dusk@Dusk . I originally thought Dusk was a “privacy chain”—meaning all transactions are anonymous by default, like Monero or Zcash. But in DuskDS, two transaction models run side by side: Moonlight is public and account-based; Phoenix is shielded, using a UTXO model plus zero-knowledge proofs. Both models use the same $DUSK token and go through the same Transfer contract.
At first, this design felt contradictory: why would a privacy chain keep a public model? But thinking it through, Moonlight’s existence is precisely for compliance. In traditional financial institutions, regulators require visibility into account balances and transaction records. On a fully private on-chain system, auditors can’t even look up the ledger, let alone pass compliance checks. Moonlight provides a transparent experience similar to traditional bank accounts—account addresses, balances, and transaction history.
Phoenix takes a different route: a UTXO model plus zero-knowledge proofs. Transaction amounts and participants can be hidden, but auditors holding the View Key can still inspect them. It’s like a company’s books: what’s published externally is a summary, but auditors with the key can see the details.
I’d compare it to a building that has both glass meeting rooms and soundproof rooms—not a single road where you have to choose either “all transparent” or “all anonymous.” For public disclosure and regulatory filings, you use the glass meeting room (Moonlight); for business negotiations and institutional settlement, you use the soundproof room (Phoenix). Same building, different scenarios enter different rooms.
However, running two models also adds complexity. Users need to manually transfer DUSK between Moonlight and Phoenix accounts, since there’s currently no automatic routing. If a dApp only supports Moonlight, users holding shielded Phoenix assets must first do a cross-model transfer—one extra step and an additional gas cost.
So when I look at the account system of #dusk , I’m not only interested in whether there is privacy, but also in which model developers and users tend to prefer in real usage, and whether the friction of cross-model transfers can be absorbed at the wallet layer. The circulation efficiency of $DUSK ultimately depends on the switching cost between these two models. @Dusk
At first, this design felt contradictory: why would a privacy chain keep a public model? But thinking it through, Moonlight’s existence is precisely for compliance. In traditional financial institutions, regulators require visibility into account balances and transaction records. On a fully private on-chain system, auditors can’t even look up the ledger, let alone pass compliance checks. Moonlight provides a transparent experience similar to traditional bank accounts—account addresses, balances, and transaction history.
Phoenix takes a different route: a UTXO model plus zero-knowledge proofs. Transaction amounts and participants can be hidden, but auditors holding the View Key can still inspect them. It’s like a company’s books: what’s published externally is a summary, but auditors with the key can see the details.
I’d compare it to a building that has both glass meeting rooms and soundproof rooms—not a single road where you have to choose either “all transparent” or “all anonymous.” For public disclosure and regulatory filings, you use the glass meeting room (Moonlight); for business negotiations and institutional settlement, you use the soundproof room (Phoenix). Same building, different scenarios enter different rooms.
However, running two models also adds complexity. Users need to manually transfer DUSK between Moonlight and Phoenix accounts, since there’s currently no automatic routing. If a dApp only supports Moonlight, users holding shielded Phoenix assets must first do a cross-model transfer—one extra step and an additional gas cost.
So when I look at the account system of #dusk , I’m not only interested in whether there is privacy, but also in which model developers and users tend to prefer in real usage, and whether the friction of cross-model transfers can be absorbed at the wallet layer. The circulation efficiency of $DUSK ultimately depends on the switching cost between these two models. @Dusk
双模型设计很聪明,兼顾合规和隐私
0%
切换太麻烦,钱包应该自动处理
0%
0 votes • Voting closed