Upgradeability Smart Contract

Apa Itu Upgradeability Smart Contract?

Upgradeability smart contract adalah kemampuan untuk mengubah, mengganti, memperluas, atau mengarahkan ulang logika sistem smart contract yang telah di-deploy setelah deployment pertama.

Dalam kripto, upgradeability digunakan karena banyak smart contract mengelola aset sungguhan, dan tim mungkin perlu memperbaiki bug, meningkatkan fitur, memperbarui integrasi, atau merespons masalah keamanan setelah peluncuran.

Dokumentasi resmi Ethereum tentang upgrade smart contract menjelaskan bahwa smart contract sering dianggap immutable, tetapi developer dapat menggunakan pola upgrade ketika perubahan di masa mendatang diperlukan.

Smart contract dasar yang telah di-deploy biasanya mempertahankan kode yang sama selamanya, kecuali dirancang dengan mekanisme upgrade.

Sistem smart contract yang dapat di-upgrade memisahkan alamat yang digunakan pengguna, status yang tersimpan, dan logika bisnis sehingga logika baru dapat diterapkan tanpa mengharuskan pengguna bermigrasi secara manual.

Model upgradeability yang paling umum menggunakan kontrak proxy yang berinteraksi dengan pengguna dan kontrak implementasi yang berisi logika saat ini.

Saat implementasi berubah, alamat proxy dapat tetap sama sementara kode di baliknya berubah.

Hal ini berguna bagi pengguna karena saldo, izin, dan integrasi dapat terus mengarah ke alamat yang sama.

Namun, hal ini berisiko karena pihak atau sistem tata kelola yang memiliki otoritas upgrade mungkin dapat mengubah perilaku kontrak setelah pengguna menyetorkan dana.

Sederhananya, upgradeability smart contract berarti merancang software on-chain agar logikanya dapat diperbarui di kemudian hari sambil mempertahankan status penting, kesinambungan alamat, dan akses pengguna.

Mengapa Upgradeability Smart Contract Penting

Upgradeability smart contract penting karena kode blockchain yang telah di-deploy dapat mengendalikan token, treasury, pasar pinjaman, sistem staking, bridge, NFT, atau hak tata kelola.

Bug dalam kode immutable dapat mengunci aset, merusak fungsi pengguna, atau membuka celah bagi penyerang.

Upgradeability memberi developer cara untuk menambal masalah kritis dan meningkatkan protokol setelah deployment.

Panduan OpenZeppelin tentang upgrade smart contract menjelaskan bahwa deployment yang dapat di-upgrade dapat mengubah kode kontrak sambil mempertahankan alamat, status, dan saldo.

Hal ini penting karena pengguna, wallet, tools analitik, dan protokol lain mungkin sudah bergantung pada alamat kontrak asli.

Tanpa upgradeability, tim mungkin harus men-deploy kontrak baru dan meminta pengguna memindahkan dana atau persetujuan secara manual.

Proses migrasi dapat lambat, berisiko, mahal, dan membingungkan.

Namun, upgradeability juga mengubah model kepercayaan smart contract.

Kontrak yang dapat di-upgrade tidak sepenuhnya immutable seperti kontrak yang tidak memiliki mekanisme upgrade.

Pengguna sebaiknya selalu menanyakan siapa yang dapat meng-upgrade kontrak, bagaimana upgrade disetujui, seberapa cepat upgrade dapat dilakukan, dan apakah pengguna dapat keluar sebelum perubahan besar berlaku.

Cara Kerja Upgradeability Smart Contract

Upgradeability smart contract biasanya bekerja dengan memisahkan penyimpanan dari logika.

Kontrak proxy mempertahankan alamat yang dipanggil pengguna dan biasanya menyimpan status utama sistem.

Kontrak implementasi berisi logika yang menentukan fungsi setiap tindakan.

Saat pengguna memanggil proxy, proxy meneruskan panggilan ke kontrak implementasi yang aktif.

Dalam sistem bergaya Ethereum, penerusan ini sering menggunakan delegatecall, yang menjalankan logika implementasi dalam konteks penyimpanan proxy.

Artinya, kode implementasi dapat membaca dan menulis penyimpanan proxy seolah-olah penyimpanan tersebut milik implementasi.

Saat protokol di-upgrade, akun yang berwenang atau proses tata kelola mengubah alamat implementasi yang disimpan oleh proxy.

Setelah perubahan, panggilan berikutnya diarahkan ke logika implementasi yang baru.

Penyimpanan lama dapat tetap digunakan sehingga saldo pengguna dan status protokol dapat dipertahankan jika tata letak penyimpanannya kompatibel.

Desain ini berdaya guna, tetapi memerlukan aturan ketat tentang tata letak penyimpanan, inisialisasi, otorisasi, audit, dan tata kelola upgrade.

Kontrak Proxy

Kontrak proxy adalah alamat kontrak stabil yang berinteraksi dengan pengguna dan kontrak lain di banyak sistem yang dapat di-upgrade.

Proxy biasanya menyimpan status dan meneruskan panggilan fungsi ke kontrak implementasi.

Dokumentasi pola upgrade proxy OpenZeppelin menjelaskan pola proxy penyimpanan tanpa struktur sebagai komponen dasar kontrak yang dapat di-upgrade.

Proxy berguna karena pengguna tidak perlu mengganti alamat kontrak setiap kali logikanya di-upgrade.

Aplikasi, wallet, dashboard, dan integrasi DeFi dapat terus menggunakan alamat proxy yang sama.

Pola proxy juga menambah kompleksitas karena pengguna dapat melihat satu alamat kontrak, sementara logika sebenarnya berada di alamat lain.

Block explorer sering menampilkan informasi proxy dan alamat implementasi jika dapat mendeteksi pola tersebut.

Pengguna sebaiknya memeriksa proxy dan implementasi saat meninjau kontrak yang dapat di-upgrade.

Proxy tidak otomatis aman karena keamanan bergantung pada kontrol upgrade, kompatibilitas penyimpanan, dan kualitas kode implementasi.

Proxy adalah pintunya, sedangkan implementasi adalah logika di balik pintu tersebut.

Kontrak Implementasi

Kontrak implementasi adalah kontrak yang berisi logika bisnis yang digunakan oleh proxy.

Kontrak ini dapat menentukan fungsi untuk transfer, deposit, penarikan, peminjaman, voting, mint, burn, pause, likuidasi, atau tindakan protokol lainnya.

Dalam sistem berbasis proxy, pengguna biasanya tidak berinteraksi langsung dengan alamat implementasi.

