Apa Itu Kontrak Pintar?

Ethereum memiliki dua jenis akun umum: Akun Milik Eksternal (EOA) dan Akun Kontrak Pintar (SCA).

EOA sangat mirip dengan akun keuangan elektronik yang biasa kita gunakan untuk menyimpan dana dan berinteraksi dengan aplikasi. Misalnya, pengguna menyetor mata uang fiat melalui PayPal dan berinteraksi dengan berbagai situs web, toko, dan aplikasi untuk pembayaran. Penambang DeFi biasanya menyimpan kripto di EOA mereka, berinteraksi dengan dApps DeFi, dan menyetor dana ke dApps untuk mendapatkan keuntungan. Namun EOA memiliki fitur yang tidak dimiliki oleh akun keuangan elektronik: pengguna harus memiliki kontrol atas EOA yang diverifikasi melalui kepemilikan kunci pribadi— bukan kunci Anda, bukan koin Anda.

SCA juga merupakan jenis akun yang pada dasarnya terkait dengan segmen bytecode yang dapat dieksekusi (juga dikenal sebagai kontrak pintar). Kontrak pintar menggambarkan berbagai logika bisnis dan berfungsi sebagai backend untuk dApps. Namun, meskipun memiliki lebih banyak batasan dibandingkan dengan bahasa pengembangan Turing lengkap tradisional, kontrak pintar quasi-Turing lengkap masih rentan terhadap berbagai serangan, memberikan pukulan tak terhitung jumlahnya pada industri blockchain.

Serangan Kontrak Pintar yang Umum

1. Serangan Reentransi

Serangan yang paling umum dan terkenal adalah serangan reentransi, yang bertanggung jawab atas fork Ethereum yang menyebabkan terciptanya Ethereum Classic. Pada tahun 2016, peretas melakukan serangan reentransi pada kontrak The DAO, mencuri 3.600.000 ETH senilai lebih dari $150 juta pada saat itu. Serangan ini, yang terjadi pada tahap awal Ethereum, menghancurkan ekosistem dan mengguncang kepercayaan investor, yang akhirnya menyebabkan fork.

Logika Spesifik

Berikut adalah contoh untuk membantu Anda lebih memahami prinsip serangan reentransi. Bank B sebelumnya meminjamkan sejumlah uang kepada Bank A. Suatu hari, Bank B memulai transfer ke Bank A, meminta pengiriman semua uang kembali ke Bank B. Alur normalnya adalah sebagai berikut:

Langkah 1: Bank B meminta penarikan dana

Langkah 2: Bank A mentransfer dana ke Bank B

Langkah 3: Bank A mengkonfirmasi transfer yang berhasil ke Bank B

Langkah 4: Bank A memperbarui saldo rekening Bank B.

Namun, jika Bank B membuat celah setelah Langkah 2 dan terus meminta semua uang dari Bank A tanpa konfirmasi di Langkah 3, maka saldo rekening Bank A di Bank B akan tetap tidak berubah. Panggilan rekursif ini akan mengosongkan semua aset Bank A.

Kontrak Pintar Terkait

Kontrak Bank A mencakup dua fungsi:

deposit(): Fungsi setoran yang menyetor uang ke Bank A dan memperbarui saldo pengguna;
withdraw(): Fungsi penarikan yang memungkinkan pengguna menarik semua dana mereka dari Bank A.

Kontrak serangan Bank B terutama melibatkan loop yang memicu fungsi callback receive(), yang pada gilirannya memanggil fungsi withdraw() dari kontrak Bank untuk menguras aset Bank A melalui serangkaian 1 setoran, 1 penarikan, dan panggilan fungsi callback receive(), dan akhirnya memperbarui saldo B di A. Ini mencakup dua fungsi:receive(): Fungsi callback yang dipicu ketika ETH diterima, yang secara rekursif memanggil fungsi withdraw() dari kontrak Bank untuk melakukan penarikan.
attack(): Pertama-tama memanggil fungsi deposit() dari kontrak Bank untuk memperbarui saldo dan kemudian fungsi withdraw() untuk memulai penarikan pertama, dan memicu fungsi callback receive() untuk secara rekursif memanggil withdraw() untuk menguras aset kontrak Bank.

