Sihir hitam manipulasi harga: Analisis kerentanan perhitungan invariant Balancer V2

Kompilasi: Bahasa biasa Blockchain

Pada 3 November 2025, Kolam Stabil Komposabel (Composable Stable Pools) dari Balancer V2 dan beberapa proyek fork di berbagai blockchain mengalami serangan kolaboratif, yang mengakibatkan total kerugian lebih dari 125 juta dolar. BlockSec segera mengeluarkan peringatan dan kemudian merilis analisis awal.

Ini adalah serangan yang sangat kompleks. Investigasi kami menunjukkan bahwa penyebab utamanya adalah kehilangan presisi dalam perhitungan invarian yang menyebabkan manipulasi harga, yang pada gilirannya mendistorsi perhitungan harga BPT (Balancer Pool Token). Manipulasi invarian ini memungkinkan penyerang untuk mendapatkan keuntungan dari satu pertukaran batch dari kolam stabil tertentu. Meskipun beberapa peneliti telah memberikan analisis yang berwawasan, ada beberapa interpretasi yang menyesatkan, dan penyebab serta proses serangan belum sepenuhnya dijelaskan. Blog ini bertujuan untuk memberikan analisis teknis yang komprehensif dan akurat tentang kejadian ini.

Poin Kunci (TL;DR)

• Penyebab utama: Ketidakcocokan pembulatan dan kehilangan presisi

• Operasi pembesaran (upscaling) menggunakan pembulatan satu arah (pembulatan ke bawah), sementara operasi pengecilan (downscaling) menggunakan pembulatan dua arah (pembulatan ke atas dan ke bawah).
• Ketidaksesuaian ini menyebabkan kehilangan akurasi, dan saat dimanfaatkan melalui jalur pertukaran yang dirancang dengan cermat, melanggar prinsip standar bahwa 'pembulatan harus selalu menguntungkan protokol'.

• Eksekusi Serangan

• Penyerang merancang parameter dengan cermat, termasuk jumlah iterasi dan nilai input, untuk memaksimalkan dampak kehilangan akurasi.
• Penyerang menggunakan metode dua tahap untuk menghindari deteksi: pertama, mereka melakukan serangan inti dalam satu transaksi, tidak segera mendapatkan keuntungan, kemudian dalam transaksi lain, mereka merealisasikan keuntungan dengan menarik aset.

• Dampak Operasional dan Pembesaran

• Karena beberapa batasan, protokol tidak dapat dihentikan. Situasi ketidakmampuan untuk menghentikan operasi ini memperburuk dampak serangan dan menyebabkan banyak serangan lanjutan atau tiruan.

Di bagian berikut, kami akan terlebih dahulu memberikan informasi latar belakang kunci tentang Balancer V2, kemudian menganalisis masalah yang ditemukan dan serangan terkait.

0x1 Latar Belakang

1. Kolam stabilisasi kombinasi Balancer V2

Komponen yang terpengaruh dalam serangan ini adalah kolam stabil kombinasi dari protokol Balancer V2. Kolam ini dirancang khusus untuk aset yang diharapkan dapat mempertahankan dekat 1:1 peg (atau diperdagangkan dengan nilai tukar yang diketahui), dan memungkinkan pertukaran besar dengan dampak harga yang minimal, sehingga secara signifikan meningkatkan efisiensi modal antara aset sejenis atau terkait. Setiap kolam memiliki Token Kolam Balancer masing-masing (BPT), yang mewakili bagian penyedia likuiditas dalam kolam, serta aset dasar yang sesuai.

Kolam ini menggunakan Stable Math (model StableSwap berbasis Curve), di mana invariant D mewakili nilai total virtual kolam.

Harga BPT dapat diperkirakan sebagai:

Dari rumus di atas, dapat dilihat bahwa jika D dapat dikurangi di buku (meskipun tidak ada kerugian dana yang sebenarnya), harga BPT akan terlihat lebih murah.

2. batchSwap() dan onSwap()