Sebaliknya, pengguna berinteraksi dengan proxy dan proxy meneruskan eksekusi melalui delegasi ke implementasi.

Upgrade biasanya berarti mengubah proxy agar mengarah ke kontrak implementasi baru.

Implementasi baru sebaiknya kompatibel dengan tata letak penyimpanan lama dan ekspektasi pengguna.

Upgrade implementasi yang berbahaya dapat menambahkan logika jahat, merusak akuntansi, mengubah izin, atau memblokir penarikan.

Karena itu, kode implementasi harus diverifikasi, diaudit, diuji, dan ditinjau sebelum upgrade dijalankan.

Jangan menganggap protokol akan tetap sama selamanya hanya karena alamat proxy tidak berubah.

Dalam sistem yang dapat di-upgrade, alamat implementasi merupakan bagian penting dari aspek keamanan.

Delegatecall

Delegatecall adalah mekanisme EVM tingkat rendah yang memungkinkan satu kontrak menjalankan kode dari kontrak lain dengan menggunakan konteks penyimpanan pemanggil.

Dalam upgradeability proxy, delegatecall memungkinkan proxy menggunakan logika implementasi sambil mempertahankan status di alamat proxy.

Inilah sebabnya implementasi baru dapat mengubah perilaku tanpa memindahkan saldo pengguna dari proxy.

Delegatecall berdaya guna karena memisahkan kode dari status.

Namun, mekanisme ini berisiko karena implementasi harus memperlakukan penyimpanan proxy seolah-olah penyimpanan tersebut miliknya sendiri, bukan penyimpanan miliknya.

Jika implementasi menggunakan tata letak penyimpanan yang berbeda dari perkiraan, variabel dapat bertabrakan atau merusak status.

Desain delegatecall yang salah dapat menimpa variabel kepemilikan, saldo, mapping, atau nilai konfigurasi.

Developer sebaiknya tidak menulis logika delegatecall proxy sendiri kecuali benar-benar memahami penyimpanan dan eksekusi EVM.

Pengguna tidak perlu memahami setiap opcode, tetapi sebaiknya mengetahui bahwa proxy yang dapat di-upgrade mengandalkan pengalihan teknis.

Delegatecall adalah salah satu alasan kontrak yang dapat di-upgrade memerlukan audit khusus.

Tata Letak Penyimpanan

Tata letak penyimpanan adalah urutan dan lokasi variabel dalam penyimpanan smart contract.

Dokumentasi resmi tata letak penyimpanan Solidity menjelaskan susunan variabel status dalam penyimpanan dan pentingnya aturan tata letak bagi kontrak serta library.

Tata letak penyimpanan merupakan salah satu risiko upgradeability yang paling penting.

Jika implementasi baru mengubah urutan, tipe, atau struktur variabel yang ada secara keliru, proxy dapat menafsirkan data penyimpanan lama dengan cara baru yang salah.

Contohnya, mapping saldo dapat bergeser, alamat pemilik dapat tertimpa, atau variabel konfigurasi dapat dibaca sebagai tipe yang berbeda.

Hal ini disebut risiko tabrakan atau kerusakan penyimpanan.

Developer biasanya menambahkan variabel baru setelah variabel yang sudah ada, bukan menyisipkannya di tengah.

Mereka juga menghindari perubahan tipe variabel atau urutan inheritance tanpa perencanaan migrasi yang cermat.

Tools upgrade modern dapat membandingkan tata letak penyimpanan sebelum mengizinkan upgrade.

Pengguna sebaiknya menganggap keamanan tata letak penyimpanan sebagai bagian inti dari keamanan kontrak yang dapat di-upgrade.

Slot Penyimpanan Proxy ERC-1967

ERC-1967 adalah standar yang menentukan slot penyimpanan khusus untuk informasi proxy, seperti alamat implementasi, alamat admin, dan alamat beacon.

Standar resmi ERC-1967 menetapkan slot penyimpanan proxy standar agar tools dan explorer dapat mengidentifikasi konfigurasi proxy dengan lebih andal.

Slot standar ini mengurangi kemungkinan variabel pengelolaan proxy bertabrakan dengan variabel penyimpanan aplikasi.

ERC-1967 juga membantu block explorer menampilkan implementasi yang sedang digunakan proxy.

Banyak sistem proxy modern menggunakan slot yang kompatibel dengan ERC-1967.

Standar ini tidak dengan sendirinya membuat upgrade aman.

Standar ini terutama menyediakan tempat yang konsisten untuk menyimpan metadata proxy.

Developer tetap memerlukan otorisasi yang benar, validasi tata letak penyimpanan, peninjauan implementasi, dan eksekusi upgrade yang aman.

Pengguna yang meninjau kontrak yang dapat di-upgrade sebaiknya memeriksa apakah proxy mengikuti standar yang dikenal, bukan pola khusus yang tidak dikenal.

Penyimpanan proxy yang terstandardisasi meningkatkan transparansi, tetapi hanya merupakan salah satu bagian dari keamanan upgradeability smart contract.

Pola Transparent Proxy

Pola Transparent Proxy memisahkan panggilan admin dari panggilan pengguna untuk mengurangi kebingungan selector fungsi antara fungsi proxy dan fungsi implementasi.

Dokumentasi proxy OpenZeppelin menjelaskan bahwa TransparentUpgradeableProxy memiliki antarmuka admin dan upgrade bawaan.

Dalam pola ini, pengguna biasa berinteraksi dengan fungsi implementasi melalui proxy.

Admin proxy menjalankan tindakan upgrade dan sebaiknya tidak secara tidak sengaja memanggil fungsi implementasi melalui proxy dengan cara yang sama seperti pengguna.

Desain ini membantu mencegah benturan ketika fungsi proxy dan fungsi implementasi menggunakan selector yang sama.

Transparent proxy banyak digunakan karena menyediakan model admin yang jelas.

Namun, kunci admin tetap harus dikelola dengan aman.

Jika admin proxy dikendalikan oleh satu kunci yang terekspos, seluruh protokol dapat terancam.

Transparent proxy dapat aman jika dipadukan dengan kontrol multisignature, timelock, audit, dan tata kelola yang jelas.

Pola ini mengurangi satu risiko teknis, tetapi tidak menghilangkan risiko tata kelola.

Pola UUPS Proxy

UUPS adalah singkatan dari Universal Upgradeable Proxy Standard.

Standar resmi EIP-1822 menjelaskan pola proxy universal yang dapat di-upgrade, dengan logika upgrade terkait desain implementasi.

