@Dusk là האם complianceは本当にプライバシーと引き換えにする必要があるのか？という点を、私はずっと振り返ってしまいます。そして設計の大部分のロジックは、Citadel 2が「検証済みの証明」を「背後にいる人間の開示」からどのように切り離すかにあります。

動作フローは、License Providerがオフチェーンでユーザーを確認し、必要な属性に署名することから始まります。

そこから、ユーザーはゼロ知識証明を作成して、自分が署名され、オンチェーンに登録された有効なライセンスを保有していることを示します。ここが私にとって最も面白い部分です。

証明は、ウォレット鍵・属性・特定のライセンスを開示することなく、暗号技術を通じて行われます。そしてここで、プライバシーに関する問いが本当に検証されます。

サービス・ポリシーは常に背後に存在し、Service Providerが、どのproviderを信頼するか、どの属性を受け入れるか、さらにセッションが有効かどうかを判断するのを待ちます。

最後に、コントラクトは有効なproofだけを確認し、公開セッションを記録します。オンチェーンに残るのは、正当なcredentialが使用されたという証拠だけです。

私がまだ分からないのは、この仕組みがポリシーが変わった場合や、誤ったcredentialが発行された場合、あるいは理想的でないのに古いセッションがなお有効なままの場合に、どう機能するのかです。

問いは、暗号技術が本当にアクセス制御から「本人性の開示」を不要にするのか、それとも、信頼をcredentialを発行する側に移し、さらにcredentialの解釈に託すだけなのか、ということです。

私は、regulated financeが実際にそれを使い始めるとき、#dusk xが暗号的なproofとサービス・ポリシーの境界をどのように扱うのかを追っています。 $DUSK $UAI $MarsCoin