私が初めて「ツー・トランザクションモデル」という設計を見たとき、最初の反応は少し複雑だと感じました。1つのチェーン上で2種類のトランザクションモデルを動かし、アカウントモデルとUTXOモデルを同時に扱う——同じコンピュータに2つのオペレーティングシステムを入れているような感覚です。動かせはするけれど、切り替え時にカクついたり、互換性の問題が起きたりしないのか。私の中では当時確信が持てませんでした。

その後、ホワイトペーパーをじっくり読んで、2つのモデルがそれぞれどう位置づけられているのかを理解し始めました。そうして初めて、なぜこのように設計されているのかが徐々にわかってきたのです。

Moonlightは透明なアカウントモデルで、Ethereumのような仕組みに近く、口座残高は公開されています。透明な監査が必要な場面に適しています。たとえば機関が、自分たちがどれくらいの資産を保有しているのか、そして$DUSK の資金の流れが適切かどうかを証明したい場合、直接Moonlightを通せばよく、一目で確認できます。

PhoenixはUTXOのルートを採用しており、透明と混合（コンフュージョン）の両方のトランザクションに対応しています。ここでいう「混合」は、完全に匿名化するという意味ではありません。第三者が、取引の当事者同士を直接結びつけられないようにすることです。ホワイトペーパーでは、Phoenixが用いる暗号技術として、キーコンセンサス、楕円曲線暗号、そしてゼロ知識証明が挙げられており、監査済みの暗号方式です。@Dusk

2つのモデルが共存することの本質は、異なるプライバシー要件をそれぞれ別のレーンに振り分けている点にあります。公開が必要ならMoonlightを使い、機密性が必要ならPhoenixを使う。ユーザー自身が選び、プロトコルがあなたに代わって決めるわけではありません。

私が後で気づいたことがあります。この設計の核心的な矛盾は、「技術的に実現できるかどうか」ではなく、「ユーザーに選択権を与えること」です。従来のパブリックチェーンは透明性の道しか用意していませんでしたし、プライバシーコインはプライバシーの道だけを用意していました。Duskは、2つの道をどちらも整えて、ユーザーがシーンに応じて選べるようにしたのです。代償としてプロトコルの複雑さは増えますが、その代わりに、より柔軟な金融シーンへの適応力を得られます。#dusk