Một chiếc lông vũ có thể đánh chìm một con tàu – Phân tích vụ tấn công Balancer gây thiệt hại hơn 100 triệu đô la.

Vào ngày 3 tháng 11 năm 2025, Balancer v2, một giao thức nhà tạo lập thị trường tự động phi tập trung lâu đời, đã bị tấn công, gây thiệt hại khoảng 120 triệu đô la trên nhiều Chuỗi cho một số dự án, bao gồm cả giao thức fork của nó. Điều này càng làm trầm trọng thêm hệ sinh thái DeFi vốn đã trì trệ.

Tác giả: Kong & Lisa

Biên tập viên: 77

bối cảnh

Vào ngày 3 tháng 11 năm 2025, Balancer v2, một giao thức nhà tạo lập thị trường tự động phi tập trung lâu đời, đã bị tấn công, gây thiệt hại khoảng 120 triệu đô la trên nhiều Chuỗi cho một số dự án, bao gồm cả giao thức fork. Điều này càng làm trầm trọng thêm tình trạng trì trệ của hệ sinh thái DeFi. Sau đây là phân tích chi tiết về cuộc tấn công lần của đội ngũ bảo mật SlowMist :

nguyên nhân gốc rễ

Trong triển khai Composable Stable Pool của Balancer v2 (dựa trên Stable Math của Curve StableSwap), có một vấn đề về độ chính xác trong phép tính số học dấu phẩy cố định của các hệ số tỷ lệ, dẫn đến chênh lệch giá/lỗi nhỏ nhưng tích lũy trong các giao dịch hoán đổi token. Kẻ tấn công có thể khai thác các giao dịch hoán đổi nhỏ trong thanh khoản thấp để khuếch đại lỗi này nhằm thu lợi nhuận tích lũy đáng kể.

Điều kiện tiên quyết

Trước khi bắt đầu phân tích, chúng ta cần hiểu một số khía cạnh chính của Balancer để hiểu được nội dung của phân tích lần.

Bể bơi ổn định có thể cấu thành

Nhóm tài sản ổn định có thể cấu thành là nhóm hoán đổi token được thiết kế riêng cho tài sản dự kiến ​​giao dịch ở mức gần ngang giá hoặc tỷ giá hối đoái đã biết. Ví dụ bao gồm USDC/USDT được hoán đổi theo tỷ lệ gần 1:1, hoặc WETH/stETH được hoán đổi theo tỷ giá hối đoái đã biết.

Mã thông báo nhóm cân bằng (BPT)

BPT đại diện cho thị phần trong nhóm Balancer. Người dùng nhận được BPT khi họ thêm thanh khoản vào nhóm, đại diện cho thị phần thanh khoản của họ trong nhóm.

Khả năng kết hợp

Các nhóm thanh khoản cho phép nhà cung cấp thanh khoản hoán đổi tài sản với tài sản thanh khoản để cải thiện hiệu quả vốn. Ví dụ: có thể hoán đổi giữa token BPT và token thanh khoản như WETH/stETH.

Hệ số tỷ lệ

Các nhóm cơ sở của Balancer sử dụng phương pháp quản lý độ chính xác thập phân và hướng làm tròn, đảm bảo rằng tất cả các quỹ, trước khi đưa vào nhóm để tính toán, đều có độ chính xác và hướng làm tròn thập phân được tối ưu hóa để mang lại lợi ích cho nhóm thông qua các yếu tố mở rộng.

Hoán đổi hàng loạt

Tính năng hoán đổi hàng loạt cho phép người dùng hoán đổi nhiều token khác nhau trong cùng một hoặc nhiều nhóm trong một giao dịch. Các nhóm sử dụng giá trị ảo để hạch toán nội bộ và quyết toán sau khi hoán đổi hàng loạt hoàn tất.

Phân tích tấn công

Ở đây, chúng ta lấy hai giao dịch liên quan đến cuộc tấn công vào Ethereum làm ví dụ:

Giao dịch tấn công: 0x6ed07db1a9fe5c0794d44cd36081d6a6df103fab868cdd75d581e3bd23bc9742

Giao dịch rút tiền: 0xd155207261712c35fa3d472ed1e51bfcd816e616dd4f517fa5959836f5b48569

1. Kẻ tấn công đầu tiên đã khởi chạy một giao dịch tấn công thông qua chức năng hoán đổi số lượng lớn, sử dụng BPT để hoán đổi lượng lớn token thanh khoản khỏi nhóm, khiến lượng token thanh khoản thanh khoản của nhóm xuống rất thấp.

