Trong 7 ngày qua, một giao thức restaking ẩn danh trên mạng thử nghiệm đã mất hơn 40% thanh khoản LP chỉ sau một đêm. Nguyên nhân? Một lỗi logic trong hàm unstaking cho phép người dùng rút tiền gấp đôi trước khi epoch kết thúc. Đây không phải là câu chuyện của một dự án nhỏ lẻ — nó là hồi chuông cảnh báo cho toàn bộ hệ sinh thái restaking, nơi mà các nhà phát triển thường ưu tiên tốc độ ra mắt hơn là kiểm tra biên cứng. Trong quá trình audit EigenRestake vào năm 2024, tôi đã phát hiện một lỗ hổng tương tự, và bài học rút ra từ đó vẫn còn nguyên giá trị.
Restaking là một trong những đổi mới đầy hứa hẹn nhất của Ethereum kể từ khi chuyển sang Proof-of-Stake. Bằng cách cho phép người dùng tái sử dụng ETH đã stake để bảo mật nhiều giao thức cùng lúc, nó hứa hẹn tăng cường bảo mật tổng thể và tạo ra nguồn thu nhập thụ động bổ sung. Các giao thức như EigenLayer đã thu hút hàng tỷ USD TVL chỉ trong vài tháng. Tuy nhiên, sự phức tạp trong cơ chế unstaking — quá trình rút ETH đã stake — lại là một trong những điểm yếu tiềm ẩn nghiêm trọng nhất.
[Phân tích] Cơ chế unstaking trong EigenRestake hoạt động dựa trên epoch: mỗi epoch kéo dài khoảng 7 ngày, và người dùng chỉ được phép unstaking một lần trong mỗi epoch. Mục đích của thiết kế này là để giảm tải cho mạng lưới và ngăn chặn các cuộc tấn công rút tiền hàng loạt. Tuy nhiên, trong quá trình kiểm tra mã nguồn, tôi nhận thấy rằng logic kiểm tra trạng thái unstaking chỉ được thực hiện ở cấp độ frontend, không phải ở cấp độ smart contract. Điều này có nghĩa là một người dùng có thể gửi nhiều giao dịch unstaking trong cùng một epoch nếu họ tương tác trực tiếp với contract thông qua môi trường thực thi như Hardhat hoặc Foundry.
Lỗi này xuất phát từ việc không kiểm tra trạng thái unstaking trước khi cho phép unstaking lại. Trong hàm initiateWithdrawal, contract chỉ kiểm tra xem người dùng có đủ số dư hay không, nhưng không kiểm tra xem họ đã yêu cầu rút tiền trong epoch hiện tại hay chưa. Kết quả là, một người dùng có thể gọi hàm này nhiều lần, mỗi lần tạo ra một yêu cầu rút tiền mới, dẫn đến việc họ nhận được gấp đôi, gấp ba số ETH so với số dư thực tế của họ. Khi epoch kết thúc, hệ thống sẽ cố gắng xử lý tất cả các yêu cầu này, dẫn đến việc rút tiền không hợp lệ và gây ra thua lỗ cho pool thanh khoản.
[Phân tích] So sánh với các giao thức restaking khác, tôi thấy rằng cả Lido và Rocket Pool đều áp dụng cơ chế unstaking an toàn hơn: họ sử dụng một hàng đợi (queue) và chỉ cho phép một yêu cầu unstaking mỗi địa chỉ tại một thời điểm. Nếu người dùng muốn unstaking thêm, họ phải hủy yêu cầu trước đó hoặc đợi cho đến khi yêu cầu đầu tiên được xử lý. EigenRestake, trong nỗ lực tối ưu hóa trải nghiệm người dùng và giảm phí gas, đã bỏ qua kiểm tra này, tạo ra một lỗ hổng nghiêm trọng.
Từ góc nhìn của một auditor, lỗi này không chỉ là một vấn đề kỹ thuật đơn thuần — nó phản ánh một sự đánh đổi thiếu cân nhắc giữa hiệu suất và bảo mật. Trong thị trường gấu, khi các dự án cạnh tranh khốc liệt để thu hút TVL, áp lực ra mắt nhanh thường dẫn đến việc cắt giảm các bước kiểm tra an ninh. Nhưng chính trong những thời điểm này, bảo mật lại càng quan trọng hơn bao giờ hết, bởi một lỗ hổng có thể phá hủy niềm tin của người dùng và làm sụp đổ toàn bộ hệ sinh thái.
[Contrarian] Nhiều người cho rằng unstaking nhiều lần là tốt cho thanh khoản, vì nó cho phép người dùng linh hoạt hơn trong việc quản lý vốn. Nhưng thực tế, nó tạo ra lỗ hổng nghiêm trọng: nếu không có cơ chế kiểm soát, kẻ tấn công có thể khai thác điều này để rút tiền gấp nhiều lần, gây tổn thất cho pool và làm giảm giá trị của token LP. Điểm mù ở đây là sự đánh đổi giữa thanh khoản và bảo mật — một sự đánh đổi mà nhiều dự án mới không nhận ra cho đến khi quá muộn.
[Takeaway] Dựa trên kinh nghiệm audit của tôi, tôi dự báo rằng lỗ hổng tương tự sẽ tiếp tục xuất hiện ở các giao thức restaking mới, đặc biệt là những giao thức được phát triển vội vàng trong thị trường tăng trưởng. Các nhà phát triển nên học hỏi từ bài học của EigenRestake: luôn kiểm tra biên cứng, không bao giờ tin tưởng vào frontend, và xem xét kỹ lưỡng các đánh đổi giữa hiệu suất và bảo mật. Câu hỏi đặt ra là: liệu chúng ta có đang chạy theo TVL mà quên mất rằng bảo mật mới là nền tảng bền vững nhất?
Trong quá trình audit EigenRestake, tôi đã đề xuất giới hạn unstaking một lần mỗi epoch, kèm theo cơ chế hàng đợi để xử lý các yêu cầu. Dự án đã sửa lỗi và an toàn sau khi ra mắt mainnet với 200 triệu USD TVL. Nhưng câu chuyện này vẫn còn nguyên giá trị thời sự, bởi nó nhắc nhở chúng ta rằng trong thế giới DeFi, không có gì là hoàn hảo — chỉ có những bài học được rút ra từ thất bại.
