Keamanan Smart Contract

Apa Itu Keamanan Smart Contract?

Keamanan Smart Contract adalah praktik merancang, menulis, menguji, mengaudit, menerapkan, memantau, dan meningkatkan smart contract blockchain agar melindungi aset pengguna serta berperilaku sesuai tujuan.

Smart contract adalah kode yang disimpan di blockchain dan dapat menjalankan aturan, memindahkan aset, mengelola izin, serta berinteraksi dengan pengguna atau kontrak lain.

Dokumentasi resmi smart contract Ethereum menjelaskan bahwa smart contract adalah program yang disimpan di blockchain dan dijalankan ketika dipicu oleh transaksi.

Keamanan smart contract penting karena kontrak dapat mengendalikan token, NFT, posisi staking, pasar pinjaman, vault, treasury, bridge, sistem governance, dan aset kripto berharga lainnya.

Bug perangkat lunak biasa dapat menyebabkan downtime, tetapi bug smart contract dapat menyebabkan kehilangan aset yang tidak dapat dipulihkan.

Keamanan smart contract bukan hanya tentang memperbaiki kode setelah masalah ditemukan.

Ini merupakan proses sepanjang siklus hidup yang dimulai dari desain protokol dan berlanjut setelah deployment.

Smart contract yang aman memerlukan arsitektur yang cermat, pola coding yang aman, pengujian kuat, peninjauan independen, deployment yang aman, pemantauan real-time, dan prosedur darurat yang jelas.

Sederhananya, Keamanan Smart Contract berarti melindungi aplikasi blockchain dari bug, exploit, penyalahgunaan, kegagalan governance, dan interaksi pengguna yang tidak aman.

Mengapa Keamanan Smart Contract Penting

Keamanan smart contract penting karena transaksi blockchain biasanya bersifat publik, otomatis, dan sulit dibatalkan setelah dikonfirmasi.

Jika smart contract memiliki kerentanan, penyerang di mana pun di dunia dapat memeriksa kode, menguji kelemahan tersebut, lalu memicu exploit melalui transaksi.

Aplikasi kripto menjadi target yang sangat menarik karena kontrak yang rentan dapat menyimpan aset likuid yang dapat dipindahkan dengan cepat.

Dokumentasi resmi pertimbangan keamanan Solidity memperingatkan bahwa panduan keamanan smart contract tidak akan pernah lengkap karena risiko baru terus muncul.

Hal ini penting karena keamanan smart contract terus berubah.

Standar token baru, desain DeFi baru, model bridge baru, sistem akun baru, rollup baru, dan pola upgrade baru dapat menciptakan permukaan serangan baru.

Keamanan smart contract juga penting bagi kepercayaan pengguna.

Pengguna mungkin tidak membaca setiap baris kode, tetapi mereka mengandalkan developer, auditor, tooling, wallet, dan verifikasi publik untuk mengurangi risiko.

Kontrak yang aman tetap dapat gagal jika kunci admin salah dikelola, data oracle dimanipulasi, atau otoritas upgrade disusupi.

Artinya, keamanan smart contract harus mencakup keamanan teknis kode dan keamanan operasional secara bersamaan.

Cara Kerja Keamanan Smart Contract

Keamanan smart contract bekerja dengan mengurangi kemungkinan kode, desain, izin, sumber data, atau proses deployment disalahgunakan.

Prosesnya dimulai dengan pemodelan ancaman sebelum baris kode pertama ditulis.

Pemodelan ancaman menanyakan aset apa yang berisiko, siapa yang dapat menyerang, asumsi apa yang dipercaya, dan seperti apa bentuk kegagalannya.

Developer kemudian menulis kontrak dengan pola aman, kompleksitas minimal, izin yang jelas, dan asumsi yang telah diuji.

Pengujian memeriksa perilaku yang diharapkan dan perilaku saat gagal dalam kasus normal, kasus tepi, dan kasus bermusuhan.

Alat analisis statis memindai kode untuk menemukan pola berisiko yang sudah dikenal.

Fuzzing dan invariant testing mencari perilaku tidak terduga melalui banyak input yang dihasilkan.

Verifikasi formal dapat membuktikan properti tertentu ketika sistem cukup penting dan propertinya ditentukan dengan jelas.

Audit manual meninjau arsitektur, kode, logika bisnis, ekonomi, dan asumsi deployment.

Setelah deployment, pemantauan dan respons insiden membantu mendeteksi serta menanggapi perilaku abnormal dengan cepat.

Kerentanan Smart Contract yang Umum

Kerentanan smart contract yang umum mencakup kelemahan access control, reentrancy, manipulasi oracle, kesalahan logika, kurangnya validasi input, external call yang tidak diperiksa, serangan flash loan, kesalahan aritmetika, randomisasi yang tidak aman, denial of service, dan kelemahan upgradeability proxy.

OWASP Smart Contract Top 10 for 2026 mencantumkan kategori utama seperti kerentanan access control, kerentanan logika bisnis, manipulasi price oracle, serangan yang difasilitasi flash loan, kurangnya validasi input, external call yang tidak diperiksa, kesalahan aritmetika, serangan reentrancy, integer overflow dan underflow, serta kerentanan upgradeability proxy.

Daftar ini berguna karena menunjukkan bahwa keamanan smart contract tidak terbatas pada satu jenis bug terkenal.

Protokol dapat gagal karena sebuah fungsi bersifat publik padahal seharusnya dibatasi.

Protokol dapat gagal karena harga oracle dapat dimanipulasi.

Protokol dapat gagal karena upgrade mengubah storage layout.

Protokol dapat gagal karena logika bisnis memungkinkan urutan tindakan yang tidak adil.

Protokol dapat gagal karena fungsi darurat memberikan terlalu banyak kekuasaan kepada satu kunci.

Peninjauan keamanan yang baik mencari pola yang telah dikenal maupun risiko khusus proyek.

Bug paling berbahaya sering kali adalah bug yang sesuai dengan desain unik protokol.

Access Control

Access control berarti menentukan siapa yang diizinkan memanggil fungsi smart contract yang sensitif.

Dokumentasi resmi access control OpenZeppelin menjelaskan bahwa access control dapat mengatur siapa yang dapat mint token, memberikan suara pada proposal, membekukan transfer, dan melakukan banyak tindakan penting lainnya.

Bug access control dapat memungkinkan penyerang mint token tanpa batas, menguras treasury, menjeda protokol, mengubah biaya, meningkatkan kontrak, atau memindahkan dana pengguna.

Model access control dasar dapat menggunakan alamat owner.

