#Scallop Lần này vụ exploit hợp đồng phụ sSUI rewards rất phù hợp để xem như một trường hợp quản lý rủi ro trong DeFi
Sự kiện diễn ra như sau: Hợp đồng phụ sSUI rewards của Scallop gặp lỗ hổng, tổn thất khoảng 150k SUI. Đội ngũ sau đó cho biết hợp đồng bị ảnh hưởng đã được đông lạnh, các hợp đồng chính vẫn an toàn, các pool thưởng khác không bị ảnh hưởng và sẽ bù đắp tổn thất
Mình thấy điểm đáng chú ý ở đây là vị trí "hợp đồng phụ"
Nhiều người khi xem xét an toàn DeFi thường chú ý đến pool chính, cốt lõi cho vay, oracle, logic thanh lý. Những điều này dĩ nhiên quan trọng, nhưng sau một thời gian, bên cạnh sẽ xuất hiện nhiều hợp đồng hỗ trợ: pool thưởng, chiến lược cũ, công cụ di chuyển, hợp đồng sự kiện
Những hợp đồng này đôi khi có giá trị nhỏ hơn, ít được chú ý hơn, lại dễ trở thành đuôi
Vì vậy, lần này mình sẽ tập trung vào quy trình xử lý sự kiện. Sau khi xảy ra, phản ứng của giao thức phải đủ tiêu chuẩn: trước tiên là đông lạnh hợp đồng bị ảnh hưởng, xác nhận tình trạng của hợp đồng chính, làm rõ phạm vi ảnh hưởng, xử lý tổn thất của người dùng
Các bước này đều rất quan trọng
Đối với người dùng, họ cũng có thể học được một cách kiểm tra từ trường hợp này: khi xem hoạt động lợi nhuận, APR chỉ là cửa vào, còn phải xem dòng tiền thực sự vào hợp đồng nào, nguồn thưởng ở đâu, pool này có còn được duy trì không
Rủi ro trong DeFi nhiều khi ẩn chứa ở những chỗ rất nhỏ. Đặc biệt là hợp đồng cũ còn lại sau khi nâng cấp, pool thưởng còn dư sau khi sự kiện kết thúc, hoặc những module nhỏ lâu không ai nhắc đến
Mình lại cảm thấy những sự kiện như thế này có giá trị giáo dục rất cao. Hệ sinh thái nước phải hướng tới một nguồn vốn lớn hơn, không thể chỉ nhìn vào những câu chuyện lợi nhuận thông thường, mà còn phải xem mỗi giao thức xử lý đuôi ra sao khi có sự cố
Nếu phân tích nhiều trường hợp như thế này, mọi người sẽ càng có cảm giác rủi ro hơn khi nhìn vào DeFi
Sự kiện diễn ra như sau: Hợp đồng phụ sSUI rewards của Scallop gặp lỗ hổng, tổn thất khoảng 150k SUI. Đội ngũ sau đó cho biết hợp đồng bị ảnh hưởng đã được đông lạnh, các hợp đồng chính vẫn an toàn, các pool thưởng khác không bị ảnh hưởng và sẽ bù đắp tổn thất
Mình thấy điểm đáng chú ý ở đây là vị trí "hợp đồng phụ"
Nhiều người khi xem xét an toàn DeFi thường chú ý đến pool chính, cốt lõi cho vay, oracle, logic thanh lý. Những điều này dĩ nhiên quan trọng, nhưng sau một thời gian, bên cạnh sẽ xuất hiện nhiều hợp đồng hỗ trợ: pool thưởng, chiến lược cũ, công cụ di chuyển, hợp đồng sự kiện
Những hợp đồng này đôi khi có giá trị nhỏ hơn, ít được chú ý hơn, lại dễ trở thành đuôi
Vì vậy, lần này mình sẽ tập trung vào quy trình xử lý sự kiện. Sau khi xảy ra, phản ứng của giao thức phải đủ tiêu chuẩn: trước tiên là đông lạnh hợp đồng bị ảnh hưởng, xác nhận tình trạng của hợp đồng chính, làm rõ phạm vi ảnh hưởng, xử lý tổn thất của người dùng
Các bước này đều rất quan trọng
Đối với người dùng, họ cũng có thể học được một cách kiểm tra từ trường hợp này: khi xem hoạt động lợi nhuận, APR chỉ là cửa vào, còn phải xem dòng tiền thực sự vào hợp đồng nào, nguồn thưởng ở đâu, pool này có còn được duy trì không
Rủi ro trong DeFi nhiều khi ẩn chứa ở những chỗ rất nhỏ. Đặc biệt là hợp đồng cũ còn lại sau khi nâng cấp, pool thưởng còn dư sau khi sự kiện kết thúc, hoặc những module nhỏ lâu không ai nhắc đến
Mình lại cảm thấy những sự kiện như thế này có giá trị giáo dục rất cao. Hệ sinh thái nước phải hướng tới một nguồn vốn lớn hơn, không thể chỉ nhìn vào những câu chuyện lợi nhuận thông thường, mà còn phải xem mỗi giao thức xử lý đuôi ra sao khi có sự cố
Nếu phân tích nhiều trường hợp như thế này, mọi người sẽ càng có cảm giác rủi ro hơn khi nhìn vào DeFi