Kontrak yang Dapat Di-upgrade

Apa Itu Kontrak yang Dapat Di-upgrade?

Kontrak yang dapat di-upgrade adalah desain smart contract yang memungkinkan aplikasi blockchain mengubah atau memperluas logikanya setelah deployment sambil mempertahankan alamat yang digunakan pengguna, state tersimpan, dan saldo yang sama.

Dalam mata uang kripto, kontrak yang dapat di-upgrade paling sering digunakan untuk protokol DeFi, sistem token, kontrak staking, bridge, pasar pinjaman, smart account, sistem governance, dan aplikasi on-chain lainnya yang mungkin memerlukan perbaikan atau fitur baru seiring waktu.

Smart contract tradisional biasanya disebut immutable karena kode yang telah di-deploy tidak dapat diedit secara langsung setelah berada di blockchain.

Kontrak yang dapat di-upgrade mengatasi keterbatasan ini dengan memisahkan alamat kontrak dan data tersimpan dari logika bisnis yang menjalankan tindakan pengguna.

Cara paling umum untuk membangun kontrak yang dapat di-upgrade adalah pola proxy, ketika pengguna berinteraksi dengan kontrak proxy dan proxy meneruskan panggilan ke kontrak implementasi terpisah.

Proxy mempertahankan alamat publik yang sama, sedangkan kontrak implementasi dapat diganti dengan versi yang lebih baru ketika upgrade dilakukan oleh pihak berwenang.

Artinya, pengguna tidak perlu berpindah ke alamat kontrak baru setiap kali protokol memperbaiki bug, menambahkan fitur, atau meningkatkan logika internal.

Bagi pengguna kripto, manfaat utamanya adalah kesinambungan, karena saldo token, catatan staking, hak voting, dan posisi protokol dapat tetap berada dalam storage kontrak yang sama.

Bagi developer, manfaat utamanya adalah fleksibilitas, karena mereka dapat meningkatkan protokol tanpa memaksa migrasi penuh dana dan data pengguna.

Bagi investor dan trader, perhatian utamanya adalah risiko governance, karena kewenangan upgrade dapat mengubah cara kerja protokol setelah pengguna menyetor aset.

Cara Kerja Kontrak yang Dapat Di-upgrade

Kontrak yang dapat di-upgrade biasanya memiliki setidaknya dua bagian inti, yaitu kontrak proxy dan kontrak implementasi.

Kontrak proxy adalah alamat yang biasanya digunakan untuk berinteraksi oleh pengguna, wallet, blockchain explorer, dan smart contract lainnya.

Kontrak implementasi berisi logika sebenarnya, seperti aturan transfer, perhitungan staking, fungsi pinjaman, distribusi reward, atau pemeriksaan kontrol akses.

Saat pengguna mengirim transaksi ke proxy, proxy menggunakan mekanisme tingkat rendah yang disebut

untuk menjalankan kode dari kontrak implementasi.

Dengan

, logika implementasi berjalan seolah-olah merupakan bagian dari proxy, tetapi storage, alamat, dan saldo tetap terikat pada proxy.

Inilah alasan proxy dapat mempertahankan data pengguna sambil mengubah alamat implementasi saat upgrade.

Upgrade itu sendiri biasanya terjadi ketika admin yang berwenang, wallet multisig, kontrak governance, atau timelock mengubah pointer implementasi proxy ke kontrak implementasi baru.

Implementasi baru harus dirancang dengan cermat agar bekerja dengan storage layout proxy yang sudah ada.

Jika storage layout rusak, kontrak yang telah di-upgrade dapat salah membaca saldo, catatan kepemilikan, izin, atau data penting lainnya.

Ini adalah salah satu alasan utama kontrak yang dapat di-upgrade memerlukan rekayasa, pengujian, dan audit yang lebih ketat daripada kontrak sederhana yang tidak dapat di-upgrade.

Mengapa Kontrak yang Dapat Di-upgrade Penting dalam Kripto

Kontrak yang dapat di-upgrade penting karena aplikasi kripto sering mengamankan aset nyata dan tidak dapat mengandalkan metode pembaruan perangkat lunak tradisional.

Dalam aplikasi web biasa, developer dapat menambal kode backend, melakukan redeploy layanan, atau mengubah database tanpa meminta pengguna memindahkan aset mereka.