1. Sau khi lượng dự trữ token thanh khoản của nhóm giảm , những kẻ tấn công bắt đầu hoán đổi token thanh khoản (osETH/WETH).

1. Cuối cùng, token thanh khoản được đổi lại thành token BPT và quá trình này được lặp lại trên nhiều nhóm.

1. Sau khi hoàn tất giao dịch tấn công, kẻ tấn công đã sử dụng một giao dịch rút tiền riêng biệt để gọi hàm manageUserBalance của Vault nhằm rút lợi nhuận. Giao dịch này giống với giao dịch mà một số nhà phân tích trước đó đã nhầm lẫn là giao dịch tấn công và phân tích, nhưng thực chất nó chỉ là một giao dịch rút tiền thông thường sử dụng logic rút tiền thông thường.

1. Vậy tại sao kẻ tấn công dường như có thể dễ dàng rút tiền từ Vault mà không cần trả bất kỳ token thông qua các thao tác trên? Chỉ cần quan sát đơn giản, chúng ta có thể thấy rằng sau khi kẻ tấn công hoàn tất giao dịch hoán đổi số lượng lớn, số dư sổ cái nội bộ của Vault tăng lên, cho phép kẻ tấn công trực tiếp rút số dư này khỏi Vault.

Tiếp theo, chúng tôi sẽ phân tích chi tiết lý do tại sao kẻ tấn công có thể tạo ra sự tăng trưởng số dư mà không cần trả giá bất kỳ token .

Phân tích nguyên tắc

Dựa trên phân tích tấn công ở trên, chúng ta có thể thấy rằng kẻ tấn công chủ yếu đạt được mục đích thông qua ba bước:

1. Sử dụng BPT để đổi lấy token thanh khoản ;
2. Thực hiện hoán hoán đổi token thanh khoản ;
3. Đổi token thanh khoản trở lại BPT.

Trước tiên, chúng ta sẽ phân tích quy trình trao đổi BPT lấy token thanh khoản . Vì loại giao dịch `kind` của kẻ tấn công là 1, nên nhóm sẽ sử dụng số tiền trao đổi của kẻ tấn công là `amountOut` để tính toán số tiền `amountIn` mà kẻ tấn công nên cung cấp cho giao dịch. Chúng ta sẽ không đi sâu vào Chuỗi lệnh gọi phức tạp ở đây; chúng ta sẽ trực tiếp phân tích hàm `_swapWithBpt` cơ bản của giao dịch BPT.

Hàm `_swapWithBpt` trước tiên sử dụng hàm `_upscaleArray` để điều chỉnh số lượng token dự trữ trong nhóm bằng cách sử dụng hệ số điều chỉnh để đảm bảo độ chính xác về giá và hướng làm tròn nhất quán. Hàm `_upscaleArray` thực hiện thao tác điều chỉnh cụ thể bằng cách sử dụng `FixedPoint.mulDown`. Chúng ta có thể nhanh chóng thấy rằng `mulDown` làm tròn kết quả tính toán xuống, tức là cắt bớt phần thập phân.

Điều này sẽ khiến bất kỳ số thập phân nào trong dự trữ của nhóm bị cắt bớt trong quá trình mở rộng quy mô. Như chúng ta đã biết từ trước, nhóm khả năng cấu thành là nhóm hoán đổi token được thiết kế riêng cho tài sản dự kiến ​​giao dịch ở mức gần ngang giá hoặc theo một tỷ giá hối đoái đã biết. Lấy WETH và osETH làm ví dụ, có một tỷ giá hối đoái đã biết giữa chúng. Do đó, khi tính toán dự trữ osETH thực tế, cần phải nhân với tỷ giá hối đoái rồi mở rộng quy mô để thống nhất giá.

Thật không may, do tỷ giá hối đoái, việc tính toán số tiền dự trữ của osETH chắc chắn sẽ dẫn đến kết quả là số thập phân bị cắt bớt.

Điều này dẫn đến số dư dự trữ của nhóm được tính toán thấp hơn dự kiến. Vì giá BPT được tính bằng cách chia tổng giá của token thanh khoản trong nhóm cho tổng lượng cung ứng token BPT, nên lỗi này sẽ khiến giá BPT thấp hơn dự kiến.

Bằng cách lợi dụng chênh lệch giá do lỗi này gây ra, kẻ tấn công sẽ thu được một khoản lợi nhuận nhỏ khi đổi token thanh khoản sang token BPT ở bước thứ ba của giao dịch hoán đổi số lượng lớn. Tuy nhiên, khoản lợi nhuận này rõ ràng còn rất xa so với khoản lợi nhuận khổng lồ mà kẻ tấn công thu được, vì vậy chìa khóa nằm ở bước thứ hai của giao dịch hoán đổi số lượng lớn.

Kẻ tấn công vẫn sử dụng loại sàn giao dịch loại 1 khi thực hiện hoán đổi thanh khoản. Bằng cách phân tích trực tiếp hàm hoán đổi cơ bản, chúng ta có thể nhanh chóng phát hiện ra rằng hàm _swapGivenOut trước tiên thực hiện việc mở rộng thông qua hàm _upscale:

Tương tự như hàm `_upscaleArray` trước đó, giá trị tỷ lệ của số tiền trao đổi của người dùng được cắt bớt thành số thập phân bằng hàm `FixedPoint.mulDown`. Điều này dẫn đến số lượng token đầu vào cuối cùng cần thiết (`amountIn`) ít hơn dự kiến. Lỗi này không đáng kể nếu số tiền trao đổi lớn, nhưng có thể dẫn đến độ lệch đáng kể nếu số tiền trao đổi nhỏ.

Những kẻ tấn công đã làm chính xác như vậy: trong bước thứ hai của quá trình hoán đổi hàng loạt, trước tiên chúng giảm số dư osETH trong nhóm, sau đó thực hiện chính xác một lần hoán đổi quy mô nhỏ 17wei osETH.

Số dư thực tế phải là 17,98825094772952 khi thực hiện tính toán tỷ lệ.

Tuy nhiên, do bị cắt bớt phần thập phân, số dư cuối cùng vẫn là 17wei, tức là 0,98825094772952. So với 17, việc mất độ chính xác đã gây ra độ lệch rất lớn. Số lượng token đầu vào được tính theo cách này cũng sẽ gây ra độ lệch rất lớn.

Để đảm bảo độ lệch này có thể tích lũy theo chu kỳ, ở bước thứ hai của quá trình hoán đổi hàng loạt, kẻ tấn công sẽ hoán đổi osETH trở lại WETH để đảm bảo vẫn còn đủ thanh khoản cho lần .

Vì WETH là token được neo theo tiền tệ nên quá trình trao đổi osETH -> WETH được thực hiện ở 1e18, do đó sẽ không bị ảnh hưởng bởi sự tích tụ của các lỗi trước đó.

Bây giờ chúng ta có thể hiểu rõ toàn bộ quá trình tấn công:

1. Những kẻ tấn công đã làm giảm lượng dự trữ token thanh khoản của nhóm bằng cách đổi BPT lấy token thanh khoản để chuẩn bị cho các giao dịch hoán đổi nhỏ;
2. Điều này nhằm chuẩn bị cho việc kiểm soát chính xác các lỗi về độ chính xác trong các giao dịch hoán đổi nhỏ bằng cách hoán đổi osETH -> WETH giữa token thanh khoản ;
3. Lỗi độ chính xác được tích lũy chính xác thông qua các lần hoán đổi osETH -> WETH;
4. Thanh khoản được khôi phục thông qua việc hoán đổi WETH -> osETH giữa token thanh khoản ;
5. Lặp lại các bước 2-4 liên tục sẽ khuếch đại lỗi;
6. Đổi lại token thanh khoản để lấy token BPT nhằm khôi phục sự cân bằng thanh khoản;
7. Bằng cách khai thác lỗi khuếch đại từ hoán đổi token số lượng nhỏ, số lượng token " Ra" tại thời quyết toán cuối cùng lớn hơn nhiều so với số lượng token " Vào" cần thiết, do đó tạo ra lợi nhuận khổng lồ.

Phân tích MistTrack

Do số lượng dự án liên quan lớn nên phần này chỉ phân tích các địa chỉ chính và dòng tiền trong sự cố lần.

1. Địa chỉ 0xaa760d53541d8390074c61defeaba314675b8e3f

Lợi nhuận: Thu nhập từ Ethereum bao gồm nhiều token khác nhau như osETH và USDC.

Chi tiết chuyển khoản: Sau khi đổi nhiều loại token như ezETH, weETH và ankrETH, cũng như một số osETH, lấy ETH, số tiền đã được chuyển đến địa chỉ 0xf19fd5c683a958ce9210948858b80d433f6bfae2.

Trạng thái số dư: chủ yếu bao gồm 7.838,3569 WETH và 7.000 ETH.

Nguồn tài trợ ban đầu: địa chỉ 0x506d1f9efe24f0d47853adca907eb8d89ae03207, nguồn tài trợ đến từ gas.zip.