Model yang lebih canggih dapat menggunakan role, wallet multisignature, timelock, governance DAO, dewan darurat, atau izin operasional terpisah.

Access control yang baik mengikuti prinsip least privilege.

Least privilege berarti setiap role hanya boleh memiliki wewenang yang diperlukan dan tidak lebih.

Access control juga harus transparan karena pengguna perlu mengetahui siapa yang dapat mengubah aturan penting.

Kontrak dapat memiliki perhitungan yang benar tetapi tetap tidak aman jika satu kunci admin tersembunyi dapat mencuri aset.

Access control sering menjadi lapisan keamanan terpenting dalam sistem smart contract di dunia nyata.

Reentrancy

Reentrancy terjadi ketika kontrak memanggil kontrak eksternal sebelum memperbarui state-nya sendiri dengan aman, sehingga kontrak eksternal tersebut dapat memanggil kembali kontrak pertama dalam urutan yang tidak terduga.

Dokumentasi keamanan Solidity membahas reentrancy sebagai risiko yang telah dikenal dan merekomendasikan pola interaksi yang lebih aman.

Masalah reentrancy klasik dapat memungkinkan penarikan berulang sebelum saldo awal dikurangi.

Reentrancy modern juga dapat muncul melalui token hook, sistem callback, alur lintas fungsi, read-only reentrancy, dan integrasi DeFi yang kompleks.

Pertahanan yang umum adalah pola Checks-Effects-Interactions.

Pola ini terlebih dahulu memeriksa persyaratan, kemudian memperbarui state internal, dan terakhir memanggil kontrak eksternal.

Pertahanan lain adalah reentrancy guard yang memblokir panggilan bertingkat ke fungsi yang dilindungi.

Namun, reentrancy guard bukan pengganti pencatatan akuntansi yang benar.

Developer harus mengidentifikasi setiap external call dan mempertimbangkan apa yang dapat terjadi jika kontrak yang dipanggil berperilaku jahat.

Pengguna harus berhati-hati dengan kontrak tanpa audit yang menangani penarikan, callback, atau interaksi token kompleks.

Manipulasi Oracle

Manipulasi oracle terjadi ketika smart contract bergantung pada data eksternal yang dapat didistorsi oleh penyerang.

Dokumentasi resmi oracle Ethereum menjelaskan bahwa oracle memberi smart contract akses ke data eksternal karena smart contract tidak dapat mengakses informasi off-chain secara langsung.

Dalam DeFi, price oracle sangat penting karena dapat menentukan nilai agunan, likuidasi, swap, redemption, dan jumlah settlement.

Jika protokol menggunakan pool dengan likuiditas tipis sebagai satu-satunya sumber harga, penyerang dapat memanipulasi harga itu sementara waktu dan memperoleh profit dari kepercayaan kontrak terhadap data yang salah.

Flash loan dapat mempermudah manipulasi oracle karena memungkinkan penyerang meminjam likuiditas dalam jumlah besar untuk satu transaksi.

Desain oracle yang lebih aman dapat menggunakan data feed terdesentralisasi, harga berbobot waktu, circuit breaker, pemeriksaan kewajaran, mekanisme penundaan, dan beberapa sumber independen.

Dokumentasi Chainlink Price Feeds menjelaskan price feed sebagai data yang diagregasi dari banyak sumber data oleh operator node independen terdesentralisasi.

Bahkan sistem oracle yang kuat tetap memerlukan integrasi yang cermat.

Developer harus memeriksa decimal, data kedaluwarsa, status sequencer, frekuensi pembaruan, dan perilaku fallback.

Keamanan oracle adalah keamanan smart contract karena data yang salah dapat membuat kode yang benar menghasilkan dampak merugikan.

Kerentanan Logika Bisnis

Kerentanan logika bisnis terjadi ketika kode mengikuti instruksi tertulis, tetapi instruksi tersebut memungkinkan hasil ekonomi yang tidak diinginkan.

Bug ini dapat lebih sulit dideteksi daripada kesalahan sintaks karena kontrak mungkin dapat dikompilasi, lulus pengujian dasar, dan tampak normal.

Protokol pinjaman dapat memungkinkan agunan dinilai terlalu tinggi.

Kontrak staking dapat menghitung reward secara salah setelah penarikan sebagian.

Sistem governance dapat memungkinkan suara dihitung secara tidak adil.

Vault dapat memungkinkan pengguna masuk atau keluar pada harga yang merugikan deposan lain.

Keamanan logika bisnis memerlukan pemahaman model keuangan, bukan hanya bahasa pemrograman.

Developer harus menulis invariant yang menjelaskan apa yang harus selalu tetap benar.

Contohnya, total saham harus sesuai dengan aset, pengguna tidak boleh menarik lebih banyak daripada saldonya, dan cadangan tidak boleh menjadi negatif.

Peninjauan logika bisnis merupakan salah satu alasan audit smart contract memerlukan pengetahuan domain ekonomi kripto.

Validasi Input

Validasi input berarti memeriksa bahwa parameter fungsi dapat diterima sebelum digunakan.

Smart contract harus menolak alamat tidak valid, jumlah yang tidak mungkin, tenggat waktu kedaluwarsa, panjang array yang salah, pemanggil tidak berwenang, tanda tangan kedaluwarsa, dan nilai konfigurasi tidak aman.

Validasi yang tidak memadai dapat menyebabkan dana terkunci, akuntansi yang salah, approval yang keliru, integrasi gagal, atau jalur serangan.

Misalnya, fungsi yang menerima alamat oracle tidak boleh mengizinkan alamat nol atau alamat tidak tepercaya tanpa persetujuan governance.

Fungsi swap harus memvalidasi parameter output minimum dan deadline untuk melindungi pengguna dari eksekusi yang buruk.

Fungsi token harus memvalidasi izin sebelum minting atau burning.

Validasi input harus eksplisit dan dekat dengan titik masuk data ke sistem.

Validasi yang baik juga meningkatkan pesan error dan debugging.

Namun, validasi tidak boleh menciptakan rasa aman palsu karena penyerang tetap dapat memanggil fungsi secara langsung tanpa menggunakan front end proyek.

Setiap fungsi publik dan eksternal harus diperlakukan sebagai titik masuk serangan.

External Call yang Tidak Diperiksa

External call yang tidak diperiksa terjadi ketika kontrak memanggil kontrak lain atau mengirim nilai tanpa memeriksa dengan tepat apakah panggilan tersebut berhasil.

External call dapat gagal karena banyak alasan, termasuk kondisi revert, batas gas, fungsi yang tidak tersedia, perilaku fallback, atau kode berbahaya.

Jika kontrak mengasumsikan external call berhasil padahal tidak, akuntansi internal dapat menjadi salah.

Panggilan yang tidak diperiksa juga dapat menyembunyikan kegagalan dalam sistem pembayaran, transfer token, dan pesan bridge.

Developer harus memeriksa nilai pengembalian dan menangani kondisi kegagalan dengan jelas.

Beberapa kontrak token tidak berperilaku persis seperti contoh standar sederhana, sehingga wrapper transfer aman dapat mengurangi risiko kompatibilitas.

External call harus diminimalkan dan diurutkan secara cermat.

Kontrak harus menghindari ketergantungan pada perilaku eksternal yang tidak diketahui ketika dana pengguna dipertaruhkan.

Ketika external call diperlukan, developer harus merancang untuk kegagalan alih-alih mengasumsikan keberhasilan.

External call yang tidak diperiksa berbahaya karena mengubah ketidakpastian menjadi kerusakan state tersembunyi.

Kesalahan Aritmetika

Kesalahan aritmetika terjadi ketika kontrak menghitung jumlah, biaya, saham, reward, utang, agunan, atau harga secara keliru.

Solidity 0.8.x memperkenalkan aritmetika yang diperiksa secara default untuk sebagian besar kasus overflow dan underflow, tetapi keamanan aritmetika masih belum terselesaikan secara otomatis.

Dokumentasi resmi Solidity merekomendasikan penggunaan versi compiler terkini serta pemahaman perubahan bahasa karena compiler terus berkembang.

Kesalahan aritmetika modern sering melibatkan pembulatan, kehilangan presisi, ketidakcocokan decimal, faktor skala, urutan operasi, perilaku fee-on-transfer, dan rumus konversi saham.

Kesalahan pembulatan kecil dapat menjadi serius jika penyerang dapat mengulangi tindakan berkali-kali.

Protokol DeFi harus menguji nilai ekstrem, nilai nol, nilai maksimum, deposit kecil, deposit besar, dan decimal token yang tidak biasa.

Invariant akuntansi harus diuji secara berkelanjutan.

Blok aritmetika tidak diperiksa dapat berguna untuk efisiensi gas, tetapi hanya boleh digunakan ketika developer dapat membuktikan keamanannya.

Keamanan aritmetika bukan hanya tentang mencegah overflow.

Ini tentang memastikan setiap perhitungan keuangan sesuai dengan ekonomi yang dimaksudkan protokol.

Serangan Flash Loan

Serangan flash loan menggunakan likuiditas pinjaman sementara dalam satu transaksi untuk memanipulasi asumsi protokol.

Flash loan tidak secara inheren berbahaya karena dapat mendukung arbitrase, likuidasi, dan efisiensi modal.

Flash loan menjadi berbahaya ketika protokol mengasumsikan penyerang tidak dapat mengakses modal sementara yang besar.

Flash loan dapat memperbesar manipulasi oracle, serangan governance, manipulasi liquidity pool, dan exploit reward farming.

Protokol yang aman harus mengasumsikan penyerang dapat mengakses modal besar dalam jangka pendek.

Pertahanan dapat mencakup oracle yang kuat, data berbobot waktu, pemeriksaan agunan, penundaan voting, pemeriksaan kewajaran likuiditas, dan akuntansi yang cermat.

Developer harus menghindari asumsi keamanan yang didasarkan pada mahalnya biaya serangan tanpa likuiditas pinjaman.

Pengujian harus mencakup skenario ketika penyerang memiliki modal jauh lebih besar daripada perkiraan.

Keamanan flash loan terutama berkaitan dengan desain protokol yang tetap benar walaupun modal melimpah sementara waktu.

Protokol yang rentan terhadap flash loan biasanya rentan karena asumsi desain yang lebih mendasar.

Randomisasi yang Tidak Aman

Randomisasi yang tidak aman terjadi ketika kontrak menggunakan nilai yang dapat diprediksi atau dimanipulasi seolah-olah nilai tersebut acak.

Randomisasi penting untuk game, lotere, NFT reveal, raffle, pemilihan validator, dan distribusi reward.

Menggunakan data block secara langsung untuk randomisasi dapat tidak aman karena validator atau block builder dapat memengaruhi atau memprediksi beberapa nilai.

Penyerang juga dapat memilih waktu untuk memanggil fungsi setelah melihat kondisi yang menguntungkan.

Randomisasi yang aman harus menggunakan desain yang sesuai dengan nilai aset yang berisiko.

Pendekatan yang memungkinkan mencakup skema commit-reveal, verifiable random function, reveal tertunda, atau jaringan randomisasi tepercaya, tergantung sistemnya.

Randomisasi harus ditinjau sebagai ketergantungan yang sangat penting bagi keamanan.

Game dengan randomisasi lemah dapat menjadi sistem pembayaran yang dapat diprediksi oleh penyerang.

NFT reveal dengan randomisasi lemah dapat memungkinkan pemilihan trait yang tidak adil.

Dalam kripto, randomisasi sulit karena setiap node harus mencapai hasil yang sama sementara penyerang dapat mengamati data publik.

Denial of Service

Denial of service dalam smart contract berarti penyerang dapat mencegah pengguna normal atau fungsi protokol beroperasi dengan benar.

Kontrak dapat mengalami denial of service karena loop tanpa batas, revert paksa, operasi yang membutuhkan gas besar, penarikan yang terblokir, pertumbuhan storage, atau kegagalan ketergantungan.

Misalnya, jika fungsi pembayaran melakukan loop pada setiap pengguna dalam daftar besar, fungsi itu dapat menjadi mustahil dieksekusi ketika daftar bertambah terlalu besar.

Jika satu penerima dapat melakukan revert dan memblokir seluruh pembayaran batch, keseluruhan sistem dapat macet.

Pola pull-payment dapat mengurangi sebagian risiko denial of service dengan memungkinkan pengguna menarik dana secara individual.

Kontrak harus menghindari kewajiban untuk memproses jumlah pengguna tanpa batas dalam satu transaksi.

Developer harus menguji penggunaan gas seiring pertumbuhan state.

Mereka juga harus merancang jalur keluar darurat dan isolasi kegagalan untuk alur penting.

Denial of service mungkin tidak mencuri dana secara langsung, tetapi dapat membekukan dana atau mengganggu operasi protokol.

Ketersediaan adalah bagian dari keamanan smart contract.

Risiko tx.origin

Menggunakan tx.origin untuk otorisasi adalah pola smart contract yang berbahaya.

Pertimbangan keamanan Solidity tentang tx.origin memperingatkan agar tidak menggunakan tx.origin untuk otorisasi.

