Khi hệ thống YieldFarm v3 vừa huy động 50 triệu USD trong đợt ICO tháng trước, phản ứng đầu tiên của tôi không phải là phấn khích, mà là mở mã nguồn trên GitHub. Với 26 năm trong ngành, tôi biết thị trường tăng che giấu nhiều lỗi kỹ thuật hơn bạn nghĩ.
Hôm qua, tôi phát hiện một lỗ hổng trong cơ chế tính phần thưởng staking của dự án này. Bằng cách chạy từng dòng code trên testnet, tôi thấy rằng khi người dùng unstake token, hàm _calculateRewards không reset biến lastUpdateTime cho từng user, dẫn đến việc kẻ tấn công có thể claim thưởng nhiều lần. Cụ thể, nếu user A unstake 100 token, sau đó stake lại ngay, hệ thống vẫn tính thưởng dựa trên thời gian từ lần stake đầu tiên, không phải mới. Điều này có thể tái tạo bằng cách chạy script Hardhat với mạng fork.
Tôi đã fork repo, sửa lỗi bằng cách thêm dòng user.lastUpdateTime = block.timestamp trong hàm unstake, và gửi pull request vào tối qua. Đội ngũ dự án chưa phản hồi, nhưng tôi muốn chia sẻ phân tích này để cộng đồng tự kiểm chứng.
Context: YieldFarm v3 là một nền tảng staking đa tầng, cho phép người dùng stake token LP để nhận phần thưởng từ phí giao dịch. Hợp đồng thông minh của nó được viết bằng Solidity 0.8.20, sử dụng mô hình RewardsDistribution phổ biến. Tuy nhiên, trong quá trình audit, tôi nhận thấy họ không dùng thư viện OpenZeppelin Rewards mà tự viết lại, dẫn đến thiếu các biện pháp bảo vệ cơ bản. Lỗi này không phải do hack, mà do logic không đồng bộ giữa các hàm.
Core: Hãy nhìn vào đoạn code dưới đây (tôi đã rút gọn để dễ hiểu):
function unstake(uint256 amount) external { require(amount > 0, "Amount must be > 0"); uint256 rewards = _calculateRewards(msg.sender, amount); // ... chuyển token và thưởng }
function _calculateRewards(address user, uint256 amount) internal view returns (uint256) { User storage u = users[user]; uint256 timeElapsed = block.timestamp - u.lastUpdateTime; return (amount timeElapsed rewardRate) / 1e18; }
Vấn đề: _calculateRewards chỉ tính dựa trên lastUpdateTime của user, nhưng unstake không cập nhật lastUpdateTime sau khi unstake. Nếu user unstake và stake lại ngay, lastUpdateTime vẫn là giá trị cũ, nên timeElapsed bị sai. Kẻ tấn công có thể lặp lại unstake-stake nhiều lần trong một block để nhân phần thưởng lên gấp bội. Đây là lỗi kinh điển trong audit, nhưng vẫn xuất hiện ở dự án gọi vốn trăm triệu.
Tôi đã mô phỏng kịch bản tấn công: với 1000 ETH staked, kẻ tấn công có thể unstake-stake 10 lần trong 1 block, nhận thưởng gấp 10 lần so với đúng. Điều này vi phạm tính an toàn của hệ thống. Tôi đã đề xuất bản vá: thêm u.lastUpdateTime = block.timestamp trong cả unstake và stake.
Contrarian: Nhiều người cho rằng lỗi này dễ phát hiện, nhưng thực tế, trong môi trường thị trường tăng, các đội ngũ thường vội vã launch, bỏ qua kiểm tra biên. Họ tin rằng dùng thư viện chuẩn là đủ an toàn, nhưng trong trường hợp này, họ tự viết lại logic mà không hiểu sâu. Điểm mù bảo mật ở đây là sự chủ quan: họ nghĩ rằng chỉ cần audit qua là xong, nhưng không có ai thử nghiệm edge case với biến lastUpdateTime. Tôi đã thấy ít nhất 5 dự án tương tự trong năm 2025 mắc lỗi này.
Takeaway: Lỗ hổng trong YieldFarm v3 là một lời nhắc: thị trường tăng không làm cho code trở nên an toàn hơn. Nếu bạn đang staking trên dự án này, hãy kiểm tra mã nguồn hoặc chờ bản vá. Đối với các nhà phát triển, hãy nhớ rằng: tự viết logic thưởng là một risk chấp nhận được, nhưng chỉ khi bạn hiểu rõ từng biến. Còn nếu không, hãy dùng thư viện đã được kiểm chứng.