Balancer V2 menyediakan fungsi batchSwap(), yang mendukung pertukaran multi-hop di dalam Vault. Berdasarkan parameter yang diberikan kepada fungsi ini, ada dua jenis pertukaran:

• GIVEN_IN (“input yang ditentukan”): Panggil menentukan jumlah Token input yang tepat, dan kolam menghitung jumlah output yang sesuai.
• GIVEN_OUT（“Diberikan Keluaran”）：Pemanggil menentukan jumlah keluaran yang diharapkan, kolam menghitung jumlah input yang diperlukan.

Biasanya, batchSwap() terdiri dari beberapa pertukaran Token yang dilakukan melalui fungsi onSwap(). Berikut adalah gambaran tentang jalur eksekusi ketika sebuah SwapRequest dialokasikan sebagai tipe pertukaran GIVEN_OUT (perhatikan bahwa ComposableStablePool diwarisi dari BaseGeneralPool):

Berikut menunjukkan perhitungan amount_in dalam tipe pertukaran GIVEN_OUT, yang melibatkan invarian D.

// dalamGivenOut token x untuk y - persamaan polinomial untuk diselesaikan // ax = jumlah yang akan dihitung // bx = saldo token di // x = bx + ax (finalBalanceIn)
// D = invariant // A = koefisien amplifikasi // n = jumlah token // S = jumlah saldo akhir tetapi x // P = produk dari saldo akhir tetapi x

               D                     D^(n+1)  

x^2 + ( S - ---------- - D) * x - ------------- = 0
(A * n^n) A * n^2n * P

3. Skala dan Pembulatan

Untuk menstandarkan perhitungan antara saldo Token yang berbeda, Balancer melakukan dua operasi berikut:

• Penskalaan (Upscaling): Sebelum melakukan perhitungan, memperbesar saldo dan jumlah ke presisi internal yang seragam.

• Downscaling: Mengonversi hasil kembali ke akurasi aslinya, dan menerapkan pembulatan terarah (misalnya, jumlah input biasanya dibulatkan ke atas untuk memastikan kolam tidak kurang biaya, sementara jumlah output sering dibulatkan ke bawah).

! [gambar] ()

Jelas bahwa pembesaran dan pengecilan secara teoritis adalah operasi yang berpasangan—masing-masing adalah perkalian dan pembagian. Namun, terdapat ketidakkonsistenan dalam pelaksanaan kedua operasi ini. Secara khusus, operasi pengecilan memiliki dua varian atau arah: divUp dan divDown. Sebaliknya, operasi pembesaran hanya memiliki satu arah, yaitu mulDown.

Penyebab ketidaksesuaian ini masih belum jelas. Menurut komentar dalam fungsi _upscale(), pengembang percaya bahwa pengaruh pembulatan satu arah adalah sangat kecil.

// Memperbesar (Upscale) pembulatan tidak selalu akan menuju arah yang sama: misalnya, dalam satu pertukaran,

// Saldo Token yang dimasukkan harus dibulatkan ke atas, sementara saldo Token yang dikeluarkan harus dibulatkan ke bawah. Ini adalah satu-satunya tempat kami melakukan pembulatan searah untuk semua jumlah.

// Karena dampak pembulatan ini diperkirakan paling kecil

// (dan kecuali _scalingFactor() ditimpa, tidak ada kesalahan pembulatan).

Analisis Kerentanan 0x2

Masalah mendasar berasal dari operasi pembulatan yang dilakukan saat menjalankan operasi pembesaran (upscaling) dalam fungsi BaseGeneralPool._swapGivenOut(). Secara khusus, _swapGivenOut() secara keliru membulatkan swapRequest.amount ke bawah melalui fungsi _upscale(). Nilai yang dibulatkan ini kemudian digunakan sebagai amountOut, yang digunakan saat menghitung amountIn melalui _onSwapGivenOut(). Perilaku ini bertentangan dengan praktik standar “pembulatan harus diterapkan dengan cara yang menguntungkan protokol.”

