Phân tích kỹ thuật: Balancer bị hack 120 triệu đô, lỗ hổng là gì?
Vấn đề chính của cuộc tấn công này nằm ở cách giao thức xử lý các giao dịch có giá trị nhỏ.
Original Article Title: " Phân Tích Kỹ Thuật Lỗ Hổng Hack Balancer 120 triệu đô"
Original Source: ExVul Security
Lời mở đầu
Vào ngày 3 tháng 11 năm 2025, giao thức Balancer đã bị tấn công trên nhiều chuỗi bao gồm Arbitrum và Ethereum, dẫn đến thiệt hại tài sản trị giá 120 triệu đô. Cuộc tấn công chủ yếu xuất phát từ lỗ hổng kép liên quan đến mất độ chính xác và thao túng Invariant.
Cơ sở hạ tầng của Chainlink từ lâu đã duy trì các tiêu chuẩn cao nhất trong không gian Web3, khiến nó trở thành lựa chọn tự nhiên cho X Layer, vốn dành riêng cho việc cung cấp các công cụ cấp tổ chức cho các nhà phát triển.
Vấn đề then chốt trong cuộc tấn công này nằm ở logic xử lý các giao dịch nhỏ của giao thức. Khi người dùng thực hiện trao đổi với số lượng nhỏ, giao thức sẽ gọi hàm _upscaleArray, sử dụng mulDown để làm tròn xuống các giá trị. Khi số dư trong giao dịch và số lượng đầu vào đều đạt đến một ranh giới làm tròn cụ thể (ví dụ: phạm vi 8-9 wei), sẽ xảy ra lỗi độ chính xác tương đối đáng kể.
Lỗi độ chính xác này được truyền sang quá trình tính toán giá trị Invariant D của giao thức, gây ra sự giảm bất thường của giá trị D. Sự dao động của giá trị D trực tiếp làm giảm giá của Balancer Pool Token (BPT) trong giao thức Balancer. Hacker đã lợi dụng giá BPT bị đè nén này thông qua một đường đi giao dịch được lên kế hoạch trước để thực hiện arbitrage, cuối cùng dẫn đến mất mát tài sản lớn.
Giao dịch bị khai thác:
https://etherscan.io/tx/0x6ed07db1a9fe5c0794d44cd36081d6a6df103fab868cdd75d581e3bd23bc9742
Giao dịch chuyển tài sản:
https://etherscan.io/tx/0xd155207261712c35fa3d472ed1e51bfcd816e616dd4f517fa5959836f5b48569
Phân tích kỹ thuật
Vector tấn công
Điểm vào của cuộc tấn công là hợp đồng Balancer: Vault , với hàm vào tương ứng là batchSwap, hàm này gọi nội bộ onSwap để trao đổi token.

Từ góc độ tham số và giới hạn của hàm, có thể rút ra một số thông tin:
1. Kẻ tấn công cần gọi hàm này thông qua Vault và không thể gọi trực tiếp.
2. Hàm sẽ gọi nội bộ _scalingFactors() để lấy hệ số tỷ lệ cho các thao tác tỷ lệ.
3. Thao tác tỷ lệ tập trung ở _swapGivenIn hoặc _swapGivenOut.
Phân tích mô hình tấn công
Cơ chế tính giá BPT
Trong mô hình stable pool của Balancer, Giá BPT là một điểm tham chiếu quan trọng quyết định số lượng BPT mà người dùng nhận được và số tài sản mà mỗi BPT nhận được.

Trong quá trình tính toán trao đổi của pool:

Phần đóng vai trò là mỏ neo giá BPT là một giá trị bất biến D, nghĩa là để kiểm soát giá BPT cần kiểm soát D. Hãy phân tích sâu hơn quá trình tính toán D:

Trong đoạn mã trên, quá trình tính toán D phụ thuộc vào mảng số dư đã được tỷ lệ hóa. Điều này có nghĩa là cần có một thao tác thay đổi độ chính xác của các số dư này, dẫn đến tính toán D không chính xác.
Nguyên nhân gốc rễ của mất độ chính xác

Thao tác tỷ lệ:

Như hình trên, khi đi qua _upscaleArray, nếu số dư rất nhỏ (ví dụ: 8-9 wei), việc làm tròn xuống trong mulDown sẽ dẫn đến mất độ chính xác đáng kể.
Chi tiết quá trình tấn công
Giai đoạn 1: Điều chỉnh đến ranh giới làm tròn

Giai đoạn 2: Kích hoạt mất độ chính xác (lỗ hổng cốt lõi)

Giai đoạn 3: Lợi dụng giá BPT bị đè nén để kiếm lời

Ở trên, kẻ tấn công sử dụng Batch Swap để thực hiện nhiều lần trao đổi trong một giao dịch:
1. Trao đổi đầu tiên: BPT → cbETH (điều chỉnh số dư)
2. Trao đổi thứ hai: wstETH (8) → cbETH (kích hoạt mất độ chính xác)
3. Trao đổi thứ ba: Tài sản cơ sở → BPT (chốt lời)
Tất cả các lần trao đổi này diễn ra trong cùng một giao dịch batch swap, chia sẻ cùng một trạng thái số dư, nhưng mỗi lần trao đổi đều gọi _upscaleArray để thay đổi mảng số dư.
Thiếu cơ chế callback
Quy trình chính được khởi tạo bởi Vault. Làm thế nào điều này dẫn đến tích lũy mất độ chính xác? Câu trả lời nằm ở cơ chế truyền mảng số dư.

Xem đoạn mã trên, mặc dù Vault tạo ra một mảng currentBalances mới mỗi lần gọi onSwap, nhưng trong Batch Swap:
1. Sau lần swap đầu tiên, số dư được cập nhật (nhưng do mất độ chính xác, giá trị cập nhật có thể không chính xác)
2. Lần swap thứ hai tiếp tục tính toán dựa trên kết quả của lần swap đầu tiên
3. Mất độ chính xác tích lũy, cuối cùng khiến giá trị invariant D giảm mạnh
Vấn đề then chốt:

Tóm tắt
Cuộc tấn công Balancer có thể được tóm tắt bởi các lý do sau:
1. Hàm tỷ lệ sử dụng làm tròn xuống: _upscaleArray sử dụng mulDown để tỷ lệ hóa, dẫn đến mất độ chính xác tương đối lớn khi số dư rất nhỏ (ví dụ: 8-9 wei).
2. Tính toán giá trị Invariant nhạy cảm với độ chính xác: Việc tính toán giá trị invariant D phụ thuộc vào mảng số dư đã tỷ lệ hóa, và mất độ chính xác ảnh hưởng trực tiếp đến việc tính toán D, khiến D giảm.
3. Thiếu xác thực thay đổi giá trị Invariant: Trong quá trình swap, không có xác thực để đảm bảo rằng sự thay đổi của giá trị invariant D nằm trong phạm vi hợp lý, cho phép kẻ tấn công liên tục lợi dụng mất độ chính xác để đè giá BPT.
4. Tích lũy mất độ chính xác trong Batch Swap: Trong cùng một batch swap, mất độ chính xác từ nhiều lần swap tích lũy lại và cuối cùng dẫn đến thiệt hại tài chính nghiêm trọng.
Hai vấn đề này—mất độ chính xác và thiếu xác thực—kết hợp với việc kẻ tấn công thiết kế cẩn thận các điều kiện biên, đã dẫn đến tổn thất này.
Tuyên bố miễn trừ trách nhiệm: Mọi thông tin trong bài viết đều thể hiện quan điểm của tác giả và không liên quan đến nền tảng. Bài viết này không nhằm mục đích tham khảo để đưa ra quyết định đầu tư.
Bạn cũng có thể thích
Top 3 đồng tiền điện tử mà các nhà phân tích dự đoán có thể tăng gấp 100 lần: Ozak AI, DOGE và XRP


Các thiết lập Altcoin trông mạnh mẽ: Nên mua khi giá giảm hay bắt dao rơi?

Cơn bão thanh lý cuốn trôi 303 triệu đô la Ethereum: Điều gì sẽ xảy ra tiếp theo với ETH?