Dokumentasi OpenZeppelin menjelaskan bahwa UUPSUpgradeable menyertakan mekanisme upgrade dalam kontrak implementasi, bukan menggunakan struktur admin proxy bawaan yang sama seperti transparent proxy.

UUPS proxy dapat lebih ringan daripada transparent proxy karena proxy itu sendiri dapat dibuat lebih sederhana.

Namun, implementasi harus menyertakan dan melindungi fungsi upgrade dengan benar.

Implementasi UUPS yang buruk dapat secara tidak sengaja menghapus kemampuan upgrade, mengekspos otoritas upgrade, atau mengizinkan upgrade tanpa otorisasi.

Developer juga harus mencegah upgrade ke implementasi yang merusak jalur upgrade.

UUPS dapat efisien dan fleksibel jika digunakan dengan library matang dan tools validasi.

Jangan menyalinnya begitu saja tanpa memahami pemeriksaan otorisasi dan keamanan upgrade.

Pengguna sebaiknya memeriksa pihak yang mengendalikan upgrade UUPS serta apakah upgrade sebelumnya dilakukan secara transparan dan diaudit.

Pola Beacon Proxy

Pola Beacon Proxy menggunakan kontrak beacon yang menyimpan alamat implementasi untuk beberapa proxy.

Alih-alih setiap proxy menyimpan alamat implementasinya sendiri, setiap proxy membaca alamat implementasi dari beacon.

Dengan memperbarui satu beacon, banyak instance proxy dapat di-upgrade secara bersamaan.

Beacon proxy berguna untuk sistem yang men-deploy banyak kontrak serupa, seperti vault, pool, akun, atau instance kontrak khusus pengguna.

Pola ini dapat mengurangi kompleksitas operasional ketika banyak instance memerlukan upgrade yang sama.

Namun, dampak kesalahan juga dapat meluas karena upgrade beacon yang buruk dapat memengaruhi banyak proxy sekaligus.

Dokumentasi proxy OpenZeppelin mencakup BeaconProxy dan UpgradeableBeacon sebagai komponen terkait proxy.

Otoritas beacon harus dilindungi dengan cermat karena dapat mengendalikan logika banyak kontrak.

Pengguna sebaiknya memeriksa apakah kontrak yang digunakan bergantung pada beacon dan siapa yang dapat memperbaruinya.

Beacon memudahkan developer, tetapi memusatkan kekuatan upgrade pada satu titik kendali bersama.

Pola Diamond Proxy

Pola Diamond Proxy memungkinkan satu kontrak mirip proxy mengarahkan panggilan fungsi ke beberapa kontrak implementasi yang disebut facet.

Standar resmi EIP-2535 Diamond Standard menetapkan sistem smart contract modular yang fungsinya dapat ditambahkan, diganti, atau dihapus melalui facet.

Diamond berguna untuk sistem besar yang akan melampaui batas ukuran kontrak atau memerlukan upgrade modular.

Diamond dapat membagi logika kompleks ke banyak facet terpisah sambil mempertahankan satu alamat utama.

Fleksibilitas ini dapat sangat berguna untuk sistem DeFi besar, game, sistem akun, atau kerangka kerja protokol.

Namun, kompleksitasnya juga meningkat karena pengguna dan auditor harus memahami pengalihan facet, tabel selector, pola penyimpanan, dan otoritas upgrade.

Upgrade diamond dapat mengganti hanya sebagian sistem, sehingga pelacakan perubahan menjadi penting.

Desain penyimpanan sangat penting karena beberapa facet dapat berbagi penyimpanan yang sama.

Developer sebaiknya menggunakan pola penyimpanan diamond yang jelas atau penyimpanan bernamespace jika sesuai.

Pengguna sebaiknya menganggap kontrak diamond sebagai sistem tingkat lanjut yang dapat di-upgrade dan memerlukan peninjauan cermat.

Penyimpanan Bernamespace

Penyimpanan bernamespace adalah metode untuk mengatur penyimpanan kontrak agar modul yang berbeda menggunakan lokasi penyimpanan yang ditentukan dan mengurangi risiko tabrakan.

Standar resmi ERC-7201 Namespaced Storage Layout menetapkan konvensi untuk mendokumentasikan lokasi penyimpanan bernamespace dalam kode sumber Solidity.

Penyimpanan bernamespace berguna dalam kontrak yang dapat di-upgrade dan modular karena mengurangi ketergantungan pada satu urutan variabel sederhana dalam rantai inheritance yang panjang.

Pendekatan ini dapat membuat upgrade lebih aman saat kontrak dibangun dari beberapa modul.

Pendekatan ini juga dapat membantu tools memvalidasi perubahan penyimpanan dengan lebih jelas jika didukung compiler dan framework.

Panduan OpenZeppelin tentang penulisan kontrak yang dapat di-upgrade menyebutkan bahwa Solidity 0.8.20 atau yang lebih baru diperlukan agar plugin upgrade-nya dapat memvalidasi tata letak penyimpanan bernamespace dengan informasi compiler yang dibutuhkan.

Penyimpanan bernamespace tidak menghilangkan kebutuhan akan audit.

Pendekatan ini membantu menyusun status agar perubahan di masa depan lebih mudah dikelola.

Jika memilih arsitektur ini, developer sebaiknya menggunakan penyimpanan bernamespace secara konsisten.

Pengguna mendapat manfaat secara tidak langsung karena desain penyimpanan yang lebih aman mengurangi kemungkinan kerusakan status akibat upgrade.

Initializer

Initializer adalah fungsi penyiapan khusus yang digunakan oleh kontrak yang dapat di-upgrade sebagai pengganti constructor.

Dalam kontrak biasa, constructor berjalan saat kontrak di-deploy.

Dalam sistem proxy, pengguna berinteraksi dengan proxy, dan constructor implementasi tidak menginisialisasi penyimpanan proxy dengan cara biasa.

Karena itu, implementasi yang dapat di-upgrade biasanya menggunakan fungsi initializer untuk mengatur pemilik, nama token, izin, nilai konfigurasi, dan status awal lainnya.

Initializer seharusnya hanya dijalankan sekali, kecuali jika digunakan reinitializer yang dirancang dengan cermat untuk upgrade berikutnya.

Jika initializer dibiarkan terbuka, penyerang dapat menginisialisasi kontrak dan mengambil alih peran penting.

Jika implementasi baru memerlukan variabel status baru, reinitializer mungkin diperlukan untuk mengaturnya dengan aman.

Developer harus melindungi initializer dan menonaktifkan inisialisasi pada kontrak implementasi mandiri jika sesuai.

