Lompat ke konten utama

Panduan keamanan kontrak pintar

Solidity
kontrak pintar
keamanan
Menengah
Trailofbits
6 September 2020
4 menit baca

Ikuti rekomendasi tingkat tinggi ini untuk membangun kontrak pintar yang lebih aman.

Panduan desain

Desain kontrak harus didiskusikan sebelumnya, sebelum menulis baris kode apa pun.

Dokumentasi dan spesifikasi

Dokumentasi dapat ditulis pada tingkat yang berbeda, dan harus diperbarui saat mengimplementasikan kontrak:

  • Deskripsi sistem dalam bahasa Inggris yang sederhana, menjelaskan apa yang dilakukan kontrak dan asumsi apa pun pada basis kode.
  • Skema dan diagram arsitektur, termasuk interaksi kontrak dan mesin status dari sistem. Slither printers (opens in a new tab) dapat membantu menghasilkan skema ini.
  • Dokumentasi kode yang menyeluruh, format Natspec (opens in a new tab) dapat digunakan untuk Solidity.

Komputasi onchain vs offchain

  • Simpan sebanyak mungkin kode secara offchain. Jaga agar lapisan onchain tetap kecil. Pra-proses data dengan kode offchain sedemikian rupa sehingga verifikasi onchain menjadi sederhana. Apakah Anda memerlukan daftar yang diurutkan? Urutkan daftar secara offchain, lalu periksa urutannya secara onchain.

Kemampuan peningkatan

Kami membahas berbagai solusi kemampuan peningkatan di postingan blog kami (opens in a new tab). Buatlah pilihan yang disengaja untuk mendukung kemampuan peningkatan atau tidak sebelum menulis kode apa pun. Keputusan ini akan memengaruhi cara Anda menyusun kode Anda. Secara umum, kami merekomendasikan:

  • Lebih mengutamakan migrasi kontrak (opens in a new tab) daripada kemampuan peningkatan. Sistem migrasi memiliki banyak keuntungan yang sama dengan sistem yang dapat ditingkatkan, tanpa kekurangannya.
  • Menggunakan pola pemisahan data daripada pola delegatecallproxy. Jika proyek Anda memiliki pemisahan abstraksi yang jelas, kemampuan peningkatan menggunakan pemisahan data hanya akan memerlukan sedikit penyesuaian. Delegatecallproxy membutuhkan keahlian EVM dan sangat rentan terhadap kesalahan.
  • Dokumentasikan prosedur migrasi/peningkatan sebelum penerapan. Jika Anda harus bereaksi di bawah tekanan tanpa panduan apa pun, Anda akan membuat kesalahan. Tulis prosedur yang harus diikuti sebelumnya. Ini harus mencakup:
    • Panggilan yang memulai kontrak baru
    • Di mana kunci disimpan dan bagaimana cara mengaksesnya
    • Bagaimana cara memeriksa penerapan! Kembangkan dan uji skrip pasca-penerapan.

Panduan implementasi

Berusahalah untuk kesederhanaan. Selalu gunakan solusi paling sederhana yang sesuai dengan tujuan Anda. Setiap anggota tim Anda harus dapat memahami solusi Anda.

Komposisi fungsi

Arsitektur basis kode Anda harus membuat kode Anda mudah ditinjau. Hindari pilihan arsitektur yang mengurangi kemampuan untuk menalar kebenarannya.

  • Pisahkan logika sistem Anda, baik melalui beberapa kontrak atau dengan mengelompokkan fungsi-fungsi serupa bersama-sama (misalnya, autentikasi, aritmatika, ...).
  • Tulis fungsi-fungsi kecil, dengan tujuan yang jelas. Ini akan memfasilitasi peninjauan yang lebih mudah dan memungkinkan pengujian komponen individu.

Pewarisan

  • Jaga agar pewarisan tetap dapat dikelola. Pewarisan harus digunakan untuk membagi logika, namun, proyek Anda harus bertujuan untuk meminimalkan kedalaman dan lebar pohon pewarisan.
  • Gunakan inheritance printer (opens in a new tab) dari Slither untuk memeriksa hierarki kontrak. Inheritance printer akan membantu Anda meninjau ukuran hierarki.

Event

  • Catat semua operasi penting. Event akan membantu men-debug kontrak selama pengembangan, dan memantaunya setelah penerapan.

Hindari jebakan yang diketahui

Dependensi

  • Gunakan pustaka yang telah diuji dengan baik. Mengimpor kode dari pustaka yang telah diuji dengan baik akan mengurangi kemungkinan Anda menulis kode yang penuh bug. Jika Anda ingin menulis kontrak ERC20, gunakan OpenZeppelin (opens in a new tab).
  • Gunakan manajer dependensi; hindari menyalin-tempel kode. Jika Anda mengandalkan sumber eksternal, maka Anda harus menjaganya agar tetap mutakhir dengan sumber aslinya.

Pengujian dan verifikasi

  • Tulis pengujian unit yang menyeluruh. Rangkaian pengujian yang ekstensif sangat penting untuk membangun perangkat lunak berkualitas tinggi.
  • Tulis pemeriksaan dan properti kustom Slither (opens in a new tab), Echidna (opens in a new tab), dan Manticore (opens in a new tab). Alat otomatis akan membantu memastikan kontrak Anda aman. Tinjau sisa panduan ini untuk mempelajari cara menulis pemeriksaan dan properti yang efisien.
  • Gunakan crytic.io (opens in a new tab). Crytic terintegrasi dengan GitHub, menyediakan akses ke detektor Slither pribadi, dan menjalankan pemeriksaan properti kustom dari Echidna.

Solidity

  • Lebih mengutamakan Solidity 0.5 daripada 0.4 dan 0.6. Menurut pendapat kami, Solidity 0.5 lebih aman dan memiliki praktik bawaan yang lebih baik daripada 0.4. Solidity 0.6 telah terbukti terlalu tidak stabil untuk produksi dan membutuhkan waktu untuk matang.
  • Gunakan rilis stabil untuk mengkompilasi; gunakan rilis terbaru untuk memeriksa peringatan. Periksa apakah kode Anda tidak memiliki masalah yang dilaporkan dengan versi kompiler terbaru. Namun, Solidity memiliki siklus rilis yang cepat dan memiliki riwayat bug kompiler, jadi kami tidak merekomendasikan versi terbaru untuk penerapan (lihat rekomendasi versi solc (opens in a new tab) dari Slither).
  • Jangan gunakan inline assembly. Assembly membutuhkan keahlian EVM. Jangan menulis kode EVM jika Anda belum menguasai yellow paper.

Panduan penerapan

Setelah kontrak dikembangkan dan diterapkan:

  • Pantau kontrak Anda. Perhatikan log, dan bersiaplah untuk bereaksi jika terjadi kompromi pada kontrak atau dompet.
  • Tambahkan info kontak Anda ke blockchain-security-contacts (opens in a new tab). Daftar ini membantu pihak ketiga menghubungi Anda jika celah keamanan ditemukan.
  • Amankan dompet pengguna yang memiliki hak istimewa. Ikuti praktik terbaik (opens in a new tab) kami jika Anda menyimpan kunci di dompet perangkat keras.
  • Miliki rencana respons terhadap insiden. Pertimbangkan bahwa kontrak pintar Anda dapat disusupi. Bahkan jika kontrak Anda bebas dari bug, penyerang mungkin mengambil kendali atas kunci pemilik kontrak.

Pembaruan terakhir halaman: 30 September 2025

mdqstm (opens in a new tab)
wackeroww (opens in a new tab)
pettinaripp (opens in a new tab)
+4

Apakah tutorial ini membantu?