Có một dòng code trong Uniswap v4 đã ám ảnh tôi suốt ba tháng qua. Nó nằm trong file PoolManager.sol dòng 137–145, nơi hooks được gọi trước khi cập nhật số dư. Khi tôi lần đầu đọc, tôi nghĩ—đây chỉ là một hook callback bình thường. Nhưng càng đào sâu, tôi càng thấy nó giống một khe nứt giữa hai mảng kiến tạo: một bên là tính linh hoạt vô hạn, một bên là bề mặt bảo mật dễ vỡ. Đây không phải là một bài phân tích lỗ hổng kiểu clickbait. Đây là một bức ảnh chụp cắt lớp về kiến trúc mà tôi gọi là “cơn bão hook” sẽ đến trong vài tháng tới.
Khi Uniswap công bố v4 vào tháng 6 năm 2023, cộng đồng lập tức bị cuốn hút bởi lời hứa về các hook—những hợp đồng nhỏ có thể can thiệp vào mọi ngóc ngách của pool thanh khoản. Trong hai năm làm audit cho các dự án AMM, tôi chưa từng thấy một cơ chế nào vừa đẹp vừa nguy hiểm đến thế. Và điều đáng sợ nhất là hầu hết mọi người chỉ nhìn vào hook từ góc độ ứng dụng: tạo thanh khoản động, phí linh hoạt, lệnh giới hạn. Họ quên mất rằng mỗi dòng code là một rạn san hô chờ được khám phá.
Context: Cơ chế giao thức
Uniswap v4 thay thế mô hình pool riêng lẻ bằng một singleton contract duy nhất gọi là PoolManager. Thay vì triển khai một hợp đồng mới cho mỗi cặp token, tất cả pool được quản lý tập trung, và mỗi pool có thể đính kèm một hook contract tùy chỉnh. Hook có thể override bảy điểm trong lifecycle của swap: beforeInitialize, afterInitialize, beforeSwap, afterSwap, beforeAddLiquidity, afterAddLiquidity, beforeRemoveLiquidity, và afterRemoveLiquidity. Mỗi hook trả về một bytes4 signature để xác nhận thành công, và nếu trả về sai, toàn bộ giao dịch revert.
Cái hay của thiết kế này là nó cho phép lập trình viên tự do mở rộng logic pool mà không cần fork Uniswap. Nhưng cái dở cũng chính ở đó—tự do là con dao hai lưỡi. Một hook được viết kém có thể phá hủy pool, drain thanh khoản, hoặc tạo ra backdoor tinh vi. Và vì hook được gọi bên trong cùng một transaction với tất cả các phép toán chính, nó có quyền truy cập vào toàn bộ trạng thái pool.
Core: Phân tích kỹ thuật và trade-off
Hãy đi vào code. Điểm mấu chốt nằm ở cách PoolManager gọi hook:
function _swap(SwapParams calldata params) internal returns (int256 amount0, int256 amount1) {
// ...
if (address(hook) != address(0)) {
bytes4 result = hook.beforeSwap(msg.sender, params);
if (result != IHooks.beforeSwap.selector) revert InvalidHookSelector();
}
// Thực hiện swap
(amount0, amount1) = _computeSwap(params);
// Cập nhật số dư
_updateReserves(amount0, amount1);
if (address(hook) != address(0)) {
bytes4 result = hook.afterSwap(msg.sender, params, amount0, amount1);
if (result != IHooks.afterSwap.selector) revert InvalidHookSelector();
}
}Tôi đã dành hai ngày để trace từng dòng. Lỗ hổng không nằm ở hook—mà nằm ở giả định rằng hook sẽ không thay đổi trạng thái pool trong quá trình callback. beforeSwap được gọi trước khi _computeSwap chạy, nhưng hook có thể gọi lại PoolManager.swap (reentrantly) với cùng pool hoặc pool khác. Điều này có thể dẫn đến mismatch số dư nếu hook thao túng amount0 hoặc amount1 trả về từ afterSwap.
Thực tế, Uniswap đã cẩn thận thêm modifier lock để ngăn reentrancy. Nhưng modifier này chỉ khóa PoolManager ở cấp độ cao nhất—nó không ngăn hook gọi lại chính PoolManager nếu hook được triển khai như một contract riêng gọi sang PoolManager qua một external call. Và nếu hook sử dụng delegatecall? Mọi thứ trở nên tối hơn.
Tôi đã xây dựng một proof-of-concept: một hook có vẻ vô hại chỉ ghi log, nhưng thực tế nó gọi PoolManager.swap trong beforeSwap với một tham số khác, tạo ra một swap ảo làm sai lệch giá oracle của pool. Vì giá oracle được cập nhật sau _computeSwap, hook có thể khai thác chênh lệch để kiếm lợi mà không cần thanh khoản thực. Đây là một dạng sandwich attack mới trên v4.
Điểm mù ở đây là: độ phức tạp của hook khiến việc audit trở nên gần như bất khả thi nếu không có công cụ chuyên dụng. Một hook có thể chứa hàng trăm dòng code, gọi đến các oracle bên ngoài, tương tác với nhiều pool cùng lúc. Công cụ phân tích tĩnh hiện tại (Slither, Mythril) không thể mô phỏng hành vi động của hook trong môi trường multi-pool.
Contrarian: Lỗ hổng không phải là điểm yếu, mà là manh mối
Ai đó sẽ nói: “Uniswap v4 đã được audit bởi ba công ty hàng đầu, mọi lỗi đều được vá trước mainnet.” Tôi tin điều đó—về mặt cơ chế cốt lõi. Nhưng câu chuyện không dừng lại ở PoolManager. Câu chuyện bắt đầu khi hàng ngàn hook do cộng đồng viết được triển khai. Những hook đó sẽ không được audit bởi Uniswap. Chúng sẽ được audit bởi chính người dùng—nếu họ biết đọc code.
Tôi nhìn thấy một kịch bản giống như vụ Curve pool bị tấn công qua reentrancy vào tháng 7 năm 2023. Lỗi đó nằm ở một phiên bản Vyper, nhưng bản chất giống nhau: một deployment với tính năng mới (reentrancy guard không hoạt động) đã gây ra thiệt hại 60 triệu USD. Với Uniswap v4, mỗi hook là một “pool” riêng lẻ, và không có ai guarantee rằng tất cả hook đều an toàn. Mỗi byte lưu trữ là một câu chuyện chưa kể, và câu chuyện của hook có thể kết thúc bằng một DELEGATECALL tới một địa chỉ độc hại.
Điều phản trực giác là: tính linh hoạt của hook thực ra làm giảm bảo mật tổng thể, bởi vì nó chuyển trách nhiệm từ một đội ngũ chuyên nghiệp (Uniswap) sang hàng ngàn developer với kỹ năng và động cơ khác nhau. Trong môi trường tăng giá hiện tại, khi mọi người đang FOMO vào các hook hứa hẹn yield cao, rủi ro này sẽ bị che phủ bởi sự phấn khích. Tôi đã thấy điều này xảy ra với các yield aggregator năm 2021—và kết quả là hàng loạt rug pull.
Takeaway: Dự báo lỗ hổng
Tôi dự đoán trong vòng 6 tháng sau khi Uniswap v4 mainnet ra mắt (dự kiến Q1 2025), sẽ có ít nhất 5 sự cố bảo mật liên quan đến hook với tổng thiệt hại trên 20 triệu USD. Các sự cố này sẽ tập trung vào hai loại: (1) hook chứa backdoor ẩn cho phép deployer rút thanh khoản, và (2) hook lạm dụng reentrancy để thao túng giá trước khi swap. Đây không phải là lời tiên tri—mà là kết luận từ kinh nghiệm audit của tôi: bất kỳ hệ thống nào cho phép code không hạn chế can thiệp vào quy trình giao dịch đều sẽ bị khai thác theo cách sáng tạo hơn cả đội bảo mật tưởng tượng.
Liệu chúng ta có sẵn sàng đối mặt với cơn bão hook này? Hay chỉ ngồi nhìn các rạn san hô mã nguồn vỡ vụn dưới chân mình?
