@Dusk がなぜ2つの異なるアカウントシステムを必要とするのか理解しようとして、1時間を費やしました。
ほとんどのチェーンは1つのモデルを選びます。既定でパブリック、必要に応じてプライバシー機能を追加する形です。あるいは既定でプライベートで、透明性のためのビューキーを用意します。私はDuskも同じパターンだろうと思いました。1つのアカウントタイプ。1つの取引モード。ウォレット内のトグルで、表示・非表示を切り替える。
ところが、実際はまったく別のものでした…
Duskはネイティブに両方を動かしています。Moonlightは公開アカウント層です。標準的なアドレス、見える残高、監査可能な取引。Phoenixはシールド層です。隠された金額、暗号化された送信者と受取人、データを公開せずに有効性を検証するゼロ知識証明。これらは同一アカウントのトグルではありません。同じチェーン上で並行して動く別々のシステムで、それぞれ独自のアドレス形式と用途があります。
これによって、ブロックチェーン上のコンプライアンスの捉え方が変わります。私はプライバシーは「必要になったときに追加するもの」だと思っていました。Duskでは、プライバシーと透明性は別々のインフラのレーンになっています。機関は規制報告のためにMoonlight上で公開準備（公開リザーブ）を保有しつつ、機密性のためにPhoenixを通じてクライアント資金を移動できます。同一の組織が両方を使いますが、チェーン間のブリッジや、資産を異なるプライバシー基準に包むようなことはしません。
ただ、その緊張関係は確かにあります。2つのアカウントシステムは、複雑さを2倍にします。ウォレットソフトは両方を扱う必要があります。ユーザーは、どのアドレスタイプをどの取引に使うべきかを理解していなければなりません。ミスは単に送金が失敗する、という話にとどまりません。公開アドレスに機密取引を送ってしまったり、本来隠されるべき決済を露出してしまったりすることになります。
私はまだ、金融市場が「公開帳簿とプライベート台帳の既存の分離」をそのまま映すチェーンを望むのか、それとも「すべてを1つのモデルに強制する」より単純な仕組みを望むのか、見極めている最中です。
2アカウント・アーキテクチャは、柔軟性なのか分断なのか？
#dusk
$DUSK
@Dusk_Foundation
ほとんどのチェーンは1つのモデルを選びます。既定でパブリック、必要に応じてプライバシー機能を追加する形です。あるいは既定でプライベートで、透明性のためのビューキーを用意します。私はDuskも同じパターンだろうと思いました。1つのアカウントタイプ。1つの取引モード。ウォレット内のトグルで、表示・非表示を切り替える。
ところが、実際はまったく別のものでした…
Duskはネイティブに両方を動かしています。Moonlightは公開アカウント層です。標準的なアドレス、見える残高、監査可能な取引。Phoenixはシールド層です。隠された金額、暗号化された送信者と受取人、データを公開せずに有効性を検証するゼロ知識証明。これらは同一アカウントのトグルではありません。同じチェーン上で並行して動く別々のシステムで、それぞれ独自のアドレス形式と用途があります。
これによって、ブロックチェーン上のコンプライアンスの捉え方が変わります。私はプライバシーは「必要になったときに追加するもの」だと思っていました。Duskでは、プライバシーと透明性は別々のインフラのレーンになっています。機関は規制報告のためにMoonlight上で公開準備（公開リザーブ）を保有しつつ、機密性のためにPhoenixを通じてクライアント資金を移動できます。同一の組織が両方を使いますが、チェーン間のブリッジや、資産を異なるプライバシー基準に包むようなことはしません。
ただ、その緊張関係は確かにあります。2つのアカウントシステムは、複雑さを2倍にします。ウォレットソフトは両方を扱う必要があります。ユーザーは、どのアドレスタイプをどの取引に使うべきかを理解していなければなりません。ミスは単に送金が失敗する、という話にとどまりません。公開アドレスに機密取引を送ってしまったり、本来隠されるべき決済を露出してしまったりすることになります。
私はまだ、金融市場が「公開帳簿とプライベート台帳の既存の分離」をそのまま映すチェーンを望むのか、それとも「すべてを1つのモデルに強制する」より単純な仕組みを望むのか、見極めている最中です。
2アカウント・アーキテクチャは、柔軟性なのか分断なのか？
#dusk
$DUSK
@Dusk_Foundation