Solusi

Menerapkan kunci reentrancy

Kunci reentrancy adalah modifier yang digunakan untuk mencegah reentrancy, memastikan bahwa sebuah pemanggilan harus menyelesaikan eksekusinya sebelum dapat dipanggil kembali. Misalnya, karena serangan oleh Bank B memerlukan pemanggilan fungsi withdraw() dari kontrak Bank beberapa kali, hal ini akan gagal dengan penerapan kunci reentrancy.

Cara Menggunakannya

2. Penyalahgunaan tx.origin

Fungsi utama tx.origin dalam kontrak pintar adalah untuk mengambil akun asli yang memulai transaksi. Di sini, kita akan membahas dua variabel umum dalam kontrak pintar: msg.sender dan tx.origin. msg.sender mengambil akun yang langsung memanggil kontrak pintar, sementara dalam dunia blockchain, karena adanya panggilan bersarang dan saling memanggil antara kontrak pintar yang berbeda (seperti DeFi Lego), tx.origin diperlukan untuk mendapatkan akun asli yang memulai transaksi. Kerentanan muncul ketika pengembang dApp hanya memverifikasi keamanan tx.origin dalam kode, mengabaikan verifikasi keamanan penyerang yang menerapkan kontrak perantara untuk melewati tx.origin dan meluncurkan serangan.

Logika Spesifik

Berikut adalah contoh untuk memahami lebih dalam skenario serangan umum. Bill memiliki dompet pintar yang memverifikasi apakah Bill adalah pemrakarsa transfer. Suatu kali, Bill mencetak NFT di situs web phishing. Hal itu memungkinkan situs web tersebut memperoleh identitas Bill dan memulai transfer dari dompet pintarnya menggunakan identitasnya, mengakibatkan kerugian aset. Dalam keadaan normal, pengguna cenderung tidak terjebak dalam perangkap ini, tetapi ketika berinteraksi dengan dApp menggunakan dompet, mereka sering lupa memeriksa prompt interaksi. Misalnya, jika keduanya melibatkan fungsi Mint(), pengguna yang tidak berhati-hati dapat dengan mudah terjebak dalam perangkap phishing. Logika bisnis dalam situs web phishing penuh dengan jebakan, jadi penting untuk memeriksa prompt interaksi untuk kesalahan selama interaksi rutin.

Kontrak Dompet Pintar

Kontrak dompet pintar mencakup satu fungsi:

transfer(): Fungsi penarikan yang hanya dapat diprakarsai oleh pemilik dompet, yang dalam hal ini adalah Bill.

Kontrak Serangan Phishing

Dalam kontrak serangan phishing, Mint() membuat pengguna mentransfer dana ke alamat peretas. Kontrak ini mencakup satu fungsi:

Mint(): Saat dipanggil, fungsi phishing secara internal mengeksekusi transfer() dari kontrak Wallet. Karena pemrakarsa awal adalah pengguna itu sendiri (dalam contoh ini, Bill), verifikasi require(tx.origin == owner, "Not owner") tidak akan menjadi masalah. Namun, alamat tujuan untuk transfer telah diubah menjadi alamat peretas, mengakibatkan pencurian dana.

Solusi

1. Gunakan msg.sender daripada tx.origin

Tidak peduli berapa banyak pemanggilan kontrak yang terlibat (Kontrak A → Kontrak B →...→ kontrak target), hanya memverifikasi msg.sender, yaitu pemanggil langsung, untuk menghindari serangan yang disebabkan oleh kontrak perantara yang berbahaya.

2. Memeriksa tx.origin == msg.sender

Metode ini dapat menjauhkan kontrak berbahaya, tetapi pengembang perlu mempertimbangkan realitas bisnis mereka sendiri karena secara efektif mengisolasi semua pemanggilan kontrak eksternal lainnya.

3. Serangan Generator Angka Acak (RNG)