Oleh karena itu, untuk kolam yang diberikan (wstETH/rETH/cbETH), amountIn yang dihitung meremehkan input yang sebenarnya dibutuhkan. Ini memungkinkan pengguna untuk menukar jumlah yang lebih sedikit dari satu aset dasar (misalnya wstETH) dengan aset lain (misalnya cbETH), yang mengakibatkan penurunan invarian D karena berkurangnya likuiditas yang efektif. Oleh karena itu, harga BPT yang sesuai (wstETH/rETH/cbETH) menjadi tertekan (deflated), karena $\text{BPT price} = \frac{D}{\text{totalSupply｝｝$.

Analisis Serangan 0x3

Penyerang telah melakukan

Serangan dua tahap, mungkin untuk meminimalkan risiko terdeteksi:

• Pada fase pertama, inti digunakan dalam transaksi tunggal, tanpa keuntungan segera.
• Pada tahap kedua, penyerang memperoleh keuntungan dengan mengekstrak aset dalam transaksi lain.

Tahap pertama dapat dibagi lagi menjadi dua tahap: perhitungan parameter dan pertukaran massal. Di bawah ini, kami menggunakan contoh transaksi (TX) serangan di Arbitrum untuk menjelaskan tahap-tahap ini.

Tahap perhitungan parameter

Pada tahap ini, penyerang menggabungkan komputasi off-chain dengan simulasi on-chain, menyesuaikan dengan tepat parameter setiap lompatan pada tahap berikutnya (pertukaran massal) berdasarkan keadaan saat ini dari kolam stabil kombinasi (termasuk faktor skala, koefisien perbesaran, nilai tukar BPT, biaya pertukaran, dan parameter lainnya). Menariknya, penyerang juga mengimplementasikan kontrak pembantu untuk membantu perhitungan ini, yang mungkin bertujuan untuk mengurangi risiko “front-running”.

Pertama, penyerang mengumpulkan informasi dasar tentang pool target, termasuk faktor skala setiap Token, parameter perbesaran, tarif BPT, dan persentase biaya pertukaran. Kemudian mereka menghitung nilai kunci trickAmt, yaitu jumlah Token target yang dimanipulasi yang digunakan untuk memicu kehilangan presisi.

Biarkan faktor skala token target (scaling factor) disebut sF, dihitung sebagai berikut:

Untuk menentukan parameter yang digunakan dalam langkah 2 (pertukaran massal) tahap berikutnya, penyerang menggunakan calldata berikut untuk melakukan panggilan simulasi lanjutan ke fungsi 0x524c9e20 dari kontrak bantuan:

uint256[] balances; // Saldo Token Pool (tidak termasuk BPT) uint256[] scalingFactors; // Faktor skala untuk setiap Token kolam uint tokenIn; // Indeks Token input yang disimulasikan dalam lompatan ini uint tokenOut; // Indeks Token output simulasi ini uint256 amountOut; // Jumlah Token keluaran yang diharapkan uint256 amp; // Parameter pembesaran kolam uint256 fee; // Persentase biaya pertukaran kolam

Data yang dikembalikan adalah:

uint256[] saldo; // Saldo Token pool setelah pertukaran (tidak termasuk BPT)

Secara spesifik, saldo awal dan jumlah iterasi dihitung di luar rantai, dan disampaikan sebagai parameter ke kontrak penyerang (laporan masing-masing adalah 100.000.000.000 dan 25). Setiap iterasi melakukan tiga pertukaran:

1. Tukar 1: Mendorong jumlah Token target ke trickAmt + 1, dengan asumsi arah tukar adalah 0 → 1.
2. Pertukaran 2: Terus tukarkan targetToken dengan trickAmt, ini akan memicu pembulatan ke bawah dalam pemanggilan _upscale(). 320.000.

Harap dicatat bahwa karena metode Newton–Raphson digunakan dalam perhitungan StableMath, langkah ini mungkin kadang-kadang gagal. Untuk mengatasi hal ini, penyerang melakukan dua upaya percobaan ulang, masing-masing menggunakan 9/10 dari nilai asli sebagai nilai cadangan.

Kontrak pendukung penyerang diturunkan dari pustaka StableMath Balancer V2, hal ini dapat dibuktikan dengan adanya pesan kesalahan kustom bergaya “BAL” yang disertakan.

$d$ Tahap Pertukaran Massal

Kemudian, operasi batchSwap###( dapat dipecah menjadi tiga langkah:

1. Langkah 1: Penyerang menukar BPT )wstETH/rETH/cbETH( menjadi aset dasar, untuk secara tepat menyesuaikan saldo satu Token (cbETH) ke batas pembulatan (amount = 9). Ini menciptakan kondisi untuk kehilangan presisi langkah berikutnya.
2. Langkah 2: Kemudian, penyerang menggunakan jumlah yang dirancang dengan cermat (= 8) untuk melakukan pertukaran antara aset dasar lainnya (wstETH) dan cbETH. Karena jumlah Token yang diskalakan dibulatkan ke bawah, Δx yang dihitung menjadi sedikit lebih kecil (dari 8.918 menjadi 8), yang menyebabkan Δy diremehkan, sehingga invariant (D, dari model StableSwap Curve) menjadi lebih kecil. Karena $\text{harga BPT} = \frac{D}{\text{totalSupply｝｝$, harga BPT ditekan secara artifisial.

! [gambar] )( 3. Langkah 3: Penyerang secara terbalik menukarkan aset dasar kembali menjadi BPT, memulihkan keseimbangan, sambil mendapatkan keuntungan dari harga BPT yang tertekan.

0x4: Serangan dan Kerugian

Kami telah merangkum serangan ini dan kerugian yang sesuai dalam tabel di bawah ini, dengan total kerugian lebih dari 1,25 juta dolar.

![Gambar])(

0x5 Kesimpulan

Peristiwa ini melibatkan serangkaian transaksi serangan terhadap protokol Balancer V2 dan proyek fork-nya, yang mengakibatkan kerugian finansial yang signifikan. Setelah serangan awal, sejumlah besar transaksi lanjutan dan tiruan diamati di beberapa rantai. Peristiwa ini menyoroti beberapa pelajaran penting tentang desain dan keamanan protokol DeFi:

• Perilaku Pembulatan dan Kehilangan Akurasi: Pembulatan satu arah (pembulatan ke bawah) yang digunakan dalam operasi perbesaran (upscaling) berbeda dari pembulatan dua arah (pembulatan ke atas dan ke bawah) yang digunakan dalam operasi pengecilan (downscaling). Untuk mencegah kelemahan serupa, protokol harus menggunakan aritmatika dengan akurasi lebih tinggi dan menerapkan pemeriksaan validasi yang kuat. Prinsip standar “pembulatan harus selalu menguntungkan protokol” harus dipatuhi.
• Evolusi Pemanfaatan Kerentanan: Penyerang melakukan pemanfaatan kerentanan yang kompleks dalam dua tahap, bertujuan untuk menghindari deteksi. Pada tahap pertama, penyerang melakukan pemanfaatan inti dalam satu transaksi, tanpa segera mendapatkan keuntungan. Pada tahap kedua, penyerang mewujudkan keuntungan dengan menarik aset dalam transaksi lain. Ini sekali lagi menyoroti “perlombaan senjata” yang berkelanjutan antara peneliti keamanan dan penyerang.
• Kesadaran Operasional dan Respons Ancaman: Peristiwa ini menekankan pentingnya peringatan tepat waktu mengenai status inisialisasi dan operasional, serta mekanisme deteksi dan pencegahan ancaman yang proaktif, untuk mengurangi potensi kerugian yang disebabkan oleh serangan yang berkelanjutan atau menyerupai.

Dalam menjaga operasi dan kelangsungan bisnis, para pelaku industri dapat memanfaatkan BlockSec Phalcon sebagai garis pertahanan terakhir untuk melindungi aset mereka. Tim ahli BlockSec selalu siap untuk melakukan evaluasi keamanan menyeluruh untuk proyek Anda.

Tautan artikel ini:

Sumber: