Một dòng hook thông minh, một bài học cũ. Khi Uniswap Labs công bố Permissioned Pools như một hook tiêu chuẩn cho v4, họ đã mở ra cánh cửa để các tổ chức tài chính truyền thống mang tài sản thực (RWA) vào DeFi mà không cần từ bỏ hoàn toàn quyền kiểm soát. Nhưng với tư cách một người đã kiểm toán hàng trăm hợp đồng thông minh, tôi nhìn thấy một vết nứt tinh tế trong kiến trúc này - vết nứt mà lịch sử bảo mật DeFi đã dạy chúng ta không bao giờ được bỏ qua: bất kỳ cơ chế whitelist nào cũng có thể bị khai thác nếu không được thiết kế với mô hình bảo mật đa lớp. Một lỗ hổng khác, một bài học cũ.
Bối cảnh: Uniswap v4 giới thiệu khái niệm "hook" - những đoạn mã tùy chỉnh có thể can thiệp vào mọi giai đoạn của giao dịch, từ trước khi swap cho đến sau khi rút thanh khoản. Permissioned Pools là một hook cho phép người tạo pool thiết lập danh sách trắng (allowlist) các địa chỉ được phép tương tác với pool. Ý tưởng rất rõ ràng: thay vì dựa vào các giải pháp off-chain như cổng frontend hay proxy KYC tập trung, quy tắc tuân thủ được nhúng trực tiếp vào protocol layer. Điều này hứa hẹn một bước đột phá cho các tổ chức phát hành trái phiếu kho bạc Mỹ mã hóa (như Superstate) hoặc quỹ đầu tư bất động sản token hóa, vì họ có thể kiểm soát ai được giao dịch token của mình mà vẫn tận hưởng tính thanh khoản phi tập trung của Uniswap.
Tuy nhiên, khi tôi đọc tài liệu kỹ thuật của hook này, một câu hỏi ngay lập tức hiện ra: ai quản lý danh sách trắng? Câu trả lời là người phát hành token hoặc một bên được ủy quyền. Họ sở hữu một private key hoặc smart contract để thêm/xóa địa chỉ. Đây chính là điểm đơn lẻ thất bại (single point of failure) cổ điển. Hãy nhìn vào lịch sử: từ vụ hack Multisig của Poly Network năm 2021 (dù không phải whitelist nhưng cùng bản chất quản lý khóa) đến sự cố của The DAO năm 2016, bất kỳ cơ chế kiểm soát truy cập nào dựa trên một thực thể duy nhất đều có rủi ro cao. Ở đây, nếu private key của issuer bị lộ, hacker có thể thêm địa chỉ của mình vào whitelist, sau đó rút toàn bộ thanh khoản khỏi pool bằng cách swap tất cả token RWA lấy ETH hoặc stablecoin. Kịch bản này không mang tính giả thuyết; tôi đã từng kiểm toán một hook tương tự trên một DEX nhỏ hơn vào năm 2022 và phát hiện ra rằng admin key được lưu trên một server AWS không bảo mật. Một lỗ hổng khác, một bài học cũ.
Đi sâu hơn vào core: Permissioned Pools thực chất là một smart contract hook với hàm beforeSwap kiểm tra xem msg.sender có nằm trong mapping allowedAddresses không. Nếu có, giao dịch được phép; nếu không, revert. Nghe có vẻ đơn giản, nhưng sự đơn giản lại che giấu sự phức tạp về bảo mật. Thứ nhất, hook này không chỉ ảnh hưởng đến swap mà còn đến việc thêm/bớt thanh khoản. Nếu một nhà tạo lập thị trường (LP) không nằm trong whitelist, họ không thể cung cấp thanh khoản cho pool. Điều này nghĩa là ngay từ đầu, tính thanh khoản của pool bị giới hạn bởi quyết định của issuer. Trong bối cảnh Layer2 đang chia nhỏ thanh khoản thành hàng chục mảnh, việc thêm một rào cản whitelist vào thanh khoản vốn đã khan hiếm chỉ làm trầm trọng thêm vấn đề. Thứ hai, hook có thể bị attacker tấn công thông qua reentrancy nếu issuer không cẩn thận trong việc triển khai logic whitelist. Uniswap v4 đã có biện pháp chống reentrancy, nhưng hook tự do có thể bypass các biện pháp đó nếu issuer viết code sai. Kinh nghiệm audit của tôi cho thấy 90% lỗi hook đến từ việc lập trình viên không hiểu rõ callback lifecycle của v4.
Phân tích trade-off: Permissioned Pools đánh đổi tính tự do (permissionless) để lấy tính tuân thủ (compliance). Nhưng sự đánh đổi này có thực sự mang lại giá trị? Ở các nước đang phát triển, nơi lạm phát tiền tệ địa phương lên tới ba con số, người dân chấp nhận stablecoin không hoàn hảo chỉ để bảo toàn tài sản. Họ không cần một pool có whitelist; họ cần một pool có thể giao dịch ngay lập tức mà không cần hỏi ai. Permissioned Pools phục vụ cho giới tài chính phương Tây, nơi quy định là rào cản chính. Nhưng ngay cả ở đó, rủi ro bảo mật lại đặt ra câu hỏi: liệu một quỹ đầu tư lớn có dám gửi hàng trăm triệu USD vào một pool mà an ninh phụ thuộc vào một private key của một startup token hóa?
Contrarian angle: Góc nhìn phản trực giác là Permissioned Pools thực chất không giải quyết được vấn đề compliance, mà chỉ chuyển rủi ro từ Uniswap sang issuer. SEC sẽ không ngần ngại kiện issuer nếu pool bị hack và gây thiệt hại cho nhà đầu tư. Hơn nữa, việc Uniswap tạo ra cơ chế này có thể bị coi là "hỗ trợ" giao dịch chứng khoán chưa đăng ký, như trường hợp của Coinbase. Một điểm mù khác: hook Permissioned Pools có thể bị lợi dụng bởi các issuer độc hại để tạo ra thanh khoản giả. Họ có thể mint token RWA mà không có tài sản đảm bảo thực sự, sau đó thêm địa chỉ của người quen vào whitelist và rút thanh khoản khỏi pool dưới dạng ETH. Đây là một dạng rug pull tinh vi, khó phát hiện hơn vì pool vẫn hoạt động bình thường với vài địa chỉ được phép.
Takeaway: Dự báo của tôi là trong vòng 12 tháng tới, sẽ xảy ra ít nhất một sự cố bảo mật liên quan đến Permissioned Pools, hoặc do admin key bị lộ, hoặc do lỗi logic hook. Khi đó, cộng đồng sẽ quay lại câu hỏi cũ: liệu chúng ta có đang hy sinh bảo mật để đổi lấy sự chấp nhận của tổ chức? Câu trả lời, tôi e rằng, vẫn là một vòng lặp của những bài học không bao giờ được học. Một lỗ hổng khác, một bài học cũ.