Rebase pool bị drain: Lỗi cơ bản trong quản lý thanh khoản dynamic

Hôm qua tôi nhận được một smart contract audit request. Dự án X — một fork của Uniswap v2 với rebase mechanism, TVL 2.5 triệu USD. Tôi mở code, đọc hàm updateRebaseIndex. Chưa đầy 2 phút, tôi thấy 3 lỗi chết người. Một pool thanh khoản mà quên kiểm tra ai được trigger update, quên tính toán chính xác, quên bảo vệ LP. Đội dev gọi đây là 'V2 của hệ thống yield farming'. Tôi gọi nó là bom nổ chậm. Rebase là cơ chế điều chỉnh nguồn cung token để phản ánh biến động giá. Trong AMM, nếu pool thanh khoản dùng rebase, lượng token trong pool thay đổi tự động khi giá tham chiếu biến động. Vấn đề: AMM không được thiết kế cho thanh khoản dynamic. Uniswap v2 giả định lượng token trong pool cố định — chỉ thay đổi qua swap. Rebase phá vỡ giả định này. Khi rebase diễn ra, tỷ lệ token trong pool thay đổi, mở ra cơ hội arbitrage cho MEV bot. Dự án X tự hào về 'yield optimization' cho người dùng. Thực tế: họ tạo ra honeypot cho attacker. Lỗi 1: Thiếu access control nghiêm ngặt. Hàm updateRebaseIndex chỉ kiểm tra onlyRebaser. Nếu rebaser là EOA, private key bị lộ đồng nghĩa attacker control toàn bộ rebase mechanism. Trong audit của tôi cho một DeFi Nigeria protocol, tôi phát hiện rebaser key được lưu trong file config trên AWS không mã hóa. Một junior dev nghĩ 'chẳng ai đọc file config của mình đâu'. Lỗi 2: Tính toán rebase không chính xác khi pool chênh lệch. Công thức mint token dựa trên tổng LP supply và chênh lệch index. Nhưng nếu pool đã bị chênh lệch do swap, rebase sẽ càng làm tăng chênh lệch, tạo cơ hội arbitrage lớn hơn. Trong audit của tôi, lỗi này xuất hiện ở 3/8 dự án fork Uniswap v2 với rebase. Tỷ lệ 37.5%. Lỗi 3: Không khóa tạm thời swap trong khi rebase. Hàm updateRebaseIndex thay đổi lượng token trong pool, nhưng không pause swap operations. Attacker có thể call swap ngay trước rebase, đợi rebase diễn ra, call swap ngược lại — hưởng chênh lệch. Flash loan amplify lợi nhuận lên 10-20 lần. Tôi chạy bot arbitrage trên Uniswap v2 năm 2020, biết rõ tốc độ này. Bot MEV chỉ cần 2-3 giây chênh lệch để drain toàn bộ pool. Nhiều team dev nghĩ rebase pool là cách hay để 'tự động điều chỉnh thanh khoản'. Họ quảng cáo 'yield optimization', 'dynamic pricing'. Thực tế: rebase pool tạo ra bất định giá và lỗ hổng bảo mật. AMM hoạt động dựa trên tính xác định: biết được lượng token trong pool, tính được giá. Rebase phá vỡ tính xác định này, biến pool thành 'active variable' — giá thay đổi không chỉ qua swap mà còn qua admin action. Trong trường hợp pool dùng rebase cho stablecoin, vấn đề càng nghiêm trọng. Nếu rebase không đồng bộ với peg mechanism, pool sẽ liên tục mất cân bằng. Tôi audit được 4 dự án stablecoin pool dùng rebase. Cả 4 đều có lỗ hổng khai thác trong vòng 3 tháng. Không phải 'nếu', mà là 'khi nào'. Nếu bạn thấy dự án AMM với rebase mechanism, hỏi đội dev ba câu: Rebaser là EOA hay multisig? Có pause mechanism khi rebase không? Audit đã kiểm tra attack vector này chưa? Câu trả lời sẽ cho bạn biết dự án có đáng đầu tư hay không. Tôi dự đoán: trong 6 tháng tới, ít nhất 2 dự án rebase pool trên BSC và Arbitrum sẽ bị drain. Lỗi cơ bản, không cần zero-day exploit. Bạn có muốn là người mất tiền không?