Năm 2017, tôi dành hai tháng để kiểm tra mã nguồn hợp đồng ICO của dự án OmiseGO (OMG). Tôi phát hiện một lỗ hổng trong logic staking token, dẫn đến rủi ro mất vốn cho người dùng. Tôi gửi báo cáo chi tiết kèm 3 bản sửa lỗi trên GitHub, được đội ngũ dự án nghiệm thu và thưởng 5 ETH. Kinh nghiệm đó củng cố niềm tin của tôi: đặt cược không chỉ là cơ hội kiếm lời, mà còn là cánh cửa dẫn đến thảm họa nếu mã nguồn không được kiểm tra kỹ lưỡng.
Ngày nay, staking đã trở thành một phần không thể thiếu của hệ sinh thái blockchain, từ Ethereum 2.0, Solana, đến các giao thức DeFi như Lido, Rocket Pool. Nhưng có một sự thật phũ phàng: staking không phải lúc nào cũng an toàn. Nhiều dự án triển khai cơ chế này mà không hiểu rõ các rủi ro tiềm ẩn trong mã nguồn. Trong bài viết này, tôi sẽ phân tích một lỗ hổng staking điển hình mà tôi từng gặp, dựa trên kinh nghiệm kiểm tra mã nguồn thực tế.
Hãy bắt đầu với một kịch bản giả định. Một giao thức DeFi cho phép người dùng stake token LP để nhận phần thưởng. Logic cơ bản: người dùng gửi token LP vào hợp đồng staking, hợp đồng ghi nhận số dư, và sau một khoảng thời gian, người dùng có thể rút token cùng lãi suất. Nghe có vẻ đơn giản, nhưng một lỗ hổng tinh vi có thể ẩn nấp trong cách tính phần thưởng.
Ví dụ, một hợp đồng staking thường sử dụng biến rewardPerToken và userRewardPerTokenPaid để theo dõi phần thưởng. Nếu logic cập nhật không chính xác, kẻ tấn công có thể khai thác để rút phần thưởng nhiều lần. Tôi từng thấy một trường hợp mà biến totalSupply được cập nhật trước khi tính phần thưởng, dẫn đến sai lệch: người dùng stake, rút ngay lập tức, và vẫn nhận được phần thưởng cho khoảng thời gian không có token nào trong pool.
Điểm mấu chốt nằm ở thứ tự thực hiện các hàm. Trong hợp đồng staking, hàm deposit() và withdraw() cần được kiểm tra cẩn thận. Nếu totalSupply thay đổi trước khi tính rewardPerToken, hệ thống sẽ tính sai. Ví dụ, khi người dùng gửi token, totalSupply tăng lên, nhưng rewardPerToken chưa được cập nhật. Nếu người dùng rút ngay, totalSupply giảm, nhưng rewardPerToken vẫn dựa trên giá trị cũ. Kết quả: người dùng nhận được phần thưởng không công bằng.
Dựa trên kinh nghiệm audit của tôi, lỗ hổng này thường xuất hiện khi nhóm phát triển không áp dụng mô hình "check-effect-interaction". Trong đó, các thay đổi trạng thái (như cập nhật totalSupply) được thực hiện sau khi tính toán phần thưởng. Một giải pháp đơn giản: tính rewardPerToken trước khi cập nhật totalSupply trong cả hàm deposit() và withdraw().
Tuy nhiên, có một góc nhìn phản trực giác: không phải lúc nào lỗ hổng cũng đến từ mã nguồn phức tạp. Đôi khi, điểm mù bảo mật nằm ở chính các giả định của nhà phát triển. Ví dụ, nhiều dự án tin rằng staking chỉ an toàn khi hợp đồng được kiểm tra bởi bên thứ ba. Nhưng thực tế, các cuộc kiểm tra thường bỏ qua các trường hợp biên như 'flash loan staking' – nơi kẻ tấn công mượn một lượng lớn token, stake, nhận phần thưởng, rút token, và trả nợ chỉ trong một giao dịch. Nếu hợp đồng không có cơ chế chống flash loan, kẻ tấn công có thể rút phần thưởng mà không cần bỏ vốn thực sự.
Tôi từng xây dựng một bot arbitrage với flash loan trên Uniswap V2 vào năm 2020. Bot quét 40 cặp token trên 5 DEX, thực hiện 120 giao dịch trong một tuần, thu về 50 ETH. Qua đó, tôi phát hiện một vector tấn công tương tự trên các giao thức staking: kẻ tấn công có thể dùng flash loan để thao túng totalSupply tạm thời, tạo ra biến động phần thưởng. Nếu hệ thống không tính đến điều này, nó sẽ dễ bị tổn thương.
Kết luận: staking không phải lúc nào cũng an toàn. Nó đòi hỏi sự hiểu biết sâu sắc về logic mã nguồn và các rủi ro tiềm ẩn. Khi bạn stake token, bạn đang giao phó tài sản của mình cho một hợp đồng thông minh. Hãy tự hỏi: hợp đồng đó đã được kiểm tra cho tất cả các trường hợp biên chưa? Hay nó chỉ an toàn trong điều kiện lý tưởng?