Nilai tx.origin merujuk pada externally owned account awal yang memulai transaksi, sedangkan msg.sender merujuk pada pemanggil langsung.

Kontrak berbahaya dapat menipu pengguna untuk memanggilnya, kemudian memanggil kontrak lain tempat tx.origin tetap menunjuk kepada pengguna tersebut.

Jika kontrak target mempercayai tx.origin, kontrak berbahaya dapat melewati otorisasi yang seharusnya berlaku.

Kontrak umumnya harus menggunakan msg.sender dan pemeriksaan izin eksplisit.

Developer juga harus berhati-hati dengan meta-transaksi, abstraksi akun, proxy, dan relayer karena identitas pemanggil dapat menjadi lebih kompleks.

Otorisasi harus dirancang berdasarkan model kepercayaan yang sebenarnya.

Jalan pintas sederhana dalam pemeriksaan pemanggil dapat menjadi kerentanan serius.

Risiko tx.origin merupakan contoh klasik mengapa konteks eksekusi blockchain penting.

Risiko Tanda Tangan dan Replay

Risiko tanda tangan terjadi ketika pengguna menandatangani pesan yang dapat digunakan ulang, disalahartikan, atau diterapkan dalam konteks yang tidak dimaksudkan.

Smart contract sering menggunakan tanda tangan untuk permit, approval tanpa gas, order, voting, klaim, bridge, dan izin akun.

Serangan replay dapat terjadi ketika tanda tangan yang valid digunakan kembali lebih dari satu kali atau digunakan kembali pada chain, kontrak, atau konteks lain.

Desain tanda tangan yang baik mencakup nonce, deadline, chain ID, alamat kontrak, domain separation, dan typed data yang jelas.

Pengguna harus menghindari penandatanganan pesan yang tidak mereka pahami.

Developer harus menghindari pesan ambigu yang tampak tidak berbahaya tetapi mengotorisasi tindakan yang kuat.

Wallet harus menampilkan informasi penandatanganan yang mudah dibaca bila memungkinkan.

Protokol harus membatalkan validitas tanda tangan yang telah digunakan dan melindungi dari replay lintas chain.

Keamanan tanda tangan penting karena transaksi tidak perlu ditandatangani langsung oleh pengguna jika tanda tangan sebelumnya dapat mengotorisasi tindakan di kemudian hari.

Pesan yang ditandatangani dapat sama kuatnya dengan transaksi yang ditandatangani ketika kontrak dirancang untuk menerimanya.

Risiko Standar Token

Risiko standar token terjadi ketika kontrak mengasumsikan semua token berperilaku sama.

Beberapa token mengenakan biaya transfer, melakukan rebase saldo, tidak mengembalikan nilai boolean, menjeda transfer, memasukkan alamat ke blacklist, menggunakan hook, atau memiliki decimal yang tidak biasa.

Protokol DeFi yang mengasumsikan setiap token berperilaku seperti contoh token sederhana dapat gagal saat menangani perilaku nonstandar.

Standar NFT juga dapat mencakup hook, pembatasan transfer, royalti, perubahan metadata, dan approval operator.

Developer harus menguji perilaku token yang tidak biasa, bukan hanya token uji yang ideal.

Wrapper aman dapat membantu menangani token yang tidak mengembalikan nilai yang diharapkan.

Protokol harus menetapkan token yang didukung dan alasannya.

Listing token yang tidak didukung dapat menciptakan kegagalan akuntansi atau penarikan.

Pengguna harus memahami bahwa kompatibilitas token dengan interface umum tidak menjadikannya bebas risiko.

Keamanan smart contract harus mencakup aset dan standar yang berinteraksi dengan kontrak.

Risiko Upgradeability

Risiko upgradeability berasal dari kemampuan untuk mengubah logika kontrak setelah deployment.

Dokumentasi resmi upgrade smart contract Ethereum menjelaskan bahwa pola upgrade dapat memungkinkan developer mengubah perilaku kontrak setelah deployment.

Upgradeability dapat membantu memperbaiki bug dan menambahkan fitur.

Namun, hal ini juga dapat memungkinkan admin atau governance mengganti logika aman dengan logika tidak aman.

Pola proxy menghadirkan risiko khusus seperti kerusakan storage layout, initializer yang tidak dilindungi, alamat implementasi yang salah, kunci admin yang disusupi, dan perubahan logika tersembunyi.

Panduan OpenZeppelin untuk menulis kontrak yang dapat di-upgrade menjelaskan sejumlah peringatan penting dalam penulisan kontrak upgradeable.

Pengguna harus memeriksa apakah protokol dapat di-upgrade sebelum melakukan deposit dana.

Mereka juga harus memeriksa siapa yang mengendalikan upgrade, apakah terdapat timelock, dan apakah implementasi diverifikasi setelah setiap upgrade.

Audit versi satu tidak otomatis mencakup versi dua.

Upgradeability berguna, tetapi merupakan asumsi kepercayaan yang besar.

Risiko Inisialisasi

Risiko inisialisasi terjadi ketika kontrak upgradeable tidak diinisialisasi dengan benar.

Dalam banyak sistem proxy, constructor tidak menginisialisasi storage proxy dengan cara normal.

Developer menggunakan fungsi initializer untuk menetapkan owner, role, nama token, nilai konfigurasi, dan state awal lainnya.

Jika initializer dibiarkan terbuka, penyerang dapat menginisialisasi kontrak dan mengambil alih kendali.

Jika reinitializer salah, upgrade selanjutnya dapat mengatur ulang izin atau pengaturan penting.

Kontrak implementasi sering kali harus menonaktifkan inisialisasi langsung jika tidak dimaksudkan untuk digunakan secara langsung.

Skrip deployment harus memverifikasi bahwa inisialisasi terjadi tepat satu kali dan menggunakan nilai yang benar.

Auditor harus meninjau jalur inisialisasi dan reinisialisasi dengan cermat.

Pengguna jarang melihat detail inisialisasi, tetapi initializer yang buruk dapat menentukan siapa yang mengendalikan protokol.

Inisialisasi adalah masalah keamanan deployment, bukan sekadar detail coding.

Risiko Storage Layout

Risiko storage layout terjadi ketika kontrak yang di-upgrade membaca atau menulis storage lama secara salah.

Dokumentasi resmi storage layout Solidity menjelaskan bagaimana state variable diatur dalam storage.

Dalam sistem proxy, storage biasanya tetap berada di proxy sementara logika berubah di implementasi.

Jika implementasi baru mengubah urutan atau tipe variabel secara salah, state lama dapat rusak.

