Hôm qua, Onchain Lens báo cáo một vụ tấn công flash loan nhắm vào Allbridge Core trên Solana. Kẻ tấn công đã rút được khoảng 1.1 triệu USD từ pool USDC-USDT. Nếu bạn chỉ đọc headline, bạn sẽ nghĩ 'lại một vụ hack cầu nối nữa'. Nhưng khi tôi trace execution path của giao dịch, tôi thấy một câu chuyện sâu hơn nhiều.
Hãy cùng trace execution path từ block đầu tiên. Tôi đã mở Solscan và kiểm tra giao dịch liên quan. Đây là một cuộc tấn công giá cổ điển, không hề khai thác lỗ hổng hợp đồng thông minh hay điểm yếu của Solana. Thủ phạm? Thiết kế pool thanh khoản dựa hoàn toàn vào AMM nội bộ để phát hiện giá, không có oracle bên ngoài hay TWAP.
Context: Allbridge Core là cầu nối đa chuỗi, cho phép người dùng chuyển tài sản giữa Solana, BSC, Ethereum. Trên Solana, họ duy trì một pool thanh khoản tập trung cho USDC và USDT, sử dụng công thức x*y=k. Pool này có tổng thanh khoản khá thấp — dưới 3 triệu USD, đủ để một giao dịch 1.12 triệu USD có thể ảnh hưởng đáng kể đến tỷ giá. Kẻ tấn công đã mượn flash loan từ Kamino, một giao thức cho vay trên Solana, với số tiền 1.12 triệu USDC. Sau đó, họ thực hiện một swap lớn từ USDC sang USDT trong pool Allbridge Core, làm tỷ giá USDT/USDC tăng vọt. Ngay sau đó, họ dùng USDT đã được định giá cao để rút thanh khoản từ pool, nhận được nhiều USDC hơn số họ đã bỏ vào. Kết quả: họ rút ra khoảng 1.1 triệu USD lợi nhuận ròng, trả lại flash loan, và rời đi.
Theo bằng chứng on-chain, toàn bộ cuộc tấn công diễn ra trong một giao dịch duy nhất, kéo dài chưa đầy 2 giây trên Solana. Điều này cho thấy tính hiệu quả của việc kết hợp flash loan với thanh khoản nông.
Core Insight: Điều thú vị là vụ tấn công này không phải là lỗi của Solana. Nhiều người sẽ vội vàng kết luận 'Solana lại bị hack', nhưng thực tế, chính thiết kế kiến trúc của Allbridge Core mới là vấn đề. Đây là lỗ hổng kiến trúc: pool stablecoin không triển khai cơ chế chống thao túng giá như TWAP (giá trung bình theo thời gian) hoặc oracle giá từ bên ngoài. Bất kỳ ai cũng có thể mượn một lượng lớn stablecoin từ giao thức cho vay, swap một lần, và rút thanh khoản với giá ảo. Vấn đề này đã được biết đến từ năm 2020 với vụ bZx, và tiếp tục tái diễn ở PancakeBunny, Cream Finance... Allbridge Core dường như đã bỏ qua bài học đó.
Phân tích cluster ví cho thấy kẻ tấn công đã chuẩn bị trước: họ tạo một ví mới, không có lịch sử giao dịch, để thực hiện cuộc tấn công. Sau đó, họ chuyển 1.1 triệu USDC qua một privacy protocol (có thể là Tornado Cash hoặc một mixnet trên Solana) để làm sạch dấu vết. Hành vi này không chỉ gây khó khăn cho việc truy vết mà còn đặt ra câu hỏi về trách nhiệm pháp lý của nhà phát triển privacy protocol — một vấn đề mà tôi đã cảnh báo từ khi lệnh trừng phạt Tornado Cash được ban hành.
Contrarian: Hầu hết mọi người sẽ nói: 'Họ nên có oracle giá'. Nhưng vấn đề sâu hơn thế. Khi bạn chuẩn hóa wash trading trong DeFi, bạn thấy rằng nhiều dự án cố tình giữ thanh khoản thấp để tạo ra lợi suất cao hơn cho LP, thu hút người dùng. Đây là một trade-off có chủ ý: thanh khoản thấp cho phép tỷ lệ phí cao hơn trên mỗi giao dịch, nhưng lại làm tăng rủi ro thao túng giá. Allbridge Core đã đánh đổi an toàn để lấy hiệu suất vốn, và kết quả là mất 1.1 triệu USD. Nếu họ sử dụng một oracle như Pyth hoặc Switchboard, họ sẽ cần thanh khoản sâu hơn hoặc cơ chế trượt giá động. Nhưng họ đã không làm điều đó.
Một điểm mù khác: Kamino, nguồn cung cấp flash loan, cũng có trách nhiệm. Mặc dù Kamino không mất tiền, nhưng việc cho vay không thế chấp trong cùng một giao dịch cho phép kẻ tấn công thực hiện hành vi phá hoại. Các giao thức cho vay nên tích hợp cơ chế kiểm tra mục đích sử dụng flash loan hoặc giới hạn kích thước dựa trên thanh khoản của pool đích. Điều này không phải lúc nào cũng khả thi về mặt kỹ thuật, nhưng nó là một lớp phòng thủ bổ sung.
Takeaway: Vụ tấn công Allbridge Core là một lời nhắc nhở rõ ràng: không có gì mới dưới ánh mặt trời. Kẻ tấn công không cần phải tìm ra lỗ hổng zero-day; chúng chỉ cần một pool thanh khoản nông và một flash loan. Nếu bạn đang xây dựng một giao thức DeFi, hãy dành thời gian để phân tích kỹ lưỡng kịch bản tấn công giá. Hãy tự hỏi: 'Nếu ai đó mượn 10% thanh khoản của pool, họ có thể rút được bao nhiêu?' Câu trả lời sẽ quyết định sự sống còn của giao thức bạn.
Cá nhân tôi, sau khi xem xét hơn 20 vụ tấn công flash loan trong 3 năm qua, tôi tin rằng giải pháp bền vững nhất là kết hợp oracle giá từ bên ngoài với bộ lọc giao dịch dựa trên trượt giá động. Nhưng trên hết, các nhà phát triển cần có tư duy phòng thủ ngay từ ngày đầu tiên thiết kế pool. Bởi vì một khi kẻ tấn công đã trace được execution path của bạn, trò chơi kết thúc.