Phiên bản phổ thông: Giải thích đơn giản "dịch" phân tích của các chuyên gia công nghệ về sự cố tấn công @CetusProtocol: Cuộc tấn công lần này đã lộ ra một vấn đề tràn số nguyên cổ điển, cụ thể là sự cắt ngắn dữ liệu trong quá trình chuyển đổi kiểu dữ liệu. Phân tích chi tiết kỹ thuật: 1) Định vị lỗ hổng: Vấn đề xuất hiện trong cơ chế chuyển đổi kiểu của hàm get_amount_by_liquidity, việc ép buộc chuyển đổi từ u256 sang u64 dẫn đến mất dữ liệu ở phần cao. 2) Quy trình tấn công: 1. Kẻ tấn công truyền vào hàm add_liquidity một tham số số lượng thanh khoản cực lớn; 2. Hệ thống gọi hàm get_delta_b để tính toán số lượng token B cần thiết; 3. Trong quá trình tính toán, hai dữ liệu kiểu u128 nhân với nhau, kết quả lý thuyết sẽ là kiểu u256; Thiếu sót chính: Khi hàm trả về, kết quả u256 bị ép buộc chuyển đổi thành u64, dẫn đến mất dữ liệu 128 bit ở phần cao. 3) Hiệu quả khai thác: Lượng thanh khoản cần nhiều token để đúc giờ chỉ cần một lượng token rất nhỏ để hoàn thành. Kẻ tấn công có được phần lớn thanh khoản với chi phí cực thấp, sau đó thực hiện chênh lệch giá trong bể thanh khoản bằng cách hủy một phần thanh khoản. So sánh đơn giản: Giống như dùng máy tính chỉ hiển thị được 8 chữ số để tính 1 tỷ × 1 tỷ, kết quả 20 chữ số chỉ hiển thị 8 chữ số cuối, 12 chữ số đầu biến mất. Kẻ tấn công đã lợi dụng lỗ hổng "mất độ chính xác tính toán" này. Cần làm rõ một điều: Lỗ hổng lần này không liên quan đến kiến trúc bảo mật cơ bản của @SuiNetwork, thuộc về "vinh quang" bảo mật của ngôn ngữ Move vẫn còn đáng tin cậy. Tại sao? Ngôn ngữ Move thực sự có ưu thế nổi bật trong quản lý tài nguyên và an toàn kiểu dữ liệu, có thể ngăn chặn hiệu quả các vấn đề bảo mật cơ bản như thanh toán kép, rò rỉ tài nguyên. Nhưng lỗi của giao thức Cetus lần này là lỗi tính toán toán học ở tầng logic ứng dụng, không phải là khiếm khuyết trong thiết kế của ngôn ngữ Move. Cụ thể, hệ thống kiểu của Move tuy nghiêm ngặt, nhưng đối với các thao tác chuyển đổi kiểu rõ ràng (explicit casting), vẫn cần phụ thuộc vào phán đoán đúng đắn của nhà phát triển. Khi chương trình chủ động thực hiện chuyển đổi kiểu từ u256 sang u64, trình biên dịch không thể xác định đây là thiết kế có chủ ý hay lỗi logic. Ngoài ra, sự cố bảo mật lần này hoàn toàn không liên quan đến cơ chế đồng thuận, xử lý giao dịch, quản lý trạng thái và các chức năng cơ bản khác của Sui. Sui Network chỉ thực hiện trung thành các chỉ thị giao dịch do giao thức Cetus gửi, lỗ hổng xuất phát từ khiếm khuyết logic của giao thức ứng dụng. Nói thẳng ra, dù ngôn ngữ lập trình có tiên tiến đến đâu cũng không thể hoàn toàn ngăn chặn lỗi logic ở tầng ứng dụng. Move có thể ngăn chặn hầu hết các rủi ro bảo mật cơ bản, nhưng không thể thay thế nhà phát triển trong việc kiểm tra biên giới logic nghiệp vụ và bảo vệ tràn số trong tính toán toán học.