Lompat ke konten utama
Change page

Menguji kontrak pintar

Pembaruan terakhir halaman: 26 Februari 2026

fuji.anggara10f (opens in a new tab)
roifnaufal21r (opens in a new tab)
Ediii_idE (opens in a new tab)
+28

Blockchain publik seperti Ethereum bersifat tetap (immutable), sehingga sulit untuk mengubah kode kontrak pintar setelah penerapan. Pola peningkatan kontrak untuk melakukan "peningkatan virtual" memang ada, tetapi ini sulit diimplementasikan dan memerlukan konsensus sosial. Selain itu, peningkatan hanya dapat memperbaiki kesalahan setelah ditemukan—jika penyerang menemukan kerentanan tersebut lebih dulu, kontrak pintar Anda berisiko dieksploitasi.

Karena alasan ini, menguji kontrak pintar sebelum menerapkannya ke Mainnet adalah persyaratan minimum untuk keamanan. Ada banyak teknik untuk menguji kontrak dan mengevaluasi kebenaran kode; apa yang Anda pilih bergantung pada kebutuhan Anda. Namun demikian, rangkaian pengujian yang terdiri dari berbagai alat dan pendekatan sangat ideal untuk menangkap kelemahan keamanan kecil maupun besar dalam kode kontrak.

Prasyarat

Halaman ini menjelaskan cara menguji kontrak pintar sebelum menerapkannya di jaringan Ethereum. Halaman ini mengasumsikan Anda sudah familier dengan kontrak pintar.

Apa itu pengujian kontrak pintar?

Pengujian kontrak pintar adalah proses memverifikasi bahwa kode kontrak pintar berfungsi seperti yang diharapkan. Pengujian berguna untuk memeriksa apakah kontrak pintar tertentu memenuhi persyaratan keandalan, kegunaan, dan keamanan.

Meskipun pendekatannya bervariasi, sebagian besar metode pengujian memerlukan eksekusi kontrak pintar dengan sampel kecil dari data yang diharapkan untuk ditangani. Jika kontrak menghasilkan hasil yang benar untuk data sampel, kontrak tersebut diasumsikan berfungsi dengan baik. Sebagian besar alat pengujian menyediakan sumber daya untuk menulis dan mengeksekusi kasus uji (opens in a new tab) guna memeriksa apakah eksekusi kontrak sesuai dengan hasil yang diharapkan.

Mengapa penting untuk menguji kontrak pintar?

Karena kontrak pintar sering kali mengelola aset keuangan bernilai tinggi, kesalahan pemrograman kecil dapat dan sering kali menyebabkan kerugian besar bagi pengguna (opens in a new tab). Namun, pengujian yang ketat dapat membantu Anda menemukan cacat dan masalah dalam kode kontrak pintar lebih awal dan memperbaikinya sebelum diluncurkan di Mainnet.

Meskipun memungkinkan untuk meningkatkan kontrak jika bug ditemukan, peningkatan tersebut rumit dan dapat mengakibatkan kesalahan (opens in a new tab) jika ditangani dengan tidak tepat. Meningkatkan kontrak lebih lanjut meniadakan prinsip sifat tetap (immutability) dan membebani pengguna dengan asumsi kepercayaan tambahan. Sebaliknya, rencana komprehensif untuk menguji kontrak Anda memitigasi risiko keamanan kontrak pintar dan mengurangi kebutuhan untuk melakukan peningkatan logika yang rumit setelah penerapan.

Metode untuk menguji kontrak pintar

Metode untuk menguji kontrak pintar Ethereum terbagi dalam dua kategori besar: pengujian otomatis dan pengujian manual. Pengujian otomatis dan pengujian manual menawarkan manfaat dan pengorbanan (tradeoff) yang unik, tetapi Anda dapat menggabungkan keduanya untuk membuat rencana yang kuat dalam menganalisis kontrak Anda.

Pengujian otomatis

Pengujian otomatis menggunakan alat yang secara otomatis memeriksa kode kontrak pintar untuk mencari kesalahan dalam eksekusi. Manfaat pengujian otomatis berasal dari penggunaan skrip (opens in a new tab) untuk memandu evaluasi fungsionalitas kontrak. Pengujian berskrip dapat dijadwalkan untuk berjalan berulang kali dengan intervensi manusia yang minimal, sehingga pengujian otomatis lebih efisien daripada pendekatan pengujian manual.