Ini kembali ke tren aplikasi terdesentralisasi (dApp) perjudian atau taruhan sekitar tahun 2018 dan 2019. Biasanya, pengembang menggunakan seed tertentu dalam kontrak pintar untuk menghasilkan angka acak guna memilih pemenang selama pengundian. Seed yang umum digunakan termasuk block.number, block.timestamp, blockhash, dan keccak256. Namun, penambang dapat sepenuhnya mengendalikan seed ini, sehingga dalam beberapa kasus, penambang jahat mungkin memanipulasi variabel-variabel tersebut untuk memperoleh keuntungan.

Kontrak Dadu Umum

Kontrak Dadu mencakup satu fungsi:

Bet(): Fungsi taruhan di mana pengguna memasukkan angka taruhan dan membayar ETH. Angka acak dihasilkan dengan beberapa seed, dan jika angka taruhan cocok dengan angka acak, pengguna memenangkan seluruh kumpulan hadiah.

Kontrak Serangan Penambang

Penambang dapat menang asalkan mereka menghitung terlebih dahulu angka acak pemenang dan mengeksekusinya dalam blok yang sama. Ini mencakup satu fungsi:

attack(): Fungsi serangan taruhan, di mana penambang menghitung terlebih dahulu angka acak pemenang. Karena dieksekusi dalam blok yang sama, blockhash(block.number - 1) dan block.timestamp dalam blok yang sama adalah sama. Kemudian penambang memanggil Bet() dari kontrak Dadu untuk menyelesaikan serangan.

Solusi

Menggunakan angka acak off-chain yang disediakan oleh proyek oracle

Melalui layanan yang disediakan oleh proyek oracle seperti Chainlink, angka acak on-chain dimasukkan ke dalam kontrak on-chain untuk memastikan keacakan dan keamanan. Namun, proyek oracle juga membawa risiko sentralisasi, sehingga memerlukan layanan oracle yang lebih matang.

4. Serangan Replay

Serangan replay melibatkan pengulangan transaksi menggunakan tanda tangan yang sebelumnya digunakan untuk mencuri dana. Salah satu serangan replay yang paling terkenal dalam beberapa tahun terakhir adalah pencurian 20 juta token $OP dari pembuat pasar Wintermute di Optimism, yang merupakan serangan replay lintas rantai. Karena akun dompet multi-tanda tangan Wintermute hanya sementara dikerahkan di jaringan utama Ethereum, peretas menggunakan tanda tangan transaksi untuk pengerahan alamat multi-tanda tangan Wintermute di Ethereum untuk mengeksekusi kembali transaksi yang sama di rantai Optimism, sehingga mendapatkan kendali atas akun dompet multi-tanda tangan di Optimism. Akun dompet multi-tanda tangan pada dasarnya adalah akun kontrak pintar, yang juga menunjukkan perbedaan signifikan antara SCA dan EOA. Untuk EOA, pengguna normal hanya membutuhkan satu kunci pribadi untuk mengendalikan semua alamat di Ethereum dan rantai yang kompatibel dengan EVM (string alamatnya persis sama), sementara SCA hanya efektif pada satu rantai setelah dikerahkan.

Logika Spesifik

Di sini, kami memberikan contoh serangan replay tipikal (serangan replay rantai yang sama). Bill memiliki dompet pintar yang mengharuskannya memasukkan tanda tangan elektroniknya sebelum setiap transaksi dapat dieksekusi. Sekarang peretas Lucy telah mencuri tanda tangan elektronik Bill, dia dapat memulai transaksi tanpa batas untuk menguras dompet pintar Bill.

Contoh

Kontrak dengan kerentanan terdiri dari tiga fungsi:

checkSig(): Fungsi verifikasi ECDSA, memastikan bahwa hasil verifikasi adalah penandatangan yang awalnya ditetapkan.
getMsgHash(): Fungsi untuk menghasilkan hash, yang menggabungkan to dan amount untuk membentuk hash.
transfer(): Fungsi transfer, memungkinkan pengguna untuk menarik dana dari pool likuiditas. Karena kurangnya pembatasan pada tanda tangan, tanda tangan yang sama dapat digunakan kembali, memungkinkan peretas untuk terus mencuri dana.

