#dusk $DUSK @Dusk 读 Dusk 白皮书时，我注意到一个容易被忽略的细节：不同合约的描述，使用了不同的时态。
Section 6.2 描述 Genesis、Transfer 和 Stake Contracts 时，主要是在陈述它们当前承担的功能：转账、Gas 扣除、质押等。这些属于 Dusk 网络运行所需的基础设施。
而 Section 6.3 在介绍 Zedger 和 Citadel 时，出现了明显更多的未来导向表述，例如“designed to be deployed”和“will allow”。
单凭时态，当然不能证明某项功能“尚未实现”。但作为技术文档的信号，它至少提醒我们：白皮书中的架构设计、已经部署的协议，以及当前可以实际使用的产品能力，并不是同一个概念。
现在再看 Dusk 官网，不同产品的状态已经被标注为 Live、Building 和 Testnet。这反而给了我们一个更具体的参照系：讨论一项能力时，我们是否也应该区分它是设计出来的、已经部署的，还是已经可以被实际验证和使用的？
今天 Dusk 对受监管链上金融的讨论，也越来越集中到投资者准入、受控转让、隐私披露和结算等完整流程。
那么问题就变得更具体了：
Zedger、XSC、Citadel 这些能力，目前分别处于“设计、部署、可验证使用”中的哪一个阶段？
如果 Dusk 的目标是承载真实的受监管金融市场，那么从白皮书中的设计走到真实市场使用，目前最需要外界验证的关键环节是什么？#dusk $DUSK @Dusk
Section 6.2 描述 Genesis、Transfer 和 Stake Contracts 时，主要是在陈述它们当前承担的功能：转账、Gas 扣除、质押等。这些属于 Dusk 网络运行所需的基础设施。
而 Section 6.3 在介绍 Zedger 和 Citadel 时，出现了明显更多的未来导向表述，例如“designed to be deployed”和“will allow”。
单凭时态，当然不能证明某项功能“尚未实现”。但作为技术文档的信号，它至少提醒我们：白皮书中的架构设计、已经部署的协议，以及当前可以实际使用的产品能力，并不是同一个概念。
现在再看 Dusk 官网，不同产品的状态已经被标注为 Live、Building 和 Testnet。这反而给了我们一个更具体的参照系：讨论一项能力时，我们是否也应该区分它是设计出来的、已经部署的，还是已经可以被实际验证和使用的？
今天 Dusk 对受监管链上金融的讨论，也越来越集中到投资者准入、受控转让、隐私披露和结算等完整流程。
那么问题就变得更具体了：
Zedger、XSC、Citadel 这些能力，目前分别处于“设计、部署、可验证使用”中的哪一个阶段？
如果 Dusk 的目标是承载真实的受监管金融市场，那么从白皮书中的设计走到真实市场使用，目前最需要外界验证的关键环节是什么？#dusk $DUSK @Dusk
