[Chuỗi tweet tiếng Anh] Phân tích sâu về sự cố bị tấn công của Balancer V2: Cơ chế lỗ hổng, các bước tấn công và bài học rút ra

Chainfeeds Dẫn nhập:

Kẻ tấn công đã cố ý thiết lập các tham số, bao gồm số lần lặp lại và số tiền đầu vào, nhằm tối đa hóa hiệu ứng mất độ chính xác.

Nguồn bài viết:

Tác giả bài viết:

BlockSec

Quan điểm:

BlockSec: Ngày 3 tháng 11 năm 2025, Composable Stable Pool của Balancer V2, cùng với nhiều dự án fork dựa trên nó trên nhiều chuỗi, đã bị tấn công phối hợp xuyên chuỗi, gây thiệt hại tổng cộng hơn 125 millions USD. BlockSec đã phát đi cảnh báo kịp thời và sau đó công bố phân tích sơ bộ. Đây là một cuộc tấn công có mức độ phức tạp rất cao. Điều tra của chúng tôi cho thấy nguyên nhân gốc rễ xuất phát từ việc mất độ chính xác trong tính toán bất biến, từ đó kích hoạt thao túng giá và ảnh hưởng đến giá BPT (Balancer Pool Token). Kẻ tấn công đã lợi dụng thao tác batchSwap duy nhất để kiếm lời từ các pool ổn định cụ thể. Thành phần bị ảnh hưởng là Composable Stable Pool của Balancer V2. Loại pool này được thiết kế dành cho các tài sản dự kiến duy trì tỷ lệ hoán đổi gần 1:1, cho phép giao dịch khối lượng lớn với trượt giá tối thiểu, từ đó nâng cao hiệu quả sử dụng vốn cho các tài sản cùng loại hoặc liên quan. Mỗi pool đều có BPT riêng, giá của nó có thể được biểu diễn xấp xỉ như sau: Giá BPT = D / totalSupply, trong đó D là bất biến trong toán học ổn định, đại diện cho tổng giá trị ảo của pool. Từ công thức này có thể thấy, nếu D bị giảm về mặt toán học (dù tài sản thực tế không bị mất), giá BPT sẽ thể hiện thấp hơn. Balancer V2 cung cấp hàm batchSwap(), cho phép thực hiện nhiều bước Swap trong Vault, với hai chế độ trong SwapRequest là GIVEN_IN và GIVEN_OUT. Ở chế độ GIVEN_OUT, bên gọi chỉ định số tiền đầu ra mong muốn, pool sẽ tính toán số tiền đầu vào cần thiết. Trong pool ổn định, khi tính toán số lượng đầu vào amountIn, cần giải phương trình đa thức dựa trên công thức bất biến, các phép tính này sẽ được thực hiện đồng bộ Upscaling và Downscaling. Về lý thuyết, hai thao tác này là ngược nhau, nhưng trong thực tế lại có sự khác biệt về hướng làm tròn: Upscaling chỉ sử dụng làm tròn xuống (mulDown), còn Downscaling có thể làm tròn lên hoặc xuống (divUp/divDown). Chính sự không nhất quán này đã tạo ra lỗ hổng cho cuộc tấn công. Nguyên nhân gốc rễ của lỗ hổng nằm ở việc hàm BaseGeneralPool._swapGivenOut() sử dụng làm tròn xuống khi Upscaling swapRequest.amount. Giá trị sau khi làm tròn xuống này được dùng làm amountOut cho đầu vào của _onSwapGivenOut(), dẫn đến amountIn cuối cùng tính được nhỏ hơn nhu cầu thực tế, vi phạm nguyên tắc thiết kế thông thường là làm tròn phải có lợi cho giao thức. Đối với các pool như (wstETH/rETH/cbETH), kẻ tấn công có thể dùng lượng tài sản đầu vào ít hơn để đổi lấy nhiều tài sản khác hơn, làm giảm bất biến D và từ đó kéo giá BPT xuống thấp. Kẻ tấn công đã thực hiện tấn công hai giai đoạn. Giai đoạn đầu hoàn thành logic tấn công chính trong một giao dịch duy nhất nhưng chưa rút lợi nhuận ngay; giai đoạn hai mới thực hiện giao dịch riêng để rút lợi nhuận. Giai đoạn đầu lại chia thành hai bước: tính toán tham số và batch swap. Lấy ví dụ giao dịch tấn công trên chuỗi Arbitrum (TX: 0x7da32e…55773), kẻ tấn công trước tiên lấy các tham số trong pool, bao gồm scaling factors, A (hệ số khuếch đại), tỷ giá BPT, swap fee, v.v., sau đó tính trickAmt và mô phỏng bằng cách triển khai hợp đồng phụ trợ. Kẻ tấn công kết hợp tính toán ngoại tuyến và mô phỏng trên chuỗi để điều chỉnh chính xác các tham số swap tiếp theo, bao gồm số lần lặp lại và giá trị đầu vào/đầu ra mỗi lần. Trong các lần lặp, thực hiện ba bước swap: bước đầu tiên đẩy số lượng token mục tiêu lên trickAmt + 1; bước thứ hai tiếp tục swap ra token mục tiêu, lúc này sẽ kích hoạt _upscale() làm tròn xuống; bước thứ ba swap ngược lại, cắt giảm số dư trong pool xuống “bỏ hai chữ số thập phân cao nhất” rồi swap lại, ví dụ 324,816 → 320,000. Trong một số trường hợp, do toán học StableSwap sử dụng phương pháp Newton–Raphson để giải, có thể thất bại, kẻ tấn công đã chuẩn bị hai lần fallback, thử lại với giá trị gốc nhân 9/10. Sau khi tấn công xảy ra, do một số cơ chế của Balancer không thể tạm dừng, tác động của cuộc tấn công bị khuếch đại, sau đó xuất hiện nhiều cuộc tấn công bắt chước và sao chép trên nhiều chuỗi, tổng thiệt hại vượt quá 125 millions USD. Sự kiện này đã phơi bày bốn vấn đề then chốt của các giao thức phi tập trung: cơ chế làm tròn không nhất quán, phương thức tấn công ngày càng tinh vi, không thể tạm dừng dẫn đến thiệt hại mở rộng, thiếu giám sát trạng thái khởi tạo và vận hành theo thời gian thực. Upscaling chỉ cho phép làm tròn xuống, còn Downscaling lại cho phép làm tròn hai chiều, sự bất đối xứng này dưới các tham số cực đoan sẽ tích tụ thành mất độ chính xác có thể khai thác. Hướng làm tròn lẽ ra luôn có lợi cho giao thức, nhưng trong trường hợp này lại gây thiệt hại cho giao thức. Kẻ tấn công sử dụng phương pháp hai giai đoạn, giai đoạn đầu thực hiện tấn công nhưng không có lợi nhuận trên sổ sách, giai đoạn hai mới rút tiền riêng, nhằm tránh các mô hình giám sát trên chuỗi. Mỗi bước tấn công đều kết hợp mô phỏng ngoài chuỗi và trên chuỗi, hợp đồng phụ trợ thậm chí còn tái sử dụng cả phần triển khai StableMath của Balancer, kể cả thông báo lỗi cũng giống hệt. Sau khi tấn công, nhiều chuỗi khác cũng bị ảnh hưởng, nhiều dự án fork cũng bị tác động, cho thấy chỉ cần toán học ổn định và logic làm tròn giống nhau, lỗ hổng có thể lan rộng khắp hệ sinh thái. Sự kiện này cho thấy các giao thức DeFi cần toán học chính xác hơn, kiểm tra làm tròn nghiêm ngặt hơn và cơ chế mô phỏng chống đường dẫn nghi ngờ, cũng như khả năng tạm dừng khẩn cấp khi có sự cố bất thường. [Bản gốc bằng tiếng Anh]