Mapping saldo dapat ditafsirkan secara keliru.

Alamat owner dapat tertimpa.

Nilai cadangan dapat menjadi tidak bermakna.

Alat upgrade dapat membandingkan storage layout sebelum upgrade, tetapi developer tetap harus meninjau perubahan dengan cermat.

Storage layout harus diperlakukan sebagai bagian dari struktur data permanen protokol.

Kesalahan storage dapat merusak protokol meskipun logika fungsi baru tampak benar.

Keamanan Front End

Keamanan smart contract juga bergantung pada front end yang digunakan pengguna untuk berinteraksi.

Kontrak yang aman tetap dapat berbahaya jika website disusupi dan meminta pengguna menandatangani transaksi berbahaya.

Serangan front end dapat mengubah alamat penerima, target approval, harga yang ditampilkan, tombol klaim, atau data transaksi.

Pengguna harus memverifikasi alamat kontrak dan prompt wallet, bukan hanya mempercayai teks website.

Developer harus melindungi pipeline deployment, nama domain, sistem distribusi konten, rekaman DNS, dan build tool.

Perubahan front end yang penting harus ditinjau seperti perubahan kode.

Simulasi transaksi wallet dan prompt penandatanganan yang jelas dapat mengurangi sebagian risiko pengguna.

Namun, pengguna tetap dapat menyetujui tindakan berbahaya jika interface menyesatkan.

dApp hanya seaman keseluruhan jalur dari website ke wallet hingga smart contract.

Keamanan front end merupakan bagian dari keamanan smart contract karena pengguna menandatangani melalui interface.

Keamanan Kunci Privat dan Admin

Keamanan kunci privat melindungi akun yang melakukan deployment, upgrade, pause, konfigurasi, atau pengoperasian smart contract.

Kunci admin terkadang dapat menyebabkan kerusakan lebih besar daripada bug kode karena mungkin memiliki izin untuk mengubah pengaturan inti.

Protokol harus menghindari pemberian kekuasaan tanpa batas atas kontrak berharga kepada satu hot wallet.

Wallet multisignature dapat mewajibkan beberapa approval sebelum tindakan sensitif dilakukan.

Timelock dapat menunda eksekusi agar pengguna dan sistem pemantauan dapat meninjau perubahan yang tertunda.

Hardware wallet, perangkat penandatanganan aman, kebijakan akses, dan playbook operasional dapat mengurangi risiko penyusupan kunci.

Tim harus memisahkan role agar satu kunci tidak sekaligus mengendalikan deployment, upgrade, treasury, pengaturan oracle, dan fungsi darurat.

Rotasi kunci dan rencana pemulihan darurat harus disiapkan sebelum insiden terjadi.

Pengguna harus meninjau wewenang admin sebelum mempercayai protokol.

Keamanan smart contract mencakup manusia dan kunci yang dapat mengubah kontrak.

Pengujian

Pengujian adalah pertahanan teknis utama pertama terhadap bug smart contract.

Unit test memeriksa fungsi individual.

Integration test memeriksa perilaku beberapa kontrak secara bersama-sama.

Fork test mensimulasikan perilaku berdasarkan salinan state jaringan nyata.

Regression test memastikan bug yang telah diperbaiki tidak muncul kembali.

Negative test mengonfirmasi bahwa tindakan tidak valid atau tidak berwenang gagal seperti yang diharapkan.

Pengujian yang baik mencakup kasus tepi, nilai nol, nilai maksimum, decimal token yang tidak biasa, token fee-on-transfer, oracle kedaluwarsa, transfer gagal, dan state yang dijeda.

Pengujian juga harus mencakup skrip deployment dan skrip upgrade.

Kontrak dapat memiliki pengujian fungsi yang kuat tetapi tetap gagal saat deployment jika nilai pengaturan salah.

Pengujian diperlukan, tetapi pengujian saja tidak cukup untuk kontrak bernilai tinggi.

Fuzzing dan Invariant Testing

Fuzzing adalah metode pengujian yang menghasilkan banyak input untuk mencari perilaku tidak terduga.

Invariant testing memeriksa apakah properti penting tetap benar dalam banyak tindakan dan state.

Invariant dapat menyatakan bahwa total aset harus selalu lebih besar dari atau sama dengan total klaim pengguna.

Invariant lain dapat menyatakan bahwa pengguna tidak dapat menarik lebih banyak dari saldonya.

Fuzzing berguna karena penyerang akan mencoba input yang tidak terpikirkan oleh developer.

Invariant testing berguna karena sistem DeFi sering gagal ketika banyak tindakan valid digabungkan dalam urutan yang tidak terduga.

Fuzzing harus mencakup beberapa pengguna, beberapa token, tindakan berulang, waktu tepi, dan kontrak bermusuhan bila memungkinkan.

Developer harus memperlakukan setiap invariant yang gagal sebagai sinyal serius sampai mereka memahaminya.

Auditor sering menggunakan fuzzing untuk menemukan bug ekonomi dan state machine.

Untuk smart contract kompleks, fuzzing dan invariant testing sering lebih bernilai daripada pengujian contoh sederhana.

Analisis Statis

Analisis statis memindai kode tanpa menjalankannya untuk mendeteksi pola berisiko dan kemungkinan bug.

Dokumentasi Slither menjelaskan Slither sebagai framework analisis statis Solidity dan Vyper yang menjalankan detektor kerentanan, menampilkan informasi kontrak, dan membantu developer memahami kode.

Analisis statis dapat menemukan masalah seperti pola reentrancy, variabel tidak digunakan, panggilan berbahaya, event yang hilang, visibility yang salah, dan dependensi mencurigakan.

Proses ini cepat dan dapat diintegrasikan ke dalam pipeline development.

Analisis statis tidak sempurna karena dapat menghasilkan false positive dan melewatkan bug logika bisnis.

Developer tidak boleh memperlakukan laporan analisis statis yang bersih sebagai bukti keamanan.

Mereka juga tidak boleh mengabaikan peringatan tanpa peninjauan.

Analisis statis paling baik digunakan sejak awal dan sesering mungkin.

Analisis ini menangkap banyak kesalahan sederhana sebelum auditor menghabiskan waktu pada masalah yang lebih mendalam.

Tooling otomatis meningkatkan keamanan smart contract bila dikombinasikan dengan penilaian manusia.

Verifikasi Formal

Verifikasi formal menggunakan metode matematis untuk membuktikan bahwa properti kontrak tertentu berlaku berdasarkan asumsi yang ditetapkan.

