Panduan keamanan kontrak pintar

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

Panduan desain

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

Dokumentasi dan spesifikasi

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

• Deskripsi sistem dalam bahasa yang sederhana, menjelaskan apa yang dilakukan kontrak dan asumsi apa pun pada basis kode.
• Skema dan diagram arsitektur, termasuk interaksi kontrak dan mesin state dari sistem. Printer Slither (terbuka di tab baru) dapat membantu menghasilkan skema ini.
• Dokumentasi kode yang menyeluruh, format NatSpec (terbuka di tab baru) dapat digunakan untuk Solidity.

Komputasi onchain vs offchain

• Simpan kode sebanyak mungkin 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 tersebut secara offchain, lalu periksa urutannya secara onchain.

Kemampuan peningkatan

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

• Lebih mengutamakan migrasi kontrak (terbuka di tab baru) 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. Pola delegatecallproxy membutuhkan keahlian EVM dan sangat rentan terhadap kesalahan.
• Dokumentasikan prosedur migrasi/peningkatan sebelum penyebaran. 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 menginisiasi kontrak baru
  • Di mana kunci disimpan dan bagaimana cara mengaksesnya
  • Bagaimana cara memeriksa penyebaran! Kembangkan dan uji skrip pasca-penyebaran.

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 printer pewarisan (terbuka di tab baru) Slither untuk memeriksa hierarki kontrak. Printer pewarisan akan membantu Anda meninjau ukuran hierarki.

Peristiwa

• Catat log semua operasi penting. Peristiwa akan membantu men-debug kontrak selama pengembangan, dan memantaunya setelah penyebaran.

Hindari jebakan yang diketahui

• Waspadai masalah keamanan yang paling umum. Ada banyak sumber daya online untuk mempelajari masalah umum, seperti Ethernaut CTF (terbuka di tab baru), Capture the Ether (terbuka di tab baru), atau Not so smart contracts (terbuka di tab baru).
• Waspadai bagian peringatan dalam dokumentasi Solidity (terbuka di tab baru). Bagian peringatan akan memberi tahu Anda tentang perilaku bahasa yang tidak jelas.

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 ERC-20, gunakan OpenZeppelin (terbuka di tab baru).
• Gunakan manajer dependensi; hindari menyalin-tempel kode. Jika Anda mengandalkan sumber eksternal, maka Anda harus terus memperbaruinya 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 (terbuka di tab baru), Echidna (terbuka di tab baru), dan Manticore (terbuka di tab baru). Alat otomatis akan membantu memastikan kontrak Anda aman. Tinjau sisa panduan ini untuk mempelajari cara menulis pemeriksaan dan properti yang efisien.
• Gunakan crytic.io (terbuka di tab baru). Crytic terintegrasi dengan GitHub, menyediakan akses ke detektor Slither privat, 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 mengompilasi; 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 penyebaran (lihat rekomendasi versi solc (terbuka di tab baru) Slither).
• Jangan gunakan assembly sebaris (inline assembly). Assembly membutuhkan keahlian EVM. Jangan menulis kode EVM jika Anda belum menguasai kertas kuning.

Panduan penyebaran

Setelah kontrak dikembangkan dan disebarkan:

• Pantau kontrak Anda. Perhatikan log, dan bersiaplah untuk bereaksi jika terjadi kompromi pada kontrak atau dompet.
• Tambahkan info kontak Anda ke blockchain-security-contacts (terbuka di tab baru). Daftar ini membantu pihak ketiga menghubungi Anda jika ditemukan celah keamanan.
• Amankan dompet pengguna yang memiliki hak istimewa. Ikuti praktik terbaik (terbuka di tab baru) 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 alih kunci pemilik kontrak.