#dusk $ACE $PORTAL $DUSK @Dusk

Duskのfoundationで気になって仕方ないのは、Citadelライセンスではありません。

別に。

問題は、Duskのさらに1段階後ろにある「信頼済みライセンス提供者(License Provider)リスト」です。ライセンス自体に触れなくても、そのライセンスを無意味にできるだけの権限がある。

いいでしょう。

投資家がオフチェーンのチェックを通過。ライセンス提供者がCitadelのクレデンシャルに署名。登録完了。ZK証明はなお検証される。DuskのCitadelセッションも問題なし。

その後、Duskのサービス提供者が、そのLPを自社の信頼リストから削除します。

そして、ここからが「クリーンな状態」が黙って嘘をつき始める地点です。

なぜならCitadelライセンスは失敗していないから。

証明も失敗していないから。

サービス提供者が、発行したライセンス提供者を受け付けるのをやめただけ。

私は「登録されたクレデンシャル」が、もっと先まで効くはずだと扱っていました。

寛大すぎた。

Duskでは、クレデンシャルの有効性とサービス提供者の受け入れを、同じ状態として扱えません。Citadelは、LP署名のライセンスを引き続き証明し続けられます。すると、次のDuskのサービス提供者のアクションが来たときに、信頼済み-LPリストがまた別の裁定を下す。

同じクレデンシャル。

答えだけ違う。

とても静かな分岐。

投資家は戻ってきます。同じウォレット、同じライセンス、同じ証明パス。セッションは検証されます。次に、次のDuskのサービス提供者のアクションが「現在の信頼済み-LP」チェックに当たります。

拒否。

今度は、サービス提供者がまだ受け付けるLPから、新しいクレデンシャルが必要になるかもしれない。

古いCitadelライセンス?

まだ検証中。

何も暗号的に壊れていない。

それなのに、なぜかもっと面倒。

自分の目が最初に向かう場所は分かります。ライセンスに戻って、そこにない失敗を探す。素敵。

時間の使い方が上手い。

いま問題になるDuskの状態は、信頼済み-LPリストです。

リストが動く。次のサービス提供者のアクションが死ぬ。Citadelのクレデンシャルはそのまま。

では、ライセンスが実際に役に立たなくなったのはいつ?

クレデンシャルが失敗したとき?

それとも、Duskのサービス提供者が「それに署名した相手」を信じるのをやめたとき?

@Dusk_Foundation #Dusk