Kontrak pintar sebagai ancaman keamanan untuk memblokir startup

Menurut situs web resmi , kontrak pintar Ethereum dijalankan "persis seperti yang diprogram, tanpa kemungkinan downtime, sensor, penipuan, atau campur tangan pihak ketiga". Hari ini saya akan mencoba mencari tahu apakah semuanya benar-benar cerah, setelah memeriksa beberapa masalah yang dihadapi pengguna kontrak pintar dalam praktik.

Di akhir artikel, saya meringkas pikiran saya dengan panduan singkat untuk menulis kontrak pintar yang aman.

Komentar

1. Artikel ini hanya akan fokus pada kontrak pintar Ethereum. Komunitas telah secara diam-diam mengidentifikasi kontrak pintar dengan kontrak pintar Ethereum. Sementara itu, yang pertama lebih merupakan konsep, dan yang kedua adalah implementasi, dan pertanyaan tentang bagaimana implementasi ini memenuhi konsep dapat didiskusikan (serta pada prinsipnya konsep kontrak yang cerdas dan implementasi lainnya yang mungkin). Topik ini kompleks, diremehkan dan menarik, tetapi ini bukan topik artikel ini, jadi saya akan merujuk mereka yang tertarik pada karya - karya Nick Szabo . Dengan demikian, di mana-mana lebih jauh, di mana saya mengatakan "kontrak pintar", saya sebenarnya berarti "kontrak pintar Ethereum".
2. Artikel ini hanya akan fokus pada bahasa kontrak pintar Solidity sebagai yang paling populer dan untuk pengguna Ethereum pada kenyataannya satu-satunya saat ini.

Masalah Keamanan Kontrak Pintar

Ini akan menjadi masalah yang dihadapi pengembang kontrak pintar pada akhirnya, dan bukan tentang keamanan platform itu sendiri (meskipun sedikit tentang itu). Kami membagi masalah ini secara konvensional ke dalam tipe berikut:

1. masalah dalam kode kontrak pintar;
2. masalah dalam proses pengembangan;
3. masalah dalam bahasa;
4. masalah dalam konsep.

1. Masalah dalam kode kontrak pintar

Dengan masalah dalam kode kontrak pintar di sini, maksud saya masalah yang diselesaikan dengan mengedit file .sol. Ini khususnya:

• Konstruk rentan yang dikenal (mis. Re-entrancy ).
  Contoh nyata : re-entrancy, atau, lebih luas lagi, pelanggaran pola Checks-Effects-Interactions - bahkan kerentanan yang diketahui secara luas (dan sebelumnya dieksploitasi ) terus ditemukan dalam kontrak baru.
• Konstruksi rentan penulis (khususnya, kesalahan dalam logika kode).
  Contoh nyata : dompet MultiSig yang sebenarnya bukan MultiSig. Untuk menandatangani transaksi dan mentransfer dana, Anda memerlukan jumlah tanda tangan dari pemilik dompet yang sama dengan yang required . Pada saat yang sama, untuk mengubah yang required (misalnya, satu, untuk lebih lanjut menandatangani transaksi sendiri), hanya tanda tangan dari salah satu pemilik yang cukup:

• Arsitektur yang buruk.
  Contoh kehidupan : upaya untuk menerapkan token, dompet, dan keystore dalam satu kontrak. Kontrak ternyata terlalu rumit, kode sulit untuk dipelihara, diaudit, modifikasi. Akibatnya, keamanan juga menderita.
• Kode berkualitas rendah.
  Contoh kehidupan : kontrak dengan indentasi berbeda, pemutusan saluran dan spasi arbitrer. Kode ini sulit dibaca, yang berarti keamanan menderita lagi. Terlepas dari kenyataan bahwa sudah ada linter untuk Solidity ( Solium , Solhit ).

Masalah dalam kode secara langsung menyebabkan serangan dan kehilangan dana. Berita baiknya adalah bahwa masalah kode dapat diidentifikasi selama proses audit dan diselesaikan. Penting untuk memahami dari mana mereka berasal untuk menghindari mereka di masa depan. Karena itu, kami beralih ke paragraf berikutnya.

2. Masalah dalam proses pengembangan

Masalah dalam kode disebabkan terutama oleh proses pengembangan yang dibangun secara tidak benar. Tampaknya pengembangan perangkat lunak adalah bisnis yang telah lama dipelajari dengan praktik terbaik yang telah ada. Namun demikian, kaum muda di bidang kontrak pintar, uang besar dan hype yang tidak proporsional mengarah pada fakta bahwa orang-orang karena satu dan lain alasan mengabaikan prosedur standar, yang sering mengarah pada masalah serius. Dari yang paling khas, perlu disebutkan:

• TK: Sebagian besar kontrak pintar Ethereum ditulis tanpa tugas teknis. Untuk apa ini bisa mengarah, untuk menjelaskan tidak perlu.
• Waktu: rata-rata, sangat sedikit waktu yang dialokasikan untuk pengembangan, sekitar satu bulan. Contoh ekstrem dari praktik saya: pelanggan meminta pengembang untuk menulis kontrak pintar 3 hari sebelum ICO.
• Tingkat pengembang: banyak orang datang ke lapangan, termasuk tanpa latar belakang pemrograman sama sekali.
• Memahami ekosistem: dan bahkan jika dengan latar belakang, maka seringkali pengembang tidak tenggelam dalam topik dan tidak memahami spesifikasi kontrak pintar.
• Biaya pengembangan: namun, mereka yang menulis kontrak pintar sedikit; bahkan lebih sedikit yang menulisnya dengan baik. Oleh karena itu biaya pembangunan yang terlalu tinggi.