Solusi

Sertakan nonce dalam kombinasi tanda tangan untuk mencegah serangan replay. Prinsip parameter tersebut adalah sebagai berikut:

nonce: Ini menggambarkan variabel jumlah transaksi EOA dalam jaringan blockchain. Ini memiliki urutan dan keunikan. Dengan setiap transaksi tambahan, nilai nonce akan meningkat sebesar 1. Jaringan blockchain akan memeriksa apakah nonce dari transaksi konsisten dengan nonce saat ini dari akun. Oleh karena itu, seorang peretas akan gagal jika dia menggunakan tanda tangan yang sudah digunakan karena nilai nonce dalam kombinasi tanda tangan kurang dari nilai nonce saat ini dari EOA.

5. Serangan Penolakan Layanan (DoS)

Serangan Penolakan Layanan (DoS) bukanlah hal baru dalam dunia Web2 tradisional. Ini mengacu pada gangguan terhadap server, seperti mengirim sejumlah besar informasi sampah atau mengganggu, yang menghambat atau benar-benar menghancurkan ketersediaan. Demikian pula, kontrak pintar juga dilanda oleh serangan semacam itu, yang pada dasarnya bertujuan untuk membuat kontrak pintar tidak berfungsi.

Logika Spesifik

Mari kita lihat sebuah contoh. Proyek A sedang melakukan penawaran publik untuk token protokol, di mana semua pengguna dapat menyumbangkan dana ke pool likuiditas (Kontrak Pintar) untuk membeli kuota berdasarkan prinsip siapa cepat dia dapat, dan dana yang berlebih akan dikembalikan kepada peserta. Peretas Alice memanfaatkan kontrak serangan untuk berpartisipasi dalam penawaran publik. Begitu pool likuiditas mencoba mengembalikan dana ke kontrak serangan Alice, serangan DoS akan dipicu, mencegah tindakan pengembalian itu terealisasi. Akibatnya, sejumlah besar dana terkunci dalam kontrak pintar.

Contoh Kontrak Penawaran Umum

Contoh

Kontrak penawaran umum mencakup dua fungsi:

deposit(): fungsi deposit, mencatat alamat penyetor dan jumlah yang dikontribusikan.
refund(): fungsi pengembalian dana, di mana tim proyek mengembalikan dana kepada investor.

Kontrak Serangan DoS

Kontrak serangan DoS mencakup satu fungsi:

attack(): Meskipun merupakan fungsi serangan, tidak ada masalah apapun. Masalah utama terletak pada fungsi callback pembayaran receive() yang tertanam dalam kontrak Hacker, yang mencakup penilaian pengecualian. Setiap kontrak eksternal yang mentransfer dana ke kontrak Hacker akan memicu pengecualian melalui revert(), sehingga mencegah operasi selesai.

Solusi

1. Hindari fungsionalitas kritis terhenti saat memanggil kontrak eksternal

Menghapus require(success, "Refund Fail!"); dari fungsi refund() kontrak PublicSale di atas, memastikan bahwa operasi pengembalian dana dapat dilanjutkan bahkan jika pengembalian dana ke satu alamat gagal.

2. Penguraian

Dalam fungsi refund() kontrak PublicSale di atas, izinkan pengguna untuk mengklaim pengembalian dana sendiri daripada mendistribusikan pengembalian dana, sehingga meminimalkan interaksi yang tidak perlu dengan kontrak eksternal.

6. Serangan permit

Dalam serangan izin, Akun A menyediakan tanda tangan untuk pihak tertentu terlebih dahulu, dan kemudian Akun B, setelah memperoleh tanda tangan tersebut, dapat melakukan transfer token yang diotorisasi untuk mencuri sejumlah token tertentu. Di sini, kita terutama membahas dua fungsi umum untuk otorisasi token dalam Kontrak Pintar: approve() dan permit().

