Pendahuluan

Dengan perkembangan cepat ekosistem DeFi, Compound Finance V2 sebagai salah satu pelopor di bidang ini, dengan model pinjaman inovatifnya menarik banyak pengguna. Namun, setiap aplikasi terdistribusi yang kompleks menghadapi ancaman keamanan potensial, terutama ketika melibatkan pergerakan dana senilai jutaan bahkan miliaran dolar. Oleh karena itu, melakukan audit keamanan yang komprehensif dan mendetail terhadap Compound Finance V2 dan proyek fork-nya sangat penting. Panduan ini ditujukan untuk pengembang, peneliti keamanan, dan penggemar DeFi untuk memberikan panduan audit keamanan yang mendetail, membantu semua orang lebih efektif dalam mengenali dan mencegah risiko potensial.

1. Gambaran Umum Latar Belakang Proyek

Compound Finance V2 adalah platform pinjam-meminjam terbuka yang dibangun di atas blockchain Ethereum, yang memungkinkan pengguna menyimpan berbagai token dasar ERC-20 dan mendapatkan bunga darinya, sekaligus juga memungkinkan meminjam token di pasar dengan membayar bunga. Dengan memperkenalkan konsep 'pasar suku bunga', ia mewujudkan pengelolaan kolam dana terdesentralisasi dan mekanisme penyesuaian suku bunga otomatis.

2. Analisis Arsitektur Proyek

Komponen arsitektur inti dari Compound Finance V2 meliputi:

  • Comptroller: Mengendalikan logika seluruh sistem, seperti perhitungan suku bunga, pemeliharaan status akun, dll.

  • cToken: Token kustom yang memenuhi standar ERC-20, mewakili kepentingan pengguna dalam sistem.

  • InterestRateModel: Model yang menghitung suku bunga pinjaman dan simpanan.

  • PriceOracle: Oracle yang menyediakan harga aset.

  • Governance: Bertanggung jawab atas fungsi terkait tata kelola komunitas.

2.1 Comptroller

Kontrak Comptroller adalah sistem saraf pusat dari Compound Finance V2, yang bertanggung jawab untuk mengkoordinasikan perilaku setiap instance cToken. Tanggung jawab utamanya adalah:

  • Mengelola daftar pasar, menentukan pasar mana yang aktif.

  • Melakukan berbagai pemeriksaan untuk operasi lintas pasar, seperti memeriksa kesehatan posisi pengguna, dll.

  • Mengatur dan memperbarui parameter global, seperti batas pinjaman, faktor jaminan, ambang batas likuidasi, dll.

2.2 cToken

Setiap token ERC-20 yang didukung memiliki instance cToken yang sesuai (yaitu kontrak CErc20 / CEther), digunakan untuk menangani semua operasi interaksi token tersebut dengan proyek. Setiap cToken tidak hanya memenuhi fungsi dasar transfer token, tetapi juga menambahkan beberapa fitur khusus untuk Compound, seperti pinjam-meminjam, akumulasi bunga, dan distribusi hadiah. Oleh karena itu, kita dapat menganggap cToken sebagai bukti bahwa pengguna telah menyimpan aset di Compound dan sebagai pintu masuk bagi pengguna untuk melakukan operasi pinjam-meminjam.

Ketika pengguna menyimpan token aset dasar ke dalam kontrak, mereka dapat mencetak token cToken yang sesuai, rasio tukar cToken dan aset dasarnya dihitung dengan rumus berikut:

Catatan: borrows menunjukkan jumlah pinjaman, cash menunjukkan saldo kolam dana, reserves menunjukkan cadangan. Suku bunga pinjaman ditentukan oleh tingkat penggunaan, sedangkan suku bunga simpanan ditentukan oleh suku bunga pinjaman.

Pengguna umumnya melakukan interaksi dengan berbagai kontrak cToken untuk melakukan operasi pinjam-meminjam token di berbagai pasar:

2.3 InterestRateModel

Kontrak InterestRateModel mendefinisikan cara menghitung suku bunga. Pasar yang berbeda mungkin menggunakan jenis model suku bunga yang berbeda untuk menyesuaikan dengan preferensi risiko dan kebutuhan likuiditas masing-masing.

Model suku bunga yang digunakan di pasar Compound V2 terutama ada dua jenis, yaitu model linier dan model titik belok.

Rumus suku bunga untuk model linier adalah sebagai berikut:

Rumus perhitungan tingkat penggunaan dana adalah sebagai berikut:

