Cetus và bài học về vấn đề an toàn: Các đội ngũ DeFi cần lưu ý điều gì?
Tuyển chọn TechFlowTuyển chọn TechFlow
Cetus và bài học về vấn đề an toàn: Các đội ngũ DeFi cần lưu ý điều gì?
Từ Cetus trở đi, tất cả các đội ngũ DeFi đều nên thoát khỏi hạn chế của tư duy thuần kỹ thuật, thực sự hình thành ý thức về rủi ro an toàn của một "kỹ sư tài chính".
Chuyên sâu báo cáo Web3Bài viết: Haotian
Sau khi đọc xong báo cáo "tái hiện an ninh" về vụ tấn công hacker của @CetusProtocol, bạn sẽ nhận thấy một hiện tượng "đáng suy ngẫm": các chi tiết kỹ thuật được tiết lộ khá minh bạch, phản ứng khẩn cấp cũng đạt tiêu chuẩn sách giáo khoa, nhưng lại né tránh câu hỏi then chốt nhất – "Tại sao lại bị hack?"
Báo cáo dùng phần lớn dung lượng để giải thích lỗi kiểm tra hàm `checked_shlw` trong thư viện `integer-mate` (phải là ≤2^192 nhưng thực tế là ≤2^256), và định tính điều này là "hiểu lầm ngữ nghĩa". Dù lập luận này đúng về mặt kỹ thuật, nhưng đã khéo léo chuyển trọng tâm sang trách nhiệm bên ngoài, như thể Cetus cũng chỉ là nạn nhân vô tội trước lỗi kỹ thuật này.
Vấn đề đặt ra là, nếu `integer-mate` là một thư viện toán học mã nguồn mở và được sử dụng rộng rãi, thì tại sao chỉ riêng bạn lại xảy ra lỗi phi lý đến mức 1 token có thể đổi lấy lượng thanh khoản khổng lồ?
Phân tích đường đi của cuộc tấn công cho thấy hacker muốn thực hiện cuộc tấn công hoàn hảo phải đồng thời thỏa mãn bốn điều kiện: kiểm tra tràn số sai, phép dịch bit lớn, quy tắc làm tròn lên, và thiếu xác minh hợp lý về mặt kinh tế.
Cetus lại "lơ là" ở từng điều kiện kích hoạt này, ví dụ: chấp nhận đầu vào người dùng là những con số khổng lồ như 2^200, sử dụng phép dịch bit cực kỳ nguy hiểm, hoàn toàn tin tưởng cơ chế kiểm tra của thư viện bên ngoài, và nghiêm trọng nhất là – khi hệ thống tính ra kết quả phi lý kiểu "1 token đổi lấy phần thưởng khổng lồ", lại không hề có bất kỳ kiểm tra nào dựa trên kiến thức tài chính thông thường mà vẫn thực thi ngay lập tức.
Vì vậy, những điểm Cetus thực sự cần suy ngẫm là:
1) Tại sao lại sử dụng thư viện bên ngoài phổ quát mà không thực hiện kiểm thử an toàn? Dù thư viện `integer-mate` có đặc điểm mã nguồn mở, phổ biến và được dùng rộng rãi, Cetus dùng nó để quản lý tài sản trị giá hàng trăm triệu USD mà lại không hiểu rõ giới hạn an toàn của thư viện này, cũng không cân nhắc phương án thay thế nếu thư viện gặp sự cố. Rõ ràng, Cetus thiếu ý thức cơ bản về bảo vệ chuỗi cung ứng;
2) Tại sao lại cho phép nhập các con số khổng lồ mà không thiết lập giới hạn? Dù các giao thức DeFi nên hướng tới phi tập trung, nhưng một hệ thống tài chính trưởng thành càng mở càng cần ranh giới rõ ràng.
Khi hệ thống cho phép nhập các con số khổng lồ do hacker tạo ra, đội ngũ rõ ràng chưa từng đặt câu hỏi: nhu cầu thanh khoản như vậy có hợp lý không? Ngay cả quỹ phòng hộ lớn nhất thế giới cũng không thể cần đến lượng thanh khoản quá mức như vậy. Rõ ràng, đội ngũ Cetus thiếu nhân sự quản lý rủi ro có trực giác tài chính;
3) Tại sao trải qua nhiều vòng kiểm toán an toàn mà vẫn không phát hiện vấn đề từ trước? Câu nói này vô tình phơi bày một sai lầm nhận thức chết người: các dự án coi việc kiểm toán an toàn là cách chuyển giao trách nhiệm, xem kiểm toán như tấm vé miễn trừ trách nhiệm. Nhưng thực tế khắc nghiệt: kỹ sư kiểm toán giỏi tìm ra lỗi mã nguồn, nhưng ai lại nghĩ đến việc kiểm tra khi hệ thống tính ra tỷ lệ trao đổi phi lý đến mức hoang đường?
Việc xác minh logic nằm giữa ranh giới toán học, mật mã học và kinh tế học chính là điểm mù lớn nhất trong an toàn DeFi hiện đại. Công ty kiểm toán sẽ nói "đây là lỗi thiết kế mô hình kinh tế, không phải lỗi logic mã nguồn"; đội ngũ dự án thì phàn nàn "kiểm toán không phát hiện vấn đề"; còn người dùng chỉ biết tiền của họ đã mất!
Bạn thấy đấy, cuối cùng điều này phơi bày điểm yếu an toàn hệ thống trong ngành DeFi: các đội ngũ chỉ có nền tảng kỹ thuật thiếu trầm trọng "trực giác rủi ro tài chính" cơ bản.
Và theo báo cáo của Cetus, đội ngũ rõ ràng chưa thực sự tự vấn sâu sắc.
Thay vì chỉ tập trung vào những thiếu sót kỹ thuật trong vụ tấn công lần này, tôi cho rằng kể từ Cetus, tất cả các đội ngũ DeFi đều nên phá vỡ giới hạn tư duy thuần kỹ thuật, thật sự nuôi dưỡng ý thức an toàn kiểu "kỹ sư tài chính".
Ví dụ: đưa chuyên gia kiểm soát rủi ro tài chính vào, lấp đầy khoảng trống kiến thức cho đội kỹ thuật; thiết lập cơ chế kiểm toán đa bên, không chỉ kiểm tra mã nguồn mà cả mô hình kinh tế cũng cần được kiểm toán; rèn luyện "trực giác tài chính", mô phỏng các kịch bản tấn công và biện pháp đối phó tương ứng, luôn nhạy bén với các thao tác bất thường, v.v.
Điều này khiến tôi nhớ đến kinh nghiệm làm việc trước đây tại các công ty an toàn, cũng như trao đổi với các chuyên gia an toàn hàng đầu ngành @evilcos, @chiachih_wu, @yajinzhou, @mikelee205, đều có chung nhận thức:
Khi ngành ngày càng trưởng thành, các lỗi kỹ thuật ở tầng mã nguồn sẽ dần giảm, còn thách thức lớn nhất lại nằm ở các "lỗi nhận thức" trong logic nghiệp vụ – nơi ranh giới mờ nhạt và trách nhiệm không rõ ràng.
Công ty kiểm toán chỉ đảm bảo mã nguồn không có lỗi, nhưng để đạt được "logic có ranh giới", đòi hỏi đội ngũ dự án phải hiểu sâu bản chất nghiệp vụ và có khả năng kiểm soát ranh giới.
Tương lai của DeFi thuộc về những đội ngũ vừa giỏi kỹ thuật mã nguồn, vừa thấu hiểu sâu sắc logic nghiệp vụ!
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
Haotian | CryptoInsight
