Nếu một hệ thống cho phép kẻ tấn công 'tạo 2.500 vị thế ma' chỉ trong vài ngày mà không bị phát hiện, thì lớp bảo vệ đầu tiên của bạn đã thất bại hoàn toàn.
Đó chính xác là những gì xảy ra với Prism, một token phân phối phí giao dịch được xây dựng trên Uniswap v4. Vào cuối tháng 7/2024, nhóm phát triển tiết lộ rằng một kẻ tấn công đã đánh cắp gần 40% phí giao dịch trong suốt tháng 7. Cách thức? Tạo ra 2.500 'vị thế ma' — những vị thế cung cấp thanh khoản ảo không có giá trị thực — để lợi dụng lỗ hổng logic trong cơ chế phân phối phí. Kết quả: giá token PRISM gốc giảm 91%, dự án buộc phải từ bỏ hợp đồng cũ và triển khai hợp đồng mới từ đầu.
Hook này không chỉ là một câu chuyện về mất mát tài chính, mà là một nghiên cứu điển hình về cách mà sự tự tin thái quá vào các cơ chế hook mới của Uniswap v4 có thể dẫn đến thảm họa.
--- Bối cảnh: Prism và Uniswap v4 Hook
Prism tự định vị là một token 'trả phí giao dịch cho tất cả người nắm giữ'. Cơ chế hoạt động dựa trên việc tận dụng các Hook của Uniswap v4 — những đoạn mã tùy chỉnh được gắn vào pool thanh khoản để thực thi các logic bổ sung. Về mặt lý thuyết, đây là một ý tưởng sáng tạo: thay vì phải lock token như ve(3,3) hoặc stake trong pool, người dùng chỉ cần nắm giữ PRISM là tự động nhận được một phần phí từ các pool thanh khoản mà dự án kiểm soát. Tuy nhiên, điểm mấu chốt nằm ở cách tính toán và phân bổ phí này cho hàng nghìn vị thế.
Theo thiết kế gốc, bất kỳ ai cũng có thể tạo một vị thế thanh khoản trong pool của Prism và nhận phí tương ứng với tỷ lệ vị thế của họ so với tổng số vị thế. Vấn đề: không có cơ chế xác thực 'vị thế thực sự có giá trị thanh khoản hay không'. Và đó là nơi lỗ hổng bắt đầu.
--- Phân tích kỹ thuật: Mã nguồn nói lên điều gì?
Dựa trên kinh nghiệm audit của tôi, đây là một lỗi phân bổ cổ điển — proportional allocation without minimum viable liquidity check. Kẻ tấn công đã khai thác bằng cách tạo hàng loạt vị thế có giá trị thanh khoản cực thấp (gần như bằng 0), nhưng vẫn được tính vào tổng số vị thế khi phân phối phí.
Hãy tưởng tượng: tổng phí thu được trong pool là 100 token. Có 1.000 vị thế hợp lệ (mỗi vị thế thực sự cung cấp thanh khoản), và 2.500 vị thế ma. Công thức tính phí cho mỗi vị thế là: phí_của_bạn = tổng_phí * (giá_trị_vị_thế_bạn / tổng_giá_trị_tất_cả_vị_thế). Vì tổng giá trị các vị thế ma gần như bằng 0, nên từng vị thế ma nhận được rất ít phí. Nhưng khi kẻ tấn công sở hữu 2.500 vị thế như vậy, tổng phí mà hắn nhận được lại rất lớn — bởi vì mỗi vị thế vẫn được tính là một đơn vị 'có quyền nhận phí' trong logic phân phối.
Thực tế, lỗ hổng nằm ở lớp cuối cùng của quá trình tính toán: không kiểm tra xem vị thế có đủ điều kiện tối thiểu (ví dụ: số dư thanh khoản > 0, thời gian tồn tại > 0, v.v.) trước khi ghi nhận vào danh sách phân phối. Điều này hoàn toàn có thể phát hiện được nếu nhóm audit kiểm tra kỹ hàm _distributeFees() hoặc logic Hook afterSwap().
Không có gì là an toàn nếu bạn chưa audit kỹ layer cuối cùng.
--- Góc nhìn phản trực giác: Ai thực sự đáng trách?
Cộng đồng thường đổ lỗi cho kẻ tấn công, nhưng trong trường hợp này, tôi cho rằng thiết kế token kinh tế và sự thiếu trách nhiệm của đội ngũ phát triển mới là nguyên nhân gốc rễ.
Trước hết, mô hình 'trả phí cho tất cả người nắm giữ' vốn dĩ đã có vấn đề. Nó tạo ra động lực cho kẻ xấu tấn công vì lợi ích ngắn hạn cao. Thứ hai, đội ngũ Prism là giả danh (pseudo-anonymous), không có danh tiếng hay trách nhiệm pháp lý. Họ có thể dễ dàng từ bỏ hợp đồng cũ, triển khai hợp đồng mới, và gần như không chịu bất kỳ hậu quả nào ngoài tổn thất uy tín.
Điểm mù ở đây là: thị trường vẫn có thể 'ăn theo' câu chuyện khởi động lại. Một số nhà đầu tư cho rằng 'sau sự cố, đội ngũ sẽ rút kinh nghiệm và làm tốt hơn'. Nhưng với tư cách là một auditor, tôi nói: một đội ngũ đã từng mắc lỗi cơ bản như không kiểm tra vị thế ma, lại không có danh tính thực, thì việc tin tưởng họ lần nữa là đánh cược với xác suất thua rất cao.
Ngay cả khi hợp đồng mới được kiểm toán bởi bên thứ ba, rủi ro vẫn còn đó. Bởi vì lỗ hổng không chỉ nằm trong code, mà còn nằm trong văn hóa phát triển và khả năng quản lý rủi ro của đội ngũ.
--- Takeaway: Lời cảnh báo cho tất cả
Prism là một ví dụ điển hình cho thấy sự kết hợp giữa thiết kế token kinh tế hấp dẫn, đội ngũ giả danh, và kiểm toán không đầy đủ có thể dẫn đến thảm họa nhanh đến mức nào. Nếu bạn đang đầu tư vào các dự án DeFi mới, hãy tự hỏi:
- Đội ngũ có thực sự chịu trách nhiệm không?
- Hợp đồng thông minh đã được audit bởi ai, và audit đó có đề cập đến 'lớp cuối cùng' của quá trình tính toán không?
- Liệu có tồn tại cách tạo 'vị thế ma' tương tự trong dự án bạn đang xem xét?
Không có gì là an toàn nếu bạn chưa audit kỹ layer cuối cùng. Câu nói này không chỉ áp dụng cho Prism, mà cho mọi giao thức DeFi. Hãy nhớ: lớp bảo vệ cuối cùng thường là nơi dễ bị khai thác nhất, và cũng là nơi ít được chú ý nhất.
Hãy để câu chuyện của Prism là một lời nhắc nhở: trong thị trường tăng giá, khi mọi thứ đều có vẻ hứa hẹn, đừng quên nhìn vào mã nguồn. Vì nếu bạn không tự kiểm tra, ai đó sẽ kiểm tra thay bạn — nhưng không phải vì lợi ích của bạn.