最初、私はDuskが「プライバシーチェーン」みたいなものだと思っていました。口座（アカウント）モデルは他のプライバシーコインと大して変わらず、デフォルトで暗号化されているだけだろう、と。ところがドキュメントを読み進めてみると、自分の考えがあまりに単純でした。Duskは実際には、2つの口座システムが並存する設計なのです。こんな構成は、私がこれまで見た別のプロジェクトでは出会っていません。

PhoenixはUTXOモードで、ゼロ知識証明を使った機密トランザクション。金額や参加者はデフォルトで見えない設計で、多くの「プライバシー系」プロジェクトの発想に近いです。ただしDuskは並行してMoonlightも動かしています。こちらはアカウントモードで、イーサリアムと同じく透明で追跡可能です。同じチェーン上で、資産の受け取り・送付にどちらの口座システムを使うか選べますし、さらに2つのシステム間で互いに変換もできます。

この設計、ぱっと見て「分裂している」ように感じませんか？私も最初はそう思いました。でも、あることを理解したら腑に落ちました。機関（インスティテューション）がコンプライアンス取引を行うなら、「プライバシーが必要なときはプライバシー、透明性が必要なときは透明性」に切り替えられることが、まさに求められるからです。単一のモードに固定されてしまうのは本筋ではありません。たとえば、内部での資産振替は秘匿したい一方で、外部に公開発行される証券は規制当局がいつでも確認できなければならない。もし同じ口座ロジックを使い回すだけだと、両方に同時にうまく対応するのは難しい。だからこそ、2つの並行システムに分ける方が、むしろ正直なやり方なのです。「一つのモードであらゆる状況が解決できる」と見せかけようとしていない点が大きい。

代償もはっきりしています。2つの口座システムは、2つの状態管理ロジックを意味します。開発者はUTXOとアカウントの2つのプログラミングパラダイムを同時に理解する必要があり、単一モードのチェーンよりも呼び出し（利用）の複雑さはかなり高くなります。開発者フォーラムを見たところ、Phoenix/Moonlight間の相互変換に関する投稿が少なくありません。学習曲線が本当に存在することが分かります。私だけが「回り道だ」と感じているわけではないようです。

複雑さと引き換えに得られるのは柔軟性。その価値があるかどうかは、「この切り替え能力を実際の場面で使えるのか」という最終結果で決まるべきで、「設計が巧妙だ」という域にとどまってはいけません。
みなさんはどう思いますか？この『両方必要』な設計は、賢い取捨選択だと思いますか。それとも、開発者にとって不必要な複雑さを増やしているだけでしょうか？
@Dusk_Foundation #dusk $DUSK