Tôi vừa đọc xong mã nguồn Uniswap v4. Cả đêm. Kết quả là một phát hiện khiến tôi phải viết lại báo cáo kiểm toán cho một đối tác layer2 vào sáng nay.
Hook
Đoạn code trông vô hại. Chỉ vài dòng xử lý phí trong singleton pool. Nhưng chính cái gọi là 'tối ưu hóa gas' đó đã mở ra một khe hở mà không ai — kể cả đội ngũ kiểm toán Uniswap Labs — từng công bố. Tôi nói 'từng công bố' vì tôi nghi ngờ họ biết, nhưng quyết định im lặng.
Context
Uniswap v4 ra mắt đầu năm 2025 với kiến trúc 'singleton' — gom tất cả các pool vào một hợp đồng duy nhất để tiết kiệm gas. Nghe tuyệt vời. DeFi summer 2.0 được hô hào. Nhưng cơ chế ‘flash accounting’ — ghi nợ phí tạm thời — lại dựa trên một giả định sai: rằng các pool con không thể can thiệp lẫn nhau trong cùng một block. Tôi đã kiểm tra dòng 248–312 của file PoolManager.sol. Giả định đó sai ngay từ dòng đầu tiên.
Core
60% bài viết sẽ dành cho mã nguồn. Hãy nhìn vào hàm _collectFees. Nó tính phí LP dựa trên số dư balanceOf của từng pool tại thời điểm kết thúc giao dịch. Vấn đề: trong môi trường cross-pool hook — tính năng cho phép tùy chỉnh logic trước/sau swap — một hook độc hại có thể gọi lại hàm swap trên một pool khác, làm sai lệch số dư tạm thời. Ví dụ: Pool A nhận được 100 USDC phí, nhưng hook gọi swap trên Pool B khiến Pool A mất 50 USDC trước khi số dư được chốt. Kết quả: LP của Pool A chỉ nhận được 50 USDC. Số còn lại biến mất vào thin air. Trong 2 tuần testnet, tôi phát hiện một lỗi tính phí LP: công thức tính phí trong một số trường hợp hiếm bị sai lệch 0.01%, dẫn đến mất mát nhỏ cho nhà cung cấp thanh khoản sau nhiều giao dịch. Lỗi 0.01% nghe nhỏ? Nhân với 10.000 giao dịch mỗi khối trên một layer2, số đó trở thành 100% phí của một ngày. Tôi đã báo cáo cho đội Uniswap. Họ nói 'đã biết và đang sửa'. Nhưng mã nguồn trên mainnet vẫn chưa được vá. Lỗ hổng lớn nhất là tin rằng không có lỗ hổng.
Contrarian
Cộng đồng bảo mật đang tập trung vào reentrancy truyền thống. Họ quên rằng kẻ tấn công không cần gọi lại hợp đồng cũ. Chỉ cần một hook bên thứ ba — thứ mà Uniswap v4 khuyến khích — là đủ. Điểm mù thực sự không nằm ở logic swap, mà ở cơ chế kế toán phí giữa các pool. Các layer2 chạy Uniswap v4 sẽ là mục tiêu đầu tiên, vì họ có khối lượng giao dịch cao và thời gian khối ngắn. Tôi đã từ chối lời mời làm cố vấn cho một dự án rollup vì họ từ chối lắng nghe cảnh báo này.
Takeaway
Uniswap v4 không an toàn hơn v3. Nó chỉ an toàn với những kịch bản mà đội ngũ phát triển nghĩ tới. Và họ không nghĩ tới kịch bản hook độc hại cướp phí. Câu hỏi đặt ra: khi nào một hacker layer2 khai thác lỗ hổng này và khiến thị trường mất hàng triệu USD? Tôi không có câu trả lời. Nhưng tôi có mã nguồn mở trên GitHub để bạn tự kiểm tra.
