#dusk $DUSK @Dusk
Duskのドキュメントを読み進めているときに私の注意を引いた点：存在する契約は2つだけです。ジェネシス時点では、ステーク契約とトランスファー契約があるだけです。DuskVMやDuskEVMを含むそれ以外のものは、その上に構築されています。

規制された資産の決済を目的としたチェーンにしては、集中度が妙に高いと思ったので、これら2つが実際に何をしているのか、そして後から変更できるのかを確認したくなりました。

ステーク契約は、どの提供者（provisioner）がいつ、どれだけステークされ、報酬が成熟するのはいつか、そしてスラッシング（減額・罰則）が適用されるのはどのような場合か、を追跡します。トランスファー契約は公開（Moonlight）とシールド（Phoenix）の残高の両方を扱い、契約間での資金移動が実際に起こる唯一の場所（contract to contract fund movement actually happens）です。現在のドキュメントの通り、すべての実行環境は決済とデータ可用性のためにこの契約を経由します。

これが重要な理由：もしDuskEVMの上で構築している、あるいはDusk Tradeを通じて資産を発行しているのなら、自分の契約ロジックだけを信頼しているわけではありません。これら2つのジェネシス契約が、下層の決済基盤として、そのほかすべてを支えている以上、無期限に正しく振る舞うことを信頼することになります。

ただ、私は次の点を特定できませんでした。ドキュメントでは、これらの契約が時間とともにリファクタリングされていると説明されています。ステーキング契約は、ストレージの問題を修正するために作り直され、さらに後のエンジニアリング更新によって、そのEventの構造が変わったようです。つまり、ジェネシス時点での意味で「不変（immutable）」のまま固定されているわけではないのは明らかです。

私にとって不明なのは、実際のアップグレード手順です。それは裁量的（プロトコルチームがネットワークアップグレードを出す）なのか、それとも、ジェネシス契約のロジックが変更される前に、提供者がオンチェーンの正式なガバナンス手順で投票して承認するものなのか、です。私が見つけたドキュメントは、契約が何をするのかは書いていますが、それらを変更することがどう承認されるのかは説明していません。

制度的な決済のためにチェーンを位置づけるなら、チームが承認したアップグレードと、提供者が追認（ratify）したアップグレードの区別は、どこかで明示的にドキュメント化されているはずだと思います。

@Dusk が、ジェネシス契約の変更に対する実際の認可（Authorization）プロセスをどこで指定しているのか、見たことがある人はいませんか？

$DUSK #dusk