Pengguna sebaiknya berhati-hati jika riwayat inisialisasi kontrak yang dapat di-upgrade tidak jelas.

Kesalahan inisialisasi merupakan sumber utama kerentanan kontrak yang dapat di-upgrade.

Otoritas Upgrade

Otoritas upgrade adalah akun, kontrak, wallet multisignature, timelock, DAO, atau sistem tata kelola yang dapat menyetujui upgrade.

Otoritas upgrade merupakan salah satu asumsi kepercayaan terpenting dalam kontrak yang dapat di-upgrade.

Jika satu private key mengendalikan upgrade, kunci tersebut mungkin dapat mengganti logika protokol.

Jika wallet multisignature mengendalikan upgrade, pengguna perlu memercayai kelompok signer dan keamanan operasionalnya.

Jika DAO mengendalikan upgrade, pengguna perlu memahami kekuatan voting, kuorum, penundaan proposal, penundaan eksekusi, dan risiko serangan tata kelola.

Jika timelock mengendalikan upgrade, pengguna mungkin memiliki waktu untuk meninjau dan keluar sebelum perubahan berlaku.

Proses upgrade yang aman sering menggabungkan eksekusi multisignature, penundaan timelock, pengungkapan proposal publik, tinjauan audit, dan pemantauan.

Otoritas upgrade seharusnya terlihat dan didokumentasikan.

Jangan menganggap kontrak yang dapat di-upgrade trustless jika kelompok kecil dapat mengubahnya secara instan.

Dalam sistem yang dapat di-upgrade, desain tata kelola adalah bagian dari desain keamanan.

Timelock

Timelock menunda eksekusi setelah upgrade diajukan atau disetujui.

Penundaan ini memberi waktu kepada pengguna, auditor, peneliti, dan sistem pemantauan untuk meninjau perubahan yang akan datang.

Timelock dapat mengurangi risiko upgrade mendadak yang langsung mengubah perilaku kontrak.

Timelock juga dapat memberi pengguna waktu untuk menarik dana jika mereka tidak setuju dengan upgrade.

Namun, timelock tidak sempurna karena perbaikan darurat mungkin perlu dilakukan dengan cepat saat serangan sedang berlangsung.

Beberapa sistem menggunakan jalur darurat yang lebih singkat dan jalur tata kelola normal yang lebih panjang.

Jalur darurat dapat melindungi pengguna dari eksploitasi, tetapi juga menimbulkan risiko sentralisasi.

Protokol yang baik menjelaskan aturan timelock dengan jelas.

Pengguna sebaiknya memeriksa apakah upgrade ditunda, dapat langsung dilakukan, atau dikendalikan oleh kewenangan darurat.

Timelock bernilai karena mengubah otoritas upgrade dari kekuatan instan menjadi kekuatan tertunda yang terlihat.

Upgrade yang Dikendalikan Tata Kelola

Upgrade yang dikendalikan tata kelola menggunakan voting token, voting delegasi, persetujuan dewan, proposal DAO, atau sistem serupa untuk menyetujui perubahan implementasi.

Pendekatan ini dapat membuat upgrade lebih terdesentralisasi dibandingkan satu kunci admin.

Pendekatan ini juga dapat membuat proses upgrade lebih lambat dan kompleks.

Keamanan tata kelola bergantung pada distribusi pemilih, aturan kuorum, ambang proposal, jeda voting, jeda eksekusi, delegasi, dan ketahanan terhadap pembelian suara atau serangan tata kelola melalui flash loan.

Persetujuan melalui voting tata kelola tidak otomatis berarti perubahan tersebut aman secara teknis.

Pemilih dapat menyetujui kode yang tidak sepenuhnya mereka pahami.

Proposal berbahaya dapat menyembunyikan logika berbahaya dalam paket upgrade yang besar.

Protokol sebaiknya memublikasikan perbedaan kode upgrade, audit, hasil simulasi, dan penjelasan dengan bahasa sederhana sebelum voting.

Pengguna sebaiknya meninjau proses upgrade tata kelola sebelum menyetorkan aset ke protokol.

Tata kelola dapat mendistribusikan kekuasaan, tetapi tidak menghilangkan kebutuhan akan tinjauan keamanan teknis.

Kontrak Immutable vs. Kontrak yang Dapat Di-upgrade

Smart contract immutable tidak dapat diubah setelah deployment, kecuali dirancang dengan kontrol eksternal atau jalur migrasi.

Smart contract yang dapat di-upgrade dapat mengubah logikanya melalui mekanisme upgrade yang ditentukan.

Kontrak immutable dapat lebih mudah dipahami karena kode yang di-deploy tetap sama.

Kontrak ini juga dapat berbahaya jika ditemukan bug serius dan tidak ada perbaikan yang aman.

Kontrak yang dapat di-upgrade dapat memperbaiki bug dan menambahkan fitur.

Namun, kontrak ini juga dapat menimbulkan risiko kepercayaan karena logika di masa mendatang mungkin berbeda dari kode yang semula ditinjau pengguna.

Tidak ada satu model yang selalu lebih baik.

Kontrak token sederhana mungkin lebih memilih sifat immutable jika aturannya tidak boleh berubah.

Protokol DeFi kompleks mungkin memerlukan upgradeability untuk patch keamanan dan kondisi pasar yang terus berkembang.

Desain yang tepat bergantung pada risiko, kompleksitas, kematangan tata kelola, dan ekspektasi pengguna.

Migrasi vs. Upgradeability

Migrasi berarti men-deploy kontrak baru dan memindahkan pengguna, aset, atau integrasi dari kontrak lama ke kontrak baru.

Upgradeability berarti mengubah logika di balik alamat atau sistem yang sudah ada sambil mempertahankan status atau kesinambungan bagi pengguna.

Migrasi dapat lebih mudah dipahami karena kontrak lama tetap tidak berubah dan kontrak baru berdiri terpisah.

Migrasi dapat merepotkan karena pengguna mungkin perlu menyetujui transfer, memindahkan posisi, mengklaim token baru, atau memperbarui integrasi.

Upgradeability dapat menghadirkan pengalaman pengguna yang lebih lancar karena alamat yang sama tetap aktif.

Namun, upgradeability juga dapat menyembunyikan perubahan besar di balik alamat yang sama.

Beberapa protokol menggunakan kedua pendekatan, bergantung pada tingkat perubahan.

Perbaikan bug kecil mungkin menggunakan upgrade, sedangkan desain ulang besar mungkin menggunakan migrasi.

Pengguna sebaiknya memahami apakah protokol dapat diubah langsung atau memerlukan migrasi manual.

