集合住宅のエレベーターが度々故障し、住民グループで改修案が共有されました。最初は票数が多ければ工事を始められると思っていましたが、見積もり、審査、施工のテスト、そして検収まで必要だと分かりました。チェーン上のガバナンスも「早く進んでいるように見える」罠がありえます。提案が公開され、議論が正式な器に載ったことは示してくれますが、本体のメインネットコードがすぐに連動して変わるわけではありません。

Duskは合意変更をDIP、つまりDusk Improvement Proposalとして整理します。公式の手順はIdeaから始まり、アイデアが固まるとDraftになって番号が付与されます。次にプロトタイプや技術成果を作るとFeedbackへ進みます。完成が近づくとStagingへ移行します。コードが関わるDIPはまずNocturneテストネットに置かれ、コンセンサスを受け取ってからActiveとされ、生産環境に成果が統合されます。#dusk

このプロセスの好きな点は、DUSKプロトコルの変更には完全な記録が残ることです。提案には、動機、技術仕様、取捨選択、後方互換性、テスト、安全への影響、実装リンクを書く必要があります。半年以上開発が続いていないStagnantな提案はDeadに入る可能性もあります。あとから振り返れば、当時どんなリスクが議論されていたかを追えるので、新しいバージョンのお知らせだけを見るのとは違います。

ただし「誰でも提出できる」から「誰でもルールを変えられる」とは直接言えません。DIPの編集者は査読、番号付与、マージ、そして実装の追跡に関わります。ノード運営者側も、変更を含むソフトウェアを導入する必要があります。現時点の公開説明では、$DUSK の保有に基づく投票の閾値が提示されておらず、「コンセンサスを得た」を明確な割合としても書いていません。オープンな議論を、すでにチェーン上のガバナンスが完了したかのように包むつもりはありません。

@Dusk のアップグレードに注目する際は、私は次の4点を分けて照合します。DIPがどの状態にあるか、実装コードが公開されているか、Nocturneのテスト結果を再検証できるか、メインネットのノードがいつ採用するのか。グループでの「いいね」は、その考えが支持されているという事実にしかならず、Activeや実際のデプロイがあってはじめて、Duskルールがどこまで進んだかが分かります。