Smart Contract Audits: What Auditors Check—and What an Audit Does Not Guarantee

Audit smart contract adalah peninjauan independen terhadap kode dan arsitektur dalam ruang lingkup yang ditentukan. Tujuannya adalah mengidentifikasi kerentanan, kesalahan implementasi, serta perbedaan antara perilaku yang diharapkan dan perilaku sebenarnya.

Audit dapat mengurangi ketidakpastian, tetapi tidak membuat kontrak bebas risiko. Panduan keamanan resmi Ethereum menjelaskan audit sebagai pemeriksaan tambahan, bukan solusi sempurna yang menemukan setiap bug.

Artikel ini hanya untuk tujuan edukasi. Audit tidak menjamin keamanan, pemulihan dana, atau hasil.

Cakupan harus diperiksa terlebih dahulu

Laporan yang berguna menyebutkan dengan tepat apa yang diperiksa:

repositori dan hash commit;
file dan kontrak;
versi compiler dan pengaturan build;
dependensi;
arsitektur dan peran istimewa;
branch atau rilis;
pengecualian, batasan, dan asumsi;
tanggal peninjauan.

Hal ini penting karena audit yang sah mungkin mencakup versi lama, penerapan berbeda, atau hanya satu bagian dari sistem yang lebih besar.

Hal yang umumnya diperiksa auditor

1. Perilaku yang diharapkan dan invarian

Auditor membandingkan kode dengan spesifikasinya:

siapa yang dapat memanggil setiap fungsi;
cara jumlah dan biaya dihitung;
kapan perubahan status terjadi;
properti mana yang harus selalu tetap benar;
cara kasus batas dan kegagalan ditangani.

Jika spesifikasi mengabaikan persyaratan penting, kode yang secara teknis benar tetap dapat menerapkan rancangan yang tidak aman atau tidak diinginkan.

2. Kontrol akses

Peninjau memeriksa peran pemilik, administrator, operator, dan peran istimewa lainnya, termasuk kewenangan untuk:

memberikan atau mencabut izin;
menjeda sistem;
mengubah biaya dan batas;
mencetak token;
menarik aset;
meningkatkan implementasi.

Peninjau juga mempertimbangkan apakah satu kunci dapat membuat perubahan kritis dan apakah kontrol seperti multisig atau timelock merupakan bagian dari rancangan.

3. Panggilan eksternal dan reentrancy

Sebuah kontrak dapat menyerahkan kendali kepada kontrak lain selama eksekusi. Hal ini dapat memungkinkan reentrancy, yaitu ketika kontrak eksternal melakukan panggilan balik sebelum perubahan status awal selesai. Panduan resmi Solidity menyarankan agar pemeriksaan, perubahan status, dan interaksi eksternal diurutkan dengan cermat jika diperlukan.

4. Perhitungan dan satuan

Auditor mencari:

pembulatan dan hilangnya presisi;
ketidaksesuaian desimal token;
urutan operasi yang salah;
nilai batas;
pembagian dengan nol;
unsafe unchecked arithmetic;
perbedaan antara unit internal dan unit yang ditampilkan.

5. Penolakan layanan dan gas

Loop tanpa batas, array yang terus bertambah, panggilan eksternal yang gagal, atau operasi mahal dapat membuat suatu fungsi tidak praktis untuk dijalankan. Peninjau menguji apakah rancangan tetap dapat digunakan ketika data bertambah dan saat menerima input yang tidak biasa.

6. Proxy dan pembaruan

Untuk sistem yang dapat ditingkatkan, peninjauan harus mencakup:

kontrak proxy dan implementasi;
hak upgrader atau administrator;
inisialisasi;
kompatibilitas tata letak penyimpanan;
jalur peningkatan tanpa izin;
dampak perubahan logika setelah audit.

Proxy dapat mempertahankan alamat yang sama bagi pengguna sambil meneruskan operasi ke logika baru. Karena itu, pernyataan bahwa “kontrak tidak dapat berubah” harus diperiksa berdasarkan arsitektur yang sebenarnya.

7. Integrasi

Kontrak dapat bergantung pada token, oracle harga, bridge, DEX, tanda tangan, atau kontrak lain. Auditor memeriksa asumsi mengenai ketergantungan tersebut, data kedaluwarsa, perilaku token yang tidak biasa, dan kemungkinan kegagalan eksternal.

8. Peristiwa dan pemantauan

Peninjau dapat memeriksa apakah event secara akurat menampilkan tindakan penting seperti perubahan peran, peningkatan, jeda, dan transfer. Event membantu pemantauan, tetapi tidak menggantikan pemeriksaan status.