Risiko migrasi dan risiko upgrade berbeda, tetapi keduanya memerlukan komunikasi yang cermat.

Verifikasi Kode Sumber

Verifikasi kode sumber membantu pengguna membandingkan kode sumber yang dipublikasikan dengan bytecode yang di-deploy.

Dokumentasi resmi verifikasi smart contract Ethereum menjelaskan bahwa verifikasi membandingkan kode sumber smart contract dengan bytecode hasil kompilasi.

Untuk kontrak yang dapat di-upgrade, jika memungkinkan, pengguna sebaiknya memverifikasi proxy dan implementasi yang sedang digunakan.

Proxy yang terverifikasi saja mungkin tidak menampilkan seluruh logika bisnis.

Implementasi yang terverifikasi membantu pengguna membaca logika saat ini, tetapi otoritas upgrade tetap perlu diperiksa.

Setelah protokol di-upgrade, implementasi baru juga sebaiknya diverifikasi.

Jangan menganggap kontrak tetap aman hanya karena implementasi sebelumnya pernah diaudit.

Upgrade dapat menambahkan fungsi baru, mengubah izin, mengubah akuntansi, atau menimbulkan bug baru.

Verifikasi merupakan langkah transparansi, bukan jaminan keamanan menyeluruh.

Sistem yang dapat di-upgrade memerlukan verifikasi berkelanjutan setelah setiap upgrade.

Celah Penyimpanan

Celah penyimpanan adalah slot penyimpanan kosong yang dicadangkan dalam kontrak yang dapat di-upgrade agar versi mendatang dapat menambahkan variabel tanpa menggeser penyimpanan kontrak turunan secara tidak terduga.

Pola ini umum digunakan dalam kontrak yang dapat di-upgrade dengan banyak inheritance.

Celah penyimpanan dapat muncul sebagai array kosong berukuran tetap yang dicadangkan untuk variabel di masa mendatang.

Ketika upgrade mendatang menambahkan variabel status, developer dapat mengurangi ukuran celah tersebut sesuai kebutuhan.

Celah penyimpanan berguna, tetapi membutuhkan kedisiplinan.

Penggunaan celah yang keliru tetap dapat menimbulkan masalah tata letak penyimpanan.

Penyimpanan bernamespace merupakan pendekatan yang lebih baru dan dapat mengurangi ketergantungan pada celah penyimpanan besar dalam beberapa arsitektur.

Developer sebaiknya mengikuti panduan framework upgrade dan tools compiler yang digunakan.

Auditor sebaiknya meninjau celah penyimpanan dan perubahan tata letak dalam setiap upgrade.

Pengguna tidak perlu mengelola celah penyimpanan, tetapi mendapat manfaat ketika developer menggunakannya dengan benar.

Pengujian Upgrade

Pengujian upgrade memeriksa apakah implementasi baru bekerja dengan benar menggunakan status proxy yang sudah ada.

Pengujian unit biasa tidak cukup karena mungkin hanya men-deploy kontrak baru dengan penyimpanan yang masih kosong.

Pengujian upgrade sebaiknya menyimulasikan versi lama, mengisi status yang realistis, menjalankan upgrade, lalu menguji versi baru dengan status yang sudah ada.

Pengujian sebaiknya memeriksa saldo, izin, akuntansi, persetujuan token, penetapan peran, pengaturan oracle, logika pause, dan posisi pengguna.

Pengujian juga harus memastikan bahwa pengguna tanpa otorisasi tidak dapat meng-upgrade kontrak.

Jika sesuai, pengujian fork dapat membantu menyimulasikan upgrade dengan status chain yang sebenarnya.

Tools validasi tata letak penyimpanan dapat mendeteksi banyak perubahan yang tidak aman sebelum deployment.

Cakupan pengujian harus mencakup alur normal dan alur kegagalan.

Setiap upgrade harus diperlakukan seperti deployment baru dengan risiko migrasi tambahan.

Protokol yang melakukan upgrade tanpa pengujian serius mengekspos pengguna pada bahaya yang sebenarnya dapat dihindari.

Audit Upgrade

Audit upgrade meninjau implementasi baru, perubahan penyimpanan, logika initializer atau reinitializer, kontrol akses, dan jalur eksekusi tata kelola.

Audit upgrade sebaiknya membandingkan versi lama dengan versi baru.

Tujuannya bukan hanya memeriksa kode baru, tetapi juga memahami dampak kode baru terhadap status dan pengguna yang sudah ada.

Auditor sebaiknya meninjau tata letak penyimpanan, panggilan eksternal, izin, otorisasi upgrade, kontrol darurat, event, dan kompatibilitas integrasi.

Auditor juga sebaiknya meninjau apakah upgrade menimbulkan perubahan ABI yang merusak aplikasi yang memanggil kontrak.

Audit tidak menjamin keamanan, tetapi mengurangi risiko.

Protokol besar sebaiknya memublikasikan laporan atau ringkasan audit jika upgrade memengaruhi dana pengguna.

Upgrade kecil pun dapat berbahaya jika menyentuh akuntansi, izin, penarikan, atau logika oracle.

Pengguna sebaiknya memeriksa apakah upgrade implementasi besar telah diaudit sebelum memercayainya.

Audit upgrade merupakan perlindungan inti terhadap regresi tersembunyi.

Kompatibilitas ABI

Kompatibilitas ABI berarti aplikasi eksternal tetap dapat memanggil kontrak sesuai harapan setelah upgrade.

ABI menentukan nama fungsi, input, output, event, dan error yang digunakan wallet serta aplikasi.

Upgrade dapat merusak kompatibilitas jika menghapus fungsi, mengubah tipe nilai yang dikembalikan, mengubah perilaku event, atau mengubah asumsi yang diandalkan integrator.

Perubahan ABI yang merusak dapat membuat aplikasi front-end, bot, sistem akuntansi, atau integrasi DeFi gagal.

Meskipun penyimpanan aman, pengalaman pengguna tetap dapat terganggu jika antarmuka berubah tanpa koordinasi.

Developer sebaiknya mendokumentasikan perubahan ABI dengan jelas sebelum upgrade.

Integrator sebaiknya memantau upgrade implementasi pada protokol yang mereka andalkan.

Pengguna mungkin melihat transaksi gagal jika aplikasi belum diperbarui untuk implementasi baru.

Kompatibilitas ABI merupakan bagian dari keamanan upgrade karena smart contract berada dalam ekosistem yang lebih luas.

Upgrade yang valid secara teknis tetap dapat merugikan pengguna jika antarmuka diubah tanpa kehati-hatian.

