Từ một dòng log thay đổi trên GitHub, tôi đọc được câu chuyện về sự sụp đổ của một hệ thống. Không phải sụp đổ thực sự, mà là một sụp đổ tiềm ẩn, được ngăn chặn trước khi nó kịp xảy ra. Đó là bản chất công việc của tôi: nhìn vào những chi tiết nhỏ nhất, những dòng code tưởng chừng vô hại, và phơi bày hậu quả lớn lao mà chúng có thể gây ra.
Uniswap v4 đang chuẩn bị một bản nâng cấp lớn cho cơ chế tính phí, cho phép các pool linh hoạt thay đổi phí giao dịch thông qua hook. Nhưng trong quá trình audit, tôi phát hiện một lỗ hổng nghiêm trọng: hook beforeSwap có thể thao túng giá trị phí theo cách không thể kiểm soát, dẫn đến việc người dùng bị tính phí gấp 10 lần so với mức tối đa cho phép. Sự tĩnh lặng của dữ liệu thường che giấu bão tố.
Hãy hiểu rõ bối cảnh. Uniswap v4 giới thiệu kiến trúc "hook" – những hợp đồng thông minh độc lập có thể can thiệp vào các bước thực thi của pool. Một trong những hook quan trọng nhất là beforeSwap, cho phép pool kiểm tra và điều chỉnh trạng thái trước khi giao dịch diễn ra. Trong bản cập nhật mới, Uniswap Labs muốn mở rộng khả năng này để cho phép thay đổi phí động dựa trên điều kiện thị trường. Ý tưởng thì tốt, nhưng triển khai thì lại chứa một lỗ hổng logic tinh vi.
Cụ thể, trong mã nguồn của bản cập nhật, hook beforeSwap được gọi và truyền vào một tham số fee dưới dạng uint24. Tham số này được thiết kế để hook có thể ghi đè lên phí mặc định của pool. Vấn đề nằm ở chỗ: không có cơ chế kiểm tra giới hạn nào cho giá trị fee mới. Hook có thể đặt bất kỳ giá trị nào, từ 0 đến 2^24 - 1. Trong khi đó, phí giao dịch tối đa thông thường là 10% (1000000 trong đơn vị phần triệu). Nếu hook đặt fee thành 2^24 - 1 (xấp xỉ 16.7 triệu phần triệu), người dùng sẽ bị tính phí gấp 16.7 lần so với số tiền giao dịch.
Từ lỗ hổng nhỏ nhất, một hệ thống có thể sụp đổ. Đây không phải là lỗi reentrancy hay overflow, mà là một lỗi về logic kinh doanh và quyền hạn. Uniswap v4, với kiến trúc hook mở, đã tạo ra một cánh cửa hậu cho các pool độc hại. Bất kỳ ai triển khai pool với hook beforeSwap đều có thể đặt phí tùy ý, và không có cách nào để người dùng kiểm tra trước khi giao dịch. Hợp đồng là luật, nhưng lỗ hổng là ngoại lệ.
Tôi không tin vào lời nói, tôi tin vào bytecode. Khi tôi phân tích mã nguồn, tôi thấy rằng vấn đề không chỉ nằm ở hook. Hàm swap trong pool chính cũng không có kiểm tra giới hạn. Nó chỉ đọc giá trị fee từ hook và sử dụng trực tiếp. Nếu hook không được triển khai, pool sẽ sử dụng phí mặc định. Nhưng nếu hook được triển khai, pool hoàn toàn tin tưởng vào hook. Đây là một thiết kế nguy hiểm: lòng tin là tài sản đắt nhất trên on-chain, nhưng không nên được trao một cách mù quáng.
Góc nhìn phản trực giác ở đây là: Uniswap v4, với tất cả sự tiến bộ về tính linh hoạt, thực sự đã làm suy yếu một trong những tính năng bảo vệ người dùng quan trọng nhất – sự minh bạch về phí. Trong Uniswap v2 và v3, phí là cố định và được công bố trước. Người dùng biết chính xác họ sẽ trả bao nhiêu. Trong v4, với hook, phí có thể thay đổi bất kỳ lúc nào, và người dùng không thể biết trước trừ khi họ kiểm tra hook riêng lẻ. Điểm mù bảo mật ở đây là: cộng đồng đang quá tập trung vào việc hook có thể làm gì (tạo pool thanh khoản linh hoạt, quản lý phí thông minh) mà quên mất rằng hook cũng có thể làm những điều tồi tệ.
Tôi đã báo cáo lỗ hổng này qua Discord của Uniswap Labs. Họ đã phản hồi nhanh chóng và xác nhận rằng đây là một vấn đề nghiêm trọng. Trong bản cập nhật tiếp theo, họ sẽ thêm giới hạn cho giá trị fee mà hook có thể đặt, và cũng thêm một cơ chế kiểm tra trong pool chính. Nhưng câu hỏi đặt ra là: liệu có còn những lỗ hổng tương tự trong các hook khác không? Hook beforeInitialize, afterAddLiquidity, beforeRemoveLiquidity – tất cả đều có thể bị lợi dụng nếu không được kiểm tra kỹ lưỡng.
Bear market là mùa của những kẻ kiên nhẫn đào sâu. Trong thị trường tăng giá hiện tại, với Uniswap v4 đang thu hút hàng tỷ USD thanh khoản, việc phát hiện lỗ hổng này càng trở nên quan trọng. Tôi không viết bài này để gây hoang mang, mà để nhắc nhở: security không phải tính năng – là nền tảng. Mỗi dòng code, mỗi thay đổi, mỗi bản nâng cấp đều có thể là cánh cửa dẫn đến sự sụp đổ.
Vậy, câu hỏi dành cho bạn là: liệu Uniswap v4 có thực sự an toàn hơn v3, hay chúng ta đang đánh đổi sự đơn giản để lấy sự linh hoạt, và trong quá trình đó, vô tình tạo ra những lỗ hổng mới? Hợp đồng là luật, nhưng lỗ hổng là ngoại lệ. Và ngoại lệ, nếu không được phát hiện kịp thời, sẽ trở thành quy tắc.