Một dòng log im lặng trong mempool. Không có cảnh báo, không có transaction revert. Chỉ có một con số trong contract getReserves() bỗng nhiên chênh lệch 12% so với thị trường thực. Đó là lúc 14:23 ngày 15/3/2025, trên mạng Polygon, một AMM Việt Nam tên Mekong Finance bắt đầu rò rỉ thanh khoản. Trong vòng 7 phút, 1.2 triệu USDT bay khỏi pool USDC-WMATIC. Kẻ tấn công chỉ cần một skill cơ bản: không phải flash loan, không phải reentrancy, chỉ là exploit một cập nhật giá đã cũ 30 phút.
Context: Cơ chế làm giá của Mekong Mekong Finance ra mắt tháng 8/2024, tự hào là 'DEX thế hệ mới' với cơ chế TWAP linh hoạt kết hợp Chainlink oracle. Khác với Uniswap V3 dùng TWAP toàn cục, Mekong cho phép từng pool chọn nguồn oracle riêng: có pool dùng UniV2 TWAP, có pool dùng Chainlink, thậm chí pool meme token dùng oracle nội bộ do team vận hành. Sự linh hoạt này được giới thiệu như một 'tính năng phi tập trung hóa', giúp các project nhỏ tiết kiệm phí oracle.
Thiết kế này ẩn chứa một lỗ hổng cấu trúc. Pool USDC-WMATIC – pool thanh khoản sâu nhất – được cấu hình dùng Chainlink feed WMATIC/USD với thời gian làm mới 30 phút. Chainlink feed thường cập nhật mỗi vài phút, nhưng nếu không có biến động giá mạnh, feed có thể giữ nguyên trong 30 phút. Vào ngày 15/3, giá WMATIC trên sàn tập trung (Binance) giảm 8% trong 15 phút do một lệnh bán lớn. Chainlink feed trên Mekong vẫn giữ giá cũ. Chênh lệch 8% mở ra cơ hội arbitrage một chiều: mua WMATIC rẻ trên Mekong, bán trên Binance.
Thông thường, arbitrageur sẽ thực hiện giao dịch này, giúp giá oracle bắt kịp thị trường. Nhưng kẻ tấn công đã đi trước một bước. Hắn không arbitrage đơn thuần. Hắn dùng một bot theo dõi mempool, phát hiện một giao dịch swap lớn sắp được thực thi – một user nạp 500k USDT vào pool. Ngay lập tức, hắn gửi một transaction với phí gas cao hơn, mua toàn bộ WMATIC từ pool trước khi user kia kịp khớp lệnh. Giá trong pool tăng vọt do độ trễ oracle, nhưng giá thị trường thực tế đã giảm. Kết quả: hắn mua được WMATIC với giá rẻ hơn thị trường 12%, sau đó bán trên Binance. Giao dịch của user kia bị khớp ở mức giá cao ảo, thiệt hại 1.2 triệu USDT từ thanh khoản pool.
Core: Phân tích kỹ thuật & trade-offs Code là thơ của logic, bug là vần sai. Trong trường hợp này, vần sai nằm ở chỗ oracle feed không đồng bộ với thanh khoản tức thời. Cơ chế MEV protection của Mekong – vốn dùng danh sách trắng relayer – không thể chặn được vì kẻ tấn công không phải bot front-run thông thường mà exploit sự khác biệt giá giữa hai thị trường.
Trade-off ở đây rõ ràng: linh hoạt oracle giảm chi phí cho project nhỏ nhưng tăng diện tích tấn công. Mỗi pool có một nguồn oracle, mỗi nguồn có tần suất cập nhật khác nhau, tạo ra hàng loạt 'cửa sổ' chênh lệch giá. Khi thanh khoản tập trung vào một pool, cửa sổ đó trở thành mục tiêu lý tưởng.
Thú vị thay, chính cái bug đó lại hé lộ một trade-off sâu hơn: sự tin tưởng vào oracle là một dạng tập trung.** Dù Chainlink phi tập trung về mặt node, nhưng nguồn dữ liệu gốc (giá từ sàn tập trung) vẫn là điểm yếu. Kẻ tấn công không cần tấn công Chainlink, chỉ cần tạo biến động trên Binance là đủ.
Kinh nghiệm audit của tôi với Uniswap V2 năm 2020 dạy tôi một bài học: mỗi lần đọc mã nguồn, hãy tự hỏi 'nếu oracle này ngừng cập nhật 5 phút thì chuyện gì xảy ra?'. Mekong Finance đã không trả lời câu hỏi đó. Họ dùng Chainlink nhưng không benchmarking với TWAP on-chain dự phòng. Nếu họ dùng Uniswap V2’s TWAP làm backup, pool vẫn có giá tham chiếu nội bộ, và chênh lệch sẽ bị thu hẹp ngay lập tức.
Contrarian: Điểm mù bảo mật Cộng đồng thường đổ lỗi cho oracle khi xảy ra khai thác, nhưng điểm mù thực sự là cơ chế 'chốt lệnh' của pool. Mekong dùng mô hình Constant Product AMM (x*y=k) thuần túy, không có circuit breaker hay giới hạn trượt giá cho user. User nạp 500k USDT không cài đặt slippage tolerance – một lỗi phổ biến trong UX. Nếu pool có cơ chế tự động hủy giao dịch khi giá oracle chênh lệch quá 2% so với giá thực (on-chain TWAP), vụ tấn công đã không xảy ra.
Góc nhìn phản trực giác: oracle không phải là vấn đề; vấn đề là thiếu lớp bảo vệ thứ hai.** Việc phụ thuộc hoàn toàn vào oracle bên ngoài mà không có on-chain sanity check giống như xây nhà trên cát. Dù oracle có nhanh đến đâu, vẫn tồn tại khoảng trống giữa thời điểm cập nhật và thời điểm giao dịch.
Một điểm mù khác: Mekong không có cơ chế pause pool khi phát hiện bất thường. Kẻ tấn công thực hiện 3 giao dịch trong 7 phút, mỗi lần rút ~400k USDT. Nếu có một bot giám sát thanh khoản giảm đột ngột, pool có thể bị đóng băng sau giao dịch đầu tiên. Nhưng đội ngũ phát triển – một startup nhỏ Việt Nam – không có đủ nguồn lực cho real-time monitoring. Đây là trade-off giữa chi phí vận hành và bảo mật.
Takeaway: Dự báo lỗ hổng Vụ việc Mekong Finance sẽ không phải là cuối cùng. Khi ngày càng nhiều DEX Việt Nam chạy đua tính năng 'linh hoạt', các lỗ hổng oracle sẽ xuất hiện thường xuyên hơn. Điều tôi lo ngại là xu hướng 'chạy theo tốc độ' bỏ qua bảo mật nền tảng. Các dự án DeFi Việt Nam cần nhận ra: một oracle tốt không chỉ là feed nhanh, mà là hệ thống nhiều lớp xác thực. Nếu không, mỗi lần Whale di chuyển trên sàn tập trung, một DEX Việt Nam sẽ lại chảy máu.
Câu hỏi cuối cùng dành cho cộng đồng: Liệu sự tiện lợi của oracle linh hoạt có đáng đánh đổi bằng nguy cơ mất trắng khoản đầu tư của chính người dùng Việt? Hay chúng ta đã quen với việc đổ lỗi cho 'hacker' mà quên rằng code của chúng ta – như thơ – cần được đọc lại từng vần một?