3. Masalah dalam bahasa

Menambahkan tar ke bahasa Solidity itu sendiri. Awalnya, itu dibuat lebih sehingga bisa dengan cepat dikuasai oleh sejumlah besar orang, daripada membuatnya nyaman untuk menulis kontrak pintar yang aman di atasnya. Berikut adalah beberapa fitur yang mengganggu keamanan:

• Pewarisan berganda, using for , call / call delegate call - semua ini memulai kode bukan dari sumber saat ini, yang berarti mengurangi pembacaan dan, sebagai hasilnya, keamanan kode.
• Pola Cek-Efek-Interaksi - jika konstruksi yang melanggar CEI tidak aman, lalu mengapa tidak melarang mereka (dan banyak lainnya) hanya di tingkat bahasa?
• Dengan memanggil kontrak lain, Anda tiba-tiba dapat jatuh ke dalam fungsi mundur dengan konsekuensi yang tidak terduga.

Jelas bahwa proyek Ethereum sedang berkembang, dan tidak mungkin untuk memperhitungkan semuanya terlebih dahulu. Tetapi pada akhirnya, pengembang dipaksa untuk mengingat banyak fitur dan menggunakan kruk untuk membuat kontrak pintar mereka aman.

4. Masalah dalam konsep

Namun, masalah yang paling serius bahkan lebih dalam - bahwa banyak yang tidak mengerti dengan baik mengapa kontrak yang cerdas diperlukan, apa yang mereka bisa, apa yang tidak bisa mereka lakukan dan bagaimana mereka bekerja. Dalam kasus terburuk, ini mengarah pada fakta bahwa kontrak pintar:

1. Tidak pintar:

   
   
   • Ditulis dengan buruk - melakukan apa yang tertulis, tetapi tidak apa yang dimaksudkan.
   • Ini sangat terkait dengan backend dan / atau frontend - dan kode ini bukan lagi kontrak pintar, dijalankan dengan cara biasa, dan implementasinya sepenuhnya dikendalikan oleh administrator server.
   
   

2. Bukan kontrak:

   
   
   • Itu tidak mencatat kewajiban para pihak - misalnya, ICO menjual token-nya untuk ETH, tetapi token pada dasarnya adalah pembungkus permen, karena jangan memaksakan pada orang yang membebaskan mereka, segala batasan atau kewajiban.
   • Mengizinkan perubahan satu sisi - dan ternyata salah satu pihak dapat mengubah kontrak setelah penandatanganannya.
     
     Contoh nyata : pemilik kontrak dapat mengubah kapitalisasi, kurs, dan durasi penjualan token secara sewenang-wenang:
     
     
   
   

3. Tidak diperlukan:

   
   
   • Kontrak pintar ditambahkan bukan karena itu secara teknis diperlukan, tetapi dalam mencoba mencari tahu apa yang harus dilakukan pada kontrak pintar dan mengendarai gelombang hype;
   • Kami mencoba mencari cara untuk mengikat kontrak pintar dengan produk yang sudah ada.
     
     
   
   

Kontrak pintar sebagai ancaman keamanan untuk memblokir startup

Apa hasilnya? Mereka ingin itu menjadi modis, aman, blockchain, tetapi kami mendapatkan kode mahal yang tidak didukung yang mengancam keamanan dan tidak diperlukan sama sekali. Kami ingin kontrak pintar kami dijalankan "persis seperti yang diprogram, tanpa kemungkinan downtime, sensor, penipuan atau intervensi pihak ketiga", dan pada akhirnya mereka benar-benar dieksekusi seperti yang tertulis - mereka hanya ditulis dengan kerentanan. Dan yang tersisa bagi kita adalah melambaikan pena dengan cara kita. Ya, atau untuk membuat garpu yang keras (dengan demikian benar-benar mendiskreditkan ide asli itu sendiri) jika pencipta Ethereum kehilangan uang karena kerentanannya.

Cara menulis kontrak pintar yang aman

Padahal, tentu saja, semuanya tidak terlalu buruk. Saya hanya melebih-lebihkan dalam upaya untuk menarik beberapa poin penting, menurut pendapat saya. Secara umum, area berkembang, orang-orang belajar, termasuk keamanan.

Jika pembaca memutuskan untuk menulis kontrak yang cerdas, saya akan menyarankan:

• memahami mengapa kontrak yang cerdas diperlukan (dan apakah itu diperlukan);
• terima dari pelanggan atau tulis TK;
• menghitung waktu;
• gunakan alat pengembangan dan pengujian ( Truffle , Remix , SmartCheck , Solhint atau Solium linter );
• menulis tes;
• melakukan beberapa audit independen dan karunia bug;
• memantau keamanan komponen proyek yang tersisa (situs web, Twitter, dll.).

Mengikuti rekomendasi sederhana ini, Anda dapat menghindari sebagian besar masalah yang dijelaskan di atas (dari percabangan keras, namun, ini masih tidak akan menyelamatkan).

Artikel itu dibuat bersama dengan Eugene Marchenko ( eMarchenko ).