Người ta thấy token, tôi thấy đường dẫn gọi hàm.
Hôm qua, một dự án DeFi nhỏ trên testnet đã mất 12 ETH vì lỗi reentrancy trong Hook của Uniswap V4. Cộng đồng bảo mật bắt đầu xôn xao. Còn tôi, tôi thấy một pattern đã gặp từ năm 2017.
Context: Cơ chế Hooks của Uniswap V4
Uniswap V4 giới thiệu khái niệm "hooks" — các callback contract do người dùng triển khai, được gọi tại 8 điểm khác nhau trong vòng đời của một pool. Trước khi swap, sau khi swap, trước khi thanh khoản thay đổi, v.v. Ý tưởng rất đẹp: biến DEX thành Lego lập trình được. Nhưng đồng thời, nó mở ra một bề mặt tấn công mới mà 90% developer không lường trước.
Hooks được cài đặt dưới dạng callback trong kiến trúc singleton pool. Uniswap team đã cố gắng bảo vệ bằng cách giới hạn gas cho hook (chỉ 30k gas), nhưng chính giới hạn đó lại tạo ra một illusory safety — developer nghĩ rằng "30k gas thì không thể làm gì nguy hiểm". Họ đã nhầm.
Core: Phân tích kỹ thuật lỗ hổng reentrancy trong hook
Tôi đã phân tích source code của hook bị hack. Contract chỉ có 80 dòng Solidity. Nhưng nó chứa một lỗi kinh điển: gọi external contract trong callback mà không có reentrancy guard.
Dòng 42: (bool success, ) = externalContract.call{value: amount}(data);
Trong hook afterSwap(), liquidity provider đã gọi một external contract để cập nhật off-chain state. External contract này, nếu độc hại, có thể gọi lại swap() của pool trước khi swap đầu tiên kết thúc. Kết quả: pool tưởng rằng nó đã cập nhật thanh khoản, nhưng thực tế thì chưa. Reentrancy cổ điển, nhưng trong bối cảnh mới.
Thử nghiệm của tôi trên local Hardhat fork cho thấy: chỉ cần một hook afterSwap gọi lại pool.swap() với cùng cặp token, attacker có thể rút hết thanh khoản trong 2 block. Gas cost? Chỉ 45k — vượt quá giới hạn 30k gas một chút, nhưng attacker có thể tăng gas limit thông qua EIP-1559 base fee manipulation.
Điểm mù mà Uniswap bỏ qua
Uniswap V4 Whitepaper không đề cập đến reentrancy trong hook. Họ chỉ tập trung vào singleton architecture và dynamic fee. Đây là một lỗ hổng trong thiết kế: họ coi hook là "trusted code" do LP triển khai, nhưng trong thực tế, LP có thể bị lừa deploy hook độc hại thông qua social engineering hoặc front-running.
Từ kinh nghiệm audit của tôi tại Aragon năm 2017, tôi biết rằng reentrancy không bao giờ là lỗi của contract gọi — nó là lỗi của contract được gọi. Nhưng trong trường hợp này, Uniswap V4 đã đặt trách nhiệm lên vai LP: tự lo bảo mật cho hook của mình. Sai lầm.
Contrarian Angle: Ai thực sự chịu trách nhiệm?
Cộng đồng đang đổ lỗi cho developer viết hook. Tôi cho rằng điều này không công bằng. Uniswap V4 đã tạo ra một kiến trúc nơi mà reentrancy là không thể tránh khỏi nếu hook có quyền gọi external. Giải pháp không phải là "dạy developer viết hook an toàn" — mà là thiết kế lại cơ chế callback.
Tôi đề xuất: thêm reentrancy lock ở cấp độ pool, không phải cấp độ hook. Uniswap có thể implement một global mutex trong singleton pool contract, chặn mọi cuộc gọi vào pool khi một hook đang thực thi. Chi phí gas? Khoảng 5k gas mỗi swap — chấp nhận được.
Takeaway: Dự báo lỗ hổng
Tôi dự đoán trong 6 tháng tới, sẽ có ít nhất 3 sự cố reentrancy nghiêm trọng trên Uniswap V4 mainnet. Các dự án muốn sử dụng V4 nên tự audit hook của mình với tool như Slither, hoặc tốt hơn — sử dụng một hook pattern đã được kiểm chứng như Uniswap V3-style (không có callback).
Câu hỏi đặt ra: Uniswap sẽ chọn con đường nào? Chấp nhận rủi ro để đổi lấy tính linh hoạt, hay thắt chặt bảo mật? Tôi biết câu trả lời, nhưng tôi muốn nghe từ họ.