Di blockchain publik, kode kontrak yang telah di-deploy biasanya bersifat permanen, sehingga bug serius mungkin memerlukan migrasi yang sulit jika kontrak tidak dapat di-upgrade.

Desain yang dapat di-upgrade dapat mengurangi masalah ini dengan memungkinkan pembaruan terkontrol pada logika protokol.

Hal ini berguna saat proyek perlu memperbaiki kerentanan, mendukung standar token baru, menambahkan kontrol risiko, meningkatkan efisiensi gas, atau merespons perubahan dalam ekosistem blockchain.

Namun, kemampuan upgrade juga mengubah model kepercayaan sebuah aplikasi kripto.

Jika satu alamat dapat langsung meng-upgrade kontrak, pengguna harus memercayai alamat tersebut agar tidak memasang logika yang berbahaya atau ceroboh.

Jika upgrade dikendalikan oleh governance terdesentralisasi, pengguna harus memercayai proses governance, aturan voting, timelock, dan partisipasi pemilih.

Kontrak yang dapat di-upgrade dengan desain baik harus menyeimbangkan fleksibilitas dengan batasan kuat atas pihak yang dapat melakukan upgrade, waktu upgrade dapat dilakukan, dan cara pengguna memantau perubahan.

Pola Proxy

Pola proxy adalah arsitektur yang paling luas digunakan untuk kontrak yang dapat di-upgrade.

Dalam pola ini, kontrak proxy menyimpan state dan meneruskan panggilan fungsi ke kontrak implementasi.

Kontrak implementasi berisi logika bisnis, tetapi tidak seharusnya digunakan secara langsung oleh pengguna biasa.

Saat protokol di-upgrade, kontrak implementasi baru di-deploy dan proxy diperbarui agar menunjuk ke implementasi baru tersebut.

Alamat yang digunakan pengguna tetap sama, sehingga wallet, integrasi, dan kontrak lain dapat terus memanggil alamat proxy.

Desain ini dijelaskan secara terperinci dalam dokumentasi upgrade smart contract Ethereum.

Pola proxy kuat karena menghindari migrasi state manual yang dapat mahal, berisiko, dan membingungkan pengguna.

Pola ini juga berbahaya ketika developer tidak memahami cara kerja storage proxy, function selector, fungsi initializer, dan izin admin.

Proxy tidak otomatis aman hanya karena dapat di-upgrade.

Keamanan desain bergantung pada kualitas implementasi, izin upgrade, pengujian, governance, dan pemantauan.

Kontrak Implementasi

Kontrak implementasi terkadang disebut kontrak logika karena berisi kode yang menentukan cara aplikasi bekerja.

Misalnya, dalam kontrak token, implementasi dapat menentukan aturan transfer, approval, batas minting, logika burning, dan izin berbasis peran.

Dalam kontrak staking, implementasi dapat menentukan aturan deposit, aturan penarikan, rumus reward, logika penalti, dan kontrol darurat.

Dalam kontrak pinjaman, implementasi dapat menentukan aturan jaminan, perhitungan bunga, logika likuidasi, dan parameter risiko.

Saat proxy mendelegasikan panggilan ke implementasi, kode implementasi menggunakan storage proxy.

Artinya, implementasi harus ditulis seolah-olah variabelnya akan disimpan di dalam kontrak proxy.

Developer biasanya harus mencegah pengguna menginisialisasi atau menyalahgunakan kontrak implementasi secara langsung.

Mereka juga perlu memastikan setiap implementasi baru kompatibel dengan storage layout versi sebelumnya.

Implementasi baru yang mengubah storage secara tidak benar dapat menyebabkan kerusakan permanen pada data on-chain.

Storage Layout

Storage layout adalah salah satu konsep terpenting dalam keamanan kontrak yang dapat di-upgrade.

Dalam Solidity, state variable ditempatkan ke storage slot berdasarkan aturan tertentu, termasuk urutan variabel dan urutan pewarisan.

Saat kontrak di-upgrade, implementasi baru harus menafsirkan storage proxy yang ada dengan cara yang sama seperti implementasi lama.

Developer biasanya hanya menambahkan variabel baru setelah variabel yang ada, bukan menghapus variabel, mengubah urutan variabel, atau mengubah tipe variabel.

