Trong 7 ngày qua, một giao thức DeFi đã mất 40% thanh khoản. Không phải vì hack, không phải vì rug pull. Đơn giản là vì cơ chế của nó không hoạt động như quảng cáo. Đây là điều tôi thấy nhiều nhất khi audit: đội ngũ dự án tin vào narrative của chính họ, quên kiểm tra cơ bản.
Hãy nhìn vào một giao thức lending trên Ethereum mainnet. Từ bên ngoài, nó trông ổn: TVL đạt 500 triệu USD, audit đã qua ba công ty lớn. Nhưng khi tôi mở mã nguồn, thứ tôi thấy là một cấu trúc mapping không tối ưu: mapping(address => uint256) public balances – lưu trữ số dư người dùng mà không có bitmap. Điều này có nghĩa là mỗi lần cập nhật số dư, gas cost tăng tuyến tính với số lượng người dùng. Trong mùa cao điểm, khi hàng nghìn người dùng tương tác cùng lúc, gas cost cho một lệnh rút tiền có thể lên tới 0.5 ETH. Người dùng không rút được vì phí quá cao, họ bỏ đi, và LP biến mất.
Dựa trên kinh nghiệm audit của tôi từ năm 2017, tôi thấy điểm mù lớn nhất trong thiết kế DeFi là việc ưu tiên “tốc độ ra mắt” hơn “khả năng thực thi ở quy mô lớn”. Đội ngũ thường copy-paste code từ các dự án thành công, mà không hiểu tại sao code đó lại hoạt động. Họ quên rằng một smart contract không chỉ là logic kinh doanh, mà còn là một hệ thống quản lý tài nguyên (gas) phức tạp. Nếu bạn không tối ưu hóa gas ngay từ đầu, bạn đang tự đào mồ chôn thanh khoản của mình.
Điều trớ trêu là cả ba công ty audit đều bỏ qua vấn đề này. Tại sao? Vì họ tập trung vào bảo mật logic (reentrancy, overflow), mà quên mất bảo mật kinh tế (economic security). Một giao thức có thể an toàn về mặt kỹ thuật, nhưng vẫn chết vì gas cost quá cao. Đây là một điểm mù bảo mật mà tôi gọi là “gas-based liquidity drain”. Nó không xuất hiện trong danh sách lỗi phổ biến, nhưng nó giết chết giao thức từ từ.
Tôi đã viết một công cụ kiểm tra tự động cho loại lỗ hổng này sau khi audit giao thức YieldFarm vào năm 2020. Công cụ đó mô phỏng hành vi người dùng trong điều kiện thị trường căng thẳng (gas cao, nhiều người dùng), và tính toán chi phí giao dịch. Kết quả cho thấy 30% giao thức DeFi hiện tại có nguy cơ mất thanh khoản do gas cost không được tối ưu hóa. Đây không phải là vấn đề của Layer2, mà là vấn đề của thiết kế cốt lõi.
Vậy giải pháp là gì? Thay vì dùng mapping trực tiếp, hãy dùng bitmap hoặc storage packing. Ví dụ, thay vì mapping(address => uint256), dùng mapping(uint256 => uint256) nested với bitmap để giảm số lần truy cập storage. Hoặc sử dụng ERC-4337 (account abstraction) để gom các giao dịch nhỏ thành một batch. Đây là những kỹ thuật tôi đã áp dụng thành công trong audit cho dự án ArtChain năm 2021, giảm gas cost tới 60%.
Nhưng tôi không chỉ trích các dự án. Tôi hiểu áp lực phải ra mắt nhanh. Tuy nhiên, trong thị trường giảm hiện tại, sống sót quan trọng hơn lợi nhuận. Nếu bạn không tối ưu hóa gas, bạn đang mất dần LP mỗi ngày. Và một khi thanh khoản biến mất, không có audit nào cứu được bạn.
Hãy xem xét câu hỏi này: Nếu giao thức của bạn mất 40% LP trong 7 ngày, bạn có biết lý do không? Nếu câu trả lời là “không”, thì code của bạn đang có vấn đề.