Pengujian otomatis sangat berguna ketika pengujian bersifat repetitif dan memakan waktu; sulit dilakukan secara manual; rentan terhadap kesalahan manusia; atau melibatkan evaluasi fungsi kontrak yang kritis. Namun, alat pengujian otomatis dapat memiliki kelemahan—alat tersebut mungkin melewatkan bug tertentu dan menghasilkan banyak positif palsu (opens in a new tab). Oleh karena itu, memasangkan pengujian otomatis dengan pengujian manual untuk kontrak pintar adalah hal yang ideal.

Pengujian manual

Pengujian manual dibantu oleh manusia dan melibatkan eksekusi setiap kasus uji dalam rangkaian pengujian Anda satu per satu saat menganalisis kebenaran kontrak pintar. Hal ini berbeda dengan pengujian otomatis di mana Anda dapat secara bersamaan menjalankan beberapa pengujian terisolasi pada sebuah kontrak dan mendapatkan laporan yang menunjukkan semua pengujian yang gagal dan berhasil.

Pengujian manual dapat dilakukan oleh satu individu dengan mengikuti rencana pengujian tertulis yang mencakup berbagai skenario pengujian. Anda juga dapat meminta beberapa individu atau kelompok berinteraksi dengan kontrak pintar selama periode tertentu sebagai bagian dari pengujian manual. Penguji akan membandingkan perilaku aktual kontrak dengan perilaku yang diharapkan, dan menandai setiap perbedaan sebagai bug.

Pengujian manual yang efektif memerlukan sumber daya yang cukup besar (keterampilan, waktu, uang, dan tenaga), dan ada kemungkinan—karena kesalahan manusia—untuk melewatkan kesalahan tertentu saat mengeksekusi pengujian. Namun, pengujian manual juga dapat bermanfaat—misalnya, penguji manusia (misalnya, auditor) dapat menggunakan intuisi untuk mendeteksi kasus ekstrem (edge cases) yang mungkin terlewatkan oleh alat pengujian otomatis.

Pengujian otomatis untuk kontrak pintar

Pengujian unit

Pengujian unit mengevaluasi fungsi kontrak secara terpisah dan memeriksa bahwa setiap komponen berfungsi dengan benar. Pengujian unit yang baik harus sederhana, cepat dijalankan, dan memberikan gambaran yang jelas tentang apa yang salah jika pengujian gagal.

Pengujian unit berguna untuk memeriksa bahwa fungsi mengembalikan nilai yang diharapkan dan bahwa penyimpanan kontrak diperbarui dengan benar setelah eksekusi fungsi. Selain itu, menjalankan pengujian unit setelah membuat perubahan pada basis kode kontrak memastikan penambahan logika baru tidak menimbulkan kesalahan. Di bawah ini adalah beberapa panduan untuk menjalankan pengujian unit yang efektif:

Panduan untuk pengujian unit kontrak pintar

1. Pahami logika bisnis dan alur kerja kontrak Anda

Sebelum menulis pengujian unit, ada baiknya untuk mengetahui fungsionalitas apa yang ditawarkan kontrak pintar dan bagaimana pengguna akan mengakses serta menggunakan fungsi-fungsi tersebut. Hal ini sangat berguna untuk menjalankan pengujian jalur bahagia (happy path tests) (opens in a new tab) yang menentukan apakah fungsi dalam kontrak mengembalikan keluaran yang benar untuk masukan pengguna yang valid. Kami akan menjelaskan konsep ini menggunakan contoh (yang diringkas) dari kontrak lelang (opens in a new tab) ini