Jika kontrak semula menyimpan saldo pengguna dalam satu slot, versi baru tidak boleh secara tidak sengaja memperlakukan slot yang sama sebagai alamat admin atau variabel reward.

Storage collision dapat menyebabkan saldo rusak, izin hilang, pencatatan yang salah, atau perilaku kontrak yang dapat dieksploitasi.

Dokumentasi storage layout Solidity menjelaskan cara Solidity mengatur state variable dalam persistent storage.

Library kontrak yang dapat di-upgrade modern juga menyertakan alat dan pemeriksaan yang membantu developer mendeteksi perubahan storage tidak aman sebelum deployment.

Meski tersedia alat, storage layout tetap harus ditinjau dengan saksama pada setiap upgrade.

Storage Slot Proxy ERC-1967

ERC-1967 adalah standar Ethereum umum yang mendefinisikan storage slot khusus untuk informasi proxy, termasuk alamat implementasi, alamat admin, dan alamat beacon.

Tujuan ERC-1967 adalah mengurangi storage collision antara proxy dan kontrak implementasi.

Standar ini juga membantu blockchain explorer dan alat developer mengidentifikasi implementasi di balik proxy.

Tanpa storage slot standar, wallet, explorer, auditor, dan alat pemantauan akan lebih sulit memahami kontrak logika mana yang digunakan sebuah proxy.

ERC-1967 sangat penting karena proxy sendiri perlu menyimpan data terkait upgrade, sementara implementasi juga mengharapkan penggunaan storage proxy.

Spesifikasi ERC-1967 resmi mendefinisikan konvensi storage slot proxy ini.

Bagi pengguna kripto, ERC-1967 dapat membuat kontrak yang dapat di-upgrade lebih mudah diperiksa karena banyak alat dapat menampilkan alamat implementasi saat ini.

Bagi developer, ERC-1967 menyediakan cara yang lebih aman dan standar untuk menyimpan metadata proxy.

Namespaced Storage ERC-7201

ERC-7201 adalah standar yang lebih baru untuk namespaced storage layout dalam smart contract.

Namespaced storage mengelompokkan state variable terkait dalam namespace tertentu untuk mengurangi konflik storage layout, terutama pada sistem yang dapat di-upgrade dan kompleks.

Hal ini berguna ketika kontrak menggunakan pewarisan, modul, plugin, atau beberapa komponen yang dapat di-upgrade.

OpenZeppelin Contracts 5.x menggunakan pola kontrak yang dapat di-upgrade yang mencakup namespace storage bergaya ERC-7201 pada varian yang dapat di-upgrade.

Spesifikasi ERC-7201 resmi menjelaskan konvensi untuk mendokumentasikan lokasi namespaced storage dalam kode sumber Solidity.

Bagi developer, namespaced storage dapat membuat upgrade lebih mudah dianalisis karena setiap komponen kontrak dapat mempertahankan area storage-nya sendiri.

Bagi pengguna, namespaced storage sebagian besar tidak terlihat, tetapi dapat meningkatkan keamanan bila diimplementasikan dengan benar.

Hal ini tidak menghilangkan kebutuhan akan audit, pengujian, dan peninjauan upgrade yang cermat.

Initializer sebagai Pengganti Constructor

Kontrak yang dapat di-upgrade biasanya menggunakan fungsi initializer sebagai pengganti constructor.

Constructor normal hanya berjalan saat kontrak di-deploy, tetapi dalam desain proxy, proxy menggunakan kode implementasi tanpa menjalankan constructor implementasi untuk state proxy.

Inilah sebabnya kontrak yang dapat di-upgrade biasanya memindahkan logika penyiapan ke fungsi seperti

.

Initializer menetapkan nilai seperti nama token, simbol token, alamat owner, peran admin, parameter biaya, atau konfigurasi awal.

Initializer harus dilindungi agar hanya dapat berjalan sekali untuk setiap proxy.

Jika initializer dapat dipanggil lebih dari sekali, penyerang dapat mengatur ulang kepemilikan, mengubah izin, atau mengambil alih kontrak.

Panduan penulisan kontrak yang dapat di-upgrade dari OpenZeppelin menjelaskan alasan constructor digantikan oleh fungsi initializer dalam kontrak yang dapat di-upgrade berbasis proxy.