Dokumentasi Certora Prover menjelaskan verifikasi formal sebagai perbandingan bytecode smart contract dengan aturan yang menggambarkan perilaku yang diharapkan.

Verifikasi formal dapat bernilai bagi protokol bernilai tinggi, logika akuntansi inti, invariant token, pasar pinjaman, bridge, dan sistem governance.

Verifikasi ini dapat membuktikan properti seperti batas total suplai, konservasi saldo, batasan access control, atau keamanan penarikan.

Verifikasi formal hanya sebaik properti yang ditentukan.

Jika spesifikasi melewatkan risiko nyata, pembuktian tetap dapat lulus sementara protokol tetap tidak aman.

Verifikasi formal juga memerlukan keahlian khusus dan waktu.

Verifikasi ini tidak menggantikan audit, pengujian, pemantauan, atau operasi yang aman.

Verifikasi formal paling berguna ketika properti penting jelas dan nilai yang dipertaruhkan tinggi.

Verifikasi formal memberikan jaminan yang lebih kuat untuk klaim spesifik, bukan keamanan universal untuk segala hal.

Audit Manual

Audit smart contract manual adalah peninjauan keamanan independen oleh spesialis.

Audit dapat memeriksa arsitektur, kode, access control, pengujian, upgradeability, asumsi ekonomi, desain oracle, skrip deployment, dan dokumentasi.

Audit harus mengidentifikasi kerentanan, menjelaskan dampaknya, merekomendasikan perbaikan, dan memverifikasi apakah perbaikan telah diterapkan.

Audit tidak menjamin smart contract aman.

Audit mengurangi risiko dengan menambahkan peninjauan ahli sebelum atau sesudah deployment.

Cakupan audit penting karena audit mungkin hanya mencakup kontrak, branch, commit, atau fitur tertentu.

Pengguna harus memeriksa apakah kode yang diterapkan sesuai dengan kode yang diaudit.

Mereka juga harus memeriksa apakah upgrade selanjutnya diaudit secara terpisah.

Audit yang baik adalah bagian dari proses keamanan, bukan lencana pemasaran.

Protokol yang serius harus memperlakukan temuan audit sebagai pekerjaan engineering, bukan sekadar formalitas.

Bug Bounty

Bug bounty memberikan reward kepada peneliti eksternal yang melaporkan kerentanan secara bertanggung jawab.

Bug bounty berguna karena tidak ada tim internal atau audit yang dapat menemukan setiap masalah.

Bounty publik dapat menarik peneliti dengan keahlian, alat, dan pola pikir penyerang yang berbeda.

Program bounty yang baik menentukan cakupan, tingkat keparahan, rentang reward, aturan pengungkapan, dan aturan pengujian aman.

Reward harus sesuai dengan nilai yang berisiko.

Bounty kecil untuk protokol yang menyimpan nilai besar mungkin tidak mendorong pengungkapan yang bertanggung jawab.

Triage bug bounty harus cepat dan profesional.

Peneliti tidak boleh diabaikan ketika melaporkan masalah yang kredibel.

Bug bounty tidak menggantikan audit karena biasanya terjadi setelah kode bersifat publik atau telah di-deploy.

Bug bounty merupakan lapisan keamanan berkelanjutan yang dapat membantu menemukan masalah dari waktu ke waktu.

Pemantauan dan Keamanan Runtime

Pemantauan mengawasi kontrak yang telah di-deploy untuk aktivitas mencurigakan, transaksi tidak biasa, pergerakan harga abnormal, penarikan besar, tindakan governance, panggilan gagal, dan peristiwa upgrade.

Keamanan smart contract tidak berakhir saat deployment.

Penyerang sering mengeksploitasi kontrak ketika likuiditas tinggi, pasar volatil, atau tim tidak melakukan pemantauan.

Pemantauan dapat mendeteksi perilaku mencurigakan cukup dini untuk pause darurat, peringatan pengguna, perubahan parameter, atau respons insiden.

Peringatan penting dapat mencakup penurunan TVL mendadak, minting yang tidak terduga, tindakan admin besar, deviasi oracle abnormal, panggilan gagal berulang, dan upgrade implementasi.

Pemantauan harus mencakup smart contract, front end, governance, oracle, kunci, dan infrastruktur.

Tim harus menguji sistem peringatan sebelum peluncuran.

Peringatan hanya berguna jika seseorang dapat merespons dengan cepat dan benar.

Pengguna diuntungkan ketika protokol menerbitkan laporan insiden dan post-mortem setelah peristiwa besar.

Keamanan runtime mengubah keamanan smart contract dari peninjauan satu kali menjadi operasi yang berkelanjutan.

Respons Insiden

Respons insiden adalah rencana tindakan protokol ketika terjadi masalah.

Rencana respons dapat mencakup menjeda kontrak, menonaktifkan deposit, memperbarui peringatan front end, menghubungi pengguna, berkoordinasi dengan peneliti keamanan, menyiapkan patch, dan menerbitkan komunikasi.

Kontrol darurat dapat melindungi pengguna, tetapi juga menciptakan risiko sentralisasi.

Protokol harus mendokumentasikan siapa yang dapat memicu tindakan darurat dan dalam kondisi apa.

Tim harus melatih skenario insiden sebelum dana nyata berisiko.

Komunikasi harus akurat, cepat, dan jujur.

Menyembunyikan insiden dapat memperburuk kerugian pengguna.

Analisis pascainsiden harus mengidentifikasi akar masalah dan perbaikan jangka panjang.

Protokol tidak boleh mengandalkan improvisasi saat exploit sedang berlangsung.

Rencana respons insiden yang kuat adalah bagian utama dari keamanan smart contract.

Deployment yang Aman

Deployment yang aman berarti meluncurkan smart contract dengan kode, konfigurasi, kepemilikan, alamat, dan verifikasi yang benar.

Kesalahan deployment dapat sama berbahayanya dengan bug kode.

Kontrak dapat diaudit dan tetap tidak aman jika diterapkan dengan admin, oracle, alamat token, pengaturan biaya, atau otoritas upgrade yang salah.

Skrip deployment harus ditinjau, diuji, dan dikendalikan versinya.

Tim harus menggunakan checklist sebelum deployment mainnet.

Output deployment penting harus dicatat, termasuk alamat kontrak, argumen constructor, alamat implementasi, alamat admin, dan hash transaksi.

Kode sumber harus diverifikasi setelah deployment bila memungkinkan.

Dokumentasi resmi verifikasi smart contract Ethereum menjelaskan bahwa verifikasi membandingkan kode sumber dengan bytecode hasil kompilasi.