Risiko Kunci Admin

Risiko kunci admin adalah risiko pencurian, penyalahgunaan, kehilangan, atau pengendalian kunci maupun akun yang mengendalikan upgrade oleh pihak yang tidak tepercaya.

Jika penyerang memperoleh otoritas upgrade, mereka dapat men-deploy logika berbahaya yang menguras dana atau mengubah saldo.

Jika kunci admin hilang, tim mungkin tidak dapat menambal bug di kemudian hari.

Jika satu orang mengendalikan kunci admin, pengguna harus memercayai orang tersebut agar tidak bertindak jahat atau lalai.

Wallet multisignature dapat mengurangi risiko satu kunci dengan mensyaratkan beberapa persetujuan.

Timelock dapat mengurangi risiko upgrade mendadak dengan menambahkan penundaan.

Tata kelola DAO dapat mendistribusikan kekuasaan upgrade, tetapi menimbulkan risiko serangan tata kelola.

Protokol sebaiknya mengungkapkan pihak yang mengendalikan upgrade dan cara pengamanan kuncinya.

Pengguna sebaiknya menganggap kendali admin yang disembunyikan atau tidak jelas sebagai tanda peringatan serius.

Dalam kontrak yang dapat di-upgrade, keamanan admin sering sama pentingnya dengan keamanan kode.

Upgrade Darurat

Upgrade darurat adalah upgrade cepat untuk memperbaiki kerentanan kritis atau menghentikan serangan yang sedang berlangsung.

Upgrade ini dapat melindungi dana pengguna saat menunggu siklus tata kelola penuh akan terlalu lambat.

Namun, upgrade darurat juga dapat menimbulkan risiko sentralisasi karena mungkin melewati tinjauan, voting, atau penundaan timelock normal.

Protokol sebaiknya menetapkan kewenangan darurat sebelum keadaan darurat terjadi.

Kontrol darurat sebaiknya dibatasi, didokumentasikan, dipantau, dan diatur melalui proses tepercaya.

Setelah upgrade darurat, tim sebaiknya memublikasikan informasi yang jelas tentang perubahan dan alasannya.

Pengguna sebaiknya memahami apakah protokol memiliki hak untuk melakukan upgrade darurat.

Protokol tanpa jalur darurat mungkin lebih lambat dalam merespons eksploitasi.

Protokol dengan kewenangan darurat tanpa batas mungkin menuntut terlalu banyak kepercayaan.

Desain terbaik menyeimbangkan perlindungan cepat dengan transparansi dan akuntabilitas.

Token yang Dapat Di-upgrade

Token yang dapat di-upgrade adalah kontrak token yang logikanya dapat diubah setelah deployment.

Hal ini dapat memungkinkan perbaikan bug, perubahan kepatuhan, model biaya baru, perubahan bridge, atau pembaruan fitur.

Namun, upgrade juga dapat memungkinkan perubahan berbahaya seperti hak mint baru, pembatasan transfer, blacklist, atau biaya tak terduga.

Periksa apakah kontrak token dapat di-upgrade sebelum menganggap aturannya tetap.

Token dengan otoritas upgrade dapat mengalami perubahan perilaku meskipun nama, simbol, dan alamatnya tetap sama.

Pemegang token sebaiknya meninjau peran admin, otoritas mint, kontrol pause, fungsi blacklist, dan tata kelola upgrade.

Kode sumber terverifikasi sebaiknya diperiksa setelah upgrade besar.

Penyedia likuiditas perlu sangat berhati-hati karena perubahan aturan token dapat memengaruhi pool trading.

Token yang dapat di-upgrade mungkin sah, tetapi model kepercayaannya berbeda dari token immutable.

Upgradeability token sebaiknya dijelaskan secara transparan kepada pengguna.

Protokol DeFi yang Dapat Di-upgrade

Protokol DeFi yang dapat di-upgrade dapat mengubah logika pinjaman, swap, staking, likuidasi, strategi vault, suku bunga, atau aturan jaminan.

Fleksibilitas ini dapat berguna karena pasar DeFi berubah cepat dan bug dapat berdampak serius.

Namun, fleksibilitas ini juga menimbulkan risiko karena aturan protokol dapat berubah setelah pengguna menyetorkan dana.

Upgrade dapat mengubah logika penarikan, perhitungan biaya, parameter risiko, sumber oracle, atau perilaku likuidasi.

Pengguna sebaiknya memeriksa apakah upgrade protokol DeFi dikendalikan tim, wallet multisignature, timelock, atau proses tata kelola.

Periksa juga apakah kontrak penting bersifat immutable atau dapat di-upgrade.

Protokol dapat memiliki sebagian kontrak yang immutable dan sebagian lainnya dapat di-upgrade.

Risiko upgrade DeFi sangat penting karena kontraknya sering menyimpan likuiditas gabungan.

Satu upgrade yang buruk dapat memengaruhi banyak pengguna sekaligus.

DeFi yang dapat di-upgrade memerlukan pemantauan berkelanjutan, bukan kepercayaan satu kali.

Upgradeability dan Oracle

Oracle menyediakan data eksternal seperti harga aset kepada smart contract.

Protokol yang dapat di-upgrade mungkin dapat mengubah logika atau alamat oracle.

Dokumentasi resmi oracle Ethereum menjelaskan bahwa oracle diperlukan karena smart contract tidak dapat mengakses data off-chain secara langsung.

Upgradeability oracle dapat berguna ketika feed lama tidak lagi andal atau tersedia sumber yang lebih baik.

Namun, upgradeability berbahaya jika admin dapat beralih ke oracle yang dimanipulasi atau berbahaya.

Dalam sistem pinjaman dan derivatif, upgrade oracle yang buruk dapat menyebabkan likuidasi tidak adil atau penyelesaian yang keliru.

Pengguna sebaiknya memeriksa pihak yang dapat mengubah sumber oracle dan apakah perubahan tersebut dikenai timelock.

Developer sebaiknya menggunakan tata kelola dan pemantauan oracle yang tangguh.

Perubahan oracle harus diperlakukan sebagai upgrade berisiko tinggi.

Sumber data merupakan bagian dari logika smart contract meskipun berada di luar kode kontrak utama.

Upgradeability dan Bridge

Bridge sering menggunakan kontrak yang dapat di-upgrade karena logikanya harus merespons chain baru, format pesan, kumpulan validator, kontrol risiko, dan patch keamanan.

Upgradeability bridge dapat meningkatkan kemampuan adaptasi.

Namun, upgradeability juga dapat menimbulkan risiko kepercayaan besar karena bridge mungkin mengendalikan aset terkunci atau aset yang di-mint dalam jumlah besar.

