#dusk $DUSK @Dusk

‎‎私の父は何年も、個人商店のために2つの別々の台帳を運用していました。1つは現金の売上用、もう1つはクレジットの取引先（口座）用です。ある日、なぜまとめないのか聞きました。彼は「現金はシンプルで即時が必要。クレジットは条件（期日）を追跡してフォローアップが必要。どちらか一方の仕組みに無理やりもう片方までやらせると、どちらの仕事も悪くなる」と言っていました。
‎
‎私は、Dusk（ダスク）がいずれは1つの取引モデルに収束すると考えていました。多くのチェーンが最終的に単一の方式に落ち着くように。ですが、私が実際に「なぜMoonlightとPhoenixの両方が存在するのか」を追ってみたところ、その前提は崩れました。
‎
‎Moonlightは口座ベースで公開されており、分かりやすい――Duskのドキュメントでは、シールド（秘匿）を必要としない残高やアプリケーションロジックのモデルだと説明されています。PhoenixはUTXO（未使用トランザクション出力）方式で、プライバシー志向のフローを支えるために存在します。すなわち、シールドされた送金、選択的開示、そして、完全な透明性が受け入れられない場面でこそ実際に規制対応で必要になる要素です。
‎
‎これらを1つのモデルに統合してしまうと、どちらかになります。すべての取引に不要なプライバシーのオーバーヘッドを強制するか、逆に必要としている人からシールドの選択肢を削り取るかです。
‎
‎DUSKにとっての本当の試験は、「両方のモデルを残すことが、異なるフローごとに異なる保証を必要とするビルダーの役に立っているのか」を示せるかどうかです。単に、多くのユーザーが触れることのない概念的な負担を増やしただけになっていないか――そこが重要です。
‎
‎そして、どこにもドキュメント化されているのを見つけられていないのが、「単一のアプリケーションが実運用の中で同時に両方のモデルをどれくらいの頻度で必要とするのか」という点です。
‎