Dalam kontrak ERC20 yang umum, Akun A dapat memanggil approve() untuk mengotorisasi sejumlah token tertentu untuk Akun B, memungkinkan yang terakhir untuk mentransfer token tersebut dari yang pertama. Selain itu, permit() diperkenalkan ke dalam kontrak ERC20 dalam EIP-2612, dan Uniswap telah merilis standar otorisasi token baru, Permit2, pada November 2022.

Logika Spesifik

Berikut adalah contohnya. Suatu hari, Bill sedang menjelajahi situs web berita blockchain ketika tiba-tiba muncul pop-up tanda tangan Metamask. Karena banyak situs web atau aplikasi blockchain menggunakan tanda tangan untuk memverifikasi login pengguna, Bill tidak terlalu memikirkannya dan langsung menyelesaikan tanda tangan tersebut. Lima menit kemudian, aset Metamask-nya habis. Bill kemudian menemukan di penjelajah blockchain bahwa sebuah alamat yang tidak dikenal memulai transaksi permit(), diikuti oleh transaksi transferFrom() yang mengosongkan dompetnya.

Contoh

Kedua fungsi tersebut adalah sebagai berikut:

approve(): Fungsi otorisasi standar di mana Akun A mengotorisasi sejumlah dana tertentu kepada Akun B.
permit(): Fungsi otorisasi tanda tangan di mana Akun B mengirimkan dan menyelesaikan verifikasi tanda tangan untuk memperoleh jumlah yang diotorisasi dari Akun A. Parameter termasuk pemilik yang memberikan otorisasi, pengguna yang diotorisasi, jumlah yang diotorisasi, batas waktu tanda tangan, dan data tanda tangan pemilik v, r, dan s.

Solusi

1. Perhatikan setiap tanda tangan dalam interaksi on-chain

Meskipun beberapa dompet mengambil langkah-langkah untuk mendekode dan menampilkan informasi tanda tangan otorisasi approve(), mereka hampir tidak memberikan peringatan untuk phishing tanda tangan permit(), sehingga meningkatkan risiko serangan. Oleh karena itu, sangat disarankan untuk memeriksa setiap tanda tangan yang tidak dikenal secara teliti untuk memastikan apakah itu ditujukan untuk fungsi permit().

2. Pisahkan dompet untuk interaksi rutin dari dompet penyimpanan aset

Hal ini sangat penting bagi pengguna kripto, terutama pemburu airdrop, karena mereka berinteraksi dengan tak terhitung banyaknya dApps atau situs web setiap hari dan rentan terhadap jebakan. Menyimpan hanya sejumlah kecil dana dalam dompet untuk interaksi rutin dapat membatasi kerugian dalam rentang yang dapat dikelola.

7. Serangan Honeypot

Dalam industri blockchain, serangan honeypot mengacu pada jenis kontrak token berbahaya yang digunakan oleh tim proyek. Kontrak tersebut hanya memberikan izin kepada tim proyek untuk menjual, sementara pengguna biasa hanya dapat membeli namun tidak dapat menjual, sehingga mengalami kerugian.

Logika Spesifik

Berikut adalah contohnya. Dalam sebuah pengumuman di Telegram, Proyek A menginformasikan kepada pengguna bahwa token telah digunakan pada jaringan utama dan tersedia untuk perdagangan. Karena token hanya dapat dibeli dan tidak dapat dijual, harganya terus melonjak pada awalnya, dan pengguna yang takut ketinggalan terus membeli. Setelah beberapa waktu ketika pengguna menyadari tidak dapat menjual, tim proyek memanfaatkan kesempatan tersebut dan membuang token, menyebabkan harga anjlok.

Contoh

Fungsi inti:

_beforeTokenTransfer(): Fungsi internal yang dipanggil selama transfer token, yang hanya dapat berhasil ketika dipanggil oleh pemilik; panggilan dari akun lain akan gagal.

Solusi

Gunakan alat pemindaian keamanan

a. Token Sniffer untuk token Ethereum