Phân tích địa chỉ 0x506d1f9efe24f0d47853adca907eb8d89ae03207 cho thấy các chi tiết giao dịch sau trong gas:

Địa chỉ này đã nhiều lần phân tán ETH từ Arbitrum trên nhiều Chuỗi trước khi phát động các cuộc tấn công. Nếu truy ngược lại, số tiền trong địa chỉ 0x506d1f9efe24f0d47853adca907eb8d89ae03207 ban đầu có thể được truy ngược về Tornado Cash.

• Tornado Cash → 0x86fedad11c4765700934639f1efe1fc01355c982: 100 ETH + 0,1 ETH rút từ Tornado Cash đã được chuyển vào địa chỉ này.
• 0x86fedad11c4765700934639f1efe1fc01355c982 → 0x766a892f8ba102556c8537d02fca0ff4cacfc492: Chuyển 15 ETH.
• 0x766a892f8ba102556c8537d02fca0ff4cacfc492 → Chuỗi Chuỗi và thực hiện thao tác gas.zip: Chuyển 5 ETH từ Ethereum sang Arbitrum và chuyển đến địa chỉ 0x506de24d01e6c8623307c9ff5e3c8a945b553207.

2. Địa chỉ 0xf19fd5c683a958ce9210948858b80d433f6bfae2

Khả năng sinh lời: Địa chỉ này là một nút chuyển tiếp cốt lõi, nhận tiền từ nhiều Chuỗi và địa chỉ ngược dòng.

Nguồn ngược dòng: Chuyển USDX và sUSDX từ địa chỉ Arbitrum 0x872757006b6F2Fd65244C0a2A5fdd1f70A7780f4;

stS từ địa chỉ Sonic 0x045371528A01071D6E5C934d42D641FD3cBE941c;

Các giao dịch chuyển tiền đến từ các địa chỉ Ethereum 0xaa760d53541d8390074c61defeaba314675b8e3f và 0x506d1f9efe24f0d47853adca907eb8d89ae03207.

Chi tiết chuyển khoản: Tài sản được trao đổi lấy ETH và WETH trên Ethereum thông qua các nền tảng như Velora, CowSwap, KyberSwap và ODOS, và một số tài sản được chuyển qua Chuỗi tới Arbitrum và Sonic thông qua LI.FI.

Đổi stS lấy S trên Sonic bằng KyberSwap.

Trạng thái số dư: Ngoài việc chuyển 7.000 ETH đến địa chỉ trên 0xaa760d53541d8390074c61defeaba314675b8e3f, không có khoản tiền nào khác được chuyển ra.

Các địa chỉ liên quan đã được thêm vào cơ sở dữ liệu địa chỉ độc hại AML của SlowMist và chúng tôi sẽ tiếp tục theo dõi bất kỳ chuyển động tiền bất thường nào.

Vào ngày 6 tháng 11, Balancer đã đưa ra tuyên bố chính thức, cho biết mặc dù lần có tác động rộng rãi, nhưng phản ứng nhanh chóng bên long đã giúp giảm đáng kể thiệt hại trong thời gian ngắn.

Tiến độ tài trợ hiện tại như sau:

