黄昏（Dusk）のプライバシーモデルで面白いのは、オンチェーンに載せないものかもしれない

私は逆の方向から、Duskのプライバシー・アーキテクチャについて考え続けました。つまり「何を隠すか」ではなく、「ネットワークがなお把握する必要があるものは何か」です。
PhoenixはシールドUTXOを使い、ノートはMerkleツリーにコミットされ、nullifierを用いて消費されます。基盤となるトランザクションは秘匿のままでも、ネットワークは有効な状態遷移に必要なルールを検証できます。

それにより、非常に特定の情報の切り分けが生まれます。

ホワイトペーパーでは、トランザクション構造がMerkleルート、nullifier、新しいノート、任意のデポジット／データ、ガスパラメータ、そしてZKプルーフを含むと説明されています。ネットワークは隠されたトランザクションの詳細を直接照合するのではなく、公開入力に対してその証明を検証します。

ただ、私がより重要だと感じるのは次の点です。
Duskは、すべてを永続的に見えなくしようとしているわけではありません。

アーキテクチャにはCitadel 2も含まれており、アプリケーションが適格性の証明を必要とするときに、ユーザーが資格情報を選択的に開示できます。エグゼクティブ・サマリーでは、登録されたライセンスの保有を、ライセンス内容を明かさずに証明できるようにすると説明されています。

つまり設計は、実のところこういうわけではありません。
非公開 vs 公開。
より近いのは：
デフォルトでは非公開 + アプリケーションが必要とする部分だけを証明する。

これは規制下の金融にとって、ずっと役に立つモデルです。

しかし、まだ未解決の運用上の問いがあります。研究は具体的に、KYCシステムとの連携やセッション情報が、基礎となる個人データがオンチェーンに保存されていなくても、リンク可能性を生み得る可能性を指摘しています。

暗号はトランザクションを保護できます。
でも、そのトランザクションを基に作られるすべてのアプリケーションが、同じプライバシー特性を確実に維持することを、自動的に保証することはできません。
それが、私が注視したい部分です。

Duskは、選択的開示を維持しつつ、周辺のコンプライアンス基盤がこっそりと、回避しようとしていた監視を再構築してしまうことを許さずに済むのでしょうか？
@Dusk $DUSK #dusk