1constructor(
2        uint biddingTime,
3        address payable beneficiaryAddress
4    ) {
5        beneficiary = beneficiaryAddress;
6        auctionEndTime = block.timestamp + biddingTime;
7    }
8
9function bid() external payable {
10
11      if (block.timestamp > auctionEndTime)
12            revert AuctionAlreadyEnded();
13
14      if (msg.value <= highestBid)
15            revert BidNotHighEnough(highestBid);
16
17 if (highestBid != 0) {
18    pendingReturns[highestBidder] += highestBid;
19        }
20        highestBidder = msg.sender;
21        highestBid = msg.value;
22        emit HighestBidIncreased(msg.sender, msg.value);
23    }
24
25 function withdraw() external returns (bool) {
26        uint amount = pendingReturns[msg.sender];
27        if (amount > 0) {
28           pendingReturns[msg.sender] = 0;
29
30        if (!payable(msg.sender).send(amount)) {
31                pendingReturns[msg.sender] = amount;
32                return false;
33            }
34        }
35        return true;
36    }
37
38function auctionEnd() external {
39       if (block.timestamp < auctionEndTime)
40            revert AuctionNotYetEnded();
41        if (ended)
42            revert AuctionEndAlreadyCalled();
43
44        ended = true;
45        emit AuctionEnded(highestBidder, highestBid);
46
47        beneficiary.transfer(highestBid);
48    }
49}
Tampilkan semua

Ini adalah kontrak lelang sederhana yang dirancang untuk menerima tawaran selama periode penawaran. Jika highestBid meningkat, penawar tertinggi sebelumnya menerima uang mereka kembali; setelah periode penawaran berakhir, beneficiary memanggil kontrak untuk mendapatkan uang mereka.

Pengujian unit untuk kontrak seperti ini akan mencakup berbagai fungsi yang mungkin dipanggil pengguna saat berinteraksi dengan kontrak. Contohnya adalah pengujian unit yang memeriksa apakah pengguna dapat mengajukan tawaran saat lelang sedang berlangsung (yaitu, panggilan ke bid() berhasil) atau pengujian yang memeriksa apakah pengguna dapat mengajukan tawaran yang lebih tinggi dari highestBid saat ini.

Memahami alur kerja operasional kontrak juga membantu dalam menulis pengujian unit yang memeriksa apakah eksekusi memenuhi persyaratan. Misalnya, kontrak lelang menetapkan bahwa pengguna tidak dapat mengajukan tawaran saat lelang telah berakhir (yaitu, ketika auctionEndTime lebih rendah dari block.timestamp). Dengan demikian, pengembang mungkin menjalankan pengujian unit yang memeriksa apakah panggilan ke fungsi bid() berhasil atau gagal saat lelang selesai (yaitu, ketika auctionEndTime > block.timestamp).

2. Evaluasi semua asumsi yang terkait dengan eksekusi kontrak

Penting untuk mendokumentasikan setiap asumsi tentang eksekusi kontrak dan menulis pengujian unit untuk memverifikasi validitas asumsi tersebut. Selain menawarkan perlindungan terhadap eksekusi yang tidak terduga, menguji asersi memaksa Anda untuk memikirkan operasi yang dapat merusak model keamanan kontrak pintar. Tip yang berguna adalah melampaui "pengujian pengguna bahagia" dan menulis pengujian negatif yang memeriksa apakah suatu fungsi gagal untuk masukan yang salah.

Banyak kerangka kerja pengujian unit memungkinkan Anda membuat asersi—pernyataan sederhana yang menyatakan apa yang dapat dan tidak dapat dilakukan oleh kontrak—dan menjalankan pengujian untuk melihat apakah asersi tersebut berlaku di bawah eksekusi. Pengembang yang mengerjakan kontrak lelang yang dijelaskan sebelumnya dapat membuat asersi berikut tentang perilakunya sebelum menjalankan pengujian negatif:

  • Pengguna tidak dapat mengajukan tawaran saat lelang telah berakhir atau belum dimulai.

  • Kontrak lelang dikembalikan (revert) jika tawaran berada di bawah ambang batas yang dapat diterima.

  • Pengguna yang gagal memenangkan tawaran akan dikreditkan kembali dengan dana mereka

Catatan: Cara lain untuk menguji asumsi adalah dengan menulis pengujian yang memicu pengubah fungsi (function modifiers) (opens in a new tab) dalam kontrak, terutama pernyataan require, assert, dan if…else.

3. Ukur cakupan kode

Cakupan kode (Code coverage) (opens in a new tab) adalah metrik pengujian yang melacak jumlah cabang, baris, dan pernyataan dalam kode Anda yang dieksekusi selama pengujian. Pengujian harus memiliki cakupan kode yang baik untuk meminimalkan risiko kerentanan yang tidak teruji. Tanpa cakupan yang memadai, Anda mungkin salah berasumsi bahwa kontrak Anda aman karena semua pengujian berhasil, padahal kerentanan masih ada di jalur kode yang tidak teruji. Namun, mencatat cakupan kode yang tinggi memberikan jaminan bahwa semua pernyataan/fungsi dalam kontrak pintar telah diuji kebenarannya secara memadai.

4. Gunakan kerangka kerja pengujian yang dikembangkan dengan baik

Kualitas alat yang digunakan dalam menjalankan pengujian unit untuk kontrak pintar Anda sangat penting. Kerangka kerja pengujian yang ideal adalah yang dipelihara secara teratur; menyediakan fitur yang berguna (misalnya, kemampuan pencatatan dan pelaporan); dan harus telah digunakan secara luas serta diperiksa oleh pengembang lain.

Kerangka kerja pengujian unit untuk kontrak pintar Solidity hadir dalam berbagai bahasa (sebagian besar JavaScript, Python, dan Rust). Lihat beberapa panduan di bawah ini untuk informasi tentang cara mulai menjalankan pengujian unit dengan berbagai kerangka kerja pengujian:

Pengujian integrasi

Sementara pengujian unit men-debug fungsi kontrak secara terisolasi, pengujian integrasi mengevaluasi komponen kontrak pintar secara keseluruhan. Pengujian integrasi dapat mendeteksi masalah yang timbul dari panggilan lintas kontrak atau interaksi antara berbagai fungsi dalam kontrak pintar yang sama. Misalnya, pengujian integrasi dapat membantu memeriksa apakah hal-hal seperti pewarisan (inheritance) (opens in a new tab) dan injeksi dependensi berfungsi dengan baik.

Pengujian integrasi berguna jika kontrak Anda mengadopsi arsitektur modular atau antarmuka dengan kontrak onchain lainnya selama eksekusi. Salah satu cara menjalankan pengujian integrasi adalah dengan melakukan pada ketinggian tertentu (menggunakan alat seperti Forge (opens in a new tab) atau Hardhat (opens in a new tab) dan menyimulasikan interaksi antara kontrak Anda dan kontrak yang diterapkan.

Blockchain yang di-fork akan berperilaku mirip dengan Mainnet dan memiliki akun dengan status dan saldo terkait. Namun, ini hanya bertindak sebagai lingkungan pengembangan lokal yang di-sandbox, yang berarti Anda tidak akan memerlukan ETH nyata untuk transaksi, misalnya, dan perubahan Anda tidak akan memengaruhi protokol Ethereum yang sebenarnya.

Pengujian berbasis properti

Pengujian berbasis properti adalah proses memeriksa bahwa kontrak pintar memenuhi beberapa properti yang ditentukan. Properti menegaskan fakta tentang perilaku kontrak yang diharapkan tetap benar dalam berbagai skenario—contoh properti kontrak pintar bisa berupa "Operasi aritmatika dalam kontrak tidak pernah mengalami overflow atau underflow."

Analisis statis dan analisis dinamis adalah dua teknik umum untuk mengeksekusi pengujian berbasis properti, dan keduanya dapat memverifikasi bahwa kode untuk suatu program (kontrak pintar dalam hal ini) memenuhi beberapa properti yang telah ditentukan sebelumnya. Beberapa alat pengujian berbasis properti dilengkapi dengan aturan yang telah ditentukan sebelumnya tentang properti kontrak yang diharapkan dan memeriksa kode terhadap aturan tersebut, sementara yang lain memungkinkan Anda membuat properti kustom untuk kontrak pintar.

Analisis statis

Penganalisis statis mengambil kode sumber kontrak pintar sebagai masukan dan mengeluarkan hasil yang menyatakan apakah kontrak memenuhi suatu properti atau tidak. Tidak seperti analisis dinamis, analisis statis tidak melibatkan eksekusi kontrak untuk menganalisis kebenarannya. Analisis statis sebaliknya menalar tentang semua kemungkinan jalur yang dapat diambil oleh kontrak pintar selama eksekusi (yaitu, dengan memeriksa struktur kode sumber untuk menentukan apa artinya bagi operasi kontrak saat runtime).

Linting (opens in a new tab) dan pengujian statis (opens in a new tab) adalah metode umum untuk menjalankan analisis statis pada kontrak. Keduanya memerlukan analisis representasi tingkat rendah dari eksekusi kontrak seperti pohon sintaksis abstrak (abstract syntax trees) (opens in a new tab) dan grafik aliran kontrol (control flow graphs) (opens in a new tab) yang dihasilkan oleh kompiler.

Dalam kebanyakan kasus, analisis statis berguna untuk mendeteksi masalah keamanan seperti penggunaan konstruksi yang tidak aman, kesalahan sintaksis, atau pelanggaran standar pengkodean dalam kode kontrak. Namun, penganalisis statis diketahui umumnya tidak kuat dalam mendeteksi kerentanan yang lebih dalam, dan dapat menghasilkan positif palsu yang berlebihan.

Analisis dinamis

Analisis dinamis menghasilkan masukan simbolis (misalnya, dalam eksekusi simbolis (opens in a new tab)) atau masukan konkret (misalnya, dalam fuzzing (opens in a new tab)) ke fungsi kontrak pintar untuk melihat apakah ada jejak eksekusi yang melanggar properti tertentu. Bentuk pengujian berbasis properti ini berbeda dari pengujian unit karena kasus uji mencakup berbagai skenario dan sebuah program menangani pembuatan kasus uji.

Fuzzing (opens in a new tab) adalah contoh teknik analisis dinamis untuk memverifikasi properti arbitrer dalam kontrak pintar. Fuzzer memanggil fungsi dalam kontrak target dengan variasi acak atau cacat dari nilai masukan yang ditentukan. Jika kontrak pintar memasuki status kesalahan (misalnya, di mana asersi gagal), masalah tersebut ditandai dan masukan yang mendorong eksekusi menuju jalur yang rentan dihasilkan dalam sebuah laporan.

Fuzzing berguna untuk mengevaluasi mekanisme validasi masukan kontrak pintar karena penanganan masukan yang tidak terduga secara tidak tepat dapat mengakibatkan eksekusi yang tidak diinginkan dan menghasilkan efek berbahaya. Bentuk pengujian berbasis properti ini bisa ideal karena banyak alasan:

  1. Menulis kasus uji untuk mencakup banyak skenario adalah hal yang sulit. Pengujian properti hanya mengharuskan Anda menentukan perilaku dan rentang data untuk menguji perilaku tersebut—program secara otomatis menghasilkan kasus uji berdasarkan properti yang ditentukan.

  2. Rangkaian pengujian Anda mungkin tidak cukup mencakup semua kemungkinan jalur di dalam program. Bahkan dengan cakupan 100%, ada kemungkinan untuk melewatkan kasus ekstrem.

  3. Pengujian unit membuktikan bahwa kontrak dieksekusi dengan benar untuk data sampel, tetapi apakah kontrak dieksekusi dengan benar untuk masukan di luar sampel tetap tidak diketahui. Pengujian properti mengeksekusi kontrak target dengan berbagai variasi nilai masukan yang diberikan untuk menemukan jejak eksekusi yang menyebabkan kegagalan asersi. Dengan demikian, pengujian properti memberikan lebih banyak jaminan bahwa kontrak dieksekusi dengan benar untuk kelas data masukan yang luas.

Panduan untuk menjalankan pengujian berbasis properti untuk kontrak pintar

Menjalankan pengujian berbasis properti biasanya dimulai dengan menentukan properti (misalnya, tidak adanya integer overflows (opens in a new tab)) atau kumpulan properti yang ingin Anda verifikasi dalam kontrak pintar. Anda mungkin juga perlu menentukan rentang nilai di mana program dapat menghasilkan data untuk masukan transaksi saat menulis pengujian properti.

Setelah dikonfigurasi dengan benar, alat pengujian properti akan mengeksekusi fungsi kontrak pintar Anda dengan masukan yang dihasilkan secara acak. Jika ada pelanggaran asersi, Anda akan mendapatkan laporan dengan data masukan konkret yang melanggar properti yang sedang dievaluasi. Lihat beberapa panduan di bawah ini untuk mulai menjalankan pengujian berbasis properti dengan berbagai alat:

Pengujian manual untuk kontrak pintar

Pengujian manual kontrak pintar sering kali dilakukan belakangan dalam siklus pengembangan setelah menjalankan pengujian otomatis. Bentuk pengujian ini mengevaluasi kontrak pintar sebagai satu produk yang terintegrasi penuh untuk melihat apakah kinerjanya sesuai dengan yang ditentukan dalam persyaratan teknis.

Menguji kontrak di blockchain lokal

Meskipun pengujian otomatis yang dilakukan di lingkungan pengembangan lokal dapat memberikan informasi debugging yang berguna, Anda pasti ingin mengetahui bagaimana perilaku kontrak pintar Anda di lingkungan produksi. Namun, penerapan ke rantai utama Ethereum menimbulkan biaya gas—belum lagi Anda atau pengguna Anda dapat kehilangan uang sungguhan jika kontrak pintar Anda masih memiliki bug.

Menguji kontrak Anda di blockchain lokal (juga dikenal sebagai jaringan pengembangan) adalah alternatif yang disarankan untuk pengujian di Mainnet. Blockchain lokal adalah salinan blockchain Ethereum yang berjalan secara lokal di komputer Anda yang menyimulasikan perilaku lapisan eksekusi Ethereum. Dengan demikian, Anda dapat memprogram transaksi untuk berinteraksi dengan kontrak tanpa menimbulkan overhead yang signifikan.

Menjalankan kontrak di blockchain lokal dapat berguna sebagai bentuk pengujian integrasi manual. Kontrak pintar sangat dapat dikomposisikan, memungkinkan Anda untuk berintegrasi dengan protokol yang ada—tetapi Anda tetap perlu memastikan bahwa interaksi onchain yang kompleks tersebut menghasilkan hasil yang benar.

Lebih lanjut tentang jaringan pengembangan.

Menguji kontrak di testnet

Jaringan pengujian atau testnet bekerja persis seperti Mainnet Ethereum, kecuali bahwa ia menggunakan ether (ETH) tanpa nilai dunia nyata. Menerapkan kontrak Anda di testnet berarti siapa pun dapat berinteraksi dengannya (misalnya, melalui frontend dapp) tanpa membahayakan dana.

Bentuk pengujian manual ini berguna untuk mengevaluasi alur ujung-ke-ujung (end-to-end) aplikasi Anda dari sudut pandang pengguna. Di sini, penguji beta juga dapat melakukan uji coba dan melaporkan masalah apa pun dengan logika bisnis kontrak dan fungsionalitas secara keseluruhan.

Menerapkan di testnet setelah pengujian di blockchain lokal sangat ideal karena testnet lebih dekat dengan perilaku Mesin Virtual Ethereum. Oleh karena itu, merupakan hal yang umum bagi banyak proyek asli Ethereum untuk menerapkan dapps di testnet guna mengevaluasi operasi kontrak pintar di bawah kondisi dunia nyata.

Lebih lanjut tentang testnet Ethereum.

Pengujian vs. verifikasi formal

Meskipun pengujian membantu mengonfirmasi bahwa kontrak mengembalikan hasil yang diharapkan untuk beberapa masukan data, pengujian tidak dapat secara meyakinkan membuktikan hal yang sama untuk masukan yang tidak digunakan selama pengujian. Oleh karena itu, menguji kontrak pintar tidak dapat menjamin "kebenaran fungsional" (yaitu, tidak dapat menunjukkan bahwa program berperilaku seperti yang disyaratkan untuk semua set nilai masukan).

Verifikasi formal adalah pendekatan untuk menilai kebenaran perangkat lunak dengan memeriksa apakah model formal program cocok dengan spesifikasi formal. Model formal adalah representasi matematis abstrak dari sebuah program, sedangkan spesifikasi formal mendefinisikan properti program (yaitu, asersi logis tentang eksekusi program).

Karena properti ditulis dalam istilah matematis, menjadi mungkin untuk memverifikasi bahwa model formal (matematis) dari sistem memenuhi spesifikasi menggunakan aturan inferensi logis. Dengan demikian, alat verifikasi formal dikatakan menghasilkan 'bukti matematis' dari kebenaran sistem.

Tidak seperti pengujian, verifikasi formal dapat digunakan untuk memverifikasi eksekusi kontrak pintar yang memenuhi spesifikasi formal untuk semua eksekusi (yaitu, tidak memiliki bug) tanpa perlu mengeksekusinya dengan data sampel. Hal ini tidak hanya mengurangi waktu yang dihabiskan untuk menjalankan lusinan pengujian unit, tetapi juga lebih efektif dalam menangkap kerentanan yang tersembunyi. Meskipun demikian, teknik verifikasi formal berada pada spektrum yang bergantung pada kesulitan implementasi dan kegunaannya.

Lebih lanjut tentang verifikasi formal untuk kontrak pintar.

Pengujian vs audit dan bug bounty

Seperti yang disebutkan, pengujian yang ketat jarang dapat menjamin tidak adanya bug dalam kontrak; pendekatan verifikasi formal dapat memberikan jaminan kebenaran yang lebih kuat tetapi saat ini sulit digunakan dan menimbulkan biaya yang cukup besar.

Namun, Anda dapat lebih meningkatkan kemungkinan menangkap kerentanan kontrak dengan mendapatkan tinjauan kode independen. Audit kontrak pintar (opens in a new tab) dan bug bounty (opens in a new tab) adalah dua cara untuk meminta orang lain menganalisis kontrak Anda.

Audit dilakukan oleh auditor yang berpengalaman dalam menemukan kasus kelemahan keamanan dan praktik pengembangan yang buruk dalam kontrak pintar. Audit biasanya akan mencakup pengujian (dan mungkin verifikasi formal) serta tinjauan manual dari seluruh basis kode.

Sebaliknya, program bug bounty biasanya melibatkan penawaran hadiah finansial kepada individu (umumnya digambarkan sebagai peretas topi putih (whitehat hackers) (opens in a new tab)) yang menemukan kerentanan dalam kontrak pintar dan mengungkapkannya kepada pengembang. Bug bounty mirip dengan audit karena melibatkan permintaan kepada orang lain untuk membantu menemukan cacat dalam kontrak pintar.

Perbedaan utamanya adalah bahwa program bug bounty terbuka untuk komunitas pengembang/peretas yang lebih luas dan menarik kelas peretas etis serta profesional keamanan independen yang luas dengan keterampilan dan pengalaman unik. Ini mungkin menjadi keuntungan dibandingkan audit kontrak pintar yang terutama bergantung pada tim yang mungkin memiliki keahlian terbatas atau sempit.

Alat dan pustaka pengujian

Alat pengujian unit

Alat pengujian berbasis properti

Alat analisis statis

  • Slither (opens in a new tab) - Kerangka kerja analisis statis Solidity berbasis Python untuk menemukan kerentanan, meningkatkan pemahaman kode, dan menulis analisis kustom untuk kontrak pintar.

  • Ethlint (opens in a new tab) - Linter untuk menegakkan gaya dan praktik terbaik keamanan untuk bahasa pemrograman kontrak pintar Solidity.

  • Cyfrin Aderyn (opens in a new tab) - Penganalisis statis berbasis Rust yang dirancang khusus untuk keamanan dan pengembangan kontrak pintar Web3.

  • Wake (opens in a new tab) - Kerangka kerja analisis statis berbasis Python dengan detektor kerentanan dan kualitas kode, pencetak untuk mengekstrak informasi berguna dari kode dan dukungan untuk menulis submodul kustom.

  • Slippy (opens in a new tab) - Linter yang sederhana dan kuat untuk Solidity.

Alat analisis dinamis

  • Echidna (opens in a new tab) - Fuzzer kontrak cepat untuk mendeteksi kerentanan dalam kontrak pintar melalui pengujian berbasis properti.

  • Diligence Fuzzing (opens in a new tab) - Alat fuzzing otomatis yang berguna untuk mendeteksi pelanggaran properti dalam kode kontrak pintar.

  • Manticore (opens in a new tab) - Kerangka kerja eksekusi simbolis dinamis untuk menganalisis bytecode EVM.

  • Mythril (opens in a new tab) - Alat penilaian bytecode EVM untuk mendeteksi kerentanan kontrak menggunakan analisis taint, analisis concolic, dan pemeriksaan aliran kontrol.

  • Diligence Scribble (opens in a new tab) - Scribble adalah bahasa spesifikasi dan alat verifikasi runtime yang memungkinkan Anda membuat anotasi kontrak pintar dengan properti yang memungkinkan Anda menguji kontrak secara otomatis dengan alat seperti Diligence Fuzzing atau MythX.

Tutorial terkait

Bacaan lebih lanjut

Tutorial: Pengujian kontrak pintar di Ethereum

Apakah artikel ini membantu?