Apa Itu Reentrancy Attack? Bug yang Menguras DeFi Protocol

Reentrancy attack adalah serangan di mana kontrak jahat memanggil kembali fungsi smart contract korban sebelum eksekusi pertama selesai — memungkinkan penarikan dana berulang dari saldo yang sama. Serangan ini bukan teori: pada Juni 2016, eksploitasi ini menguras 3,6 juta ETH (sekitar $60 juta) dari The DAO, memaksa komunitas Ethereum melakukan hard fork darurat dan melahirkan Ethereum Classic.

Bagaimana Reentrancy Attack Bekerja

Bayangkan ATM yang memeriksa saldo, mengeluarkan uang, lalu baru mencatat transaksi. Jika kamu bisa menekan tombol “tarik” berkali-kali sebelum catatan diperbarui, ATM akan terus mengeluarkan uang dari saldo yang belum berkurang. Itulah persis yang dilakukan reentrancy attack pada smart contract.

Urutan eksekusi yang rentan terlihat seperti ini:

1. Penyerang memanggil fungsi withdraw() di kontrak korban
2. Kontrak memeriksa saldo penyerang — misalnya 1 ETH
3. Kontrak mengirim 1 ETH ke alamat penyerang
4. Di sinilah masalahnya: kontrak penyerang memiliki fungsi receive() atau fallback() yang otomatis dipanggil saat menerima ETH
5. Fungsi tersebut langsung memanggil kembali withdraw() sebelum langkah update saldo dieksekusi
6. Kontrak korban memeriksa saldo lagi — masih tercatat 1 ETH karena belum diperbarui
7. Proses berulang sampai kontrak korban kehabisan dana

Dalam kasus The DAO 2016, penyerang berhasil mengulang siklus ini ribuan kali dalam satu transaksi tunggal sebelum siapapun menyadari ada yang salah.

Kode rentan terlihat sesederhana ini (dalam Solidity):

// RENTAN — jangan gunakan ini
function withdraw(uint amount) public {
    require(balances[msg.sender] >= amount);
    (bool success,) = msg.sender.call{value: amount}(""); // transfer dulu
    require(success);
    balances[msg.sender] -= amount; // baru update state — TERLAMBAT
}

Mengapa Bug Ini Sulit Dideteksi

Masalahnya bukan pada logika yang terlihat — setiap baris kode di atas tampak masuk akal secara individual. Bug ini muncul dari urutan operasi yang salah dikombinasi dengan cara Ethereum mengeksekusi panggilan eksternal.

Saat kontrak mengirim ETH ke alamat kontrak lain (bukan wallet biasa), Ethereum secara otomatis menjalankan kode di kontrak penerima. Ini adalah fitur yang sah — dipakai untuk berbagai keperluan. Tapi jika kode penerima memanggil balik kontrak pengirim, eksekusi “masuk kembali” (re-enter) ke fungsi yang belum selesai.

Ada dua varian utama:

Single-function reentrancy — penyerang memanggil kembali fungsi yang sama persis (kasus The DAO).

Cross-function reentrancy — penyerang memanggil fungsi berbeda yang berbagi state yang sama. Lebih sulit dideteksi karena audit biasanya memeriksa satu fungsi secara terpisah.

DeFi protocol dengan liquidity pool dan fitur penarikan dana menjadi target paling umum karena volume dana yang terkunci besar dan kompleksitas interaksi antar kontrak.

Cara Mencegah Reentrancy Attack

1. Pola Checks-Effects-Interactions (CEI)

Ini adalah solusi paling fundamental: selalu perbarui state sebelum melakukan transfer dana eksternal.

// AMAN — pola CEI yang benar
function withdraw(uint amount) public {
    require(balances[msg.sender] >= amount); // Check
    balances[msg.sender] -= amount;           // Effect — update dulu
    (bool success,) = msg.sender.call{value: amount}(""); // Interaction — baru transfer
    require(success);
}

Dengan urutan ini, bahkan jika penyerang memanggil kembali fungsi tersebut, saldo sudah tercatat nol dan serangan gagal.

2. ReentrancyGuard dari OpenZeppelin

Library standar industri ini menambahkan modifier nonReentrant yang memblokir panggilan rekursif secara eksplisit:

import "@openzeppelin/contracts/security/ReentrancyGuard.sol";

contract SafeVault is ReentrancyGuard {
    function withdraw(uint amount) public nonReentrant {
        // kode aman di sini
    }
}

3. Pull Payment Pattern

Alih-alih kontrak yang mengirim dana secara aktif, biarkan pengguna yang menarik dana mereka sendiri. Ini memisahkan logika akuntansi dari transfer, mengurangi permukaan serangan secara signifikan.

4. Audit dan Formal Verification

Protocol dengan TVL besar wajib menjalani multiple security audit dari firma seperti Trail of Bits, OpenZeppelin, atau Certik. Formal verification — membuktikan secara matematis bahwa kode berperilaku sesuai spesifikasi — menjadi standar baru untuk protocol tier-1.

Menurut data Chainalysis, total kerugian akibat eksploitasi smart contract (termasuk reentrancy) mencapai lebih dari $3,8 miliar sepanjang 2022 saja.

Perbandingan: Sebelum dan Sesudah Kesadaran Industri

Insiden The DAO 2016 mengubah standar industri secara permanen. Sebelumnya, reentrancy nyaris tidak dibahas dalam dokumentasi Solidity. Sesudahnya, pola CEI dan ReentrancyGuard menjadi persyaratan minimum di setiap audit.

Namun serangan serupa masih terjadi — Cream Finance kehilangan $130 juta pada 2021, dan beberapa protocol kecil masih menjadi korban setiap tahunnya. Alasannya: kode lama yang tidak di-upgrade, fork protokol tanpa audit ulang, dan kompleksitas interaksi lintas protokol yang menciptakan celah baru.

Bagi pengguna DeFi, cara paling praktis untuk mengurangi risiko adalah memeriksa apakah protocol yang digunakan sudah diaudit, memiliki bug bounty aktif, dan tidak memiliki riwayat eksploitasi. Dashboard seperti DeFiLlama menampilkan status audit untuk banyak protocol populer.

Kesimpulan

Reentrancy attack adalah pengingat bahwa smart contract tidak otomatis aman hanya karena berjalan di blockchain. Bug ini lahir dari urutan operasi yang salah — sesuatu yang tampak sepele tapi bisa menguras jutaan dolar dalam satu transaksi. Pola Checks-Effects-Interactions dan ReentrancyGuard adalah perlindungan minimum yang harus ada di setiap kontrak yang mengelola dana, dan audit independen bukan opsional bagi protocol yang serius.

💡 Mau belajar lebih dalam? Kelas WhaleX mengajarkan strategy dan eksekusi nyata, bukan hanya teori. Lihat kelas tersedia →