#dusk $DUSK @Dusk
前几天分研究了 Moonlight 和 Phoenix,我原本以为它们更像是两套平行运行的账户体系。
一个负责公开交易,一个负责隐私交易,各自解决自己的问题。
直到看到 @Dusk_Foundation 里的 convert 机制,这个理解才被我推翻。
Moonlight 里的 DUSK 是公开余额,Phoenix 里的资产则以加密 note 的形式存在。看起来完全是两种不同的记账方式,但 Dusk 并没有让它们各玩各的,而是通过 Transfer Contract 把两种模型连接了起来
比如 Phoenix 里的资产想进入 Moonlight,系统会处理对应的 note,然后把等值的 DUSK 加到指定的公开账户里
反过来也一样。Moonlight 账户里的余额减少之后,系统会创建对应面值的 Phoenix note,并发送到指定的隐私地址
真正让我觉得这个设计有意思的,是这里的“转换”不是简单做一次转账
官方工程资料里提到,convert 可以让 DUSK 在 Phoenix 和 Moonlight 两种模型之进行原子转换。也就是说,这个过程不会出现“公开余额已经扣掉,但隐私资产还没生成”这种中间状态。
这样一来,Moonlight 和 Phoenix 的关系就清楚多了。
它们不是两条互相隔离的路线,而是同一套结算体系里的两种使用方式。
需要透明的时候,可以使用 Moonlight;需要保护交易细节的时候,可以使用 Phoenix。
我觉得这可能才是 Dusk 这个设计真正值得看的地方。
隐私并不是把资产关进一个完全封的系统,而是在保持资产可流动的前提下,让用户能够选择不同的信息披露方式。
从这个角度再回头看前面三天讲的内容,Moonlight 和 Phoenix 才算真正拼成了一张完整的图。
前几天分研究了 Moonlight 和 Phoenix,我原本以为它们更像是两套平行运行的账户体系。
一个负责公开交易,一个负责隐私交易,各自解决自己的问题。
直到看到 @Dusk_Foundation 里的 convert 机制,这个理解才被我推翻。
Moonlight 里的 DUSK 是公开余额,Phoenix 里的资产则以加密 note 的形式存在。看起来完全是两种不同的记账方式,但 Dusk 并没有让它们各玩各的,而是通过 Transfer Contract 把两种模型连接了起来
比如 Phoenix 里的资产想进入 Moonlight,系统会处理对应的 note,然后把等值的 DUSK 加到指定的公开账户里
反过来也一样。Moonlight 账户里的余额减少之后,系统会创建对应面值的 Phoenix note,并发送到指定的隐私地址
真正让我觉得这个设计有意思的,是这里的“转换”不是简单做一次转账
官方工程资料里提到,convert 可以让 DUSK 在 Phoenix 和 Moonlight 两种模型之进行原子转换。也就是说,这个过程不会出现“公开余额已经扣掉,但隐私资产还没生成”这种中间状态。
这样一来,Moonlight 和 Phoenix 的关系就清楚多了。
它们不是两条互相隔离的路线,而是同一套结算体系里的两种使用方式。
需要透明的时候,可以使用 Moonlight;需要保护交易细节的时候,可以使用 Phoenix。
我觉得这可能才是 Dusk 这个设计真正值得看的地方。
隐私并不是把资产关进一个完全封的系统,而是在保持资产可流动的前提下,让用户能够选择不同的信息披露方式。
从这个角度再回头看前面三天讲的内容,Moonlight 和 Phoenix 才算真正拼成了一张完整的图。