今週、DuskEVM のテストネット活動を進める中で、何度も頭の中に戻ってきたテーマがあります。特に、8月16日のブリッジ状況が落ち着いた後に稼働したコントラクト同士のやり取りを見ていて感じたのは、Dusk Network（$DUSK ）が「アイデンティティ」と「認可」をどれだけ別物として扱っているか、という点です。#dusk @Dusk
多くのオンチェーンのアイデンティティ系プロジェクトは、この2つを混同しています。あなたが誰であるかを証明すると、その証明が許可（権限）になる。— それで終わり。ですが Dusk のアーキテクチャでは、アイデンティティと認可は別レイヤーです。Citadel は ZK-KYC を通じてアイデンティティのアテステーションを扱い、属性を開示せずに属性を証明できます。けれども、特定のアセットに対して実際にあなたが行えること（何が許可されるか）は別の問いで、別途に制御されます。規制対象となるアセットそのものが、認可ロジックを持っているのです。アイデンティティの資格情報ではありません。
うん、この切り分けは、聞こえる以上に重要です。TradFi では、自分が誰かを知っていることが、すべての金融商品に対する免除や適格性の自動クリアにつながるわけではありません。検証済みの機関ウォレットと、検証済みの個人（リテール）ウォレットは、債券発行において同じ代替可能な相手ではありません。Dusk は、この違いをアプリ層に押し上げるというより、プロトコルレベルでモデル化しているように見えます。
正直、私は最初ほとんど読み飛ばしそうになりました。認可の分離が理解できるまで、セッションの大半は ZK 証明の構造に注力していました。
とはいえ、その認可ロジックがアセット種別をまたいで維持するのに高コストになりすぎたり、壊れやすくなりすぎたりする前に、どれくらい細かな粒度まで設定できるのかは、まだはっきりしません。