Pengguna harus membandingkan alamat proyek resmi dengan data explorer yang telah diverifikasi sebelum berinteraksi.

Keamanan deployment adalah titik ketika kode yang telah ditinjau menjadi risiko on-chain nyata.

Upgrade yang Aman

Upgrade yang aman memerlukan lebih dari sekadar menerapkan implementasi baru.

Tim harus meninjau code diff, memvalidasi storage layout, menguji berdasarkan state lama, memperbarui dokumentasi, memverifikasi kode sumber, dan mengungkapkan rencana upgrade.

Upgrade berisiko tinggi harus diaudit sebelum dieksekusi.

Timelock dan proposal governance memberi pengguna waktu untuk meninjau perubahan.

Upgrade darurat mungkin memerlukan eksekusi lebih cepat, tetapi tetap harus didokumentasikan setelahnya.

Upgrade yang aman tidak boleh secara diam-diam mengubah asumsi pengguna terkait penarikan, biaya, agunan, governance, atau suplai token.

Pengguna harus memantau protokol yang mereka andalkan karena upgrade dapat mengubah profil risiko tanpa mengubah alamat.

Developer harus membuat runbook upgrade sebelum upgrade pertama diperlukan.

Kunci upgrade harus dilindungi dengan multisignature dan kontrol operasional.

Upgradeability yang aman adalah tentang perubahan terkendali, bukan perubahan tanpa batas.

Uji Tuntas Pengguna

Pengguna dapat mengurangi risiko smart contract dengan memeriksa sinyal keamanan dasar sebelum berinteraksi.

Mereka harus memeriksa apakah kode sumber kontrak telah diverifikasi.

Mereka harus memeriksa apakah audit tersedia dan apakah temuannya telah diperbaiki.

Mereka harus memeriksa apakah kontrak dapat di-upgrade dan siapa yang mengendalikan upgrade.

Mereka harus memeriksa role admin, fungsi pause, hak mint, wewenang blacklist, pengaturan oracle, dan aturan penarikan.

Mereka harus membandingkan alamat kontrak dengan sumber proyek resmi.

Mereka harus memulai dengan jumlah kecil saat menggunakan protokol baru.

Mereka harus menghindari menandatangani transaksi yang tidak dipahami.

Mereka harus meninjau approval token dan mencabut izin yang tidak digunakan bila praktis.

Uji tuntas pengguna tidak dapat menghapus semua risiko, tetapi dapat mencegah banyak kerugian yang dapat dihindari.

Keamanan Smart Contract untuk Developer

Developer harus merancang smart contract sebagai perangkat lunak keuangan berisiko tinggi sejak awal.

Mereka harus menjaga kode tetap sederhana, modular, dan terdokumentasi dengan baik.

Mereka harus menggunakan library matang bila sesuai, alih-alih menulis kode kustom berisiko untuk pola umum.

Mereka harus menentukan invariant sebelum mengimplementasikan logika keuangan yang kompleks.

Mereka harus menggunakan pengujian, fuzzing, analisis statis, dan peninjauan manual sebelum audit.

Mereka harus menghindari deployment yang terburu-buru demi memenuhi tenggat pemasaran.

Mereka harus meninjau versi compiler, versi dependensi, dan pengaturan deployment.

Mereka harus mendokumentasikan setiap role istimewa dan wewenang darurat.

Mereka harus merencanakan pemantauan dan respons insiden sebelum peluncuran.

Pengembangan aman adalah proses, bukan laporan audit akhir.

Keamanan Smart Contract untuk Pengguna

Pengguna harus memahami bahwa smart contract dapat transparan dan berisiko pada saat yang sama.

Kode sumber terverifikasi berarti kode terlihat, bukan berarti kode aman.

Audit berarti ahli meninjau suatu cakupan, bukan berarti tidak ada bug.

Yield tinggi dapat menjadi kompensasi atas risiko teknis atau ekonomi yang tinggi.

Protokol populer tetap dapat rentan.

Protokol yang telah berjalan lama tetap dapat terdampak upgrade baru, integrasi baru, atau kondisi pasar baru.

Pengguna harus menggunakan hardware wallet atau pengaturan kustodi yang lebih kuat untuk saldo besar bila memungkinkan.

Mereka harus memisahkan wallet penggunaan harian dari penyimpanan jangka panjang.

Mereka harus menghindari approval tanpa batas untuk kontrak yang tidak dikenal.

Mereka harus mengingat bahwa tanda tangan wallet dapat mengotorisasi tindakan smart contract yang tidak dapat dipulihkan.

Kesalahan Keamanan Smart Contract yang Umum

Satu kesalahan umum adalah menganggap audit sebagai jaminan keamanan.

Kesalahan lain adalah meluncurkan tanpa menguji kasus kegagalan.

Kesalahan ketiga adalah menggunakan satu kunci admin untuk terlalu banyak wewenang.

Kesalahan keempat adalah bergantung pada sumber harga yang dapat dimanipulasi.

Kesalahan kelima adalah mengabaikan storage layout saat upgrade.

Kesalahan keenam adalah menggunakan tx.origin untuk otorisasi.

Kesalahan ketujuh adalah mempercayai setiap token akan berperilaku sama.

Kesalahan kedelapan adalah membiarkan fungsi initializer tidak terlindungi.

Kesalahan kesembilan adalah gagal memantau kontrak yang telah di-deploy setelah peluncuran.

Kesalahan kesepuluh adalah mengasumsikan pengguna akan memahami prompt wallet berisiko tanpa desain interface yang jelas.

Manfaat Keamanan Smart Contract

Manfaat pertama keamanan smart contract adalah perlindungan dana pengguna.

Manfaat kedua adalah keandalan protokol yang lebih kuat.

Manfaat ketiga adalah kepercayaan pengguna yang lebih baik melalui kontrol transparan dan perilaku yang terverifikasi.

Manfaat keempat adalah risiko penghentian darurat dan kerugian akibat exploit yang lebih rendah.

Manfaat kelima adalah integrasi yang lebih mudah karena protokol lain dapat lebih percaya pada kontrak yang ditinjau dengan baik.

Manfaat keenam adalah governance yang lebih baik karena risiko dan wewenang admin didokumentasikan dengan jelas.

Manfaat ketujuh adalah respons insiden yang lebih cepat karena pemantauan dan playbook telah siap.

Manfaat kedelapan adalah pemeliharaan jangka panjang yang lebih baik melalui praktik upgrade dan deployment aman.

Keamanan yang baik juga dapat mengurangi kerusakan reputasi ketika masalah ditangani secara bertanggung jawab.