Kontrak yang dapat di-upgrade dengan desain baik juga menggunakan fungsi reinitializer secara hati-hati saat versi baru menambahkan kebutuhan penyiapan baru.

Setiap initializer dan reinitializer harus ditinjau sebagai bagian dari proses upgrade.

Transparent Proxy

Transparent proxy adalah desain proxy yang memisahkan panggilan admin dari panggilan pengguna.

Dalam model ini, admin dapat melakukan tindakan terkait upgrade, sedangkan pengguna biasa diteruskan ke kontrak implementasi.

Pola transparent proxy membantu menghindari masalah ketika admin secara tidak sengaja memicu fungsi implementasi melalui proxy.

Pola ini juga mengurangi risiko konflik function selector antara fungsi admin proxy dan fungsi implementasi.

Pola ini umum digunakan dalam sistem produksi karena memberikan struktur admin yang jelas untuk upgrade.

Konsekuensinya, pola ini dapat melibatkan komponen deployment dan manajemen tambahan, seperti kontrak proxy admin.

Bagi pengguna, hal pentingnya adalah mengidentifikasi pihak yang mengendalikan proxy admin dan apakah upgrade ditunda, diatur oleh governance, atau dipantau secara eksternal.

UUPS Proxy

UUPS adalah singkatan dari Universal Upgradeable Proxy Standard.

Dalam desain UUPS, logika upgrade biasanya ditempatkan dalam kontrak implementasi, alih-alih dikelola sepenuhnya oleh proxy itu sendiri.

Hal ini dapat membuat proxy lebih kecil dan lebih murah untuk di-deploy, tetapi berarti implementasi harus menyertakan dan melindungi fungsi upgrade dengan benar.

Jika logika otorisasi upgrade salah, kontrak dapat menjadi rentan terhadap upgrade tidak sah.

Jika fungsi upgrade dihapus atau rusak dalam implementasi mendatang, proxy dapat menjadi sulit atau tidak mungkin di-upgrade kembali.

Proxy UUPS populer, tetapi memerlukan kontrol akses dan pengujian yang cermat.

Pengguna perlu memeriksa apakah kontrak UUPS memiliki otoritas upgrade yang jelas, timelock, dan riwayat upgrade publik.

Beacon Proxy

Beacon proxy adalah desain ketika beberapa kontrak proxy membaca alamat implementasinya dari kontrak beacon bersama.

Hal ini memungkinkan banyak instance proxy di-upgrade sekaligus dengan mengubah alamat implementasi yang disimpan dalam beacon.

Beacon proxy dapat berguna ketika sebuah protokol men-deploy banyak kontrak serupa, seperti vault, pool, akun, atau posisi tokenisasi.

Keunggulan utamanya adalah efisiensi operasional, karena satu upgrade beacon dapat memperbarui banyak proxy.

Risiko utamanya adalah konsentrasi, karena upgrade beacon yang buruk dapat memengaruhi banyak kontrak pada saat bersamaan.

Kepemilikan beacon dan izin upgrade harus dilindungi dengan governance dan pemantauan yang kuat.

Diamond Pattern

Diamond pattern adalah arsitektur upgrade ketika satu proxy dapat merutekan panggilan fungsi yang berbeda ke kontrak implementasi berbeda, yang sering disebut facet.

Hal ini memungkinkan sistem smart contract besar dipisahkan menjadi modul-modul yang lebih kecil.

Desain diamond dapat meng-upgrade satu bagian sistem tanpa mengganti setiap fungsi sekaligus.

Hal ini dapat berguna bagi protokol kripto kompleks yang memerlukan banyak fitur di bawah satu alamat.

Konsekuensinya adalah kompleksitas, karena developer harus mengelola function selector, storage facet, kontrol akses, dan aturan upgrade dengan sangat cermat.

Sistem bergaya diamond dapat sangat kuat, tetapi mungkin lebih sulit diperiksa pengguna rata-rata daripada struktur proxy yang lebih sederhana.

Manfaat Kontrak yang Dapat Di-upgrade

Manfaat pertama kontrak yang dapat di-upgrade adalah perbaikan bug.

