*** 私はDuskのアーキテクチャを読み進めていて、ある疑問に引っかかりました。どうすれば、相手がコンプライアンス要件を満たしていることを“証明”しつつ、すべての金融情報を見える状態にせずに済むのでしょうか?
それは簡単に聞こえますが、実務面を考えると話は別です。KYCやAMLのチェックには根拠(エビデンス)が必要です。しかし、機密性の高い金融データをそのままオンチェーンで公開してしまうと、別の問題が生じてしまいます。
そこで、私にとってDuskの考え方がようやく腑に落ちてきました。
ホワイトペーパーでは、参加者が基礎となる非公開データを開示せずに、必要な条件を満たしていることを証明できる「ゼロ知識コンプライアンス」が説明されています。最初は、プライバシーとコンプライアンスは自然に相反する方向に引っ張られるはずだと思い込んでいたので、その部分は2回読まなければなりませんでした。
また、Citadelモジュールにも注目しました。アイデンティティ、権限、アクセス制御を、完全に別のものとして扱うのではなく、プロトコルのより近くに配置しているのです。
そしてDuskは、単一の暗号技術アイデアに依存しているわけではありません。BLS12-381、JubJub、Schnorr署名、Poseidonハッシュ、PLONKといったプリミティブが、そのスタックに含まれています。
ただし、技術的な主張には慎重です。これらの構成要素が設計に入っていることが、システム全体が現実の金融市場で完璧に機能することを自動的に保証するわけではありません。
それでも、私にとって重要に感じる根本的な問いがあります。規制対象の資産がオンチェーンに載せられるなら、誰かのプライベートな金融情報を公開データに変えずに、検証は可能であるべきではないでしょうか?
おそらく、それが私がDuskの設計の中で最も考えている点です。
$DUSK #dusk @Dusk
それは簡単に聞こえますが、実務面を考えると話は別です。KYCやAMLのチェックには根拠(エビデンス)が必要です。しかし、機密性の高い金融データをそのままオンチェーンで公開してしまうと、別の問題が生じてしまいます。
そこで、私にとってDuskの考え方がようやく腑に落ちてきました。
ホワイトペーパーでは、参加者が基礎となる非公開データを開示せずに、必要な条件を満たしていることを証明できる「ゼロ知識コンプライアンス」が説明されています。最初は、プライバシーとコンプライアンスは自然に相反する方向に引っ張られるはずだと思い込んでいたので、その部分は2回読まなければなりませんでした。
また、Citadelモジュールにも注目しました。アイデンティティ、権限、アクセス制御を、完全に別のものとして扱うのではなく、プロトコルのより近くに配置しているのです。
そしてDuskは、単一の暗号技術アイデアに依存しているわけではありません。BLS12-381、JubJub、Schnorr署名、Poseidonハッシュ、PLONKといったプリミティブが、そのスタックに含まれています。
ただし、技術的な主張には慎重です。これらの構成要素が設計に入っていることが、システム全体が現実の金融市場で完璧に機能することを自動的に保証するわけではありません。
それでも、私にとって重要に感じる根本的な問いがあります。規制対象の資産がオンチェーンに載せられるなら、誰かのプライベートな金融情報を公開データに変えずに、検証は可能であるべきではないでしょうか?
おそらく、それが私がDuskの設計の中で最も考えている点です。
$DUSK #dusk @Dusk
