Saya dulu menganggap "immutability" sebagai jaminan. Kode dideploy, aturan terpasang, tidak ada yang mengutak-atik. Lalu Anda duduk dengan aset bernyawa yang harus hidup dua puluh tahun. Dalam rentang waktu itu, sebuah bug muncul, hukum berubah, dan ada kesalahan yang perlu diperbaiki. Kode yang immutable tidak bisa ditambal. Fitur itu berubah menjadi jebakan.
Jadi tim diam-diam menambahkan upgradeability — kunci admin, pemungutan suara tata kelola yang bisa mengganti logika. Dan sekarang Anda sudah menghidupkan kembali hal persis yang seharusnya dimatikan oleh immutability: seseorang yang bisa menulis ulang aturan aset Anda setelah Anda membelinya. Immutable dan upgradeable adalah kebalikan, dan aset teregulasi yang berumur panjang tampaknya butuh keduanya.
Artinya pertanyaan jujurnya bukan pernah "apakah itu immutable?" Melainkan "siapa yang bisa mengubah kode, dan apakah Anda akan melihatnya datang?" Kunci admin yang sunyi adalah backdoor dengan label merek.
Di sinilah rantai seperti @Dusk harus berhati-hati. Aturan yang hidup di dalam aset hanya membantu jika perubahan dibatasi, diberi versi, dan terlihat — amandemen yang sah, bukan pertukaran oleh kunci tersembunyi. Rantai itu harus membuat siapa yang mengubah apa tidak mungkin disembunyikan.
Saya tetap skeptis. Kebanyakan kontrak "upgradeable" bersandar pada multisig yang tipis; satu kali kompromi bisa mengubah segalanya. Dan tata kelola yang cukup lambat agar aman mungkin terlalu lambat untuk bug yang sedang berdarah.
Siapa yang memerlukannya? Penerbit aset yang melampaui basis kode pertamanya. Yang mematikannya: kunci tersembunyi, atau tata kelola yang terlalu lambat untuk situasi kebakaran.
Layak diperhatikan. Pertanyaan sebenarnya adalah siapa yang memegang pena.
$DUSK #dusk