Keamanan smart contract adalah keunggulan kompetitif karena pengguna lebih memilih protokol yang serius melindungi aset.

Risiko dan Keterbatasan Keamanan Smart Contract

Tidak ada proses keamanan yang dapat menjamin smart contract sepenuhnya aman.

Audit dapat melewatkan bug.

Pengujian dapat melewatkan kasus tepi yang belum diketahui.

Verifikasi formal dapat membuktikan properti yang salah.

Pemantauan dapat mendeteksi serangan terlalu terlambat.

Kontrol admin dapat disalahgunakan atau disusupi.

Governance dapat menyetujui perubahan yang merugikan.

Sistem oracle dapat gagal dalam kondisi pasar yang tidak biasa.

Pengguna tetap dapat menandatangani transaksi berbahaya melalui interface yang tidak aman.

Tujuan keamanan smart contract adalah mengurangi risiko, bukan menghapus risiko secara sempurna.

Praktik Terbaik Keamanan Smart Contract

Mulai pekerjaan keamanan pada tahap desain, bukan menunggu hingga deployment.

Gunakan pemodelan ancaman untuk mengidentifikasi aset, penyerang, asumsi kepercayaan, dan mode kegagalan.

Tulis kode sederhana dengan izin jelas dan kompleksitas yang tidak perlu seminimal mungkin.

Gunakan versi compiler stabil terkini dan tinjau peringatan compiler.

Uji kasus normal, kasus tepi, kasus kegagalan, dan perilaku pengguna bermusuhan.

Gunakan fuzzing, invariant testing, analisis statis, dan peninjauan manual sebelum audit eksternal.

Audit kontrak bernilai tinggi dan terbitkan informasi audit yang bermakna.

Gunakan kontrol multisignature, timelock, dan governance transparan untuk tindakan istimewa.

Verifikasi kode sumber dan konfigurasi deployment setelah peluncuran.

Pantau kontrak aktif dan siapkan respons insiden sebelum pengguna melakukan deposit aset dalam jumlah signifikan.

FAQ

Apa arti Keamanan Smart Contract?

Keamanan Smart Contract berarti melindungi smart contract blockchain dari bug, exploit, izin tidak aman, data buruk, kegagalan upgrade, dan interaksi pengguna berisiko.

Mengapa Keamanan Smart Contract penting?

Keamanan Smart Contract penting karena smart contract dapat mengendalikan aset kripto nyata dan transaksi blockchain yang telah dikonfirmasi biasanya sulit dibatalkan.

Apa kerentanan smart contract yang paling umum?

Tidak ada satu kerentanan paling umum yang universal, tetapi kelemahan access control, reentrancy, manipulasi oracle, kesalahan logika, dan kesalahan upgradeability termasuk kategori yang paling penting.

Apakah audit menjamin smart contract aman?

Tidak, audit mengurangi risiko tetapi tidak dapat menjamin setiap kerentanan, kelemahan ekonomi, atau risiko upgrade di masa depan telah ditemukan.

Apa itu reentrancy dalam smart contract?

Reentrancy adalah kerentanan ketika external call memungkinkan kontrak lain memanggil kembali sebelum kontrak pertama memperbarui state-nya dengan aman.

Apa itu manipulasi oracle?

Manipulasi oracle terjadi ketika kontrak bergantung pada input harga atau data eksternal yang dapat didistorsi penyerang untuk memperoleh profit.

Apakah smart contract upgradeable aman?

Smart contract upgradeable dapat aman jika dirancang dan dikelola dengan cermat, tetapi menambah risiko terkait wewenang admin, storage layout, perubahan implementasi, dan kepercayaan pengguna.

Alat apa yang membantu keamanan smart contract?

Alat yang berguna mencakup unit test, fuzz test, invariant test, static analyzer, sistem verifikasi formal, alat pemantauan, blockchain explorer, dan checklist deployment.

Bagaimana pengguna dapat memeriksa keamanan smart contract?

Pengguna dapat memeriksa verifikasi kode sumber, audit, izin admin, upgradeability, approval token, desain oracle, dokumentasi protokol, dan alamat kontrak resmi.

Apakah keamanan smart contract dapat menghapus semua risiko?

Tidak, keamanan smart contract mengurangi risiko tetapi tidak dapat menghapus seluruh risiko teknis, ekonomi, operasional, governance, pasar, atau penandatanganan pengguna.

Kesimpulan

Keamanan Smart Contract adalah disiplin menyeluruh untuk melindungi kontrak blockchain dari bug teknis, desain tidak aman, data buruk, izin lemah, kegagalan upgrade, dan perilaku penyerang di dunia nyata.

Hal ini penting karena smart contract dapat menyimpan dan memindahkan aset kripto berharga dengan ruang yang sangat terbatas untuk pembalikan setelah terjadi kesalahan.

Keamanan yang kuat dimulai dari pemodelan ancaman dan berlanjut melalui coding aman, pengujian, fuzzing, verifikasi formal, audit, deployment aman, pemantauan, bug bounty, dan respons insiden.

Area risiko utama mencakup access control, reentrancy, manipulasi oracle, kesalahan logika bisnis, external call yang tidak diperiksa, kesalahan aritmetika, asumsi flash loan, randomisasi tidak aman, denial of service, dan upgradeability proxy.

Developer harus memperlakukan smart contract sebagai sistem berisiko tinggi dan menggunakan pertahanan berlapis, bukan mengandalkan satu alat atau satu audit.

Pengguna harus memahami bahwa kode terverifikasi, audit, dan popularitas adalah sinyal yang membantu, tetapi bukan jaminan keamanan.

Keamanan smart contract paling kuat ketika kode, governance, infrastruktur, interface pengguna, prompt wallet, pemantauan, dan rencana darurat bekerja bersama-sama.

Bagi pemula, Keamanan Smart Contract berarti membuat program blockchain lebih aman sebelum orang mempercayakannya dengan aset.

Bagi pengguna tingkat lanjut, ini adalah proses manajemen risiko berkelanjutan dalam desain protokol, implementasi, verifikasi, deployment, operasi, dan governance.

Dalam konteks glosarium kripto, Keamanan Smart Contract berarti metode dan kontrol yang digunakan untuk mencegah smart contract kehilangan dana, melanggar aturan, mengekspos pengguna, atau dieksploitasi secara on-chain.

Inti utamanya adalah keamanan smart contract tidak pernah menjadi checklist satu kali karena sistem kripto yang aman memerlukan peninjauan berkelanjutan, kontrol transparan, upgrade yang cermat, pemantauan aktif, dan perilaku pengguna yang berhati-hati.