Upgrade bridge yang berbahaya dapat mengubah aturan penarikan, mencetak aset wrapped secara tidak semestinya, atau mengalihkan dana.

Pengguna sebaiknya memeriksa otoritas upgrade bridge, tata kelola validator, timelock, audit, dan kontrol darurat.

Bridge sudah kompleks karena bergantung pada beberapa jaringan dan asumsi verifikasi.

Upgradeability menambahkan lapisan risiko lainnya.

Kontrak bridge dengan tata kelola upgrade yang kuat mungkin lebih aman daripada kontrak yang dikendalikan satu kunci.

Namun, tidak ada proses upgrade yang menghilangkan seluruh risiko bridge.

Pengguna bridge sebaiknya memahami asumsi teknis dan tata kelola sebelum mentransfer aset.

Upgradeability dan Kepercayaan Pengguna

Upgradeability menciptakan kompromi dalam hal kepercayaan.

Pengguna memperoleh manfaat dari perbaikan bug dan peningkatan fitur.

Pengguna menerima risiko bahwa logika di masa depan dapat berubah dengan cara yang tidak mereka sukai.

Proses upgrade yang transparan dapat meningkatkan kepercayaan dengan menunjukkan perubahan sebelum diterapkan.

Proses upgrade yang tersembunyi atau instan dapat mengurangi kepercayaan karena pengguna tidak memiliki waktu untuk mengevaluasi perubahan.

Protokol sebaiknya menjelaskan hak upgrade dengan bahasa yang mudah dipahami.

Protokol sebaiknya memublikasikan alamat implementasi, alamat admin, detail timelock, laporan audit, dan proposal tata kelola.

Pengguna sebaiknya tidak hanya bertanya apakah kontrak telah diaudit.

Pengguna juga sebaiknya bertanya apakah kode yang diaudit dapat diganti besok.

Dalam smart contract yang dapat di-upgrade, kepercayaan bergantung pada kode saat ini dan kendali atas perubahan di masa mendatang.

Cara Memeriksa Apakah Kontrak Dapat Di-upgrade

Mulailah dengan memeriksa halaman kontrak di block explorer untuk mengetahui apakah kontrak diberi label sebagai proxy.

Kemudian, periksa alamat implementasi jika ditampilkan oleh explorer.

Periksa apakah proxy mengikuti pola yang dikenal, seperti ERC-1967, Transparent Proxy, UUPS, Beacon Proxy, atau Diamond.

Periksa apakah kode sumber implementasi telah diverifikasi.

Periksa pihak yang mengendalikan upgrade melalui alamat admin, peran pemilik, wallet multisignature, timelock, atau kontrak tata kelola.

Tinjau event terbaru untuk melihat perubahan implementasi atau transaksi upgrade.

Baca dokumentasi protokol untuk memahami kebijakan upgrade.

Periksa laporan audit untuk mengetahui apakah upgradeability termasuk dalam cakupan audit.

Pantau proposal tata kelola jika protokol menggunakan upgrade yang dikendalikan DAO.

Alamat kontrak saja tidak cukup karena sistem yang dapat di-upgrade mengharuskan pengguna meninjau proxy, implementasi, dan struktur otoritas secara bersamaan.

Kesalahan Umum dalam Upgradeability Smart Contract

Salah satu kesalahan umum adalah mengubah urutan variabel penyimpanan saat upgrade.

Kesalahan lainnya adalah lupa melindungi fungsi initializer.

Kesalahan ketiga adalah menggunakan satu private key sebagai satu-satunya admin upgrade.

Kesalahan keempat adalah melakukan upgrade tanpa timelock atau pemberitahuan publik.

Kesalahan kelima adalah men-deploy implementasi baru tanpa memverifikasi kode sumber.

Kesalahan keenam adalah menganggap audit lama masih mencakup implementasi baru.

Kesalahan ketujuh adalah mengubah ABI dengan cara yang merusak integrasi.

Kesalahan kedelapan adalah tidak menguji upgrade menggunakan status yang menyerupai lingkungan produksi.

Kesalahan kesembilan adalah menggunakan logika proxy khusus tanpa peninjauan mendalam.

Kesalahan kesepuluh adalah menyebut sistem terdesentralisasi padahal kelompok kecil admin dapat langsung mengganti logikanya.

Manfaat Upgradeability Smart Contract

Manfaat pertama adalah kemampuan memperbaiki bug setelah deployment.

Manfaat kedua adalah kemampuan menambahkan fitur tanpa mengharuskan pengguna bermigrasi secara manual.

Manfaat ketiga adalah kesinambungan alamat bagi pengguna, wallet, dan integrasi.

Manfaat keempat adalah kemampuan merespons keadaan darurat dengan lebih baik.

Manfaat kelima adalah pemeliharaan jangka panjang yang lebih baik untuk protokol kompleks.

Manfaat keenam adalah iterasi produk yang lebih lancar di pasar kripto yang bergerak cepat.

Manfaat ketujuh adalah kemampuan memperbarui integrasi oracle, parameter risiko, atau dependensi eksternal.

Manfaat kedelapan adalah berkurangnya hambatan migrasi saat desain protokol berkembang.

Manfaat-manfaat ini menjelaskan mengapa banyak aplikasi kripto canggih memilih arsitektur yang dapat di-upgrade.

Manfaatnya paling besar jika otoritas upgrade transparan, aman, tertunda, diaudit, dan dikelola secara bertanggung jawab.

Risiko dan Keterbatasan Upgradeability Smart Contract

Risiko pertama adalah otoritas upgrade yang berbahaya atau disusupi.

Risiko kedua adalah kerusakan penyimpanan akibat perubahan implementasi yang tidak aman.

Risiko ketiga adalah penyalahgunaan initializer atau reinitializer.

Risiko keempat adalah sentralisasi tersembunyi melalui kunci admin.

Risiko kelima adalah integrasi yang rusak akibat perubahan ABI atau perilaku.

Risiko keenam adalah kebingungan pengguna karena alamat yang terlihat mungkin tetap sama sementara logikanya berubah.

Risiko ketujuh adalah penyalahgunaan upgrade darurat.

Risiko kedelapan adalah rasa aman palsu akibat audit yang hanya mencakup implementasi lama.

Risiko kesembilan adalah pengambilalihan tata kelola atau voting yang terburu-buru.

Risiko kesepuluh adalah kompleksitas yang membuat sistem lebih sulit dipahami pengguna dan auditor.

Praktik Terbaik bagi Developer

