私は「不変（immutable）」を安心だと思っていました。デプロイすればコードは固定され、誰も口を出さない。――でも、二十年生き続けなければならない絆に座ると、話は変わります。その間にバグが表面化し、法律が変わり、誤りを直す必要が出てくる。Immutableなコードはパッチできません。するとその機能は罠になります。
だからチームはこっそりアップグレード可能性を追加するのです――管理者キー、ロジックを差し替えられるガバナンス投票。そしてあなたは、イミュータブルが潰そうとしていた“まさにそのもの”を再導入してしまう。つまり、買った後にあなたの資産のルールを書き換えられる誰かです。不変とアップグレード可能は反対概念であり、長寿命で規制された資産には両方が要るように思える。
つまり、本当の問いは「不変なのか？」ではありません。「誰がコードを変えられるのか、そしてそれを見抜けるのか？」です。静かな管理者キーは、ブランディング付きの裏口です。
ここでチェーンの<@Dusk >は慎重である必要があります。資産の中で生きているルールは、変更が制限され、バージョン管理され、見える形になっている場合にだけ役に立つ。隠しキーによる差し替えではなく、適法な修正であるべきです。チェーンは、「誰が何を変えたか」を隠せないようにしなければならない。
私は懐疑的です。ほとんどの「アップグレード可能」コントラクトは、薄いマルチシグに頼りがちで、たった一度の妥協で崩れます。そして、安全のために十分遅いガバナンスは、今まさに出血しているバグに対しては遅すぎるかもしれません。
誰がそれを必要とするのか？最初のコードベースより長生きする資産を発行する人たちです。これを壊すもの：隠されたキー、あるいは火事に対して遅すぎるガバナンス。
注目すべき点です。真の問いは、誰がペンを持っているか。
$DUSK #dusk