1. SEAL Whitehat Safe Harbor (BIP-726, tháng 10 năm 2024): Nhờ khuôn khổ pháp lý của SEAL Whitehat Safe Harbor (BIP-726) có hiệu lực vào tháng 10 năm 2024, đội ngũ Mũ trắng đã có thể can thiệp nhanh chóng và phối hợp xử lý sự cố.
2. Cơ chế tạm dừng khẩn cấp tự động của HyperNative đã được kích hoạt: Vào lúc 08:06 UTC, hệ thống tạm dừng khẩn cấp của Hypernative đã được kích hoạt; đến 08:07 UTC, tất cả các nhóm CSPv6 trên mạng bị ảnh hưởng đã bị tạm dừng để ngăn chặn sự lây lan thêm.
3. Tất cả các nhóm thanh khoản CSPv6 có thể bị tạm dừng đều đã vào chế độ phục hồi, bao gồm cả các nhóm thanh khoản TVL thấp trước đây không được đưa vào thống kê.
4. Chức năng nhà máy CSPv6 bị vô hiệu hóa: Không thể tạo nhóm lỗ hổng mới cho đến khi bản sửa lỗi hoàn tất.
5. Mọi khích lệ và phát thải từ các nhóm bị ảnh hưởng đã bị chấm dứt để bảo toàn tài sản thưởng của BAL và đối tác.
6. nhà cung cấp thanh khoản lớn đã thoát ra an toàn: bao gồm Crypto.com (khoảng 800.000 đô la, cdcETH/wstETH) và Ether.fi (khoảng 1.060.000 đô la, eBTC/wBTC).
7. Stakewise đã thu hồi được 5.041 osETH (khoảng 19 triệu đô la Mỹ) và 13.495 osGNO (khoảng 1,7-2 triệu đô la Mỹ), chiếm khoảng 73,5% tổng số osETH bị đánh cắp. Tài sản sẽ được trả lại cho người dùng bị ảnh hưởng theo tỷ lệ tương ứng.
8. Mạng xác thực Berachain tạm dừng: Để kiểm soát rủi ro của Balancer v2 trên BEX, các hoạt động trên Chuỗi đã bị tạm dừng và một fork khẩn cấp đã được khởi tạo.
9. Sonic Labs đóng băng các địa chỉ liên quan: Các địa chỉ nghi ngờ là kẻ tấn công có liên quan đến Beets (một fork Balancer v2 trên Sonic) đã bị đóng băng để ngăn chặn các hoạt động chuyển hoặc trao đổi tiền tiếp theo.
10. Robot MEV cơ bản hỗ trợ quá trình thu hồi: đã thu hồi được khoảng 150.000 đô la.
11. Đội ngũ Mũ trắng BitFinding: Đã chặn và thu hồi thành công khoảng 600.000 đô la tài sản trên mạng chính.
12. Monerium đóng băng tài sản EURe: khoảng EURe đã bị khóa để ngăn chặn dòng tiền tiếp theo.
13. Hạn chế của Cầu nối Gnosis : Phối hợp với đội ngũ Monerium, việc chuyển giao chuỗi Chuỗi trên Chuỗi Gnosis đã bị hạn chế tạm thời để giảm rủi ro lan truyền chuỗi Chuỗi .
14. Đội ngũ SEAL đang liên lạc với những kẻ tấn công: Họ đang tiếp tục đàm phán để trả lại tiền theo khuôn khổ của SEAL.
15. Nhiều đội ngũ Mũ trắng đang tham gia hỗ trợ: nhiều đội ngũ bảo mật, bao gồm SNP, đang hỗ trợ phân tích, giải cứu và thu hồi tiền.

Hiện tại, Balancer đang tích cực hợp tác với các đối tác bảo mật, nhà nghiên cứu, sàn giao dịch và đội ngũ Mũ trắng để hỗ trợ việc thu hồi tiền. Báo cáo phân tích chính thức chi tiết hơn sẽ được công bố sau khi quá trình xác minh và thanh lý hoàn tất.

Tóm tắt

Cốt lõi của cuộc tấn công lần nằm ở việc kẻ tấn công khai thác lỗ hổng mất độ chính xác trong triển khai Composable Stable Pool của giao thức Balancer v2 khi thực hiện phép tính số học dấu phẩy cố định nguyên trên các hệ số tỷ lệ. Bằng cách cẩn thận tạo ra các giao dịch hoán đổi số lượng nhỏ, kẻ tấn công đã khuếch đại lỗi do lỗ hổng này gây ra, cho phép chúng tạo ra lợi nhuận khổng lồ thông qua các giao dịch hoán đổi số lượng lớn. Đội ngũ bảo mật SlowMist khuyến nghị các nhóm dự án và kiểm toán tăng cường phạm vi kiểm tra cho các tình huống cực đoan và điều kiện biên khi đối diện những tình huống tương tự, đặc biệt là khi cân nhắc các chiến lược xử lý chính xác trong các tình huống thanh khoản thấp.

tham khảo

[1] https://docs-v2.balancer.fi/concepts/pools/composable-stable.html

[2] https://docs.balancer.fi/concepts/core-concepts/balancer-pool-tokens.html

[3] https://docs.balancer.fi/concepts/vault/token-scaling.html

[4] https://docs-v2.balancer.fi/reference/swaps/batch-swaps.html

[5] https://docs-v2.balancer.fi/concepts/advanced/valuing-bpt/valuing-bpt.html#informational-price-evaluation

Tuyên bố miễn trừ trách nhiệm: Là một nền tảng thông tin blockchain, các bài viết được đăng trên trang web này chỉ thể hiện quan điểm tác giả và khách truy cập, không phản ánh quan điểm của Web3Caff. Thông tin trong bài viết chỉ tham khảo và không cấu thành bất kỳ lời khuyên hay ưu đãi đầu tư nào. Vui lòng tuân thủ luật pháp và quy định hiện hành của quốc gia hoặc khu vực của bạn.