Suku bunga simpanan berubah secara linier seiring dengan suku bunga pinjaman:

Peningkatan tingkat penggunaan secara bertahap berarti uang dalam kolam dana semakin berkurang, ketika mencapai puncak tertentu dapat menyebabkan pengguna tidak dapat menyimpan dan meminjam dengan normal. Untuk menghindari situasi ini, Compound meluncurkan model suku bunga kedua - tipe titik belok.

Rumus perhitungan suku bunga pinjaman tipe titik belok adalah sebagai berikut:

Ketika tingkat penggunaan mencapai puncak tertentu, suku bunga pinjaman dan simpanan akan meningkat secara signifikan, mendorong pengguna untuk lebih banyak menyimpan dan sedikit meminjam, sehingga mengendalikan tingkat penggunaan dalam batas yang sesuai, puncak ini juga disebut titik belok (biasanya ketika tingkat penggunaan mencapai 80%).

2.4 PriceOracle

Kontrak PriceOracle bertanggung jawab untuk mendapatkan informasi harga pasar eksternal dan mengubahnya menjadi nilai yang digunakan dalam sistem, yang sangat penting untuk menghitung nilai posisi pengguna dengan akurat.

2.5 Mekanisme Pengelolaan dan Model Insentif

Compound memperkenalkan mekanisme tata kelola yang unik, memungkinkan pengguna yang memiliki token tata kelola (COMP) untuk berpartisipasi dalam pemungutan suara keputusan penting, seperti mengubah parameter tertentu atau menambahkan jenis aset baru. Dengan menerbitkan token tata kelola (COMP), Compound mendorong pengguna untuk berpartisipasi aktif dalam kegiatan platform dan memberikan penghargaan kepada kontributor. Untuk informasi lebih lanjut, silakan merujuk pada dokumentasi resmi dan repositori kode Compound. (https://docs.compound.finance/v2/; https://github.com/compound-finance/compound-protocol)

3. Proses Interaksi

Selanjutnya, kita akan menjelaskan secara sederhana proses interaksi pengguna di Compound Finance V2:

3.1 Proses Penyimpanan dan Penebusan

Jika pengguna Alice perlu menyimpan 1 WBTC ke dalam Compound, maka dia akan memanggil fungsi mint dari kontrak cWBTC untuk melakukan penyimpanan. Kontrak ini mewarisi kontrak cToken, akan terlebih dahulu memanggil fungsi accrueInterest melalui fungsi mintInternal untuk memperbarui suku bunga pinjaman dan simpanan, kemudian memanggil mintFresh untuk melakukan operasi pencetakan yang spesifik.

Fungsi mintFresh akan memanggil fungsi mintAllowed kontrak Comptroller untuk memeriksa apakah pasar saat ini mengizinkan penyimpanan, kemudian akan mentransfer 1 WBTC milik pengguna ke dalam kontrak melalui fungsi doTransferIn, lalu berdasarkan rasio pertukaran terbaru saat itu, akan mencetak jumlah cToken yang sesuai untuk pengguna (misalkan rasio pertukaran terbaru saat ini adalah 0.1, maka Alice akan menerima 10 cWBTC).

Jika Alice memutuskan untuk menebus simpanannya di masa depan, dia dapat memanggil fungsi redeem untuk menukar cWBTC kembali ke WBTC, rasio pertukaran mungkin sudah berubah (misalkan 0.15), yang berarti Alice dapat menebus 1.5 WBTC, di mana 0.5 WBTC adalah pendapatan bunga.

3.2 Proses Peminjaman dan Pembayaran Kembali

Alice pertama-tama perlu memanggil fungsi enterMarkets dari kontrak Comptroller untuk mengatur cWBTC-nya sebagai status yang dapat digunakan sebagai jaminan, kemudian baru dapat melakukan pinjaman.

Misalkan Alice memilih untuk meminjam 70 USDC, karena faktor jaminan WBTC adalah 0.75, Alice dapat meminjam maksimal setara dengan 75% dari nilai aset WBTC, jadi ini tidak akan melebihi batas pinjaman maksimumnya.

Catatan: Untuk menghindari risiko dilikuidasi, Alice sebaiknya menyimpan ruang buffer tertentu dan tidak menghabiskan semua batas pinjamannya.

Alice memanggil fungsi borrow kontrak cUSDC, yang akan terlebih dahulu memanggil fungsi accrueInterest melalui fungsi borrowInternal untuk memperbarui suku bunga pinjaman dan simpanan, kemudian memanggil borrowFresh untuk melakukan operasi pinjaman yang spesifik.

Setelah melakukan pemeriksaan nilai posisi pengguna melalui fungsi borrowAllowed kontrak Comptroller, pertama-tama mencatat data pinjaman, kemudian menggunakan fungsi doTransferOut untuk mentransfer token kepada pengguna.

Jika Alice perlu membayar kembali, dia dapat memanggil fungsi repayBorrow kontrak cUSDC untuk membayar sendiri, atau meminta orang lain untuk memanggil fungsi repayBorrowBehalf untuk membayar kembali atas namanya.

3.3 Proses Likuidasi

Jika harga WBTC turun drastis, sehingga nilai jaminan Alice berada di bawah 75% dari batas pinjamannya, maka posisi pinjaman Alice akan berada dalam keadaan likuidasi.

Peliquidasi eksternal (misalnya Bob) dapat memanggil fungsi likuidasi borrow di kontrak cUSDC untuk membantu Alice melunasi sebagian utangnya. Fungsi tersebut akan terlebih dahulu memperbarui suku bunga cUSDC dan suku bunga token jaminan yang digunakan untuk pembayaran kembali melalui fungsi liquidateBorrowInternal, kemudian memanggil liquidateBorrowFresh untuk melakukan operasi likuidasi yang spesifik.

Setelah memeriksa apakah likuidasi diizinkan melalui fungsi liquidateBorrowAllowed dari kontrak Comptroller, akan terlebih dahulu memanggil fungsi repayBorrowFresh untuk mentransfer USDC ke dalam kontrak untuk pembayaran kembali, dan memperbarui data pinjaman dari debitur yang dilikuidasi. Selanjutnya, panggil fungsi liquidateCalculateSeizeTokens dari kontrak Comptroller untuk menghitung jumlah jaminan yang dapat diambil Bob dari Alice berdasarkan nilai likuidasi, dan akhirnya menggunakan fungsi seize dari kontrak cToken yang ditunjuk untuk jaminan (misalnya cWBTC) untuk mentransfer cToken kepada Bob dan Alice.

Buka tautan ini untuk melihat versi HD dari gambar di atas, klik baca artikel asli untuk langsung melompat: https://www.figma.com/board/POkJlvKlWWc7jSccYMddet/Compound-V2?node-id=0-1&node-type=canvas.

Bob melunasi sebagian pinjaman Alice (misalnya 20 USDC), dan karena itu menerima jaminan yang bernilai setara dengan Alice (seperti WBTC), sementara Bob juga dapat menerima insentif likuidasi tambahan (misalkan 5%). Hasil akhirnya adalah Bob menerima WBTC senilai 21 USDC (20 USDC pinjaman + 1 USDC insentif likuidasi).

4. Daftar Periksa Kerentanan Keamanan

4.1 Kerentanan pembulatan yang disebabkan oleh pasar kosong

Jika cToken adalah pasar kosong (yaitu tidak ada pengguna yang melakukan pinjam-meminjam di pasar), karena nilai exchangeRate dalam fungsi exchangeRateStoredInternal bergantung pada jumlah token aset dasar dalam kontrak, maka dapat memanipulasi harga cToken dengan mentransfer sejumlah besar token aset dasar ke kontrak cToken.

Oleh karena itu, dapat menggunakan sejumlah kecil cToken untuk meminjam banyak token lain, kemudian memanggil fungsi redeemUnderlying dari cToken untuk menarik token aset dasar. Saat menghitung penebusan, jumlah cToken yang harus dipotong akan jauh lebih sedikit dari yang diharapkan (hampir hanya setengah).

Misalkan saat ini jumlah cToken yang dimiliki adalah 2 (juga merupakan total totalSupply), sementara exchangeRate setelah manipulasi dinaikkan menjadi 25.015.031.908.500.000.000.000.000, jumlah token aset dasar yang perlu ditebus adalah 50.030.063.815. Maka jumlah cToken yang harus dipotong seharusnya adalah:

Namun, jumlah cToken yang dihitung adalah:

Oleh karena itu, pada akhirnya hanya sedikit cToken yang perlu dilikuidasi untuk mendapatkan sejumlah besar token aset yang dipinjam dari pasar lain.

Anda dapat merujuk pada transaksi yang menyebabkan proyek fork Compound Hundred Finance diretas karena kerentanan ini: https://optimistic.etherscan.io/tx/0x6e9ebcdebbabda04fa9f2e3bc21ea8b2e4fb4bf4f4670cb8483e2f0b2604f451

Poin audit: Dalam audit, perlu memperhatikan apakah cara menghitung rasio pertukaran mudah dimanipulasi dan apakah cara pembulatan sudah tepat, dan juga dapat disarankan kepada tim proyek untuk segera mencetak sejumlah kecil cToken setelah pasar baru dibuat, untuk mencegah pasar menjadi kosong dan kemudian dimanipulasi.

4.2 Kerentanan reentrancy yang disebabkan oleh token ERC677 / ERC777

ERC677 / ERC777 adalah perluasan dari kontrak ERC20, yang kompatibel dengan standar protokol token ERC20. Token-token ini memungkinkan selama proses transfer, jika alamat penerima adalah kontrak maka akan memicu fungsi callback dari alamat penerima (seperti transferAndCall atau tokensReceived).

Dalam kode Compound Finance V2 versi lama, ketika pengguna meminjam di pasar cToken, token yang dipinjam akan terlebih dahulu dipindahkan, kemudian data pinjaman dicatat.

Jika token yang dipinjam pengguna adalah token ERC677 / ERC777 yang memiliki fungsi callback, maka dapat membangun kontrak jahat untuk menerima token yang dapat memanggil fungsi callback untuk masuk kembali ke dalam fungsi borrow, karena data pinjaman pengguna sebelumnya belum dicatat, sehingga dapat berhasil melewati pemeriksaan kesehatan akun untuk meminjam token lagi.

Anda dapat merujuk pada transaksi yang menyebabkan proyek fork Compound Hundred Finance diretas karena kerentanan ini: https://blockscout.com/xdai/mainnet/tx/0x534b84f657883ddc1b66a314e8b392feb35024afdec61dfe8e7c510cfac1a098

Poin audit: Versi terbaru dari kode Compound V2 telah memperbaiki logika peminjaman, diubah untuk terlebih dahulu mencatat data peminjaman sebelum mengeluarkan token yang dipinjam. Dalam audit, perlu diperhatikan apakah kode terkait fungsi pinjam-meminjam mematuhi norma CEI (Checks-Effects-Interactions), dan juga harus mempertimbangkan dampak token dengan fungsi callback.

4.3 Risiko manipulasi harga yang disebabkan oleh mekanisme oracle yang tidak tepat

Karena Compound Finance mengadopsi model pinjaman yang disertai jaminan berlebih, jumlah token yang dapat dipinjam pengguna bergantung pada apakah nilai jaminan cukup.

Oleh karena itu, jika mekanisme pemberian harga oracle yang digunakan proyek untuk menghitung nilai jaminan mudah dimanipulasi, maka akan sangat mudah untuk meminjam token yang melebihi ekspektasi.

Sebagai contoh, dalam peristiwa peretasan proyek fork Compound Lodestar Finance, cara oracle mendapatkan harga token jaminan plvGLP adalah dengan membagi jumlah token plsGLP dalam kontrak plvGLP (totalAssets) dengan total pasokan plvGLP (totalSupply) untuk menghitung rasio pertukaran, lalu mengalikan rasio pertukaran dengan harga token GLP untuk menghitung harga token plvGLP.

Sementara itu, plvGLP memiliki fungsi donasi, yang memungkinkan pengguna menyumbangkan sGLP untuk mencetak token plsGLP yang sesuai untuk kontrak plvGLP.

Oleh karena itu, penyerang dapat terlebih dahulu menggunakan pinjaman kilat untuk menciptakan posisi jaminan plvGLP yang besar di pasar Lodestar Finance, kemudian menggunakan pinjaman kilat di GMX untuk mencetak sGLP dalam jumlah besar, dan melalui fungsi donasi untuk mencetak token plsGLP untuk kontrak plvGLP untuk meningkatkan nilai totalAssets. Dengan meningkatnya total aset, rasio plvGLP akan meningkat, menyebabkan harga token plvGLP melonjak tajam, sehingga dapat meminjam token lain melebihi yang diharapkan di pasar.

Anda dapat merujuk pada transaksi yang menyebabkan Lodestar Finance diretas: https://arbiscan.io/tx/0xc523c6307b025ebd9aef155ba792d1ba18d5d83f97c7a846f267d3d9a3004e8c

Selain itu, perlu diperhatikan bahwa Compound Finance atau proyek fork-nya juga menggunakan oracle off-chain seperti ChainLink atau CoinBase untuk mendapatkan harga jaminan. Jika terjadi fluktuasi pasar yang tajam, hal ini dapat menyebabkan harga off-chain dan on-chain muncul selisih, yang membahayakan keamanan dana proyek.

Sebagai contoh, jika harga token LUNA tiba-tiba anjlok karena alasan pasar, dan protokol fork Compound Finance seperti Venus Protocol dan Blizz Finance menggunakan oracle Chainlink sebagai sumber harga untuk menghitung nilai jaminan, di mana harga minimum (minAnswer) untuk token LUNA telah di-hardcode menjadi 0.10 dolar.

Ketika harga token LUNA turun di bawah 0.1 dolar (misalnya 0.001 dolar), siapa pun dapat membeli banyak LUNA dengan harga pasar dan menggunakannya sebagai jaminan (senilai 0.10 dolar) untuk meminjam aset lain dari platform.

Poin audit: Dalam audit, perlu memperhatikan apakah mekanisme pemberian harga oracle yang digunakan untuk menghitung nilai jaminan mudah dimanipulasi oleh pihak eksternal, dapat disarankan kepada tim proyek untuk menggunakan berbagai sumber harga untuk evaluasi gabungan, untuk menghindari risiko yang disebabkan oleh sumber harga tunggal.

4.4 Risiko manipulasi rasio tukar yang disebabkan oleh token dengan banyak titik masuk

Dalam kode Compound, ada fungsi bernama sweepToken, yang bertujuan agar pengguna yang tidak sengaja mentransfer token ke kontrak dapat menarik token tersebut. Kode versi lama adalah sebagai berikut, fungsi ini memiliki satu pemeriksaan keamanan penting: parameter token yang dimasukkan tidak boleh berupa token aset dasar kontrak.

Namun, jika ada beberapa kontrak titik masuk untuk token aset dasar di pasar cToken tertentu (di mana beberapa alamat kontrak dapat mengakses saldo dasar yang sama, interaksi eksternal mempengaruhi saldo semua titik masuk, ini adalah mode proxy yang mirip dengan awal), penyerang dapat memanggil fungsi sweepToken dengan mengirimkan kontrak titik masuk yang berbeda dari underlying untuk mengekstrak token aset dasar dari kontrak.

Berikut ini menggunakan TUSD sebagai contoh, yang memiliki dua kontrak titik masuk, kontrak titik masuk tambahan 0x8dd5fbce akan meneruskan segala panggilan (seperti transfer atau balanceOf) ke kontrak utama, ini berarti interaksi dengan salah satu kontrak akan mempengaruhi data saldo di kedua kontrak (artinya kedua kontrak yang berbeda berbagi data saldo yang sama).

Saat ini, misalkan alamat token dasar yang diatur di pasar adalah alamat kontrak utama TUSD, maka kita dapat memanggil fungsi sweepToken dengan alamat kontrak titik masuk tambahan 0x8dd5fbce sebagai parameter token yang dikirim, maka dapat berhasil melalui pemeriksaan address(token) != underlying, setelah itu kontrak akan memindahkan semua token aset dasar TUSD ke alamat administrator.

Sementara itu, rasio pertukaran TUSD / cTUSD akan dipengaruhi oleh jumlah token aset dasar TUSD dalam kontrak cTUSD, ketika TUSD seluruhnya dipindahkan ke alamat administrator, rasio TUSD / cTUSD akan turun dengan drastis. Saat itu, penyerang dapat melakukan likuidasi pengguna lain dengan rasio pertukaran yang sangat rendah atau membayar kembali jumlah token yang lebih sedikit dari yang diharapkan setelah meminjam untuk mendapatkan keuntungan.

Perlu dicatat bahwa dalam kode versi terbaru Compound V2, fungsi sweepToken telah ditambahkan verifikasi hak akses, memastikan bahwa hanya peran administrator yang dapat memanggil kontrak tersebut, dan semua pasar yang memiliki token dengan banyak titik masuk telah dihapus.

Poin audit: Dalam audit, untuk fungsi memindahkan token dalam kontrak, perlu dipertimbangkan dampak dari adanya token dengan banyak titik masuk terhadap proyek, dapat disarankan kepada tim proyek untuk tidak menggunakan token dengan banyak titik masuk atau memverifikasi apakah jumlah token aset dasar dalam kontrak berubah sebelum dan sesudah transfer token, dan melakukan pemeriksaan hak akses yang baik untuk fungsi terkait.

4.5 Masalah kompatibilitas kode kontrak versi lama dan baru

Jika dalam proyek fork Compound Finance V2, kode dari suatu kontrak inti fork adalah versi baru dari kode Compound Finance V2, tetapi salah satu kontrak lain yang berinteraksi dengannya menggunakan versi kode lama, maka mungkin akan muncul masalah kompatibilitas.

Sebagai contoh, dalam model InterestRateModel versi lama yang digunakan kontrak cToken, fungsi getBorrowRate mengembalikan dua nilai bertipe uint, sementara dalam fungsi InterestRateModel versi baru, fungsi getBorrowRate hanya akan mengembalikan satu nilai bertipe uint.

Namun, di proyek fork Compound Finance V2 yaitu Percent Finance, tim proyek menggunakan kode kontrak cToken versi lama, sementara kontrak InterestRateModel menggunakan versi baru, yang mengakibatkan fungsi accrueInterest dalam cToken gagal memanggil fungsi getBorrowRate. Dan fungsi accrueInterest digunakan dalam penarikan dan peminjaman, yang pada akhirnya membuat fungsi penarikan dan peminjaman tidak dapat beroperasi dengan normal, dana dalam kontrak terkunci sepenuhnya.

Poin audit: Dalam audit, perlu memperhatikan apakah perubahan pada antarmuka kontrak, variabel status, tanda tangan fungsi, dan peristiwa dalam kode yang diperbarui dapat merusak operasi normal sistem yang ada, memastikan konsistensi pembaruan versi kode kontrak atau memastikan bahwa kode yang diperbarui dapat kompatibel dengan versi kode lama.

4.6 Masalah pengkodean keras yang disebabkan oleh penyebaran multi-rantai

Dalam kode Compound Finance V2, konstanta blocksPerYear mewakili perkiraan jumlah blok yang dihasilkan per tahun, nilainya di-hardcode dalam kontrak model suku bunga menjadi 2102400, karena waktu rata-rata pembuatan blok Ethereum adalah 15 detik.

Namun, waktu blok di berbagai rantai tidak selalu sama, dan jumlah blok yang dihasilkan sepanjang tahun juga tidak selalu sama. Jika proyek fork Compound diterapkan di rantai lain, tetapi tidak mengubah nilai yang dikeraskan berdasarkan kondisi rantai yang berbeda, maka dapat menyebabkan hasil akhir dari perhitungan suku bunga melampaui yang diharapkan. Ini karena nilai blocksPerYear mempengaruhi nilai baseRatePerBlock dan multiplierPerBlock, yang pada gilirannya mempengaruhi suku bunga pinjaman.

Sebagai contoh, waktu pembuatan blok di rantai BSC adalah 3 detik, jadi perkiraan jumlah blok sepanjang tahun (blocksPerYear) seharusnya menjadi 10.512.000. Jika nilai blocksPerYear tidak diubah sebelum penyebaran, maka suku bunga pinjaman yang dihitung akan lima kali lipat dari yang diharapkan.

Poin audit: Dalam audit, perlu memperhatikan apakah konstanta atau variabel yang di-hardcode dalam kontrak proyek dapat menyebabkan hasil yang tidak diinginkan dalam keadaan rantai yang berbeda, disarankan agar tim proyek memperbarui nilainya sesuai dengan kondisi rantai yang berbeda.

Lainnya

Selain masalah utama yang disebutkan di atas, proyek fork Compound V2 biasanya akan memodifikasi sebagian logika bisnis berdasarkan desain tim proyek, seperti menambahkan kode untuk berinteraksi dengan protokol pihak ketiga eksternal. Ini perlu dievaluasi pada saat audit sesuai dengan logika bisnis spesifik dan kebutuhan desain untuk melihat apakah akan mempengaruhi model pinjam-meminjam inti dari Compound Finance V2 itu sendiri serta proyek.

Ditulis di akhir

Semoga panduan audit keamanan untuk Compound Finance V2 dan proyek Fork-nya ini dapat membantu semua orang memahami dan mengevaluasi keamanan sistem yang kompleks ini dengan lebih baik saat melakukan audit, seiring dengan iterasi dan pembaruan teknologi, panduan ini juga akan diperbarui dan ditingkatkan.

Referensi:

[1] https://github.com/YAcademy-Residents/defi-fork-bugs

[2] https://medium.com/chainsecurity/trueusd-compound-vulnerability-bc5b696d29e2

[3] https://github.com/code-423n4/2023-05-venus-findings/issues/559

[4] https://learnblockchain.cn/article/2593

[5] https://github.com/compound-finance/compound-protocol

Penulis | Jiu Jiu

Editor | Liz