Jika masalah serius ditemukan, developer mungkin dapat menambal logika tanpa memaksa pengguna memigrasikan dana secara manual.

Manfaat kedua adalah perluasan fitur.

Protokol dapat menambahkan jenis jaminan baru, aturan reward baru, modul baru, atau kontrol keamanan baru sambil mempertahankan alamat kontrak yang sama.

Manfaat ketiga adalah stabilitas integrasi.

Wallet, platform analitik, agregator, dan smart contract lainnya dapat terus menunjuk ke alamat proxy yang sama setelah upgrade.

Manfaat keempat adalah pengalaman pengguna.

Pengguna mungkin tidak perlu melakukan approval, menarik, deposit ulang, atau memindahkan posisi secara manual pada setiap pembaruan protokol.

Manfaat kelima adalah respons darurat.

Proses upgrade yang dikelola dengan baik dapat membantu protokol merespons risiko aktif lebih cepat daripada proses migrasi penuh.

Risiko Kontrak yang Dapat Di-upgrade

Risiko terbesar kontrak yang dapat di-upgrade adalah penyalahgunaan admin.

Jika otoritas upgrade dikendalikan oleh private key yang lemah, tim yang ceroboh, atau proses governance yang disusupi, kontrak dapat diubah dengan cara yang merugikan.

Upgrade berbahaya dapat menguras dana, memblokir penarikan, mengubah biaya, memodifikasi saldo, atau menghapus perlindungan pengguna.

Risiko besar lainnya adalah kerusakan storage.

Upgrade implementasi yang dirancang buruk dapat merusak hubungan antara data lama dan logika baru.

Risiko ketiga adalah kompleksitas tersembunyi.

Pengguna mungkin mengira mereka berinteraksi dengan satu kontrak, tetapi perilaku sebenarnya bergantung pada alamat implementasi saat ini dan izin upgrade.

Risiko keempat adalah pemantauan yang buruk.

Jika pengguna dan integrasi tidak melacak upgrade, mereka mungkin melewatkan perubahan penting pada perilaku protokol.

Risiko kelima adalah pengambilalihan governance.

Jika kekuatan voting terkonsentrasi, kelompok kecil dapat menyetujui upgrade yang menguntungkan mereka sendiri dengan mengorbankan pengguna lain.

Cara Pengguna Mengevaluasi Kontrak yang Dapat Di-upgrade

Pengguna sebaiknya terlebih dahulu memeriksa apakah kontrak tersebut adalah proxy dan implementasi apa yang saat ini digunakannya.

Banyak blockchain explorer menampilkan informasi proxy ketika kontrak mengikuti standar proxy umum seperti ERC-1967.

Pengguna juga perlu memeriksa pihak yang memiliki izin untuk meng-upgrade kontrak.

Upgrade yang dikendalikan oleh satu externally owned account biasanya lebih berisiko daripada upgrade yang dikendalikan oleh multisig, timelock, atau proses governance yang transparan.

Pengguna perlu meninjau apakah proyek mengumumkan upgrade sebelum upgrade dilakukan.

Mereka juga perlu memeriksa apakah kontrak telah diaudit, apakah laporan audit mencakup logika upgrade, dan apakah upgrade sebelumnya dilakukan dengan aman.

Untuk deposit besar, pengguna perlu memperhatikan durasi timelock, kewenangan pause darurat, perubahan peran admin, dan riwayat event upgrade.

Kontrak dapat ditulis dengan baik secara teknis tetapi tetap berisiko jika otoritas upgrade terlalu terpusat atau dipantau dengan buruk.

Praktik Terbaik bagi Developer

Developer sebaiknya menggunakan framework upgrade yang telah ditinjau dengan baik alih-alih menulis logika proxy dari awal, kecuali mereka memiliki pengalaman keamanan yang kuat.

Mereka perlu melindungi fungsi upgrade dengan kontrol akses yang kuat, seperti kepemilikan multisig, izin berbasis peran, timelock, atau governance on-chain.

Mereka perlu menulis pengujian otomatis untuk deployment awal dan setiap jalur upgrade.

Mereka perlu membandingkan storage layout sebelum dan setelah upgrade untuk mendeteksi perubahan tidak aman.

Mereka perlu menggunakan perlindungan initializer dan menghindari fungsi penyiapan tanpa perlindungan.

