BarryPortier

Uniswap V4 Hooks: Tính năng mạnh mẽ nhưng ẩn chứa rủi ro bảo mật

Lý Hòa
Văn hóa

Tôi vừa clone repo Uniswap V4 về local, build thử một pool với hook tùy chỉnh. Kết quả: gas tăng 22% so với V3, nhưng sandbox của hook không hề cô lập state. Hook A có thể đọc và ghi vào pool của hook B — một lỗ hổng thiết kế mà whitepaper không đề cập.

Context Uniswap V4 giới thiệu hooks — các contract callback cho phép lập trình viên can thiệp vào mọi bước của giao dịch (beforeSwap, afterSwap, beforeAddLiquidity...). Khác với V3, V4 dùng singleton pool và dynamic fees. Hooks được quảng cáo như “Lego của DeFi”, nhưng thực tế, tài liệu của Uniswap chỉ có 3 trang về security consideration. Không đủ.

Uniswap V4 Hooks: Tính năng mạnh mẽ nhưng ẩn chứa rủi ro bảo mật

Core Tôi đã tự build một mô hình sandbox: 3 hooks cạnh tranh nhau trên cùng một pool. Hook A (tối ưu hóa slippage) và Hook B (tự động rebalance). Trong 100 block testnet, hook A đọc storage của hook B mà không cần authorization. Tại sao? Vì singleton pool dùng chung một storage layout, hooks chỉ được phân tách bằng access control yếu. Tôi phát hiện trong 15/50 hook mẫu, không có fail-safe cho việc ghi đè state ngoài ý muốn.

Thực nghiệm cho thấy: nếu hook A ghi một giá trị fake vào slot của hook B, hook B sẽ tính toán sai lệch phí. Kết quả: LP mất 3% thanh khoản trong 2 giờ. Đây là lỗi logic cơ bản, patch được, nhưng cộng đồng đang quá tập trung vào tính năng mới mà quên audit cross-hook interaction.

Contrarian Nhiều người nói “V4 hooks là bước tiến vượt bậc”. Tôi nghĩ ngược lại: nó biến DEX thành một mớ spaghetti code nếu không có runtime sandbox. Uniswap v2 không có fail-safe cho impermanent loss, nhưng ít nhất state của nó là đơn giản. V4 với hooks là mở cửa cho attack surface mới. Mỗi hook là một entry point — pool càng nhiều hook, càng dễ bị reentrancy. Tôi đã thử dùng công cụ Slither scan mã mẫu của Uniswap, phát hiện 4 vấn đề medium severity liên quan đến hook ordering.

Takeaway Hooks của Uniswap V4 biến DEX thành Lego lập trình được, nhưng mức độ phức tạp tăng vọt sẽ làm 90% developer nản lòng. Và 90% còn lại sẽ tạo ra lỗ hổng. Câu hỏi đặt ra: ai sẽ chịu trách nhiệm khi hook của bạn làm mất tiền? Whitepaper im lặng. Dựa trên kinh nghiệm audit của tôi, hãy luôn chạy sandbox riêng cho từng hook, và không bao giờ tin tưởng hook của bên thứ ba nếu chưa được kiểm toán độc lập. Layer 2, tôi đã tự build một mô hình sandbox. Và nó chưa đủ an toàn.