@Dusk 的隐私交易模型 Phoenix 用的是 note 加 nullifier，也就是 UTXO 那一套。
听到这个通常第一反应是：2026 年了还用 UTXO？账户模型多简单，一个地址一个余额，钱包打开就看到，合约读起来也直接。
但换成账户模型，隐私这件事根本做不成。
原因在于余额是一个持续存在的状态。同一个账户余额被反复读写，每一次交互都跟前一次绑在同一个对象上。就算把数值加密，你依然能看到"这个账户又动了一次"。次数、间隔、频率本身就是信息。加密数值挡不住关联分析。
note 模型反过来。每一笔收到的钱是一个独立的 note，花掉的时候公开一个 nullifier 把它作废，同时生成新的 note。没有一个跨时间持续存在的对象可以被盯住。不是把余额藏起来，是让"余额"这个东西在链上不存在。
这就是为什么隐私链几乎都回到 UTXO。不是审美偏好，是账户模型在结构上就漏。
更值得看的是 Zedger 那一层。它是 UTXO 加账户能力的混合模型，专门服务 XSC 标准，处理合格投资者限制、转让上限、分红、投票、强制转移。
为什么要混？因为证券需要名册。分红按持仓派发、投票按份额计票，这些动作必须知道"谁持有多少"——那是账户模型的强项，纯 UTXO 做不了。所以隐私要 UTXO，证券要账户，Zedger 是被这两个需求同时逼出来的，不是设计者贪心。
代价很实在。note 模型下钱包必须自己扫描、试解密、管理一堆碎片，用户体验天然比账户模型笨重，开发难度也高一档。这是选了这条路就得付的账。
以上基于官方文档与白皮书公开材料，实现细节可能已更新，请自行核对，不构成建议。
所以最后问一句：如果账户模型注定会漏，你愿意为了真隐私忍受一个更笨的钱包吗？
#dusk $DUSK @Dusk
听到这个通常第一反应是：2026 年了还用 UTXO？账户模型多简单，一个地址一个余额，钱包打开就看到，合约读起来也直接。
但换成账户模型，隐私这件事根本做不成。
原因在于余额是一个持续存在的状态。同一个账户余额被反复读写，每一次交互都跟前一次绑在同一个对象上。就算把数值加密，你依然能看到"这个账户又动了一次"。次数、间隔、频率本身就是信息。加密数值挡不住关联分析。
note 模型反过来。每一笔收到的钱是一个独立的 note，花掉的时候公开一个 nullifier 把它作废，同时生成新的 note。没有一个跨时间持续存在的对象可以被盯住。不是把余额藏起来，是让"余额"这个东西在链上不存在。
这就是为什么隐私链几乎都回到 UTXO。不是审美偏好，是账户模型在结构上就漏。
更值得看的是 Zedger 那一层。它是 UTXO 加账户能力的混合模型，专门服务 XSC 标准，处理合格投资者限制、转让上限、分红、投票、强制转移。
为什么要混？因为证券需要名册。分红按持仓派发、投票按份额计票，这些动作必须知道"谁持有多少"——那是账户模型的强项，纯 UTXO 做不了。所以隐私要 UTXO，证券要账户，Zedger 是被这两个需求同时逼出来的，不是设计者贪心。
代价很实在。note 模型下钱包必须自己扫描、试解密、管理一堆碎片，用户体验天然比账户模型笨重，开发难度也高一档。这是选了这条路就得付的账。
以上基于官方文档与白皮书公开材料，实现细节可能已更新，请自行核对，不构成建议。
所以最后问一句：如果账户模型注定会漏，你愿意为了真隐私忍受一个更笨的钱包吗？
#dusk $DUSK @Dusk