Mereka perlu menghindari pola tingkat rendah yang berbahaya kecuali diperlukan dan telah ditinjau sepenuhnya.

Mereka perlu memublikasikan kode sumber implementasi dan membuat hubungan proxy mudah diperiksa.

Mereka perlu mengeluarkan event yang jelas ketika upgrade terjadi agar sistem pemantauan dapat mendeteksi perubahan.

Mereka perlu mendokumentasikan apa yang berubah, mengapa perubahan dilakukan, dan risiko apa yang dipertimbangkan.

Mereka perlu merencanakan respons darurat tanpa memberikan kekuasaan tak terbatas kepada satu pihak.

Kontrak yang Dapat Di-upgrade vs Kontrak Immutable

Kontrak immutable tidak dapat mengubah kode yang telah di-deploy setelah deployment.

Hal ini memberikan prediktabilitas yang kuat kepada pengguna karena aturan bersifat tetap, kecuali kontrak telah menyertakan parameter yang dapat dikonfigurasi.

Kontrak yang dapat di-upgrade dapat mengubah logikanya melalui mekanisme upgrade yang telah ditentukan.

Hal ini memberi developer fleksibilitas tetapi mengharuskan pengguna memercayai proses upgrade.

Kontrak immutable sering lebih disukai untuk aset sederhana, protokol minimal, atau sistem ketika aturan tetap lebih penting daripada fleksibilitas di masa depan.

Kontrak yang dapat di-upgrade sering lebih disukai untuk protokol kompleks yang mungkin memerlukan patch, kontrol risiko, integrasi, dan pemeliharaan jangka panjang.

Tidak ada satu desain yang selalu lebih baik.

Pilihan yang tepat bergantung pada nilai aset yang diamankan, kompleksitas aplikasi, kebutuhan upgrade yang diperkirakan, dan kekuatan governance.

Mengapa Kemampuan Upgrade Memengaruhi Risiko Token dan Protokol

Kontrak yang dapat di-upgrade dapat secara langsung memengaruhi pemegang token karena logika kontrak dapat menentukan minting, burning, pembatasan transfer, biaya, atau hak governance.

Jika upgrade mengubah aturan token, hal tersebut dapat memengaruhi kepercayaan pasar dan utilitas token.

Kontrak staking yang dapat di-upgrade dapat memengaruhi tingkat reward, periode penguncian, penalti, dan perilaku penarikan.

Kontrak pinjaman yang dapat di-upgrade dapat memengaruhi rasio jaminan, ambang likuidasi, suku bunga, dan kontrol risiko pasar.

Bridge yang dapat di-upgrade dapat memengaruhi kustodi aset, verifikasi pesan, dan logika penarikan.

Karena itu, trader dan investor jangka panjang perlu memperlakukan izin upgrade sebagai bagian dari analisis fundamental protokol.

Sebuah token mungkin tampak terdesentralisasi di tingkat pasar tetapi tetap bergantung pada kontrak yang dapat di-upgrade oleh kelompok kecil.

Memahami kemampuan upgrade membantu pengguna menilai apakah aturan protokol benar-benar tetap atau masih dapat berubah.

Kesalahpahaman Umum

Salah satu kesalahpahaman umum adalah bahwa kontrak yang dapat di-upgrade berarti kode kontrak asli diedit di blockchain.

Dalam sebagian besar desain proxy, kode proxy asli tidak diedit, tetapi proxy diarahkan ke kontrak implementasi yang berbeda.

Kesalahpahaman lainnya adalah bahwa kemampuan upgrade selalu buruk.

Kemampuan upgrade dapat berguna jika transparan, dibatasi, diaudit, dan dikelola secara bertanggung jawab.

Kesalahpahaman ketiga adalah audit menghilangkan risiko upgrade.

Audit dapat meninjau kode saat ini dan proses upgrade, tetapi implementasi masa depan dapat memperkenalkan risiko baru.

Kesalahpahaman keempat adalah pengguna hanya perlu memeriksa alamat kontrak token.

Untuk sistem yang dapat di-upgrade, pengguna juga perlu memeriksa kontrak implementasi, peran admin, dan event upgrade.

Kesalahpahaman kelima adalah desentralisasi secara otomatis mencegah upgrade yang buruk.

