Bom Tấn Công: Một Lỗ Hổng Phổ Biến Khác Bị Bỏ Qua Trong DeFi?
Lỗ hổng vẫn còn đó, không phải FUD.
Tuần trước, tôi thấy một tweet lan truyền về một dự án DeFi bị khai thác, mất hơn 2 triệu USD. Mọi người lại đổ xô đi tìm lỗi trong contract, đổ lỗi cho oracle, cho team. Nhưng tôi thì nhìn vào một thứ khác: cấu trúc cơ bản của pool thanh khoản, cụ thể là cách nó xử lý phí.
Đây không phải là một exploit mới. Đây là một phiên bản cũ của một lỗi mà tôi đã thấy từ năm 2020, khi tôi tự audit Uniswap v2. AMM 2020: lỗi vẫn còn sống. Mọi người vẫn mắc phải những sai lầm cơ bản nhất.
____
Context: Cơ Chế Phí và Impermanent Loss
Hãy hiểu điều này: Mọi AMM đều có công thức tính phí. Uniswap tính 0.3%. Khi bạn swap, một phần phí đó được giữ lại trong pool, làm tăng giá trị của LP token. Vấn đề không phải là con số 0.3%, mà là khi nào nó được tính và làm tròn như thế nào.
Trong phần lớn các triển khai, phí được tính toán tại thời điểm giao dịch dựa trên amountIn và amountOut. Một số contract sử dụng số học với độ chính xác cao (18 decimals) để tránh mất mát. Nhưng khi bạn có một pool với biến động giá mạnh, công thức căn bậc hai trong tính toán phí có thể dẫn đến sai số làm tròn nhỏ.
Hãy đọc code. Một lỗi điển hình trông như thế này (giả mã):
function getOutputAmount(uint inputAmount, uint inputReserve, uint outputReserve) public pure returns (uint outputAmount) {
uint inputAmountWithFee = inputAmount * 997;
uint numerator = inputAmountWithFee * outputReserve;
uint denominator = (inputReserve * 1000) + inputAmountWithFee;
outputAmount = numerator / denominator;
}Vấn đề nằm ở chỗ chia số nguyên (/). Trong một giao dịch nhỏ lẻ, sai số là không đáng kể. Nhưng trong một pool có khối lượng giao dịch cực lớn, hàng nghìn giao dịch mỗi ngày, sai số làm tròn này tích lũy dần và tạo ra một lỗ hổng có thể khai thác được.
____
Core: Phân Tích Cấp Code và Sự Đánh Đổi
Đào sâu tận gốc: Lỗi nằm ở chỗ ẩn trong công thức.
Hãy tưởng tượng bạn có một pool ETH/USDC với tổng thanh khoản cực lớn. Mỗi lần swap, một phần nhỏ của phí (ví dụ, 0.0000001 ETH) bị mất đi do làm tròn. Nó không đáng kể? Sai.
Trong thị trường gấu, khi thanh khoản khan hiếm và khối lượng giao dịch giảm, các trader săn mồi (MEV bots) có thể lợi dụng điều này. Chúng có thể thực hiện vô số giao dịch nhỏ, mỗi lần đều tạo ra một lượng nhỏ “phí rò rỉ” ra ngoài contract (không được phân phối cho LP). Qua nhiều ngày, số tiền này có thể trở nên đáng kể và có thể bị rút ra bởi một ai đó (thường là kẻ tấn công đầu tiên phát hiện ra lỗi).
Đây không phải là một lỗi reentrancy hay overflow. Nó là một lỗi logic trong mô hình giá và phí. Nó tinh vi, khó phát hiện bằng các công cụ static analysis cơ bản. Nó đòi hỏi bạn phải chạy mô phỏng với dữ liệu lịch sử để thấy được tác động tích lũy.
Dự án bị khai thác tuần trước đã sử dụng một công thức AMM tùy chỉnh. Họ tự hào về “tính linh hoạt” của nó. Nhưng tính linh hoạt đó đã mở ra cánh cửa cho lỗ hổng này. Họ đã đánh đổi tính an toàn của một công thức đã được kiểm chứng (Uniswap v2/v3 gốc) để lấy một chút hiệu quả về mặt tính toán hoặc một tính năng mới.
____
Contrarian: Điểm Mù Bảo Mật
Chống đám đông kiên định: Vấn đề không phải là oracle hay admin key. Vấn đề là toán học cơ bản.
Hầu hết các security audit report đều tập trung vào các lỗ hổng bảo mật thông thường: reentrancy, access control, integer overflow. Những lỗi đó quan trọng. Nhưng chúng thường được phát hiện bởi các công cụ tự động. Lỗi mà tôi đang nói đến là một lỗi toán học thuần túy, nó nằm ngoài tầm với của hầu hết các automated scanner.
Các auditor thường không đủ thời gian hoặc động lực để ngồi hàng giờ mô phỏng từng công thức, kiểm tra từng trường hợp biên với số liệu thực tế. Họ dựa vào kinh nghiệm và pattern. Nhưng khi một dự án sửa đổi công thức AMM cốt lõi, họ vô tình tạo ra những pattern mới mà không ai có kinh nghiệm để nhìn ra.
Điểm mù ở đây là niềm tin mù quáng vào toán học. Team nghĩ rằng một công thức có vẻ đúng về mặt lý thuyết sẽ an toàn. Nhưng thực tế, các giao dịch không phải lý thuyết. Chúng là các phép chia số nguyên trong EVM với hàng triệu biến số. Một sai số 0.0001% có vẻ nhỏ, nhưng khi được nhân với khối lượng giao dịch hàng triệu USD, nó trở thành một lỗ hổng có khả năng sinh lời cao.
____
Takeaway: Dự Báo Lỗ Hổng
Hãy đọc code, đừng nghe hype. Nhìn vào công thức, đừng chỉ nhìn vào logo.
Tôi dự đoán rằng chúng ta sẽ thấy ngày càng nhiều các vụ khai thác kiểu này trong thị trường gấu. Khi khối lượng giao dịch giảm, LP thanh khoản trở nên kém hiệu quả hơn, và các lỗ hổng toán học nhỏ này sẽ trở thành miếng mồi ngon cho những kẻ săn mồi hiểu biết.
Câu hỏi dành cho anh em: Dự án DeFi bạn đang farm có đang tự hào về công thức AMM “độc đáo” của họ không? Nếu có, hãy tìm hiểu xem nó có mắc phải lỗi làm tròn phí như trên không. Nếu không, thời gian đào sâu vào code là đây.