#dusk $DUSK @Dusk
NPEXがDusk上で実際に$300M以上の実在・トークン化された資産を稼働させているのを見て、Citadelのドキュメントに戻って確認しました。これはもうテストネットの例ではありません。だからこそ、「プライバシーの主張」が、ホワイトペーパーの図解だけでなく、実際の規制のある場で本当に成り立つのかを確かめたくなったんです。
結論、プロトコルは「1つ」ではなく、実際には「別々の2つのフロー」から成っています。
まず、ユーザーはステルスアドレスを使ってLicense Providerにライセンスの発行を依頼します。これにより、発行されたライセンスが依頼側に紐づけられないようになります。
次に、ユーザーがサービスを使いたいとき、ライセンスを再送するわけではありません。代わりに、その有効なライセンスを所持していることを示すゼロ知識証明を送ります。サービスプロバイダー（SP）が見るのは、その証明だけです。そして、十分とみなす基準を決めるのはSP自身のポリシーです。
ここで私が足を止めたポイントがあります。その証明はただではありません。ライセンス保有を証明するためのCitadelの回路は、だいたい34,800 constraints程度で、その半分ほどは、ライセンスが実際に登録されていることを確認するために、深さ17のメルカリツリーを辿る処理だけに費やされています。
つまり「明かさずに証明する」には、スライド上の設計思想に留まらない、すべてのサービスリクエストに組み込まれた現実の計算コストがあるんです。
「IDを見せて、プラットフォームにすべて検証させる」とは別のモデルです。
より近いのは：やり取りごとに、一定の証明コストを一度支払う代わりに、その場（会場）には「はい／いいえ」以外は何も見せない、という考え方です。
ただ、まだ分からないのは、そのコストが今日のNPEXユーザーにとって実際に“見えない”のか、ウォレットが裏で処理してしまうのか。それとも、規制のある取引の当事者と誰かが実際に取引をするまでの間に、感じられる遅延として存在するのか、という点です。