#dusk @Dusk
今日は目が覚めて、正直マーケットが半分寝ぼけてて半分起きてる感じだった。あの「何も動いてないのに、死んでもいない」みたいな妙な中間の気分。だからドゥームスクロールでチャートを眺める代わりに、気づいたらCitadel 2のドキュメントに戻ってた。理由は聞かないで。たぶん技術的なものを読んで落ち着きたかったんだと思う。

Citadelがユーザーのアクセス権を実際に決める“正確なポイント”を探そうとしてた。スクロールして、そこに当たるはずだってずっと期待してた。でも見つからない。結論として、あれはCitadelの仕事じゃなかった。

ユーザーは、自分が誰かを明かさずに有効なライセンスを保持していることを証明する。Dusk上のライセンス契約がそれを検証して、nullifierが追記され、セッションクッキーが発行される。アクセスが許可された、って読み取れるよね。

でも、フローの最後の一手は誰も触れない。サービスプロバイダ（SP）はそのセッションを取り出して、クッキーをローカルでチェックし、それから“実際にサービスを許可するかどうか”を自分で判断する。Citadelは、資格情報が本物で、すでに使い回されていないことだけを確認する。

その資格情報が、SPが求める条件として十分なのかどうかについては、何も言わない。

小さな違いだけど、これが解こうとしている全体像を変える。有効なセッションは、その証明が“正しく生成された”こと、つまり本物のライセンスを持つ誰かが二重使用なく生成したことを示す。しかし、その属性セットが、この特定のSPが今日要求しているものと一致しているかまでは分からない。

前者は数学の問題。Duskが一度解けば終わり。後者はビジネス上の判断で、各SPが自分で決める。しかも明日、その方針は、証明システムに一切触れずに変わり得る。

私が注目しているのは、Duskでの証明がどれだけ速く生成されるかじゃない。SPがCitadelの上に、ちゃんと“実際のポリシーロジック”を組み込んでいるのか、それとも検証が静かに、余計なステップ付きのただのパス/フェイル判定として置き換わってしまっているのか——そこだ。

もしシステムが「何かが真実である」ことは証明できても、その真実が何を意味するのかを決められないなら、現実のボトルネックが“証明”そのものではない気がする。ずっと、問いを投げる側の方だった。

$DUSK

$TUT

$PORTAL


Citadel 2のアクセスモデルは、次にどこへ向かうべきだ？