#dusk $DUSK 翻DUSKのGitHubのコミット履歴は、白書を見るよりずっと面白い。2026年4月から6月にかけて、ruskリポジトリに高頻度で出てきたキーワードが1つあった。それがrevocation（失効）だ。3回続けてのminor releaseでは、Citadelの証明書（credential）失効の境界ケースを延々と補完している——機関が倒産した後に署名された「適格投資家」トークンはどう扱うべきか、管轄をまたいだ失効リストはどう同期するのか、失効後にすでに生成されたZK証明は遡って無効化すべきかどうか。
これはまさに、DUSKが見落としやすい最大の弱点に合致している。皆がPhoenixのプライバシーUTXOとHedgerの選択的開示にばかり注目し、「デフォルトで秘匿＋許可があれば監査可能」というモデルが、コンプライアンスとプライバシーの矛盾をすでに解決していると考えがちだ。だがCitadelのアイデンティティ層の信頼アンカーはZK回路ではなく、発行者それ自体だ。発行者が破産したり、免許を剥奪されたりすれば、発行者が過去に発行したすべてのcredentialは、法的な意味では即座に無効な紙切れになる。一方で、チェーン上でこれらのcredentialを使って生成された証明は、自動的には無効にならない。
そしてまた、古い問題に戻る。ZK証明の「その時は条件を満たしていた」と「今も条件を満たしている」は別物であり、後者にはリアルタイムの失効チェックが必要になる。リアルタイムの失効チェックは、チェーン上（gasコストが高い）か、オラクル経由（信頼モデルが劣化する）か、どちらかだ。DUSKのドキュメントでは、失効の遅延ウィンドウ、発行者責任の保険、管轄をまたいだcredentialのマッピングといった重要なガバナンス・パラメータがあまり語られていない。しかし、それらこそが、ライセンスを持つ金融機関がデューデリジェンスで最初に必ず尋ねる点だ。
コードは「どう証明するか」は解決できても、「誰が責任を負うのか（誰が正しいと言うのか）」は解決できない。DUSKが今後1年のうちに、Citadelのガバナンス・フレームワークを法的な附属契約に書き込まず、NPEXや21Xのようなライセンス保有者に、契約形式で発行責任を負わせないままでいるなら、機関の目にはDUSKは永遠に「技術検証品」であって、委託運用できる金融インフラにはならない。
#dusk @Dusk