---
title: "Kontrak proksi"
description: "Kontrak proksi meneruskan panggilan ke kode implementasi sambil mempertahankan alamat dan status proksi. Pelajari cara kerjanya serta risiko peningkatan, penyimpanan, dan administrator."
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 proksi
> Hanya untuk tujuan edukasi; bukan merupakan nasihat investasi atau rekomendasi investasi. Investasi dapat mengakibatkan kerugian.
## Jawaban langsung
Kontrak proksi adalah kontrak perantara yang meneruskan panggilan ke kontrak lain, biasanya disebut kontrak implementasi atau logika. Dalam desain EVM yang umum, proksi menggunakan `delegatecall`, sehingga kode implementasi berjalan dalam konteks proksi sementara status dan saldo tetap berada di alamat proksi.
Lapisan tidak langsung ini memungkinkan sistem mempertahankan alamat yang stabil bagi pengguna sambil mengganti implementasinya. Biaya penerapan juga dapat berkurang ketika banyak proksi berbagi kode. Proksi tidak otomatis dapat ditingkatkan: sebagian proksi minimal menunjuk secara permanen ke satu implementasi, sedangkan proksi yang dapat ditingkatkan menambahkan cara terkendali untuk mengganti implementasi atau beacon.
Karena itu, pengguna harus menilai implementasi aktif sekaligus pihak yang berwenang mengubahnya. Bytecode proksi yang terverifikasi saja tidak menentukan kode apa yang akan dijalankan besok.
## Cara kerjanya
Saat panggilan mencapai proksi, jalur fallback menyalin atau meneruskan data panggilan ke implementasi. Dengan `delegatecall`, `address(this)` adalah proksi, pembacaan dan penulisan penyimpanan memengaruhi proksi, sedangkan nilai asli `msg.sender` dan `msg.value` dipertahankan. Proksi kemudian mengembalikan data dari implementasi atau membatalkan panggilan bersamanya.
Karena metadata proksi berbagi ruang penyimpanan proksi dengan status aplikasi, slot terstandar membantu mencegah tabrakan yang tidak disengaja. ERC-1967 menetapkan slot untuk alamat implementasi, alamat beacon, dan administrator opsional, serta menganjurkan penerbitan peristiwa ketika nilai tersebut berubah. Standar ini memudahkan pemeriksaan proksi, tetapi tidak dengan sendirinya membuat peningkatan aman.
Desain yang umum menempatkan wewenang peningkatan di lokasi berbeda:
- **Proksi transparan:** proksi membedakan panggilan administratif dari panggilan pengguna biasa, umumnya melalui kontrak administrator terpisah.
- **Proksi UUPS:** logika peningkatan berada dalam implementasi, yang harus mengesahkan perubahan dan tetap kompatibel dengan antarmuka peningkatan yang diharapkan.
- **Proksi beacon:** proksi meminta implementasinya dari beacon; perubahan satu beacon dapat memengaruhi semua proksi yang mengikutinya.
- **Klon minimal:** banyak proksi kecil mendelegasikan ke kode bersama, sering kali tanpa jalur peningkatan sama sekali.
## Contoh
Misalkan sebuah proksi vault menyimpan saldo pengguna dan mendelegasikan ke implementasi A. Pengguna menyetor melalui alamat proksi, dan kode implementasi A memperbarui catatan saldo dalam penyimpanan proksi.
Kemudian tata kelola mengubah slot implementasi ERC-1967 menjadi implementasi B. Alamat proksi dan saldo tercatat tidak berpindah, tetapi panggilan berikutnya menjalankan kode B. Jika B mempertahankan tata letak penyimpanan dan menerapkan aturan yang dimaksud, pengguna melihat perilaku baru pada alamat yang sama.
Jika B mengubah urutan variabel penyimpanan, menghilangkan pemeriksaan otorisasi, atau menambahkan jalur penarikan yang dikendalikan oleh pihak peningkat, peningkatan yang sama dapat merusak akuntansi atau mengekspos aset. Jadi, pertanyaan operasional bukan sekadar apakah suatu kontrak merupakan proksi, melainkan siapa yang dapat mengubah jalur eksekusinya, dengan penundaan dan verifikasi apa.
## Risiko
- **Kompromi kunci peningkatan:** administrator, multisig, atau proses tata kelola dapat memasang kode berbahaya atau cacat.
- **Ketidakcocokan tata letak penyimpanan:** perubahan urutan, jenis, atau pewarisan variabel dapat membuat kode baru salah membaca atau menimpa status yang ada.
- **Kegagalan inisialisasi:** konstruktor tidak menginisialisasi penyimpanan proksi; perlindungan yang hilang atau dapat dijalankan ulang dapat memungkinkan akun lain mengambil peran istimewa.
- **Kejutan perutean panggilan:** tabrakan selektor fungsi, perutean khusus administrator, atau beacon tak terduga dapat membuat jalur eksekusi berbeda dari antarmuka yang terlihat.
- **Dampak luas peningkatan bersama:** satu keputusan mengenai beacon atau implementasi dapat mengubah banyak instans kontrak sekaligus.
Sebelum menyetor aset atau memberikan persetujuan, tentukan implementasi atau beacon saat ini di chain, identifikasi wewenang peningkatan dan timelock, tinjau kode sumber terverifikasi dan kompatibilitas penyimpanan, serta periksa peristiwa terbaru `Upgraded`, `BeaconUpgraded`, dan `AdminChanged` jika berlaku. Pemantauan tetap diperlukan setelah tinjauan pertama karena jalur eksekusi dapat berubah.
## Kesalahpahaman umum
- **“Proksi tidak menyimpan status yang berarti.”** Dengan `delegatecall`, status aplikasi dan sering kali aset adalah milik proksi meskipun logikanya berasal dari alamat lain.
- **“Implementasi terverifikasi membuat sistem tidak memerlukan kepercayaan.”** Kunci peningkatan, tata kelola, beacon, inisialisasi, dan implementasi masa depan tetap menjadi bagian dari model kepercayaan.
- **“Setiap proksi dapat ditingkatkan.”** Klon dan proksi tetap lainnya dapat mendelegasikan secara permanen; kemampuan peningkatan bergantung pada desain spesifik dan kode otorisasi.
## Topik terkait
- [Risiko penyimpanan Delegatecall](/id/crypto/delegatecall-storage-risk/)
- [Tabrakan penyimpanan proksi](/id/crypto/proxy-storage-collision/)
- [Pemantauan peningkatan proksi](/id/crypto/proxy-upgrade-monitoring/)
- [Kontrak pintar](/id/crypto/smart-contract/)
- [Kontrak yang dapat ditingkatkan](/id/crypto/upgradeable-contract/)
## Sumber
- [Pengantar kontrak pintar](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html) - Solidity Documentation (diakses: 2026-08-21)
- [ERC-1967: slot penyimpanan proksi](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (diakses: 2026-08-21)
- [ERC-1822: standar proksi universal yang dapat ditingkatkan (UUPS)](https://eips.ethereum.org/EIPS/eip-1822) - Ethereum Improvement Proposals (diakses: 2026-08-21)
- [Proksi](https://docs.openzeppelin.com/contracts/5.x/api/proxy) - OpenZeppelin Documentation (diakses: 2026-08-21)
Source: https://wiki.fcontext.com/id/crypto/proxy-contract/index.mdx