---
title: "Kontrak pintar yang dapat ditingkatkan"
description: "Kontrak pintar yang dapat ditingkatkan mempertahankan alamat dan status proxy saat pihak berwenang mengganti atau mengarahkan ulang implementasinya. Fleksibilitas ini menambah risiko penyimpanan, inisialisasi, tata kelola, dan pemantauan."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Kontrak pintar yang dapat ditingkatkan
> Hanya untuk tujuan edukasi; bukan nasihat investasi atau keamanan. Kemampuan peningkatan dapat memberi pihak berhak kuasa untuk mengubah perilaku kontrak dan dapat menimbulkan kerugian.
## Jawaban langsung
Kontrak pintar yang dapat ditingkatkan adalah sistem terpasang yang logika efektifnya dapat diubah tanpa memindahkan pengguna ke alamat utama baru atau membuang status yang tersimpan. Di jaringan kompatibel Ethereum, proxy biasanya menyimpan status dan meneruskan panggilan melalui `delegatecall` ke kontrak implementasi. Peningkatan berwenang mengganti implementasi, sedangkan alamat, penyimpanan, dan saldo proxy tetap.
Bytecode kekal tidak ditulis ulang; lapisan pengalihan ditambahkan. Mekanisme ini dapat memperbaiki cacat dan menambah fitur, tetapi juga menciptakan jalur istimewa yang dapat mengubah penarikan, biaya, izin, atau akuntansi. Nilailah kode saat ini serta aturan untuk kode mendatang.
Tidak semua proxy dapat ditingkatkan dan tidak semua sistem yang dapat berubah memakai proxy. Ada proyek yang memasang kontrak baru dan memigrasikan status; ada pula yang menonaktifkan peningkatan selamanya. Arsitektur serta wewenang on-chain lebih penting daripada label antarmuka.
## Cara kerja
Proxy membaca alamat implementasi dan menjalankan kodenya dalam konteks penyimpanan proxy melalui `delegatecall`. Baca-tulis memengaruhi proxy, sementara pengirim dan nilai asli dipertahankan. ERC-1967 menstandarkan slot implementasi, beacon, dan admin.
Proxy transparent memisahkan panggilan admin dan pengguna. Proxy UUPS menempatkan logika peningkatan dalam implementasi serta memakai kompatibilitas ERC-1822, sehingga otorisasi sangat penting. Proxy beacon mengambil implementasi dari beacon; satu pembaruan dapat mengubah banyak proxy.
Kompatibilitas status adalah batasan utama. Mengurutkan ulang, menghapus, mengubah tipe variabel, atau mengubah pewarisan dapat merusak data. Layout yang hanya ditambah, celah cadangan, atau penyimpanan namespace ERC-7201 membantu, tetapi tetap memerlukan validasi antarversi.
Konstruktor menginisialisasi implementasi, bukan penyimpanan proxy. Karena itu inisialisator seperti `initialize` biasanya dipanggil sekali. Implementasi harus mengunci inisialisasi langsung dan migrasi berikutnya memakai reinisialisator terbatas. Inisialisator publik atau berulang dapat menyerahkan kendali.
Proses yang dapat dipertanggungjawabkan adalah:
1. Tetapkan sumber, compiler, dependensi, layout, alamat, dan bytecode harapan kedua implementasi.
2. Tinjau selisih, kompatibilitas, inisialisasi atau migrasi, otorisasi, dependensi, dan rollback; uji transaksi lengkap pada fork.
3. Terbitkan proposal dan alamat, lalu jalankan multisig, tata kelola, dan timelock yang dinyatakan tanpa jalan pintas tersembunyi.
4. Eksekusi dan verifikasi slot implementasi atau beacon, peristiwa, bytecode, status awal, peran, dan invariant pada blok tercatat.
5. Pantau perubahan slot, peran, serta parameter dan siapkan insiden tanpa menganggap rollback selalu aman.
## Contoh
Protokol pinjaman memerlukan fitur pembayaran baru. Proxy-nya mendelegasikan ke implementasi A. Tim memasang B, memastikan B hanya menambah penyimpanan, lalu menyiapkan migrasi. Tata kelola menerbitkan bytecode dan menaruh peningkatan di balik timelock 48 jam. Sesudahnya alamat yang sama mendelegasikan ke B dan saldo tetap di proxy.
Pengguna harus memastikan slot berubah dari A ke B, migrasi berjalan sekali, serta peran dan saldo sesuai. Jika penjaga dapat melewati timelock atau penanda tangan mengganti B dengan kode sebarang, kuasa itu termasuk dalam model kepercayaan.
## Risiko
- **Penggantian istimewa:** admin, multisig, gubernur, atau kunci bocor dapat memasang logika jahat atau cacat.
- **Kerusakan penyimpanan:** layout tidak kompatibel dapat salah menafsirkan saldo, pemilik, mapping, atau akuntansi.
- **Kegagalan inisialisasi:** inisialisator hilang, berulang, atau terbuka dapat melumpuhkan sistem atau memindahkan kendali.
- **Kegagalan khusus pola:** proxy transparent, UUPS, beacon, dan khusus gagal dengan cara berbeda; nama pola bukan bukti.
- **Tata kelola semu:** timelock atau suara dapat memiliki bypass darurat, jeda pendek, kuasa terpusat, atau penanda tangan lemah.
- **Migrasi atau rollback tidak aman:** status dapat berubah permanen; kode lama belum tentu memulihkan makna lama.
- **Celah verifikasi:** sumber implementasi terverifikasi tidak membuktikan proxy menunjuk kepadanya atau status dan admin sesuai.
- **Risiko pemantauan dan integrasi:** penjelajah, antarmuka, auditor, dan integrasi dapat mengikuti versi lama atau melewatkan perubahan beacon.
## Kesalahpahaman umum
- **“Kontrak di alamat ini kekal.”** Bytecode proxy mungkin kekal sementara slot implementasi atau beacon mengubah perilakunya.
- **“Multisig mendesentralisasi peningkatan.”** Itu hanya mengurangi ketergantungan satu kunci bila penanda tangan, ambang, operasi, dan penggantian kuat.
- **“Timelock mencegah peningkatan jahat.”** Ia memberi waktu untuk mengamati dan keluar, bukan membuat kode aman.
- **“Lulus pemeriksaan penyimpanan membuktikan keamanan.”** Itu hanya mencakup layout, bukan logika, otorisasi, oracle, migrasi, atau ekonomi.
- **“Melepas peningkatan selalu menghapus kendali.”** Admin, beacon, gubernur, otorisasi UUPS, dan jalur alternatif harus diperiksa on-chain.
## Topik terkait
- [Kontrak pintar](/id/crypto/smart-contract/)
- [Cara membaca audit kontrak](/id/crypto/contract-audit/)
- [Dompet multisignature](/id/crypto/multisig-wallet/)
- [Timelock](/id/crypto/timelock/)
## Sumber
- [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (diakses: 2026-08-22)
- [ERC-1822: Universal Upgradeable Proxy Standard (UUPS)](https://eips.ethereum.org/EIPS/eip-1822) - Ethereum Improvement Proposals (diakses: 2026-08-22)
- [ERC-7201: Namespaced Storage Layout](https://eips.ethereum.org/EIPS/eip-7201) - Ethereum Improvement Proposals (diakses: 2026-08-22)
- [Proxy Upgrade Pattern](https://docs.openzeppelin.com/upgrades-plugins/proxies) - OpenZeppelin Docs (diakses: 2026-08-22)
- [Writing Upgradeable Contracts](https://docs.openzeppelin.com/upgrades-plugins/writing-upgradeable) - OpenZeppelin Docs (diakses: 2026-08-22)
- [Proxy](https://docs.openzeppelin.com/contracts/5.x/api/proxy) - OpenZeppelin Docs (diakses: 2026-08-22)
- [Layout of State Variables in Storage and Transient Storage](https://docs.soliditylang.org/en/latest/internals/layout_in_storage.html) - Solidity Documentation (diakses: 2026-08-22)
Source: https://wiki.fcontext.com/id/crypto/upgradeable-contract/index.mdx