Governance tetap dapat gagal jika kekuatan voting terkonsentrasi, partisipasi rendah, atau proposal sulit ditinjau.

FAQ

Apa itu kontrak yang dapat di-upgrade dalam kripto?

Kontrak yang dapat di-upgrade adalah desain smart contract yang memungkinkan protokol mengubah logikanya setelah deployment sambil mempertahankan alamat dan data tersimpan yang sama.

Mengapa proyek kripto menggunakan kontrak yang dapat di-upgrade?

Proyek kripto menggunakan kontrak yang dapat di-upgrade untuk memperbaiki bug, menambahkan fitur, meningkatkan kontrol keamanan, mengurangi biaya migrasi, dan mempertahankan integrasi seiring waktu.

Apakah kontrak yang dapat di-upgrade aman?

Kontrak yang dapat di-upgrade dapat aman ketika menggunakan kontrol akses yang kuat, manajemen storage yang cermat, audit, pemantauan, dan governance yang transparan.

Apa risiko utama kontrak yang dapat di-upgrade?

Risiko utamanya adalah pihak yang berwenang melakukan upgrade dapat memasang logika berbahaya atau cacat yang mengubah perilaku protokol atau menempatkan dana pengguna dalam risiko.

Apa itu kontrak proxy?

Kontrak proxy adalah kontrak yang digunakan pengguna, menyimpan data, dan meneruskan panggilan ke kontrak implementasi yang berisi logika saat ini.

Apa itu kontrak implementasi?

Kontrak implementasi adalah kontrak logika yang menentukan perilaku fungsi ketika proxy mendelegasikan panggilan kepadanya.

Mengapa kontrak yang dapat di-upgrade menggunakan initializer?

Kontrak yang dapat di-upgrade menggunakan initializer karena logika constructor tidak menginisialisasi storage proxy dengan cara yang sama seperti deployment kontrak biasa.

Apa itu storage collision?

Storage collision terjadi ketika logika kontrak baru membaca atau menulis storage slot dengan cara yang bertentangan dengan layout lama.

Apa itu ERC-1967?

ERC-1967 adalah standar yang mendefinisikan storage slot untuk informasi proxy seperti alamat implementasi, alamat admin, dan alamat beacon.

Apa itu ERC-7201?

ERC-7201 adalah standar untuk namespaced storage layout, yang membantu mengatur state variable dan mengurangi konflik storage dalam kontrak kompleks yang dapat di-upgrade.

Dapatkah kontrak yang dapat di-upgrade menjadi immutable di kemudian hari?

Ya, beberapa proyek dapat melepaskan atau menonaktifkan otoritas upgrade, tetapi pengguna perlu memverifikasinya secara on-chain, bukan hanya mengandalkan pengumuman.

Bagaimana pengguna dapat memeriksa apakah kontrak dapat di-upgrade?

Pengguna dapat memeriksa kontrak melalui blockchain explorer, mencari informasi proxy, meninjau alamat implementasi, serta memeriksa izin admin atau governance.

Kesimpulan

Kontrak yang dapat di-upgrade adalah desain smart contract yang kuat dan memberi protokol kripto kemampuan untuk meningkatkan logika sambil mempertahankan alamat, state, dan saldo.

Desain yang paling umum menggunakan kontrak proxy yang menyimpan data dan mendelegasikan eksekusi ke kontrak implementasi yang dapat diganti.

Model ini dapat memudahkan perbaikan bug, upgrade fitur, dan pemeliharaan protokol jangka panjang.

Model ini juga dapat menimbulkan risiko serius jika izin upgrade terpusat, storage layout ditangani dengan buruk, atau governance lemah.

Standar dan praktik penting seperti storage slot proxy ERC-1967, namespaced storage ERC-7201, fungsi initializer, audit, timelock, dan kontrol admin yang transparan dapat mengurangi risiko ini.

Bagi pengguna kripto, kemampuan upgrade harus selalu menjadi bagian dari analisis risiko karena menentukan apakah aturan protokol bersifat tetap atau masih dapat berubah.

Bagi developer, kontrak yang dapat di-upgrade harus diperlakukan sebagai infrastruktur yang kritis terhadap keamanan dan memerlukan desain, pengujian, pemantauan, serta governance yang cermat sejak deployment pertama.