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

Audit kontrak pintar ialah semakan bebas terhadap kod dan seni bina dalam skop yang ditetapkan. Tujuannya adalah untuk mengenal pasti kerentanan, ralat pelaksanaan dan ketidakpadanan antara tingkah laku yang dimaksudkan dengan tingkah laku sebenar.

Audit boleh mengurangkan ketidakpastian, tetapi tidak menjadikan kontrak bebas risiko. Panduan keselamatan rasmi Ethereum menerangkan audit sebagai semakan tambahan, bukan penyelesaian mutlak yang menemui setiap bug.

Artikel ini hanya untuk tujuan pendidikan. Audit tidak menjamin keselamatan, pemulihan dana atau pulangan.

Skop didahulukan

Laporan yang berguna mengenal pasti dengan tepat perkara yang disemak:

• repositori dan hash commit;
• fail dan kontrak;
• versi compiler dan tetapan binaan;
• kebergantungan;
• seni bina dan peranan berkeistimewaan;
• cabang atau keluaran;
• pengecualian, batasan dan andaian;
• tarikh semakan.

Ini penting kerana audit yang sah mungkin meliputi versi lama, pelaksanaan yang berbeza atau hanya satu bahagian daripada sistem yang lebih besar.

Perkara yang lazim diperiksa oleh juruaudit

1. Tingkah laku yang dimaksudkan dan invarian

Juruaudit membandingkan kod dengan spesifikasinya:

• siapa yang boleh memanggil setiap fungsi;
• cara jumlah dan yuran dikira;
• bila perubahan status berlaku;
• sifat yang mesti sentiasa kekal benar;
• cara kes pinggir dan kegagalan dikendalikan.

Jika spesifikasi meninggalkan keperluan penting, kod yang betul secara teknikal masih boleh melaksanakan reka bentuk yang tidak selamat atau tidak dikehendaki.

2. Kawalan akses

Penyemak memeriksa pemilik, pentadbir, operator dan peranan berkeistimewaan lain, termasuk kuasa untuk:

• memberikan atau membatalkan kebenaran;
• menjeda sistem;
• mengubah yuran dan had;
• mencetak token;
• mengeluarkan aset;
• menaik taraf pelaksanaan.

Mereka juga mempertimbangkan sama ada satu kunci boleh membuat perubahan kritikal dan sama ada kawalan seperti multisig atau timelock menjadi sebahagian daripada reka bentuk.

3. Panggilan luaran dan reentrancy

Kontrak boleh menyerahkan kawalan kepada kontrak lain semasa pelaksanaan. Ini boleh membolehkan reentrancy, apabila kontrak luaran memanggil kembali sebelum perubahan keadaan asal selesai. Panduan rasmi Solidity mengesyorkan susunan pemeriksaan, kesan keadaan dan interaksi luaran dengan teliti apabila sesuai.

4. Pengiraan dan unit

Juruaudit mencari:

• pembundaran dan kehilangan ketepatan;
• perpuluhan token yang tidak sepadan;
• urutan operasi yang salah;
• nilai sempadan;
• pembahagian dengan sifar;
• unsafe unchecked arithmetic;
• percanggahan antara unit dalaman dan unit yang dipaparkan.

5. Penafian perkhidmatan dan gas

Gelung tanpa had, array yang terus berkembang, panggilan luaran yang gagal atau operasi mahal boleh menjadikan sesuatu fungsi tidak praktikal untuk dilaksanakan. Penyemak menguji sama ada reka bentuk kekal boleh digunakan apabila data bertambah dan apabila menerima input luar biasa.

6. Proksi dan naik taraf

Bagi sistem yang boleh dinaik taraf, semakan hendaklah merangkumi:

• kontrak proksi dan pelaksanaan;
• hak pihak peningkat taraf atau pentadbir;
• pengasalan;
• keserasian susun atur storan;
• laluan peningkatan tanpa kebenaran;
• kesan perubahan logik selepas audit.

Proksi boleh mengekalkan alamat yang sama bagi pengguna sambil menyerahkan operasi kepada logik baharu. Oleh itu, dakwaan bahawa ‘kontrak tidak boleh berubah’ mesti diperiksa terhadap seni bina sebenar.

7. Integrasi

Kontrak mungkin bergantung pada token, oracle harga, jambatan, DEX, tandatangan atau kontrak lain. Juruaudit meneliti andaian tentang kebergantungan tersebut, data lapuk, tingkah laku token yang luar biasa dan mod kegagalan luaran.

8. Peristiwa dan pemantauan