Metode yang digunakan dalam audit

Suatu peninjauan biasanya menggabungkan:

analisis kode dan arsitektur secara manual;
pengujian unit dan integrasi;
analisis statis dan dinamis;
fuzzing dengan input yang dihasilkan;
pengujian berbasis properti;
pemeriksaan kelas kerentanan yang telah diketahui;
peninjauan build dan penerapan;
terkadang verifikasi formal atas properti tertentu.

Tidak ada satu metode yang mencakup semuanya. Verifikasi formal dapat membuktikan bahwa kode memenuhi spesifikasi formal; metode tersebut tidak dapat membuktikan sifat yang tidak dinyatakan dalam spesifikasi.

Cara pengguna membaca audit

1. Cocokkan dengan versi yang diaudit

Temukan hash commit dan tentukan:

apakah implementasi saat ini dibuat dari kode tersebut;
apakah peningkatan terjadi setelah tanggal laporan;
apakah chain dan alamat yang diterapkan sesuai;
apakah dependensi kritis termasuk dalam cakupan.

Jika hal ini tidak dapat dipastikan, laporan tersebut hanya memberikan bukti terbatas tentang penerapan aktif.

2. Baca temuannya, bukan hanya ringkasannya

Untuk setiap temuan, tinjau:

tingkat keparahan dan skenario;
kode yang terdampak;
rekomendasi;
respons pengembang;
status saat ini;
apakah auditor menguji ulang perbaikan.

Diperbaiki atau Selesai is meaningful only when tied to a specific corrected version.

3. Baca batasannya

Laporan mungkin tidak mencakup:

sistem frontend dan backend;
pengelolaan kunci;
rancangan ekonomi;
kontrak pihak ketiga;
infrastruktur penerapan;
konfigurasi produksi;
masalah hukum dan operasional.

Pengguna berinteraksi dengan seluruh sistem, bukan hanya file Solidity-nya.

4. Tinjau risiko administratif

Tanyakan:

siapa yang mengendalikan peningkatan;
apakah operasi dapat dijeda;
apakah biaya atau alamat tertaut dapat berubah;
apakah timelock tersedia;
apakah multisig digunakan;
cara pengguna mengetahui perubahan.

Ini tetap merupakan persoalan tata kelola dan kepercayaan meskipun tidak ditemukan kerentanan pada kode.

5. Periksa keamanan setelah audit

Langkah berkelanjutan yang berguna meliputi:

menguji setiap rilis;
meninjau peningkatan yang signifikan;
program bug bounty;
pemantauan peran dan implementasi;
prosedur respons insiden;
membatasi jumlah aset yang terekspos.

Apa yang tidak dijamin oleh audit

Audit tidak menjamin:

ketiadaan semua bug;
keamanan kode yang diubah setelah peninjauan;
keamanan situs web, dompet, DNS, atau server;
keamanan kunci istimewa;
keakuratan token eksternal, oracle, dan bridge;
ketahanan terhadap setiap serangan ekonomi;
integritas tim;
kepatuhan hukum;
likuiditas token;
pengembalian dana;
hasil tetap atau hasil lainnya.

Pertanyaan yang perlu diajukan pengguna yang berhati-hati

Is an auditor’s logo enough?
No. Find the report from the auditor’s own source and check its scope, commit, date, and findings.

If every finding was fixed, is the contract safe?
It means the listed findings were addressed in a stated version. Unknown issues and out-of-scope risks remain.

Are several audits automatically better?
The count alone says little. Coverage, quality, independence, recency, and version matching matter more.

Does an audit still apply after a proxy upgrade?
Only if the new implementation and configuration are covered by the reviewed version.

Daftar periksa laporan

Laporan tersedia dari auditor.
Repositori dan hash commit dicantumkan.
Kontrak dan ketergantungan penting termasuk dalam ruang lingkup.
Versi yang ditinjau sesuai dengan penerapan aktif.
Proxy, implementasi, dan administrator tercakup.
Cara menemukan status dan melakukan pengujian ulang telah didokumentasikan.
Asumsi dan pengecualian telah dibaca.
Risiko di luar kode telah dinilai secara terpisah.

Sumber dan Bacaan Lebih Lanjut

Ethereum.org — Keamanan Smart Contract
Ethereum.org — Pengujian Smart Contract
Ethereum.org — Verifikasi Formal Smart Contract
Solidity Documentation — Pertimbangan Keamanan
OpenZeppelin Docs — Pola Peningkatan Proxy