Duskで私が予想していなかった「プライバシーの詳細」は、残高を隠すことが目的ではありません。ゼロ知識のアイデンティティ証明が成功した後に何が起こるか、という話です。

Citadel 2の2026年5月のドラフト仕様では、nullifierとしてオンチェーンの「session_id」を使います。同じ秘匿ライセンスと受け入れられたチャレンジであれば、コントラクトは重複したセッションを拒否できます。これは一見するとリプレイ保護のように聞こえます。

しかし、仕様はより厳密な線引きをしています。nullifierは、オンチェーンでの重複セッション作成を止めるだけで、開示された同じセッションクッキーをオフチェーンで使い回すことまでは止めません。

それで私は二度見しました。

Citadelでは、チェーンが暗号学的妥当性を検証し、セッションを記録します。とはいえサービス提供者は、独自のリプレイ規則、発行者への信頼、失効、期限、アカウント紐付け、レート制限を依然として強制しなければなりません。

この切り分けは、「プライバシー＋コンプライアンス」という単純なスローガンよりも、ずっと興味深いと思います。基盤プロトコルに、あらゆる組織のアクセス方針をハードコードさせず、実際の認可責任をアプリケーション層へ押し出すからです。

トレードオフも明らかです。開発者は「有効なZK証明」を「安全に使い回せるアクセス資格情報」と同等だとみなせません。

@Dusk and $DUSK については、プライバシーを弱めることなく、一回限りの使用、紐付け、失効をどう標準化したCitadelの本番プロファイルを見ていくべきでしょう。どの方針がデフォルトになり、どれがアプリケーション固有として残るのか？ #dusk

#dusk $DUSK @Dusk