Lompat ke konten
Financial Context Wiki

Cara memantau peningkatan kontrak proksi

Pantau perubahan implementasi, beacon, dan kendali pada proksi yang dapat ditingkatkan, lalu verifikasi kode, kompatibilitas penyimpanan, inisialisasi, izin, dan perilaku penting setelah eksekusi.

Diperbarui

Hanya untuk tujuan edukasi; bukan nasihat investasi. Investasi dapat menyebabkan kerugian.

Jawaban langsung

Pantau jalur kendali sistem yang dapat ditingkatkan, bukan hanya alamat proksinya. Peringatan harus mengidentifikasi siapa yang dapat mengesahkan dan mengeksekusi peningkatan, setiap penundaan wajib, implementasi lama dan baru, serta calldata inisialisasi. Setelah eksekusi, baca konfigurasi on-chain secara independen dan uji perilaku penting.

Alamat proksi dan saldonya dapat tetap sama ketika kode yang didelegasikan mengubah izin, biaya, akuntansi, perilaku jeda, atau logika penarikan. Audit sebelumnya tidak otomatis mencakup implementasi baru atau inisialisasinya.

Cara kerja

Pertama, identifikasi pola proksi. ERC-1967 menetapkan slot penyimpanan terpisah untuk eip1967.proxy.implementation, eip1967.proxy.beacon, dan eip1967.proxy.admin yang bersifat opsional. Perubahan implementasi langsung seharusnya memancarkan Upgraded; perubahan alamat beacon memancarkan BeaconUpgraded; dan perubahan slot administrator memancarkan AdminChanged. Untuk proksi beacon, panggil juga implementation() pada beacon karena beacon dapat mengganti implementasinya sementara slot beacon pada proksi tetap sama.

Jangan menyimpulkan seluruh model kewenangan dari slot administrator. Proksi Transparent dapat dikendalikan melalui ProxyAdmin, sedangkan otorisasi peningkatan UUPS diterapkan di kontrak logika saat ini melalui _authorizeUpgrade. Telusuri pemilik, peran, ambang multisig, timelock, kontrak tata kelola, jalur darurat, dan kewenangan untuk mengubah kendali tersebut.

Gunakan langganan peristiwa sekaligus pembacaan status berkala. ERC-1967 merekomendasikan peristiwa tersebut, tetapi tidak mewajibkan setiap implementasi memancarkannya. Catat chain, blok, transaksi, proksi, implementasi atau beacon, hash kode runtime, pelaksana, dan status kendali terkait dari endpoint RPC independen. Beri peringatan untuk operasi yang dijadwalkan, dibatalkan, dan dieksekusi, lalu tunggu kebijakan konfirmasi atau finalitas yang dipilih untuk chain sebelum menganggap status telah tetap.

Contoh

Sebuah proksi pinjaman dikendalikan oleh multisig 3 dari 5 melalui timelock 24 jam. Ketika peningkatan dijadwalkan, sistem pemantauan mencatat pengenal proposal, target, calldata, waktu eksekusi paling awal, implementasi saat ini, implementasi yang diusulkan, dan status verifikasi kode sumber. Peninjau membandingkan kode dan tata letak penyimpanan, memeriksa panggilan inisialisasi, serta menilai perubahan pada peran, panggilan eksternal, biaya, aturan jeda, dan jalur penarikan.

Setelah eksekusi, sistem membaca kembali slot ERC-1967 yang relevan, memverifikasi kode runtime yang diterapkan, dan memeriksa pascakondisi yang diharapkan seperti versi implementasi, administrator atau pemegang peran, status jeda, akuntansi aset, dan pratinjau penarikan hanya-baca. Peringatan lain dipicu jika alamat atau hash kode yang teramati berbeda dari proposal yang ditinjau, atau jika polling berkala menemukan perubahan yang tidak dilaporkan peristiwa.

Risiko

  • Risiko kendali: Multisig nominal dapat dilewati oleh pemilik lain, peran, modul, kontrak tata kelola, kunci darurat, atau timelock yang dapat diubah. Telusuri setiap jalur hingga penanda tangan akhir dan penundaannya.
  • Risiko kode dan penyimpanan: Kode yang belum diverifikasi, tata letak penyimpanan yang tidak kompatibel, inisialisasi yang tidak aman, atau dependensi yang berubah dapat merusak status atau memberikan kewenangan yang tidak dimaksudkan. Validasi artefak persis yang diterapkan, bukan sekadar branch repositori atau nama audit.
  • Risiko pemantauan: Satu RPC, pengindeks yang hanya melihat peristiwa, front-end, atau penjelajah blok dapat terlambat atau keliru. Cocokkan peristiwa dengan penyimpanan, bytecode, tanda terima transaksi, dan status protokol di sumber independen.
  • Risiko respons: Peringatan tanpa penanggung jawab dan prosedur teruji dapat datang terlambat. Tentukan siapa yang meninjau, menjeda integrasi, berkomunikasi, atau keluar selama penundaan, sambil menyadari risiko tambahan dari persetujuan terburu-buru dan tautan pemulihan tidak resmi.

Prosedur minimum:

  1. Inventarisasi setiap proksi, beacon, implementasi, administrator, peran, dan titik masuk peningkatan pada setiap chain.
  2. Simpan baseline yang diketahui baik untuk slot, hash kode, status kendali, dan hasil penting hanya-baca.
  3. Beri peringatan sebelum eksekusi jika penjadwalan tata kelola atau timelock memungkinkannya, lalu beri peringatan lagi saat eksekusi atau pembatalan.
  4. Bandingkan target, calldata, implementasi, bytecode, tata letak penyimpanan, dan status pascapeningkatan yang dieksekusi dengan proposal yang ditinjau.
  5. Eskalasikan perubahan tak terduga, kegagalan pascakondisi, verifikasi sumber yang tidak ada, atau penundaan yang dipersingkat atau dilewati; jangan mengandalkan alamat proksi yang tidak berubah sebagai bukti keamanan.

Kesalahpahaman umum

  • Mitos 1: “Memantau Upgraded sudah cukup.” Perubahan implementasi beacon dan proksi nonstandar mungkin memerlukan pemantauan kontrak lain atau polling status; cocokkan peristiwa dengan pembacaan langsung.
  • Mitos 2: “Slot administrator menunjukkan siapa yang mengendalikan setiap peningkatan.” Slot tersebut opsional, sedangkan desain Transparent, UUPS, beacon, tata kelola, dan khusus menempatkan kewenangan di kontrak dan fungsi berbeda.
  • Mitos 3: “Kode sumber terverifikasi atau audit terdahulu membuktikan peningkatan aman.” Verifikasi bytecode yang diterapkan, asumsi compiler dan constructor, kompatibilitas penyimpanan, inisialisasi, konfigurasi, serta perilaku untuk rilis yang tepat.

Topik terkait

Sumber

Navigasi

Cari di wiki...