Tối qua tôi đã nghiên cứu mã nguồn của cetus gặp vấn đề, điều đầu tiên khiến tôi rất nghi ngờ là tại sao hàm get_delta_b lại chuyển đổi u256 thành u64, dẫn đến vấn đề cắt giảm độ chính xác. Tôi đã hỏi AI, cetus rất có khả năng đã chuyển toàn bộ công thức của uniswap v3 sang, vì uni sử dụng số cố định nên cần chuyển đổi thành số thập phân nhưng quá trình này không được suy nghĩ kỹ về tính an toàn, dẫn đến việc thực hiện chuyển đổi. Đây thuộc về logic nghiệp vụ ở tầng thuật toán, rất khó phát hiện trong quá trình kiểm toán mã nguồn, trừ khi tổ chức kiểm toán cũng có các nhà nghiên cứu quen thuộc cả thuật toán và mã nguồn. Dưới đây là phân tích của AI về lý do tại sao mã nguồn được viết như vậy: Dựa trên phân tích của tôi về thư viện mã nguồn, tôi hiện có thể giải thích tại sao tác giả chọn cách thực hiện hàm get_delta_b như vậy và các lý do có thể: Tối ưu hóa hiệu suất: Xử lý trực tiếp loại u256 bằng cách sử dụng bitmask. Điều này rất có thể nhằm cải thiện hiệu suất và giảm chi phí tính toán. Trong các ứng dụng DeFi, đặc biệt là trong các tình huống giao dịch tần suất cao, hiệu suất là rất quan trọng. Tiết kiệm phí Gas: Các thao tác trên blockchain Sui yêu cầu trả phí Gas, các thao tác phức tạp hơn sẽ tiêu tốn nhiều Gas hơn. Việc đơn giản hóa các phép toán toán học có thể giảm chi phí giao dịch, đặc biệt là đối với các hàm cốt lõi của AMM được sử dụng thường xuyên. Giảm phụ thuộc: Hàm module hiện tại giảm bớt việc gọi các hàm này, có thể nhằm giảm sự phụ thuộc vào thư viện bên ngoài hoặc tránh các vấn đề của một số hàm bên ngoài. Di chuyển từ Solidity sang Move: Từ phong cách mã nguồn, điều này có thể là việc di chuyển mã từ ngôn ngữ Solidity của Ethereum sang ngôn ngữ Move của Sui. Việc sử dụng bitmask và thao tác bit rất phổ biến trong Solidity, đặc biệt là trong các triển khai AMM như Uniswap V3. Xử lý toán học số cố định: Kết quả 256 bit được tạo ra cần được xử lý đúng cách, việc dịch chuyển 64 bit sang phải là phương pháp phổ biến để lấy vị trí dấu thập phân chính xác. Toán học số cố định thường được sử dụng trong AMM để xử lý các giá trị nhỏ. Các vấn đề tiềm ẩn Tuy nhiên, cách thực hiện này đã đưa ra một số vấn đề: Khả năng đọc mã kém: Việc sử dụng bitmask và thao tác dịch chuyển bit cứng khiến mã khó hiểu và kiểm toán. Thiếu kiểm tra biên đầy đủ: Các thao tác bit và chuyển đổi loại thiếu kiểm tra biên toàn diện, có thể dẫn đến hành vi không mong muốn trong các trường hợp cực đoan. Mã chú thích và mã thực hiện cùng tồn tại: Việc giữ lại phiên bản cũ của mã chú thích cho thấy mã có thể đang trong trạng thái chuyển tiếp hoặc chưa được kiểm tra đầy đủ, điều này rất nguy hiểm đối với mã nguồn xử lý tài sản tài chính. Rủi ro tràn số nguyên: Khi xử lý các giá trị lớn, thao tác bit và chuyển đổi có thể dẫn đến tràn số nguyên, trong khi cách thực hiện đơn giản có thể thiếu các cơ chế bảo vệ đầy đủ. Tóm lại Lý do chính khiến tác giả thực hiện đoạn mã này rất có thể là để tối ưu hóa hiệu suất và giảm chi phí Gas, đồng thời xử lý các phép toán số cố định trong AMM. Tuy nhiên, sự tối ưu hóa này đã đánh đổi bằng việc giảm tính an toàn và khả năng đọc mã, có thể cung cấp lỗ hổng cho kẻ tấn công, như sự kiện cetus bị đánh cắp mà bạn đã cung cấp. Trong các dự án DeFi, tính an toàn nên luôn được ưu tiên hơn tối ưu hóa hiệu suất, đặc biệt là đối với các chức năng cốt lõi xử lý tài sản của người dùng. Cách làm tốt hơn là sử dụng các hàm thư viện đã được xác minh, tăng cường kiểm tra biên toàn diện và thực hiện kiểm toán an toàn đầy đủ.