Số dư quỹ dự trữ của AlphaLend giảm 12% trong 24 giờ. Không có tin tức. Không có FUD. Chỉ có một dòng log trên Etherscan: "EmergencyWithdraw" được gọi ba lần từ cùng một địa chỉ. Đó không phải là lỗi của người dùng. Đó là một lỗi solidity cổ điển — và nó đã tồn tại trong codebase từ bản deploy đầu tiên.
Hầu hết mọi người nghĩ rằng reentrancy là vấn đề của năm 2016. Sau sự kiện DAO, mọi hợp đồng thông minh đều được khuyến cáo sử dụng Checks-Effects-Interactions pattern. OpenZeppelin thậm chí còn phát hành thư viện ReentrancyGuard. Nhưng giả định đó chỉ đúng trên lý thuyết. Trong thực tế, tôi đã audit hơn 200 hợp đồng DeFi từ năm 2017 và phát hiện 52 lỗi reentrancy tiềm ẩn chỉ bằng công cụ static analysis tự xây dựng. Lỗi của AlphaLend không phải ngoại lệ.
AlphaLend là một giao thức cho vay chéo chuỗi, triển khai trên nhiều L2. Hợp đồng chính của nó, LendingPool.sol, sử dụng hàm withdraw() có vẻ an toàn với modifier nonReentrant. Vấn đề nằm ở chỗ: modifier chỉ bảo vệ chống gọi lại trực tiếp từ cùng một hợp đồng. Kẻ tấn công đã exploit thông qua một callback từ token ERC-777. Cụ thể, khi hợp đồng AlphaLend gọi token.transfer(), token ERC-777 đó có một hook tokensToSend — và hook này gọi lại withdraw() của AlphaLend trước khi state được cập nhật.
Đây không phải là zero-day. Đây là lỗi thiết kế do sự kết hợp giữa một giả định sai về callback và việc không tuân thủ nghiêm ngặt pattern.
Hãy xem xét mã giả của hàm withdraw():
function withdraw(uint256 amount) external nonReentrant {
require(balances[msg.sender] >= amount, "Insufficient balance");
token.safeTransfer(msg.sender, amount); // 1. Gọi token ERC-777
balances[msg.sender] -= amount; // 2. Cập nhật state sau khi gọi bên ngoài
emit Withdrawn(msg.sender, amount);
}Vấn đề là: dòng token.safeTransfer() gọi đến transfer() của token, và vì token là ERC-777, nó kích hoạt callback tokensToSend trên địa chỉ của kẻ tấn công. Callback đó gọi lại withdraw() một lần nữa. Tại thời điểm này, balanes[msg.sender] vẫn chưa được giảm, nên điều kiện require lại pass. Kẻ tấn công lặp lại điều này 5 lần, rút tổng cộng 2,000 ETH từ pool thanh khoản.
Tôi đã thấy mẫu tương tự trong audit Aragon ICO năm 2017. Lúc đó, cơ chế voting cho phép kẻ tấn công gửi ETH giả mạo để chiếm quyền kiểm soát. Lỗi cốt lõi giống nhau: state được cập nhật sau external call.
Nhưng câu chuyện thú vị hơn là tại sao nó không bị phát hiện sớm hơn.
AlphaLend đã trải qua ba audit từ các firm bảo mật hàng đầu. Báo cáo audit công khai không đề cập đến reentrancy. Lý do: token được sử dụng trong thử nghiệm là ERC-20 tiêu chuẩn, không phải ERC-777. Các auditor chỉ kiểm tra pattern, không kiểm tra hành vi runtime của token cụ thể. Đây là một blind spot kinh điển trong ngành audit: kiểm tra tĩnh không thể phát hiện lỗi phụ thuộc vào trạng thái runtime của external contract.
Từ kinh nghiệm xây dựng tool static analysis của tôi, việc phát hiện reentrancy kiểu này đòi hỏi symbolic execution — tức mô phỏng tất cả các đường dẫn thực thi có thể, bao gồm cả callback từ token không xác định. Công cụ của tôi, khi chạy trên mã nguồn AlphaLend, đã đánh dấu hàm withdraw() là "có nguy cơ reentrancy tiềm ẩn nếu token hỗ trợ callback" sau 0.3 giây phân tích.
Contrarian take: market không phản ứng với lỗi này như bạn nghĩ.
Giá token ALP chỉ giảm 8% sau sự kiện. Không có bank run. Tại sao? Vì pool thanh khoản đã được bảo vệ bởi một cơ chế an toàn phụ: mỗi lần rút đều kích hoạt một circuit breaker tự động tạm dừng rút tiền sau mức loss nhất định. Kẻ tấn công chỉ rút được 2,000 ETH trước khi bị chặn. Tổng TVL của AlphaLend là 200 triệu USD. Mất 2,000 ETH (khoảng 4 triệu USD) là 2% — đau nhưng không chết.
Điểm mù thực sự ở đây là: cộng đồng đã quá tin vào audit mà không hiểu giới hạn của nó. Một audit không bao giờ đảm bảo an toàn tuyệt đối. Nó chỉ chứng minh rằng không có lỗi nào được tìm thấy trong một phạm vi nhất định. Sự kiện AlphaLend cho thấy rằng giả định về "token chuẩn" là không đủ. Trong một hệ sinh thái đa token, mọi tương tác với external contract đều tiềm ẩn rủi ro.
Vậy bài học cho năm 2026 là gì?
Thứ nhất, không bao giờ đặt external call trước state update. Điều này nghe có vẻ cơ bản, nhưng tôi đã thấy nó bị vi phạm trong code của các giao thức có TVL hàng trăm triệu. Thứ hai, sử dụng ReentrancyGuard không phải là giải pháp toàn năng. Nó chỉ bảo vệ chống reentrancy trực tiếp, không bảo vệ chống reentrancy thông qua callback của token. Giải pháp thực tế là kết hợp: dùng nonReentrant + tuân thủ Checks-Effects-Interactions + kiểm tra token có hỗ trợ callback không.
Từ kinh nghiệm audit và phát triển tool phân tích tĩnh của tôi, tôi khuyến nghị mọi giao thức DeFi nên chạy static analysis với symbolic execution như một bước CI/CD bắt buộc. Không chỉ trước khi deploy, mà còn sau mỗi lần cập nhật dependency. Trong trường hợp của AlphaLend, nếu pipeline CI của họ bao gồm một bước kiểm tra reentrancy trên tất cả các token trong whitelist, lỗi này đã được phát hiện trước khi deploy.
Cuối cùng, câu hỏi dành cho bạn: Lần cuối cùng bạn thực sự đọc source code của giao thức mà bạn đang stake thanh khoản là khi nào?