b. Ave Check untuk token di rantai lain

c. Situs web market dengan alat deteksi bawaan seperti Dextools

Hindari perdagangan token dengan skor rendah.

8. Serangan Front-Running

Front-running awalnya muncul di pasar keuangan tradisional, di mana asimetri informasi memungkinkan perantara keuangan memperoleh keuntungan dengan mengambil tindakan cepat berdasarkan informasi industri tertentu. Dalam industri blockchain, front-running terutama berasal dari front-running on-chain, yang melibatkan manipulasi penambang untuk memprioritaskan pengemasan transaksi mereka sendiri ke dalam rantai untuk mendapatkan keuntungan.

Di bidang blockchain, penambang dapat memperoleh keuntungan dengan memanipulasi transaksi yang mereka kemas ke dalam blok, misalnya mengecualikan transaksi tertentu dan mengurutkan ulang transaksi. Keuntungan semacam itu dapat diukur dengan Miner Extractable Value (MEV). Sebelum transaksi pengguna ditambahkan ke jaringan utama Ethereum, mayoritas transaksi dikumpulkan dalam mempool. Penambang mencari transaksi dengan harga gas yang lebih tinggi di mempool ini dan memprioritaskan pengemasannya untuk memaksimalkan keuntungan mereka. Umumnya, transaksi dengan harga gas yang lebih tinggi lebih mudah dikemas oleh penambang. Sementara itu, beberapa bot MEV juga menjelajahi mempool untuk mencari transaksi yang menguntungkan.

Logika Spesifik

Berikut adalah contohnya. Bill menemukan token baru yang populer dengan fluktuasi harga yang signifikan. Untuk memastikan keberhasilan transaksi token di Uniswap, Bill menetapkan rentang slippage yang sangat lebar. Sayangnya, bot MEV Alice mendeteksi transaksi ini di mempool dan segera meningkatkan biaya gas, memulai transaksi pembelian sebelum transaksi Bill dan menyisipkan transaksi penjualan setelah transaksi Bill dalam blok yang sama. Setelah konfirmasi blok, hal ini menyebabkan kerugian slippage yang signifikan bagi Bill, sementara Alice mendapatkan keuntungan dari operasi arbitrase dengan membeli murah dan menjual mahal.

Contoh

Fungsinya adalah sebagai berikut:

solve(): Sebuah fungsi tebakan di mana siapa pun dapat mengirimkan jawaban, dan jika jawaban yang dikirimkan cocok dengan jawaban target, pengirim dapat menerima 10 ether.

Proses: Bill menemukan jawaban yang benar.
Alice memantau mempool, menunggu seseorang mengirimkan jawaban yang benar.
Bill memanggil solve() untuk mengirimkan jawaban dan menetapkan harga gas menjadi 100 Gwei.
Alice melihat transaksi yang dikirim oleh Bill dan menemukan jawabannya. Dia menetapkan harga gas yang lebih tinggi dari Bill yaitu 200 Gwei dan memanggil solve().
Transaksi Alice dikemas oleh penambang sebelum transaksi Bill.
Alice memenangkan hadiah sebesar 10 ether.

Solusi

Tiga fungsi utama adalah sebagai berikut:

commitSolution(): Sebuah fungsi untuk mengirimkan hasil, menempatkan jawaban yang diajukan pengguna solutionHash, waktu pengiriman commitTime, dan status revealed ke dalam struktur Commit.
getMySolution(): Sebuah fungsi untuk mendapatkan hasil, memungkinkan pengguna untuk melihat jawaban yang mereka kirimkan dan informasi terkait, termasuk jawaban yang diajukan pengguna solutionHash, waktu pengiriman commitTime, dan status revealed.
revealSolution(): Sebuah fungsi untuk mengklaim hadiah atas tebakan teka-teki, memungkinkan pengguna untuk mengklaim hadiah setelah memberikan jawaban dan kata sandi yang mereka tetapkan.

Proses:

Bill menemukan jawaban yang benar.
Bill memanggil commitSolution() untuk mengirimkan jawaban yang benar.
Pada blok selanjutnya, Bill memanggil revealSolution(), memberikan jawaban dan kata sandi yang telah dia tetapkan untuk mengklaim hadiah.

Dalam commitSolution(), Bill mengirimkan string terenkripsi, menyimpan data teks biasa yang dikirimkan hanya untuk dirinya sendiri. Pada langkah ini, waktu blok pengiriman commitTime juga dicatat. Selanjutnya, dalam revealSolution(), waktu blok diperiksa untuk mencegah front-running dalam blok yang sama. Karena memanggil revealSolution() memerlukan pengiriman jawaban teks biasa, langkah ini bertujuan untuk mencegah orang lain melewati commitSolution() dan langsung memanggil revealSolution(). Setelah verifikasi berhasil, hadiah akan didistribusikan jika jawaban diperiksa benar.

Kesimpulan

Kontrak pintar memainkan peran penting dalam teknologi blockchain dan menawarkan banyak keuntungan. Pertama, mereka memungkinkan eksekusi terdesentralisasi dan otomatis, memastikan keamanan dan keandalan transaksi tanpa pihak ketiga. Kedua, kontrak pintar mengurangi langkah-langkah perantara dan biaya, meningkatkan efisiensi transaksi.

Meskipun memiliki begitu banyak manfaat, kontrak pintar juga menghadapi risiko serangan yang dapat menimbulkan kerugian finansial bagi pengguna. Oleh karena itu, beberapa kebiasaan sangat penting bagi pengguna on-chain. Pertama, pengguna harus selalu memilih dApp dengan hati-hati untuk berinteraksi dan meninjau kode kontrak serta aturan terkait secara menyeluruh. Selain itu, mereka harus secara teratur memperbarui dan menggunakan dompet dan alat interaksi kontrak yang aman untuk mengurangi risiko serangan peretas. Lebih lanjut, disarankan untuk menyimpan dana mereka di beberapa alamat untuk meminimalkan potensi kerugian dari serangan kontrak.

Bagi para pelaku industri, memastikan keamanan dan stabilitas kontrak pintar sama pentingnya. Prioritas utama harus memperkuat audit kontrak pintar untuk mengidentifikasi dan memperbaiki potensi kerentanan dan risiko keamanan. Kedua, pelaku industri harus selalu mengikuti perkembangan terbaru blockchain terkait serangan kontrak dan mengambil tindakan keamanan yang sesuai. Terakhir namun tidak kalah penting, mereka juga harus meningkatkan edukasi pengguna dan kesadaran keamanan dalam hal penggunaan kontrak pintar yang benar.

Kesimpulannya, dengan upaya bersama dari pengguna dan pelaku industri, risiko keamanan yang ditimbulkan oleh kontrak pintar dapat dikurangi secara signifikan. Pengguna harus selalu memilih kontrak dengan hati-hati dan melindungi aset pribadi, sementara pelaku industri harus meningkatkan audit kontrak, mengikuti perkembangan teknologi, dan meningkatkan edukasi pengguna serta kesadaran keamanan. Bersama-sama, kita akan mendorong perkembangan kontrak pintar yang aman dan dapat diandalkan.

Referensi:

Solidity by Example：https://solidity-by-example.org/

Blockchain Know-how of SlowMist：https://mp.weixin.qq.com/mp/appmsgalbum?__biz=MzU4ODQ3NTM2OA==&action=getalbum&album_id=1378673890158936067&scene=173&from_msgid=2247498135&from_itemidx=1&count=3&nolastread=1#wechat_redirect

Chainlink - Top 10 DeFi Security Best Practices：https://blog.chain.link/defi-security-best-practices/#post-title

WTF - Solidity 104 Contract Security：https://www.wtf.academy/solidity-104/

Vulnerabilities in DeFi Smart Contracts in 4 Categories with 38 Scenarios：https://www.weiyangx.com/381670.html

OpenZeppelin：https://github.com/OpenZeppelin/

KGeN (KGEN): Сеть Web3 Гейминга и DeFi 2025