Jika memungkinkan, gunakan library upgrade yang matang dan telah ditinjau dengan baik alih-alih membuat kode proxy sendiri.

Pilih pola upgrade yang jelas, seperti Transparent Proxy, UUPS, Beacon Proxy, atau Diamond, hanya setelah memahami komprominya.

Validasi tata letak penyimpanan sebelum setiap upgrade.

Lindungi initializer dan reinitializer dengan cermat.

Gunakan kontrol multisignature, timelock, dan proses tata kelola untuk otoritas upgrade yang signifikan.

Publikasikan alamat implementasi, transaksi upgrade, dan penjelasan upgrade dalam bahasa sederhana.

Verifikasi kode sumber untuk setiap implementasi baru.

Jalankan pengujian upgrade menggunakan status yang menyerupai produksi dan lingkungan fork jika sesuai.

Audit upgrade besar sebelum eksekusi.

Pantau event upgrade dan siapkan rencana rollback atau respons insiden jika arsitektur memungkinkan.

Praktik Terbaik bagi Pengguna

Periksa apakah kontrak dapat di-upgrade sebelum menyetorkan dana.

Tinjau pihak yang mengendalikan otoritas upgrade.

Pilih protokol yang menggunakan timelock, kontrol multisignature, audit, dan tata kelola publik untuk upgrade.

Periksa apakah kode sumber implementasi saat ini telah diverifikasi.

Jangan menganggap audit lama mencakup implementasi baru.

Pantau pengumuman upgrade protokol besar jika Anda sering menggunakan protokol tersebut.

Pahami apakah upgrade darurat dapat melewati penundaan normal.

Tinjau peran admin, kontrol pause, kontrol oracle, dan izin mint token.

Jika memungkinkan, pertimbangkan untuk menarik dana sebelum upgrade yang kontroversial atau tidak jelas.

Perlakukan upgradeability sebagai asumsi kepercayaan, bukan detail teknis kecil.

FAQ

Apa arti Upgradeability Smart Contract?

Upgradeability smart contract berarti sistem smart contract yang telah di-deploy dapat mengubah logikanya setelah deployment melalui mekanisme upgrade yang dirancang khusus.

Mengapa smart contract di-upgrade?

Smart contract di-upgrade untuk memperbaiki bug, menambahkan fitur, meningkatkan keamanan, memperbarui integrasi, menyesuaikan kontrol risiko, atau merespons kebutuhan protokol yang berubah.

Apakah smart contract yang dapat di-upgrade kurang aman?

Smart contract yang dapat di-upgrade tidak otomatis kurang aman, tetapi menambahkan risiko terkait kontrol admin, tata letak penyimpanan, tata kelola, dan perubahan implementasi di masa depan.

Apa itu kontrak proxy?

Kontrak proxy adalah alamat stabil yang meneruskan panggilan ke kontrak implementasi sambil biasanya mempertahankan status sistem.

Apa itu kontrak implementasi?

Kontrak implementasi berisi logika yang dijalankan proxy melalui delegasi.

Apa risiko terbesar dari upgrade smart contract?

Risiko terbesar adalah otoritas upgrade yang berwenang atau telah disusupi dapat mengganti logika yang aman dengan logika yang rusak atau berbahaya.

Apa itu risiko tata letak penyimpanan?

Risiko tata letak penyimpanan adalah kemungkinan implementasi baru membaca atau menulis penyimpanan proxy yang sudah ada secara keliru sehingga merusak status penting.

Apa itu timelock dalam upgradeability?

Timelock menunda eksekusi upgrade agar pengguna dan peninjau memiliki waktu untuk memeriksa perubahan yang diusulkan sebelum berlaku.

Apakah kode sumber terverifikasi berarti kontrak yang dapat di-upgrade aman?

Tidak. Kode sumber terverifikasi meningkatkan transparansi, tetapi pengguna tetap harus meninjau otoritas upgrade, audit, keamanan penyimpanan, tata kelola, dan risiko perubahan di masa depan.

Bagaimana cara mengetahui apakah kontrak dapat di-upgrade?

Anda dapat memeriksa label proxy di block explorer, alamat implementasi, slot ERC-1967, event upgrade, peran admin, dokumentasi tata kelola, dan laporan audit.

Kesimpulan

Upgradeability smart contract adalah pendekatan desain yang memungkinkan aplikasi blockchain mengubah logika kontrak setelah deployment sambil mempertahankan alamat dan status penting.

Upgradeability banyak digunakan karena aplikasi kripto sering memerlukan perbaikan bug, peningkatan fitur, patch keamanan, dan pembaruan integrasi setelah peluncuran.

Desain upgradeability yang paling umum menggunakan proxy, kontrak implementasi, delegatecall, slot penyimpanan standar, dan otoritas upgrade yang dikendalikan.

Upgradeability dapat membuat protokol lebih mudah dipelihara dan tangguh, tetapi juga mengubah model kepercayaan karena kode di masa depan dapat berbeda dari kode yang semula ditinjau pengguna.

Keamanan sistem yang dapat di-upgrade bergantung pada disiplin tata letak penyimpanan, perlindungan initializer, verifikasi kode sumber, pengujian, audit, keamanan kunci admin, timelock, dan tata kelola yang transparan.

Pengguna sebaiknya tidak pernah menganggap kontrak yang dapat di-upgrade sepenuhnya immutable, kecuali otoritas upgrade telah dihapus atau secara desain tidak mungkin digunakan.

Developer sebaiknya tidak menganggap upgradeability sebagai jalan pintas sederhana karena pola ini menambah tanggung jawab serius dalam rekayasa dan tata kelola.

Bagi pemula, upgradeability smart contract paling mudah dipahami sebagai cara memperbarui software blockchain setelah deployment.

Bagi pengguna tingkat lanjut, upgradeability merupakan model keamanan lengkap yang mencakup arsitektur proxy, kompatibilitas penyimpanan, kontrol akses, eksekusi tata kelola, pemantauan, dan hak pengguna untuk keluar.

Dalam konteks glosarium kripto, Upgradeability Smart Contract berarti kemampuan sistem smart contract yang telah di-deploy untuk mengubah logikanya melalui mekanisme terkendali sambil mempertahankan status on-chain penting dan alamat yang digunakan pengguna.

Intinya, upgradeability smart contract dapat melindungi pengguna dari bug permanen dan mendukung perkembangan protokol, tetapi harus dikelola secara transparan melalui kontrol yang kuat, pengujian cermat, dan pengungkapan yang jelas karena kekuatan upgrade juga dapat menjadi sumber risiko besar.