Penyemak boleh memeriksa sama ada peristiwa mendedahkan tindakan penting secara tepat, seperti perubahan peranan, peningkatan, jeda dan pemindahan. Peristiwa membantu pemantauan, tetapi tidak menggantikan pemeriksaan keadaan.

Kaedah yang digunakan dalam audit

Semakan lazimnya menggabungkan:

• analisis kod dan seni bina secara manual;
• pengujian unit dan integrasi;
• analisis statik dan dinamik;
• fuzzing dengan input yang dijana;
• pengujian berasaskan sifat;
• pemeriksaan bagi kelas kelemahan yang diketahui;
• semakan binaan dan pelaksanaan;
• kadangkala pengesahan formal bagi sifat terpilih.

Tiada satu kaedah yang merangkumi segala-galanya. Pengesahan formal boleh membuktikan bahawa kod memenuhi spesifikasi formal; ia tidak dapat membuktikan sifat yang gagal dinyatakan dalam spesifikasi.

Cara pengguna harus membaca audit

1. Padankan versi yang disemak

Cari hash commit dan tentukan:

• sama ada pelaksanaan semasa dibina daripada kod tersebut;
• sama ada peningkatan berlaku selepas tarikh laporan;
• sama ada rantaian dan alamat yang digunakan sepadan;
• sama ada kebergantungan kritikal termasuk dalam skop.

Jika perkara ini tidak dapat dipastikan, laporan tersebut hanya memberikan bukti terhad tentang pelaksanaan aktif.

2. Baca penemuan, bukan ringkasan sahaja

Bagi setiap penemuan, semak:

• tahap keterukan dan senario;
• kod yang terjejas;
• cadangan;
• respons pembangun;
• status semasa;
• sama ada juruaudit menguji semula pembetulan.

Tetap atau Diselesaikan is meaningful only when tied to a specific corrected version.

3. Baca batasan

Laporan mungkin tidak merangkumi:

• sistem bahagian hadapan dan bahagian belakang;
• pengurusan kunci;
• reka bentuk ekonomi;
• kontrak pihak ketiga;
• infrastruktur pelaksanaan;
• konfigurasi produksi;
• isu undang-undang dan operasi.

Pengguna berinteraksi dengan keseluruhan sistem, bukan hanya fail Solidity-nya.

4. Semak risiko pentadbiran

Tanya:

• siapa yang mengawal peningkatan;
• sama ada operasi boleh dijeda;
• sama ada yuran atau alamat terpaut boleh berubah;
• sama ada timelock wujud;
• sama ada multisig digunakan;
• cara pengguna dimaklumkan tentang perubahan.

Ini ialah persoalan tadbir urus dan kepercayaan walaupun tiada kelemahan ditemukan dalam kod.

5. Periksa keselamatan selepas audit

Langkah berterusan yang berguna merangkumi:

• menguji setiap keluaran;
• menyemak peningkatan penting;
• program ganjaran pepijat;
• memantau peranan dan pelaksanaan;
• prosedur tindak balas insiden;
• mengehadkan jumlah aset yang terdedah.

Apa yang tidak dijamin oleh audit

Audit tidak menjamin:

• ketiadaan semua pepijat;
• keselamatan kod yang diubah selepas semakan;
• keselamatan laman web, dompet, DNS atau pelayan;
• keselamatan kunci berkeistimewaan;
• ketepatan token luaran, oracle dan jambatan;
• ketahanan terhadap setiap serangan ekonomi;
• integriti pasukan;
• pematuhan undang-undang;
• kecairan token;
• pemulangan dana;
• pulangan tetap atau apa-apa pulangan lain.

Soalan yang harus ditanya oleh 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.

Senarai semak laporan

• Laporan tersedia daripada juruaudit.
• Repositori dan hash commit dinyatakan.
• Kontrak dan kebergantungan kritikal termasuk dalam skop.
• Versi yang disemak sepadan dengan pelaksanaan aktif.
• Proksi, pelaksanaan dan pentadbir termasuk dalam liputan.
• Proses menentukan status dan menguji semula didokumenkan.
• Andaian dan pengecualian telah dibaca.
• Risiko di luar kod dinilai secara berasingan.

Sumber dan Bacaan Lanjut

1. Ethereum.org — Keselamatan Kontrak Pintar
2. Ethereum.org — Pengujian Kontrak Pintar
3. Ethereum.org — Pengesahan Formal Kontrak Pintar
4. Solidity Documentation — Pertimbangan Keselamatan
5. OpenZeppelin Docs — Corak Peningkatan Proksi